Service Advisor Design Sprint
This 1-week design sprint aims to improve the company’s customer service. It was the first time our team tried this method. We wanted to get as many ideas and test our solutions. We have around 10 participants joining the design sprints, people from different fields and knowledge that generated many ideas from different angles.
The challenge is to find a way to help service advisors work better so that our customers, the end-user, become happy with our services.
At the beginning of the workshop, we presented all the information to the participants, such as feedback on our services, and the existing operations. We interview the service advisors about how they work, and what type of tools they are using. From this, we could create a service blueprint along with the customer journey.
Two of our main customers’ pain points are the amount of time in waiting for the service, and the insufficient explanation from our advisor for fixing and maintenance. So we start by setting a long-term goal, which is “Making the ISUZU customers trust our after-sales service”.
Our advisor’s pain points are that the platform that they are using is provided on a desktop computer, having the advisors and mechanics walk back and forth to input and update the data, which makes the process very slow. We also found that repair explanation quality depends a lot on the experience of the advisor. If the advisor has little experience, they could not give a good explanation to the customers.
From the journey, we mapped all the tasks and pain points of the customers on to the journey and voted on the ones that have the most impact, so that we can focus on the problem we wanted to solve first.
After we have our focus, brainstorming, and sketches were done so that we can move on to testing out our ideas by prototyping and testing with our advisors and customers.
The solution we want to test is creating a platform for service advisors and the customers to check the vehicle status and show explanations about the repair that has to be done on the vehicle. We want to provide a tablet for the advisors to update operation status and features that can preview repair explanations to the customers. The same solution can also be provided to the customer on their own mobile device so that the customers can see the information about their vehicle status and what is being done to their vehicle while waiting in the lounge.
Designers now are in charge of creating a minimum scope of the prototype to test the ideas with service advisors and customers. We set up a testing room with cameras to record and stream the test to all the participants. After a short usability testing, we ask additional questions to check if the advisor thinks that these tools will help them.
Results and conclusions from the test were separated into two different types of users.
The service advisors think that most customer does not question the repair. Some think that it is useful, and they collect photos on their mobile device for showing while explaining to the customers how their vehicle is being fixed. Even if they think that it is useful but the total number of advisors using it might be lower than expected.
As for the end customer, trust comes from the quality of repairing (successfully fixed), and the ability to diagnose correctly, what is being used on their vehicle, and price, not from customers’ understanding of the repair order.
Customers find the tracking status and digital repair history feature more useful than the explanation page but it doesn’t relate to trust.
From this conclusion, the product and business team were able to decide that we should put effort into improving the operations first so that we can increase the trust of our customers and we should keep on experimenting with our next assumption.
