Rivian
Service Outline
Role
Team
Scope
Product Designer
1 Designer
1 Product Manager
4 Engineers
Visual Design
Product Strategy
Problem
At any one time, there are thousands of Rivian vehicles waiting for service. This scale makes it very hard for our Service Operations teams to prioritize what work to do next. Our teams needed a way to streamline their working cadence and ensure that the most important issues are addressed first, and all issues are addressed in a timely manner.
Solution
A new main nav item of ServiceOS called Service Operations Dashboard - the best way for Repair Plan Advisors to prioritize which vehicles to work on first
Result
Service Operations Dashboard launched in 2022 and is now an integral part of the way the call center, repair advisor, and field service teams prioritize work at Rivian.
Background and Context
When a Rivian vehicle needs service, typically 3 different types of digital containers of information are created:
Service Ticket
Service Request
A service ticket is used as a log of a conversation. One (and only one!) is created whenever a customer calls the Rivian call center or submits an issue on the mobile app.
Service Request
A service request is used to track one specific issue. For example: ‘vehicle pulls to the left’ or ‘Spotify app won’t sign in’.
Work Order
Work orders are tied to a specific vehicle and indicate which service requests will be addressed during one specific appointment.
These 3 containers of information are all used to accomplish different workflows. For example, Scheduling is done using the Work Order, Photos and other media are uploaded to the Service Ticket, and Remote Diagnostics are performed on the Service Request. As Rivian continues to ramp production and scale deliveries, the amount of data that was being created was becoming overwhelming. This was causing important service data to slip through the cracks. For example, some customers would go weeks without a phone call because Rivian simply lost their service ticket.
Previous solution
To illustrate the problem, here was the existing solution before Service Operations Dashboard. Basically, just 3 giant tables of Tickets, Requests, and Work Orders, sorted by most recent. While this works well for small amounts of data, we found that it started to get unwieldy very quickly. For example, here are just some examples of things Service Leadership wanted to keep track of:
Customers with high service count. Vehicles that are at risk of Lemon Laws in their respective states.
Customers marked as High Tough, I.e. influencers, YouTubers, investors, etc.
Tickets marked as “open” that have gone more than 48hrs since we have updated the customer.
And many more. However, users had no way to track items with these characteristics in RivianOS, as all they had to work with was one big table.
First idea: Metrics and Dashboards 📊
My first idea to solve this problem was to create a system of dashboards that would show the overall ‘health’ of the business. My idea was to show how many tickets appeared to be stalled, how many mobile tickets were awaiting service requests, and the average output of the team over time. This would give the Service Operations leadership key insights and metrics to help them prioritize where to spend their time problem-solving. However, when I showed this idea to our user base, they hated it! This approach was too high level and didn’t give them any actionable things they could do to improve these numbers. Basically, they already knew they were falling behind, they needed our help to tell them how to catch up.
Next idea: Queues and new ways of working 📍
My first idea to solve this problem was to create a system of dashboards that would show the overall ‘health’ of the business. My idea was to show how many tickets appeared to be stalled, how many mobile tickets were awaiting service requests, and the average output of the team over time. This would give the Service Operations leadership key insights and metrics to help them prioritize where to spend their time problem-solving. However, when I showed this idea to our user base, they hated it! This approach was too high level and didn’t give them any actionable things they could do to improve these numbers. Basically, they already knew they were falling behind, they needed our help to tell them how to catch up.
Solution: Service Operations Dashboard ✅
We have finally arrived at our final solution! Ultimately we ended up creating 3 different tabs, one for each of our main user groups. For the Service Support Operations Center and Field Services tabs, we utilized a buckets and grids approach. With collaboration with our users and leadership, we defined certain buckets of data that would allow them to find and prioritize important items. For example, one bucket on the SSOC tab is “High Risk Tickets”, a collection of service tickets that are either from High Touch customers, contain a repeat service issue, or contain a VIN with > 100 service requests since delivery.
For the Diagnostics tab, we utilized the Queue approach to highlight which VINs were awaiting remote diagnostics support. This allowed these users to provide that support for all outstanding Service Requests on a VIN, their preferred way of working but something that was impossible before this product was released.
Feature highlight: the Monte Carlo Scheme 🎰
One feature I would love to highlight is the Priority Matrix, affectionately nicknamed the Monte Carlo Scheme™️ . After working closely with the diagnostics team on this project, I noticed that they often referenced a very complicated matrix of values that management defined. This matrix defined which VINs the diagnostics specialists should work on next, taking into consideration things such as how long until the service appointment, whether it is labeled a “Noise, Vibration, Harshness” issue, whether or not it has been escalated, etc. This ranking was all done manually by the Diagnostics team leadership and required extreme levels of effort to maintain. So much effort, in fact, that the general manager of this team hadn’t taken a significant vacation since he started, because he had to maintain this list!
The Monte Carlo scheme was a way to digitize this manual process. Inspired by card counting in casinos, the priority column would assign each VIN a base value of 0. Then, it would compare the service requests awaiting diagnostics support with the priority matrix and add or remove points accordingly. Then, the diagnostics tab would always be sorted by this priority number and visible as the first column. By crafting this matrix in collaboration with the diagnostics team, we were able to ensure that the highest risk and most important VINs would always be the top priority, all without any human intervention.
Results and Impact
The SSOC and Field tabs of the Service Operations Dashboard were successfully launched in Q4 2022. As the diagnostics tab is going to take more development effort, it is slated for a launch date in Q2 of 2023. While it is hard to say how well-embedded this tool has become as it has been released so recently, we expect it to be an integral part of the 130+ Vehicle Services org at Rivian in the near future.