D2d Version 1 2 Spec Clean

D2D Version 1.2 Specification Nov, 17, 2008 - document version 1.0

Introduction The functionality envisioned in this document can be bundled into smaller functional groups that may be implemented and released in individual releases, or gathered together in one large release. Some of these bundles build on each other, and other bundles can be developed and implemented somewhat independently of the rest of the functionality in this document. Visual Standards - data lists • All listing screens should be sortable by clicking on the heading of each column • All heading rows should have the same background and foreground pallette (e.g. dark blue background, and white foreground) • All Listing screens should have the ability to select the number of records to view at a time (ideally in a dropdown box) this selector should be in the same place relative to the table for all lists • If listings can not be housed completely in a full list with a scroll bar, then there should be a visual indicator of the number of visible records and the total (e.g. "Vehicles 11-20 of 134"). This index indicator should be in the same place relative to the table in all lists. • If a listing is not scrollable with a scroll bar, then there should be a list navigation capability (e.g. << prev 1 2 3 4 5 next >> where clicking on << takes the user to the previous N pages, >> the next N pages (in this case the next 5 pages 6 -10, "prev" the previous page, "next" the next page, and any of the numerals will take the user to that specific page). Note: this feature is not shown in the wireframes, but should be implemented in the site. • Actions that can be performed on a list should be accessible through a common visual menuing method (the prototype screens use a drop down box) that appears in the same place relative to the table in each list • All listings should have a column (either the first or last, but consistent for all lists) that is check boxes to allow for bulk actions to be performed on the list. (because it was difficult to embed checkboxes in tables in the wireframe, checkboxes do not appear in all tables in the wireframes, although I have tried to leave a column in each table for this purpose)

I have tried to adhere to a common set of standards in the wireframes. These may not be the best way visually or practically to lay out these screens, so feel free to show me any options that you think work better.

1 Vestibulum dignissim viverra erat.

Automated Upload Process Overview The primary objective of version 1.2 is to schedule and automate the uploading of vehicles to our advertising outlets (autotrader, cars.com, google, and craigslist (if it is possible to automate craigslist)). To do this we will be need to implement a means of attaching a vehicle to an office. Each office will be 'responsible' for cars in a defined geographic area (in this release office geography will be defined by zip codes). Such geographic identification will allow us to assign vehicles in the Baltimore area to the Baltimore office; and to assign an automated upload for that office to our Baltimore Sun Cars.com account and our other, Northern Virginia office will upload its vehicles to the Washington Post Cars.com account. Automated uploading of vehicles depends on being able to assign vehicles to D2D "offices". Each office can have a unique combination of advertising sites, while one advertising site can support several offices. For instance, vehicles in the Washington DC office advertise vehicle on a Cars.com/Washington Post account, while vehicles in the Baltimore office get published to a Cars.com/Baltimore Sun account. At the same time both offices share an Autotrader account. This means that for automated uploading to work, the system must be able to assign vehicles to offices either manually, or in an automated way. For now we plan to assign office geographic territory based on zip codes.

Zip Code Management: The wireframe for this subsystem is included in the protoshare site Version 1.2/Admin/Admin Options/Offices/Zip Codes. From this screen an admin user can: Add a new zip code record, update an existing zip code record, delete an existing zip code record, remove assignment of one or more zips to an office. A zip code can only be assigned on one office at any given time. The system will use the zip codes of an office to assign vehicles to offices when the vehicle is registered. The seller's zip code is used to assign a vehicle to an office.

Use Cases: Add new zip code(s): An admin user should be able to add one or more new zip codes to the database by specifying unique 5-digit zip codes and the state, city and county. If the zip code entered by the user already exists in the database, then the user should be notified and not allowed to insert the new record. The entry field for the zip code should allow for entry of multiple zip codes, making it easier to enter large numbers of zip codes when new offices are created.

1 Vestibulum dignissim viverra erat.

Update an existing zip: We may need to update the state, city, and county fields for existing records. This may be necessary as new zip codes are added. Because zip code is the only unique field the only validation required for modification is that the state field must have a value of one of the 51 state (50 states plus DC), and city and county must be populated. If the user changes values in the screen and chooses not to update the database, a cancel option should exist to reset the original values in the screen. The user can also change the office assignment of an individual zip code record from this screen. The value of the office assigned should be none or one of the existing D2D offices in the database. Delete one or more existing zip code records: We may also need to delete one or more zip code records. The screen specified in protoshare anticipates deleting a single record from within the Zip Code Detail panel, or deleting several zip codes at once from the zip code list. The system to should prompt the user to confirm the deletion with a message that says something like "Delete (XX) zip codes?" the default option in the confirmation message should be "no". Remove assignment of one or more zips to an office: From the zip code list, a user should be able to selecte one or more zip codes and set the office assignment to null (no office assigned). Again a confirmaiton message shold be displayed to confirm the action before it is committed to the database. More often zips will be reassigned from one office to another through the Office Detail Screen (described in another section)

Zip Codes Screen Description: General: This screen is a relatively simple detail and list presentation of the zip codes in the database. The data presented in the top detail panel allows the user to edit the information for a specific record. The list panel has the ability to sort the list by any of the columns by simply clicking on the column heading. I am not sure whether it is easier to do a scrolling list, or to do a list that shows "n records of nn" with a "prev | next" option. From a users perspective a scrolling list would be most useful if it does not slow down screen load or update times.

Screen Interactions: Initial State: When this screen is first loaded the zip list should be sorted by Office (with nulls at the bottom of the sort), and the detail panel should show the first record in the list. The Office Assigned drop down list should be populated with all the offices in the database and an entry "(no office assigned)" for records with no office.

1 Vestibulum dignissim viverra erat.

Detail Panel: The data should be presented in updatable fields with the exception of the "Manager" data which is just shown for information purposes. If there is no office assigned for the current zip then the Office Assigned field should read "(no office assigned)", and the Manager information should be empty. Data in the State drop down box should include all the unique states in the zip data table with "--" being the default value representing a null value in this field. Similarly the Office assigned drop down box should be populated with the names of all the offices in the office table and "(no office assigned)" for null values. The data displayed in this panel can be changed by clicking on any row in the zip code list below. The default value is the first visible row in the zip code list (if this is possible). The Zip Code(s): field should allow users to enter one or more zip code values (one 5 digit zip code per line). This will allow multiple zip codes to be added to the database at one time, all zips in the input box will be added to the database with the city, county, state, and office assigned values entered in teh detail panel. Ideally the "Save" button only commits additions and changes to the data base if information for the current record(s) has been changed. Cancel will reset the values of the current record to the current values in the database for that record. When the office value is changed, it would be nice (but not mandatory), if the manager information changed even if the "Save" button hasn't been pressed. The Actions drop down box allows two actions on individual records: Create New Zip Record - changes the "Save" button to "Insert", and empties the values in all of the input fields (zip, city, county, state, and office). New record(s) will be inserted into the database when the user clicks on "Insert" and the Zip Code is unique, and the State, City, and County fields are populated (the default value of the office field will be null--"(no office assigned)". If "Insert" is pressed and the necessary data is not present, a message should be displayed that identifies the missing or incorrect data. If the user clicks "Cancel", then the data is abandoned, data from the first record in the visible zip code list is loaded into the detail panel, and the "Insert" button is changed back to "Save". Delete Current Zip Record - Changes the "Save" button to "Delete" and displays text next to it that says "Click to confirm delete -->". If the user clicks "Delete" the record is deleted, data from the first visible reord in the zip code list is loaded into the detail panel, and "Delete" is changed back to "Save". If the user clicks "Cancel", then data from the first visible reord in the zip code list is loaded into the detail panel, and "Delete" is changed back to "Save".

1 Vestibulum dignissim viverra erat.

Zip Code List Panel: This panel contains a list presentation of all the zip code records in the database. Each item row in the list has a checkbox (not shown in protoshare, but intended to be in the first column). The list is sortable by clicking on any column. The first click on the column sorts ascending and the second sorts descending. Bulk Actions - from the "Bulk Actions" drop down users can select (check the boxes for) all zips currently visible in the list, de-select (uncheck) all zips in the list, select (check) all zips in the list that are currently assigned to an office, or select all zips that are currently have no office assigned. Un-assign Selected: if the user choses this action all zips currently checked in the zip code list will be have their office set to null. The system will prompt the user with a confirmation message that asks if the user really wishes to remove the office assignment for (N) zip codes; and the user will have the chance to cancel or confirm the deletions. If the current zip displayed in the detail panel is affected, then the detail panel should be updated to reflect the changes. Delete Selected: if the user chooses this action, all zips currently checked in the zip code list will be deleted. The system will prompt the user to confirm that N zip codes records will be delete, and the user will have the chance to cancel or confirm the deletions. If the zip displayed in the detail panel is deleted, the detail panel will be set to show the values of the first visible record in the zip list after the deletion has been committed to the database and the list is updated.

Assign Vehicles to Offices There are two ways that vehicles can get assigned to an office. The first is through registration based on seller's zip code. During the registration process, when the seller enters the seller's zip code (or the seller identifies his userid that should have a zip code stored in the account), the system should use the zip code to look up the office to assign the vehicle to. If there is no office assigned to the seller's zip code then the vehicle is not assigned to any office; and a manager will have to assign the vehicle manually later. If the zip code for the vehicle is not assigned to an office, then the notification e-mail that is sent to D2D upon vehicle registration should have in the Subject of the message "Office Assignment Needed" to alert manager that this vehicle needs to be assigned to an office. If the zip is not present in data base, the system should create a new zip code record with the city, state and zip from the seller's address. [Note: Another way to handle unassigned vehicles would be to create a default office that all vehicles are assigned to if the seller's zip is not owned by another office, this was we could configure the e-mail notifications for these vehicles as well. Thoughts?] If there is an office identified with the seller's zip the vehicle is assigned to that office, and upon completion of registration the "newly registered vehicle" e-mail is sent to the office manager's email address as well as the currently specified recipients of that list (if I remember correctly this is the seller, and [email protected]).

1 Vestibulum dignissim viverra erat.

The second means of assigning a vehicle to an office is through the admin screens. When a vehicle is assigned to an office for the first time, or when the vehicle is re-assigned to a new office (i.e. when the office assigned is changed from one active office to another), the system to should send a "new vehicle registered" e-mail to the designated recipients for the office newly assigned to the vehicle. Note that for a vehicle to be assigned by an administrator, it must already be registered, and as a result the seller already has received the registration e-mail and does not need to receive the e-mail again if his/her vehicle is simply being newly assigned or reassigned to an office.

Office Management The wireframe for this subsystem is included in the protoshare site Version 1.2/Admin/Admin Option/Offices and its children. There is a main Offices list screen that provides access to managing zip codes and managing individual office information. Offices will be the entities used to divide vehicles into geographic territories that are managed and serviced by personnel focused on that territory. Given that part of our service may be to drive to a seller's home to take pictures of the vehicle, and certainly we will want to have D2D personnel available to do test drives for vehicles, it is logical that we will divide the inventory and market(s) into geographic regions that can be managed somewhat independently, but will share access to the D2D system.

Use Cases: Add a new Office: An admin user should be able to add a new office. This includes specifying an office name, address, main phone number, and office manager; and identifying the geographic area covered by this office. Once an office is created the admin user can assign advertising sites for the office. Office names should be unique. Office managers must be existing users in the D2D database. Change the Manager of an Office: From time to time the manager assigned to an office will need to change. Managers can be assigned to one or more offices at a time. Right now, there will be a single manager for any given office. Create/Change the geographic area of an office: Much of our advertising both to consumers and vehicle advertising to buyers is local in addition or service delivery is also very local, as a result offices will have an identifiable geographic coverage. The system should allow us to identify the geographic coverage of an office. Initially this geography will be defined by zip codes covered. In the future this may have to become much more granular (zip+4, or some other smaller area designations). Admin users should be able to define the area served by an office by specifying (adding or removing) the zip codes served by the office. Set-up and manage advertising sites used by an office: Many of our vehicle advertising partners allow their buyers to narrow searches by zip code, as a result they require us to specify a

1 Vestibulum dignissim viverra erat.

zip code for our offices. As a result we will need to open numerous vehicle advertising accounts to show where our vehicles are geographically. For instance, we have two cars.com accounts one for our office in Virginia, and one for our office in Baltimore, MD. As a result, when we set up an office in Baltimore, vehicles assigned to that office will be advertised in the Baltimore Cars.com account, and vehicles in Virginia will be advertised in the Washington, DC Cars.com account. The office administration screen should allow us to specify which advertising sites/accounts will be used to advertise the vehicles assigned to that office. Deactivate an office: D2D managers may want to de-activate an office if we abandon a territory, or move and office from one geographic location to another. Because vehicles may be assigned to the office that is to be deactivated, the manager de-activating the office will have to decide whether to leave the vehicles assigned to the now inactive office, reassign all vehicle to another office, or leave all vehicles unassigned to be assigned to offices later. View Inventory of an Office: Managers and field personnel will want to see all the vehicles currently in the office's inventory. From the list of vehicles, users may want to access and update information on a specific car. Assign e-mail notifications for office: The office manager may want to configure who will receive the e-mail notifications for newly registered vehicles, new vehicle appointment requests, and vehicle inquiries for the office. There may be one or more office recipients on each of these e-mail notices.

Screen Descriptions General: The screens used to manage offices are a little more complex than the zip code screen(s). There are two main office screens. The first is a simple office list that allows a limited set of bulk functions. Clicking on any individual row in the office list takes the user to the detail screen for that office. This detail view is the second major office screen. From the detail screen a user can change and manage much of the activities for an office. The spec includes a tabbed panel in this screen that attempts to isolated major areas of activity for the office: inventory management, advertising sight management, zip/geography management, and misc. admin. These screens will be described in more detail below.

Offices List Screen This screen is prototyped in protoshare at Version 1.2/Admin/Admin Options/Offices Screen Interactions

When the screen is first opened the list should show all offices currently identified in the database, sorted in office ID order. The table can be sorted by clicking on any of the headings on the table.

1 Vestibulum dignissim viverra erat.

Clicking on any row in the table will take the user to the Office Details screent (shown in the wireframes in Version 1.2/Admin/Admin Options/Offices/Washington DC). --- Actions ---: Create an Office...: Selecting this action from the action menu will create an new office record and take the user to the office detail screen (wireframe prototype "Offices/Washington DC". The office detail screen used to insert an new office allows the user to edit the Office Name (in the light blue title bar of the wireframe), and changes the "Save" to "Create", and the "Cancel" button will bring the user back to the Office List. The only field required to create an office is the Office Name, a default value of "New Office XXXX" where "XXXX" is the office ID can be loaded into the title bar when the new record is created. Users can add any additional information in the office detail panel (address and phone number), and assign a manager before clicking on "Create". No other functions should be enabled before the office is created. Manage Zip Codes: Selecting this action will take the user to the Zip Codes administration screen (/Admin Options/Offices/Zip Codes in the protoshare hierarchy). --- Selections ---: Select All: Check the box for all visible records Select None: Uncheck the box for all visible records Invert Selection: for each row if the box is checked, then uncheck it. If the box is unchecked then check it --- Bulk Actions ---: Mark Selected Inactive: Make selected (checked) offices inactive. Prompt user whether to move inventory to a new office, leave inventory in the inactive office, or move inventory to unassigned, with an option to "Cancel" the action or "Deactivate".

Office Detail Screen This screen is made up of several panels each displaying information and allowing actions on information related to the selected office. These panels are discussed in more detail below.

Office Information Panel This is the top panel of the screen, and is visisble when each of the other panels is displayed. This panel displays (and allows the user to edit) the basic information about the office: address, main phone number, and the manager. The manager information is read from the user database and displayed in this screen, but the manager data (phone and e-mail address in not editable from this screen). This panel include the office title bar that includes the office ID, office name and the "Active" checkbox. Screen interactions The fields are initially populated with data from the database for the selected office. The office title bar displays the office ID and the office name, and a check box showing whether the office is active or inactive. If the office is inactive then new vehicles are no longer assigned to the office,

1 Vestibulum dignissim viverra erat.

and automatic publishing of inventory to the advertising sites is not done for this inventory assigned to this office. Active checkbox: If the box is checked the office's status is set to active and new inventory can be assigned to the office based on zip codes or manually. If a user unchecks the box, then the system should show a prompt that asks what should be done with inventory currently assigned to the office "leave it assigned to the office, reassign it to an existing office (showing a dropdown box to select the new office assigned), or mark inventory unassigned". The default option is to leave the inventory assigned to the office. The user from this prompt can either "Cancel" or "Deactivate". Change link: This link below the manager information display will open a dropdown box that allows the user to select from the user table a new manager for the office. If a new manager is selected the information for the newly selected manager is now displayed in this panel (even though the manager change is not commited until the user clicks the Save button). Remove link: This link below the manager information display will remove set the current manager to null, although the change isn't permanent until the user clicks the Save button. Cancel Button: If the user clicks on the cancel button the data showing in the panel is reset to what is currently in the database including changes to the manager assigned; but does not undo changes to the Active check box. Save Button: If the user clicks on the save button, any data that has been edited in any of the data fields (Note the active check box change is committed to the data base as described above, and is unaffected by the Save button) will be saved to the database.

Inventory Panel This panel shows a listing of all vehicles currently assigned to this office, using the same table format as in the Admin/Vehicles screen. We may want to add some basic filter options to this list, but for now the list is only sortable by each of the columns. Clicking on any row in the inventory listing will take the user to the vehicle details screen specified in ...Admin/Vehicles/Vehicle Detials wireframe(s). From the Actions menu a user can: Download Inventory: Download a .csv file of the inventory for the selected office. The inventory is all vehicles currently assigned to the office, which will include vehicles of all status values. --- Selections ---: Select All: Check the box for all visible records Select None: Uncheck the box for all visible records Invert Selection: for each row if the box is checked, then uncheck it. If the box is unchecked then check it --- Bulk Actions ---: Mark Selected as Sold: change the status of the selected vehicles to "Sold" Mark Selected as Inactive: change the status of the selectd vehicles to "Inactive"

1 Vestibulum dignissim viverra erat.

Ad Sites Panel This panel shows a list of the advertising sites used by this office to advertise its inventory. The ad sites listed in this panel will the the only ad sites that the inventory for this office will be uploaded to. Clicking on any row in the ad site list will take the user to the Ad Service Details screen (.../ Admin/Advertising Outlets/Ad Service Details wireframe). From the Advertising Actions dropdown menu a user can: Add a Publisher: The user will be shown a drop down list of all ad services not currently used by this office, and can "Cancel" or select and "Add" one of the ad services from the dropdown list. If the user selects a service and clicks "Add", this office's vehicles will be included in uploads to the newly added service. If the user clicks "Cancel", then there is no change to the services used by this office --- Selections ---: Select All: Check the box for all visible records Select None: Uncheck the box for all visible records Invert Selection: for each row if the box is checked, then uncheck it. If the box is unchecked then check it --- Bulk Actions ---: Remove Selected: Will break the link between this office and the ad sites checked in the list.

Area Assignment Panel When first opened this panel simply shows a list of the zip codes currently assigned to this office (the top half of the panel shown in the .../Admin Options/Offices/Washington DC 1 wireframe). The bottom half of the panel shown in the wireframe (i.e. the national zip code list panel) only becomes visible if the user clicks on the Add Zip Code(s).. option from the Area Actions menu. From the Area Actions menu users can: Add Zip Code(s)...: Selecting this action opens the National Zip Code List panel (which can be a replica of the National Zip Code Panel describe in the Zip Code Management section, with the addition of one action in the --- Zip Actions -- menu: Add Selected to [Office Name] where "[Office Name]" is the name of the currently selected office showing in the Office Information Panel). From the National Zip Code List panel users can select new zip codes to add to this office. --- Selections ---: Select All: Check the box for all visible records Select None: Uncheck the box for all visible records Invert Selection: for each row if the box is checked, then uncheck it. If the box is unchecked then check it --- Bulk Actions ---: Remove Selected: Remove the office assignment from the zip codes selected (i.e. checked) in the Area Definition zip code list National Zip Code List sub-panel

1 Vestibulum dignissim viverra erat.

This panel can be a clone of the National Zip Code List panel described in the Zip Code Management section above. The only difference would be that there is a new item in the Zip Actions menu as described above.

Admin Panel This panel displays the e-mail routing assignements for the current office. The user can specify where to route e-mail that are automatically generated by the system. Specifically, the new vehicle registration e-mail, the appointment request e-mail, and any other system generated e-mails. The routing list for each can include multiple recipients. Recipients are specified by entering e-mail address(es) into the text boxes. Multiple e-mail addresses can be specified by separating each with a comma (note: may need to strip out white space because some users will specify as ....gmail.com, mwalker@... instead of ...gmail.com,mwalker@...). There are only three actions allowed from this panel: Save, which will save changed entered into the fields, Cancel, which will reset the values of the fields to what is currently in the database, and Test which will send test emails to the addresses sepcified with the subject line specifying which type of e-mail it is (e.g. the Subject lines could be Test--New Vehicle, Test--Appointment Request, Test--Vehicle Inquiry).

Other Changes Related to Offices At this time the only real impact of offices elsewhere in the system is during registration (described in the Zip Code Management section), vehicle administration (changing the office of a vehicle), and automated uploading, all are described in this document. We may want to add an indicator of office in the myD2D screen for our seller's benefit, but that is not included in this specification.

Ad Site Management The wireframes for ad site management are included in protoshare (Version 1.2/Admin Options/ Advertising Sites and .../Advertising Sites/Ad Site Details wireframes). These records will be created whenever we want to add a new advertsing site account. For autotrader and cars.com we will need to open many accounts to ensure that the vehicles we list are shown on these advertising sites and being the appropriate geographic region (this is because for these sites the location of the vehicle is tied to the location of the autotrader or cars account; thus we will need accounts that are at least regional). The data stored in the ad site records should be useful not only to human users (reminders of account id and passwords, ftp url addresses, etc.), but should also contain information necessary to drive automated batch uploading from D2D to our ad sites (as these automated processes are developed for each advertiser). I have tried to specify all the data I think is necessary, but that does not mean that my specification is necessarily complete. There are two screens specified for ad site management: Advertising Sites, and Ad Site Details.

1 Vestibulum dignissim viverra erat.

Each of them are discussed below. How ad sites are used in the automated upload process is described in the Automated Upload Processing section.

Use Cases Adding an Ad Site: Admin users can create an ad site specifying the type of ad site it is (right now ad site types are limited to Cars.com, Autotrader, Craigs List, and Google). Whether an ad site is uploaded automatically or manually will be determined by the developers, who will have to update the database when new automated upload services have been built and tested. De-activating an Ad Site: Admin users can de-activate an ad site (only active ad sites will automatically upload inventory for offices assigned), or de-activate multiple ad sites Processing Uploads for an Ad Site: For ad sites that have been automated, the system should routinely upload the data and images necessary to advertise all active vehicles for all active offices that are attached/subscribe to the the ad site. Once the upload is complete the system should log any messages generated during the upload, a final status of the upload and the total number of vehicles uploaded for each office. Attaching an Ad Site to an Office: Admin users should be able to add new offices to the subscriber list for a given ad site. Detaching an Ad Site from an Office: Admin users should be able to remove offices from the subscriber list for a given ad site. Manually Running and Ad Site Upload: Thruugh the admin screens, a user should be able to force an automated upload to run immediately (even though it may have run the previous night, or will run the following night as scheduled) forced uploads could be a necessity for newly created offices, or if previous uploads failed. Checking the Status of Ad Site Uploads: Office managers and other admin users should be able to go on the site and check to status of the uploads that have been automated. As much information as it possible on the status and statistics of the uploads should be available through the admin screens

Ad Site Screens Advertising Sites Screen This screen is prototyped in protoshare at Version 1.2/Admin/Admin Options/Advertising Sites Screen Interactions

1 Vestibulum dignissim viverra erat.

When the screen is first opened the list should show all ad sites currently identified in the database, sorted in Account Description order. The table can be sorted by clicking on any of the headings on the table. Clicking on any row in the table will take the user to the Ad Site Details screen (shown in the wireframes in Version 1.2/Admin/Admin Options/Advertising Sites/Ad Site Details). --- Actions ---: Add New Service...: Selecting this action from the action menu will create an new ad site record and take the user to the ad site details screen (wireframe prototype "Advertising Sites/Ad Site Details". The ad site details screen used to insert an new record allows the user to edit the all the ad site information. The new record is create with the ad site description of "New Ad Site", the new record's status is no active, and manual. The ad site detail screen used to insert the new record has a few modifications: the "Save" is changed to "Create", and the "Cancel" button will bring the user back to the Advertising Site List. The only field required to create an ad site is the ad site description, and the ad site type (autotrader, cars.com, etc.). The new ad site description will default to a value of "New Ad Site" and can be loaded into the title bar when the new record is created. Users can add any additional information in the ad site detail panel (url addresses and IDs and passwords) before clicking on "Create". No other functions should be enabled before the ad site is created. --- Selections ---: Select All: Check the box for all visible records Select None: Uncheck the box for all visible records Invert Selection: for each row if the box is checked, then uncheck it. If the box is unchecked then check it --- Bulk Actions ---: De-activate Selected: Change the status of all records checked in the list to inactive (and send an e-mail message to the offices that use this ad site notifying them of the status change) Activate Selected: Change the status of all records checked in the list to active (and send an e-mail message to the offices that use this ad site notifying them of the status change) Delete Selected: Prompt the user to confirm that he/she wishes to delete, and if so, delete the record(s) from the database.

Ad Site Details Screen This screen is made up of several panels each displaying information and allowing actions on information related to the selected ad site. These panels are discussed in more detail below. Ad Site Information Panel This is the top panel of the screen. This panel displays (and allows the user to edit) the basic information about the ad site. This panel includes the ad site title bar that includes the ad site description, and whether the ad site is automated or not ("(automated)" or "(manual)"), and the "Active" checkbox. Screen interactions

1 Vestibulum dignissim viverra erat.

The fields are initially populated with data from the database for the selected ad site. If the screen is opened to insert a new ad site, then the fields are empty with the exception of the Ad Site Description (set to "New Ad Site", the automated/manual flag (set to manual for new records), and the active flag (set to inactive for new records). The ad site title bar displays the ad site description and automation status, and a check box showing whether the ad site is active or inactive. If the ad site is inactive then automated uploading will not happen for this ad site. Active checkbox: If the box is checked the ad site's status is set to active then if the ad site is automated it will be included in automatic uploads. If a user unchecks the box, then the system should set the status to inactive and e-mail the offices that use this ad site to let them know that vehicles will not be uploaded automatically anymore. Uplaod Now Button: this button is enabled (or visible) only if the ad site is active and automated. If the button is enabled and the user clicks on it, the automated upload process is run immediately for that ad site only. Cancel Button: If the user clicks on the cancel button the data showing in the panel is reset to what is currently in the database; but does not undo changes to the Active check box. Save Button: If the user clicks on the save button, any data that has been edited in any of the data fields (Note the active check box change is committed to the data base as described above, and is unaffected by the Save button) will be saved to the database.

Offices Panel This panel shows a listing of all offices currently subscribed to (using) this ad site to publish inventory, using the same table format as in the Admin/Admin Options/Offices screen. Clicking on any row in the office listing will take the user to the office details screen specified in ...Admin/ Admin Options/Offices/Washington DC wireframe(s). From the Actions menu a user can: Add an Office: Should show the user a drop down list of offices not currently subscribed to this ad site, allowing the user to select one (or more if multiselect is possbile) offices and then click "OK" or "Cancel" to attach the selected offices to the current ad site. --- Selections ---: Select All: Check the box for all visible records Select None: Uncheck the box for all visible records Invert Selection: for each row if the box is checked, then uncheck it. If the box is unchecked then check it --- Bulk Actions ---: Unsubscribe Selected Offices: breaks the link between the checked offices in the list and the current ad site. Upload History Panel

1 Vestibulum dignissim viverra erat.

This is an information panel that shows any information that we have on the last several uploads for automated ad sites. The columns specified in the wireframe are the kinds of things I could think to show, and not a hard and fast specification. It would be nice at a minimum to see the time of the last upload, whether it was successful or not, and if not, some way to get to information about why the upload may have failed.

Automated Uploading This section will describe the logic that should drive automated uploads. The details specification of the interfaces used by each service are specified in documentation published by each advertiser (e.g. Autotrader's Dealer FTP Datafeed Setup document). Automated uploading of inventory should be triggered both by a scheduled process that runs each day (probably should be run overnight in the US); or can be triggered by an admin user from the web site, forcing an individual ad site to be uploaded. Currently there are only two automated advertisers that are important: Autotrader, and Cars.com (down the road, we may want to automate uploads to Google Base). The general logic for selecting inventory for each service is the same: Find all Ad Site records in the data base for the give service type (autotrader, or car.com), or if the process has been initiated by clicking "Upload Now" from the Ad Site screen find just the selected Ad Site Record. 2. For all Ad Sites marked active and automated 1. Note the start date and time 2. Find all offices marked active that subscribe to the current ad site record 3. Create the upload file for this instance (date and time) of the upload 4. For each active office 1. Select all vehicles for that office that have a status of "active" 2. Map the data for each vehicle to the fields defined in the upload spec for this ad site 3. Append the data to the file to be uploaded to the site 4. Handle image upload (different process for each site) 5. Once all office are processed, upload the file (and images if necessary) 6. Update data in the database for Ad Site History, with upload start and end date/time, number of records uploaded (for each office and total), status of the uload (success or failure), and location of log file (logged messaged from upload process, if there is one created by our process). 1.

Field Mapping for Data Files

Autotrader Field

Cars.com Field

D2D Data Source

1 Vestibulum dignissim viverra erat.

Dealer ID

Dealer Name Ad Site.AccountID or ID Type

"USED"

Stock Number

Stock Number

Vehicle.ID

Year

Year

Vehicle.Year

Make

Make

Vehicle.Make

Model

Model

Vehicle.Model

Trim

Trim-Style

Vehicle.Trim

Body Type

Body

Vehicle.Body (if populated)

VIN

VIN

Vehilce.VIN

Mileage

Miles

Vehicle.Mileage

Price

Selling Price Vehicle.Asking Price

Exterior Color

Ext Color

Vehicle.Exterior Color

Interior Color

Int Color

Vehicle.Interior Color

Transmission Transmission Vehicle.Transmission (if populated) Image upload handled two different ways (see documentation from autotrader and cars.com)

Image Description

Vehicle Comments

Vehicle.Description + Vehicle.Office.Message Addon

Dealer Added Features

Vehicle.Options[] (comma separated list of all installed options--both factory options and user installed options when that feature is enabled in the web site. User installed options should be first in the list)

Engine Type Engine

Vehicle.Engine (if populated)

Promotion Codes & Discounting We will need the ability to apply discounts to orders (registrations) made by sellers. The idea is that sellers can enter a discount code during registration that will discount the cost of the service at check-out. We can print codes on coupons and/or use them to discount pricing as we test the market's reaction to our pricing. Discount codes can offer either a fixed dollar amount, or a percentage of the order price. A discount code should have a start and end date so that the discount can not be redeemed years from now. Also, we may want to create discounts that have a one-time or limited number of uses. Finally, we may want to have a discount tied to a specific package of services (right now Discounting will require the creation two administration screens: a promo codes listing, and a promo code details screen. In addition, a change to one of the registration screens will be necessary to provide an opportunity for a seller to enter a promo/discount code.

1 Vestibulum dignissim viverra erat.

A wireframe for each of these screens is in protoshare under the Version 1.2 node of the hierarchy. Use Cases

Promotion Codes List Screen This screen is prototyped in protoshare at Version 1.2/Admin/Admin Options/Promotion Codes Screen Interactions

When the screen is first opened the list should show all promotion codes currently identified in the database, sorted in Live Date order. The table can be sorted by clicking on any of the headings on the table. Clicking on any row in the table will take the user to the Promotion Code Details screent (shown in the wireframes in Version 1.2/Admin/Admin Options/Promotion Codes/INTRO2009). The status field can show three values: Inactive - meaning that the code's status is marked inactive. This occurs by manually deactivating the code, or the code has been automatically deactivated because the end date for the code has passed or the max number of redemptions has been met. Active - meaning that the code's status is active AND the start date for the code has passed, but the end date (or number of max redemptions) has not yet been reached. Pending - meaning that the code's status is active AND the start date has not yet passed --- Actions ---: Create New Promo...: Selecting this action from the action menu will create an new promotion code record and take the user to the promo code detail screen (wireframe prototype "Promotion Codes/INTRO2009". The detail screen used to insert an new promo code is identical to the normal detail screen with the exceptions: the "Save" button is changed to "Create", and the "Cancel" button will bring the user back to the Promortion Code List rather than reload in the detail screen. The only field required to create a promotion code record is the Redemption Code field, a default value of "New Promo Code" can be loaded into the Remdemption field by default, and the rest of the field can take the following default values: description, start date, and end date = null, redemption value = 0, the '%' check box is checked, and the packages value is set to "All" . Users can add data to or modify information in the any of these fields before clicking on "Create". --- Selections ---: Select All: Check the box for all visible records Select None: Uncheck the box for all visible records Invert Selection: for each row if the box is checked, then uncheck it. If the box is unchecked then check it --- Bulk Actions ---: Deactivate Selected: Make selected (checked) promotion codes inactive. Delete Selected: Only inactive codes with no redemptions can be deleted. Warn user that deletions can not be done if any code is active or has redemptions. If none of the selected codes is

1 Vestibulum dignissim viverra erat.

active or has redemptions then prompt the user to confirm the deletion(s). Delete the records if the user confirms, do nothing if the user cancels at the warning prompt.

Promotion Code Details Screen (.../Promotion Codes/INTRO2009) This screen displays (and allows the user to edit) the basic information about the selected promotion code. This panel includes the promotion code title bar that includes the Redemption Code for the promotion, and current status of the code ("(Active)", "(Pending)", or "(Inactive)"), and the "Active" checkbox. Screen interactions The fields are initially populated with data from the database for the selected promo code. If the screen is opened to insert a new code (this is initiated from the actions menu in the promotion codes list screen), then the fields are populated with the default values described above. The title bar displays the promo redemption code and status, and a check box showing whether the promo code's status is active or inactive. Inactive or pending codes can not be redeemed by sellers during registration. Some of the fields on this screen may need further explanation Active checkbox: If the box is checked the promo code's status is set to active. This means that redemption code can be used by seller to get discounts IF the code's start date has passed, the end date has not yet passed, and the max number of redemptions has not yet occured. If a user unchecks the box, then the system should set the status to inactive regardless of the start and end date or number of redemptions. Changes to this status are written to the database immediately. Redemption Value and Redemption type radio buttons: A promo code can be redeemed EITHER or a specific dollar discount, OR for a percent discount off the total order. These two fields are one way of making it easy for a user to specify the value and type of the redemption. If the "%" radion button is pressed the number in the Value field must be <= 100. Redemption Value Applies to dropdown box: Each promo code can be used for either both existing packages, only for the premium package, or only for the base packge. We will probably not move to a line item (or menu based) pricing mechanism in the short term, so this should work for now. Max Redemptions: This field governs the maximum number of times a redemption code can be used. I have assumed that zero in this field means unlimited redemptions, but you have a better way for allowing the user to make the redemption max unlimited.

There are only two buttons on this screen: Cancel Button: If the user clicks on the cancel button the data showing in the panel is reset to what is currently in the database; but does not undo changes to the Active check box.

1 Vestibulum dignissim viverra erat.

Save Button: If the user clicks on the save button, any data that has been edited in any of the data fields will be saved to the database.

Promotion Code Redemption Screen (../Promotion Codes/Check Out (step 7) v1.2) Sellers can redeem promotion codes during registration (this is the only way that promotion codes can be redeemed in version 1.2). The wireframe for the check out screen with a promotion code redemption capability is included in protoshare (Version 1.2/Admin/Admin Options/Promotion Codes/Check Out (step 7) v1.2 and .../Check Out (Step 7) v1.2 w discount). This screen is the same as specified in the version 1.1 spec with the addtion of an input field, and a new "Update Price" button. Promo Code Input Field: Seller can enter a promo code in this field. Apply Discount button: This button does nothing if there is no value in the Promo Code Input field. If a Promo code is entered this button causes the screen to reload with the affect of the discount diplayed in the Check Out Summary block. Redemption Logic If a promo code is entered, the a discount is calculated and applied (if the code entered matches a redemption code for a valid, active promotion code record in in the database) when the user clicks either the "Update Price" or the "Create Account and Finish" buttons. If the "Update Price" button is clicked, the page refreshes and the discount is calculated and reflected in the Check Out Summary block. The new Total Charge value is what will be used for the credit card transaction. Somehow the screen must flag that the discount has been applied, so that it is not re-applied when the user clicks the "Create Account and Finish" button. If the "Create Account and Finish" and there is a value in the Promo Code field, the system will first check to see if the code has already been applied to the total value. If so, the check out proceeds as normal. If the code has not already been applie, the system confirms that the code is valid and active, applies the discount to the current total, and proceeds to process the credit card with the discounted price. Once the credit card transaction is successful, the system will increase the number of redemptions for this code by one. If the new value of redemptions is greater than the max redemptions for the code, then the code is set inactive.

1 Vestibulum dignissim viverra erat.

Vehicle Administration Overview The version 1.1 vehicle administration screens are very useful. In version 1.2 we would like to add features that will allow or field staff and central call center staff to share information easily, and to add data that will help us manage closing vehicle sales when a buyer and seller agree on price and terms. In this version we would like to add the following features:

Enhanced Vehicle Data Listing Date and Age

The wireframes for the version 1.2 Vehicle list and details screens show a few new data fields we would like to capture. On the listing screen we would like to see the data the vehicle was first listed with Driveway2Driveway (this should be the date the vehicle as registered and the fee was paid). The listing wireframe also shows an Age column which is simply the number of days the vehicle has been listed (number of days from first listing to today). We would also like to capture the date the vehicle was sold (or marked inactive). In the case were vehicles are sold or inactive, the Age in the listing screen should be the number of days from first listing to the date it sold or was mad inactive. Additional Vehicle Values

The version 1.1 vehicle details screens should be enhanced to add a section to capture and view vehicle values. As shown in the wireframe, the database should maintain fields for the current asking price, floor price, KBB trade-in, and KBB, private party prices as it does today; and add fields for us to capture an estimate of what CarMax or another dealer may have offered the seller for the vehicle. Finally, we should capture the final sale price of the vehicle when the car sells. Each of these prices should have a time assigned to it. For instance the first four prices may be set at registration, but the asking price may change over time as the seller decides to drop the price of the vehicle, we should capture when that price change was set. Also, the KBB values change every week for some vehicles. We should have an ability to re-run the KBB for a vehicle and see what the current values are. If we want should be able to "reset" the KBB trade-in and private party values to current KBB values; or leave the orginal values in place. The layout of these fields will not look like the wireframes, but should be worked into the version 1.1 vehicle detail display screen.

Vehicle Docs Upload and Attach Documents to a Vehicle

In addition to being able to uplaod interior and exterior photos, administration users and sellers should also be able to upload non-public documents (e.g. copies of the vehicle title, loan

1 Vestibulum dignissim viverra erat.

documents, etc). Documents uploaded by sellers should be visible by both administration users and the seller. Documents uploaded by adminstrative users should only be visible to admin users (we may not want to share internal documents with the seller, especially if we have documents from buyers with personal information on them), unless they are marked 'visible to seller'. When a document is uploaded, the system should prompt the user (either seller or admin user) for a brief description of the document. The filename should default to the uploaded file's name. If an admin user is doing the upload, the admin user should be able to click a check box to make the document 'visible to seller'. If the document is visible to seller, then the document should be accessible throught the seller's myD2D page. All documents are visible to admin users. A mock up of the document listing is shown in the Version 1.2/Admin/Vehicles/Vehicle Detail 1 wireframe.

Vehicle Events/Notes Administrative Events and Notes

In order to easily share information between central and field agents, and to maintain a history of all activity related to a vehicle, the system should provide a simple events and notes capabilty (visible only to admin users) as shown in the Version 1.2/Admin/Vehicles/Vehicle Detail 1 wireframe. Events are specific types of activities that happen for each vehicle (Concierge visit, buyer contacts, seller contacts, testdrives, etc). Admin users should be able to create a new event for vehicle by simply picking a event type, and typing a description in the note field. The default date for an event should be the current date and time; although users may want to document events from the past, so should have a way to change the date and time value before saving the event. In addition some events may have documents associated (e.g. test drives will have signed test drive release forms, and may have pictures of the potential buyer and his drivers license). These documents should be uploaded and attached to the event from this screen (with ability to assign 'visible to seller' if necessary--see above). In the future, certain system events (such as vehicle registered, vehicle marked (in)active, and vehicle sold) could automatically populate this list, but this is not necessary in this release.

1 Vestibulum dignissim viverra erat.