Loan Car internal workflows
Context
Cazoo give a loan car to customer’s whose order is delayed, or in for post purchase repairs. Ideally these are from a fleet of company owned courtesy cars, otherwise they pay for a 3rd party rental car.
Multiple 1* Trustpilot reviews mentioned Courtesy Cars, resulted in Analysis of fleet usage, had highlighted problems with customer experience, costs and fleet utilisation. Bad fleet management practices costs the company around £5millon per year in additional 3rd party rental costs.
- Getting a confirmation of a booking could take days to complete internally.
- Cazoo courtesy cars were 'going missing' or being left with customers who no longer needed them.
- Cars were booked and then actually not available on the day.
My initial brief was very vague and I sought to understand why our Customer Service (CS) Agents were having trouble with this process. Then to see how we might improve theirs and our customers experience.
User problems
New Findmypast users didn’t know how to use the site effectively.
User’s either exclusively searched for records or started a family tree. The segmented approach led to frustration.
User research found we had to make it easier for new users to find and use the features on site.
Business problem
Help new users get more value, by personalising their experience and showing them different aspects of the product in one page.
The metrics tracked to define ‘increased engagement’ were the number of searches performed, building family trees, and how large the tree’s were, increased return visits and page views.
Tools used
- User research
- Ideation workshops
- Journing Mapping
- Miro
- Figma
- Salesforce
- Google Sheets
In 2021, Cazoo had scaled very quickly. Lots of legacy processes were very manual, time consuming, essentially held together with 'duct tape'. Compounding the issues were multiple legacy systems that were not able to integrate. Whilst in the 'start-up/scale-up' environment where priorities change frequently.
Discovery
Understanding the current process
I setup time to interview and observe our CS Agents working, this was a mix of virtual and face to face sessions.
Data on the current process wasn't being tracked, so we created tracking to hopefully use later in the process if needed.
After each session I'd start to map out what I learnt of the process flow. This then formed the basis of conversations with the next CS Agent. The reason I took this approach was that every single team with Cazoo's CS function had a different way to complete a task. So in order to capture the nuances I'd further flesh out the map. This helped where one team may use a Slack template, another uses googledocs and another the sticky notes app on their desktop.
First pass of mapping the process after a couple CS Agent interviews.
Layering in further detail
Another detail that was quickly apparent was that this multistep process involved different teams at different stages.
CS Agents only did the first step of requesting a booking. This was an unstructured task in Salesforce (think a single free text block).
The actual booking was handled by a small team, taking the information provided, they'd use a third party system to book ou our fleet (Coopers Business Solutions). Where no Cazoo fleet car was available, the booking team would use another third party system (Enterprise Rental Cars) to book a rental car for the customer. They'd then tell the CS Agent if they had a car available via slack or Salesforce.
The CS Agent would then manage the message back to the customer and submit a logistics planning request (a different Salesforce workflow) to get a car delivered.
Adding more detail and the booking team (pink post-its) to the flow.
Exploring the 3rd party systems
Working with the booking team to understand the 3rd party booking systems and dependancies. Here I was able to understand their pain points in the request process.
Inconsistent and inaccurate request data from the CS Agents
Slow approvals processes (in some cases leading to 4 days of back and forth)
Excessive internal communications between colleagues (Slack, Salesforce Chatter)
To explore integration with these booking systems, I setup a call with our Account Manager and we discussed their API with our developer.
Unfortunately the API was very limited and didn't offer any value. So our focus stayed on refining the workflows and processes.
Mapping out how the flow on 'task by task basis'
Discovery playback
A lot of the problems identified in this research were outside the scope of our Prod/Eng team. So in order to get buy in to help change more than just the workflows in CS, I arranged a cross team workshop. This included about 20 people from other teams, CS, Logistics, Fleet operations.
In the session I shared our research findings, and got some discussion and input on these points, using Miro. By the end I wanted there to be a common understanding of the main issues and some agreement on a priority list.
Main problems identified for CS Agents were:
- Time taken to complete requests varied from hours to days
- Customer services felt like their requests were sent off into a black hole
- Back and forth Slack communications filled the 'notification gap' from between teams during these processes
- Common understanding of what was ‘important information’ for the next team to process their request, was non-existent
- Different teams used different templates (copied/pasted) to start this process, and then manually input all data for the request, allowing for many points of failure
- Legacy working practices and processes slowed the team down
Some of the slides highlighting painpoints an opportunities for the CS Agent point of view
Some of the slides highlighting painpoints an opportunities for the Booking Team point of view
Output of the group alignment on problems and a HMW improve these session
Ideation
Moving into the solution space I wanted to empower the specialist teams (the consumers of these workflows) with accurate, relevant data so they could quickly action tasks.
To achieve this I wanted to give the CS Agents a 'create request' flow the was easy, automating as much data entry as possible. And ensure all parties involved in this process had timely notifications about the status of the bookings.
Refining the journey and requirements
Refining how a 'loan car' journey would look in Miro, a new request type journey mapped at the top. At the bottom mapping out how a CS Agent would extend a booking or close a booking out.
By giving a request a lifecycle, we could support CS by nudging them to take action as a booking approached its end date.
Mapping out the flow for the refined request and booking flow.
First pass testing of the 'create flow' journey was tested in Figma with CS Agents. Iterating on this design a couple times and exploring different ways of rendering the flow to them in Salesforce (Popover panel and Modal).
Feedback on more complex request types informed how we'd chunk down the form to reduce overwhelm with options.
Testing and iterating
First iteration of the form, feedback helped shaped how this was done in later versions
Iteration of form in a panel, chunked down into sections
Testing the 'specialist teams' workflow and screens as also done a couple of times to understand how the more structure approach to them receiving the information would support their work.
Working from a list of tasks requiring attention was well received. And though they still needed to manually input data into a 3rd party system, data entry into the request was much simplified compared to their legacy process.
Feedback from testing had us rethink a bit about what else we could add to this page to help the booking and logistics teams get some context of the customer order. We added order summary information, and refined the actions to be dynamic actions depending on the status of the booking.
Specialist teams get requests in a list form, allowing them to select more urgent requests to work on first
Iteration of form in a panel, chunked down into sections
Mapping out object statuses and the actions available in each step
Measuring impact and next steps
Our release of this new process conincided with structural changes in the teams managing this process. We saw a decrease in 'time to book' and a decrease in Slack messaging on the legacy channels.
As of February 2022, we are integrating this request into another workflow, to essentially daisychain these tasks together for CS Agents, further enhancing their efficiency and reducing points of failure.
The new process also enabled tracking, which allowed me to do some work in GoogleSheets to identify potential opportunities for refining the process. As well as helping us highlight better ways of working to the CS Mangement. Having this data shared with other Product teams helped with getting work in their backlogs that we could leverage.
One such example is our Driver handover app in the neat future will have events based on when a customer gets to returns a Loan car to us. We'll be able to use this to automate the insurance (at the beginning) and track the returns (at the end) to close off a booking.
Screen shots of my analysis summary in Notion
