Currently, a big part of car revenue is in the aftersales sector, which includes maintenance, inspections, and repairs. To support this sector, car dealerships have a wide array of aftersales software in use. There is an application to find parts, to make customer appointments, and interactive repair manuals or tools for managing warranty issues. While there is third party software available for some of these use cases (e.g. making appointments), a lot of it is provided directly by the manufacturer to its dealers. This means that car manufacturers do not only produce cars, but also employ quite a few software engineers and designers, who constantly update and optimize a suite of aftersales software.
Providing an optimal aftersales experience is in the best interest of the manufacturer. It keeps customers happy by making repairs and maintenance as easy and seamless as possible. It makes dealers happy because easy-to-use software means less time spent training employees, less errors, and faster turnaround; a mechanic desperately trying to find a repair manual in the software is not working cars during this time and, therefore, not earning money.
Thus, there is plenty of incentive for the manufacturer to optimize the user experience of the aftersales software. What our client wanted to avoid was to develop shiny new tools, hand them out to the dealerships, and then learn that this is not what users needed.
While the designers and programmers were highly motivated to deliver the best possible software, they had a big challenge to overcome: They were software developers, not car dealers or mechanics. Without in-depth knowledge of the inner workings of a car dealership, it was very hard to optimize the software. An additional hurdle was that procedures and requirements varied from dealership to dealership; something that works for one is not guaranteed to work for others.
The project called for a close collaboration between developers and users. The developers needed constant access to a pool of users to ask questions like, ‘who performs which task at a dealership?’, ‘who needs what piece of information at which point?’. They needed to discuss their ideas with users. Of course, they also needed participants for user experience tests to see if their solutions worked.
Our first step was to develop internal presentation materials for the manufacturer to distribute to local district managers that would encourage participation in our study. The managers’ familiarity with area dealerships enabled them to suggest potential candidates for the panel. The managers then talked to the dealerships about the panel and distributed the initial information. This step was important, as it prepared the dealers to get a call from us. Cold calling dealerships to ask if they wanted to participate in market research would have likely failed. But this way, dealerships were expecting our call, knew this was an official project sponsored by the manufacturer, and were keen to participate.
After the initial call with the dealers, we sent materials and a questionnaire. Once completed, the dealership was ready to participate in our studies.
While we encouraged close collaboration between the developers and users, we wanted to regulate the amount of times the dealerships were contacted with requests to avoid overstressing individual dealerships. Therefore, all communication went through us so we could distribute the workload between dealerships evenly.
Once the panel was established, we had a list of dealerships ready to support the developers. The process was for the developer teams to approach us when they had a question. We would define the study details with the team (e.g. how many participants were needed). Then we reached out to the panel.
The panelists received an invitation with study details and could decide if they wanted to participate in this specific research activity. The willing participants’ contact details were then given to the developers who conducted the study. We entered the results into a database that we provided for all teams to access.
The panel facilitated all kinds of research: from 20-minute phone interviews (to get some quick answers) to shadowing a mechanic in the workshop for a full day, anything was possible. Developers could drop by the dealerships and bring prototypes for a UX test, or could discuss the latest changes with users via screen sharing; all this while keeping developers’ recruitment and study set up efforts to a minimum. Ultimately, developers only needed to send a simple email to us to get the ball rolling for any request.
This low-barrier approach turned out well. Teams who were previously developing in a vacuum, suddenly had quick and convenient access to users – and they were using it! The panel helped with institutionalizing user research within the manufacturer. It became the main channel of reaching aftersales-software users, not only for UX-related questions, but also to discuss strategic management decisions with those impacted.
The dealers were happy as well. They could voice their opinion and help shape the optimal software. Even though only a small percentage of all dealerships participated in the panel, simply knowing that this institution existed, and that the developers were actively listening to users, helped with acceptance of the innovations.