From Vehicle Groups to Calendar: Evolving Fleet Management at the Dealership
Background
With changing consumer shopping habits around purchasing vehicles, dealerships are looking for ways to diversify what they can offer to customers, and many are looking into adding rental fleets alongside their courtesy vehicle fleets. In 2020, Dealerware began working toward building the foundation of features needed to enable dealerships to set up and manage rental fleets. While managing a rental fleet is similar in many ways to managing a fleet of courtesy vehicles, rental brings many new complexities, including scheduling, vehicle availability, dynamic pricing, and more. Starting in 2020, I began work at Dealerware on the Vehicle Groups feature, the first step in creating a software platform that could handle the complexities of both loaner and rental fleet management.
I worked on the evolution of this feature from Vehicle Groups through Calendar as lead designer, typically working with a team of about 4-7 engineers, a product manager, a scrum master, and a QA engineer.
First Steps: Vehicle Groups
The current view of Vehicle Groups in Dealerware web. Each group allows a dealership to set specific prices, tax settings, credit card holds, and more.
The Vehicle Groups feature is intended to allow dealerships to customize different settings and prices for their fleets (rather than a single set of settings for the entire fleet). Introducing this feature was essential to enabling Dealerware to become a platform for dealerships to manage not only their loaner vehicle fleets, but rental fleets as well. Vehicle Groups was especially complex given issues around migrating parts of the Dealerware web platform from Angular to React, as well as changing fundamental structures around how fleets were attached to dealership locations that had been in place for several years.
Later, as more users adopted Vehicle Groups and more settings were added to the groups, the team realized that ultimately, Vehicle Groups would not be the customization solution dealerships needed, but it provided the starting ground we needed to move forward. Dealerships would need the ability to swap vehicle usage between courtesy and rental, while also making sure that the appropriate contracts and insurance were used depending on the use case.
Introducing Availability
Once the MVP of Vehicle Groups was released, my team turned our attention to the fast-follow we knew would be critical to making Dealerware the future platform for managing a rental fleet: availability. This meant enabling dealerships to be able to see in real time the status of their loaner and rental vehicles, and whether they were available to rent, rented, in maintenance, and other statuses. Availability would also mean dealers would be able to avoid problems like double-booking vehicles, or coming up short on vehicles at critical or busy times. To get things rolling, I worked with my product manager to create two user journeys, one for the dealership/Dealerware user, and one for the dealership customer, or driver.
User journey mapping: dealership customer (referred to as a “driver” by Dealerware)
User journey mapping: Dealerware customer (dealership employee)
Next, the team worked to introduce the first availability indicators ever in Dealerware in the New Reservation flow. This is where users would go to create reservations and contracts which their own customers would sign, receive insurance information, and connect their relevant information such as insurance and driver’s license. This proved to be a far more complex endeavor than the simple form that came to be the first iteration of availability, as engineering and design had to work together to figure out the complicated logic determining when cars were available and when they were booked, something Dealerware had never tackled before.
Default form when a user starts to create a new reservation.
Availability is displayed to the user through the selection of dates and times. Overbooking was allowed as some dealerships did want this ability, and if overbooking occurred there were several points users were warned of this. A later introduction of an overbooking setting at the dealership location level was planned for the future.
Once a reservation or contract had been created, users had the option to go into reservations/contracts to view the details as well as make edits.
Availability indicators were later added to the editing window for making changes to contracts and reservations.
Calendar View V1
Once basic availability was established and released, it was clear that while it functioned, it was not the best possible experience for users to get an overhead view of what was happening with their vehicles. There were basic KPIs around utilization available to users, but these did not provide the bird’s eye view that the average service manager needed to get customers in vehicles and out the door. This led us to brainstorming through the best ways to not only display availability in the overall fleet, but to question and rethink the structure of vehicle groups and availability within Dealerware entirely. Eventually, the team settled on a calendar view to not only view fleet status, but to create, manage and edit contracts, similar to how Google Cal manages and creates meetings.
Wireframe concept for Calendar View. Originally, the feature was dubbed “Flex Fleets” to acknowledge that many dealerships would want to use their vehicle fleets as both loaner and rental fleets. This wireframe shows rollover options meant to reveal information that needed to be readily accessible, but would have contributed to overall page clutter if displayed on the page itself. The key at the top denoting contract statuses was also meant to be used as a filter function, as many dealers would want to be able to filter by status to see what contracts needed the most attention.
The engineering team settled on Mobiscroll as the React plugin to build out Calendar, which enabled us to move quickly and avoid manually constructing a large, complex calendar component. However, we did have to fully design how the calendar would look, and to a larger extent, behave when customers created contracts, reassigned them between vehicles, and edited the contracts. We also had to think through how contracts that did not yet have vehicles assigned would display.
One major challenge my team had to figure out was defining the rules for a contract status changed based on how and where it was dragged or edited on the Calendar. The editable nature of the Calendar meant that the changing contract statuses had to become a little more flexible in how and when they changed, but also the Calendar had to work with the existing structure already in place for contract statuses.
Eventually, the first iteration of calendar made its way to production. Some compromises had to be made from the original wireframe, such as moving the status key/filtering component inside a dropdown, and contracts having to be made via the “add contract” button rather than dragging to create a contract, though this was scheduled as a fast follow once the MVP was released.
Default view for the Calendar page. Having contracts appear in a calendar or timeline view eliminated the need for cumbersome overbooking indicators in the original availability designs. This also meant overbooking was visually immediately identifiable, and did not require moving through steps to see when dealerships were running low on vehicles.
Editing an existing contract in Calendar view.
User Adoption
The release of Calendar was well received, with nearly 72% of active users adopting Calendar in the first month. Calendar is on track to become a robust and central feature of Dealerware in the months and years to come.
