PROTOTYPING BEYOND THE END CUSTOMER

By: Salvador Zepeda  |  Sep 1, 2017

A prototyping journey that built a new competitive advantage

Adopting prototyping is more than only rapidly testing customer-facing features. Rather, it is an insightful and tangible way to think through internal or external problems in a business.

Prototyping is typically imagined as testing a service with the end customer. Its role can be much more expansive, however, because it is actually a widely-applicable way of learning through insightful trial-and-error. Insightful here is defined as finding the cheapest and quickest way to get to truth. Eventually, with enough resources and time you can prototype and learn about everything. The real question is not whether you will get there, it is whether you will get there before others or before you run out of resources. In this article, I will share one of our most challenging prototyping journeys which eventually defined one of our core internal process. We believe that this process is one of the main competitive advantages of our business today.

The Challenge: Managing the Process

Autolab is a multi-brand, multi-service car repair chain with the mandate to dramatically improve customer satisfaction and offer fair prices while providing quality jobs for mechanics. During its first months, an experienced head mechanic ran the shop operations based on his best knowledge. Unfortunately, most car repair shops are not customer-centric and Autolab was providing a similar experience to that of the industry. Our three main challenges to improve customer satisfaction were:

1. Jobs were assigned to mechanics with no consideration to specific customer needs, such as delivery times

2. The job was assigned to a mechanic only after he was free, thus, making it impossible to estimate delivery times for cars waiting to be served

3. The head mechanic was the only person who knew the status of all cars, making it really hard for the customer reps to keep customers updated

Initially, we started under the assumption that the most important problem was to share the information about the status of a car with the team and customers. Focusing on that issue was where the prototyping journey started, but not where it ended. Soon, the scope would be proven wrong.

1) Visualizing the state of the car

Hypothesis: If we visualize car status, we could provide quality updates to customers

Prototype description: Post-it matrix built on a wall with the process steps (e.g. execution, waiting for parts, ready) as columns and the physical location (e.g. elevator) of the car as rows. Each post-it within the matrix represented a car. The matrix was filled at the start of the day.

Results:

+ Provided visibility to the status at the start of each day

– Analogue version was difficult to update during the day

2) Real time visualization

Hypothesis: If we keep a shareable car status on real time, we could provide quality and on-time updates to customers

Description: Establish a dedicated role to update car status in real time in Google Slides. Everyone in the team had access to review the status of any car at any moment. There was an adjustment to the matrix: each row became a car. That adjustment allowed us to see the car’s previous steps. Also, we used colors at each step to show whether the car was waiting, in progress of finished.

Results:

+ Provided visibility to the whole team around car status

– Customer feedback showed us that knowing car status was less important than knowing delivery dates (we still couldn’t predict them with accuracy)

– Mechanics engaged less with a digital tool

3) Job Order Visibility

Hypothesis: If we give visibility to a job pipeline per mechanic, we could estimate delivery times better. The job pipeline will let us understand the order in which the jobs would be performed

Description: Redesign the board to show the car job pipeline for each mechanic. Each column was a mechanic and the post-its represented their job pipeline. Post-its were placed in the matrix after car reception. We went back to an analog prototype (post-its) to increase mechanic engagement.

Results:

+ Visibility on the order of jobs execution

– Order of jobs was not enough to give accurate delivery times – we needed to know the duration of the jobs for each car.

4) Visibility on job times

Hypothesis: If we included time as a variable in the board, we could estimate the time at which each car would be ready

Description: We added time on the vertical axis of the board. Additionally, we wrote the duration of the jobs in the car post-its to be able to estimate when they would be ready. We also added the committed time to customer to have it in mind when prioritizing jobs. Finally, the post-its became the job orders for the mechanics with a checklist for all services.

Results:

+ Delivery times became visible and more reliable

+ For the first time, we used the committed delivery time as a variable to prioritize all cars

– The board could not be scaled to a much larger operation since it was time intensive to write all the information on post-its

5) Blend into existing processes

Hypothesis: If we could eliminate the work required to rewrite the information on the post-it, we could manage a much larger operation with the same dedicated role

Description: We redesign the client reception sheet to turn it into the post-it (job order). Most of the information in the reception sheet and the job order overlapped. Therefore, we only needed to get a photocopy of the reception sheet and use that as a job order. We added some strings to the board so we could clip the job orders to the mechanic row.

Results:

+ The board became manageable by one person for a larger operation

– Commitments made when booking at the call center were not visible at the shop and were not part of the board management

6) Call Center Integration

Hypothesis: If sales used a similar board, they could consider the shop capacity when making commitments to the customer and easily transmit the information to the shop

Description: We created a simpler board for next day bookings in sales. On that board, the sales team would place the bookings to ensure that we could serve the cars at the promise times. A picture of that board would be given to the shop at the end of day so they could prepare the shop board based on that.

Results:

+ Commitments acquired at sales were prioritized by shop operations

– Usage of different boards increased the chance of accidentally losing some information

7) One board for all

Hypothesis: If the sales team and the shop used the same board, we could avoid mistakes when passing information from one board to another

Description: We digitized the board and gave access to both the call center and the shop. It became a tool where both could book jobs any day, at any time as long as the mechanic was free.

Results:

+ Reduce workload and mistakes by having a system that shares information

– Required increased discipline of how the tool is used and creating rules of interaction between sales and shop ops

The System Today

This system became the core of our operation and is the brain of the shop and sales team. Our operation is not perfect today, but this system allows us to serve 550 customers per month with an average satisfaction rate of 4.6 out of 5. Furthermore, we discovered the system’s potential to be a core tool in customer interactions and quality assurance processes. For instance, to improve satisfaction, we added automatic client updates and digital reports for car diagnostics.

Final Lessons

Prototyping is never constrained by tech

You can always prototype in analogue ways. You can recreate any digital solution with an analogue solution, especially for internal operations. It will take more effort to run, but much less to set up and start learning. However, an analogue solution might constrain scale since often the complexity of running an operation can grow exponentially. However, for prototyping, you will be safe with analogue most of the time.

Customer needs dictate the internal challenge you will solve

Even when the prototype is not customer-facing, you are ultimately still trying to solve a customer issue. Our customer does not interact with these prototypes, but their needs still dictated what problems we were solving. In our prototyping, we did not prioritize what we wanted to solve, but what was more painful to clients.

If the learnings are clear, prototyping is not reinventing the wheel

The final board looks similar to a tool called Heinjuka in Lean Ops. One could argue that we could just have read about Lean Ops to get to the solution. However, during our prototypes we learned valuable lessons that reduced rework when building the digital solution. There is value in the struggle to get to the right solution. For instance, we understood how the different users interacted with the board and its post-its. Through these lessons, we defined the rules of the system: workflow, constraints and available information per user.

Give enough support to change people’s behavior while prototyping

Designing the boards was the easy task compared to changing people’s behavior. In car shops, the person who assigns jobs typically is the boss. The board for job assignments took that power away from the head mechanic. He resisted it and eventually left. In addition, getting mechanics to be disciplined and consistently using the boards and tools was a long process. When prototyping, give enough support to ensure that a prototype fails because of bad design and not because of poor implementation.

About Autolab

Autolab is a multi-brand, multi-service car repair chain with the goal to improve service level in the industry, offer fair prices and solve an employment problem. Car owners are subject to the poor service and high prices in the car repair industry. Autolab aims to provide great service and on-budget options. Mechanics have poor employment options: low compensation, no social security and, often, condescending treatment. Autolab wants to provide them with quality jobs, a safety net and recognition. The company started less than three years ago and is part of Polymath Ventures.

Polymath Ventures and its unique perspective

Polymath Ventures is a company builder focused on creating and developing scalable companies that serve the growing middle class in Latin America. It differentiates from other organizations by having a methodological approach to entrepreneurship, borrowing tools from management consulting, human-centered design, lean startup, and a variety of other disciplines.

Many of Polymath’s ventures operate with real production units such as repair shops, schools, and restaurants. This involves managing staff, real estate, and equipment. Still, we believe that our lessons are relevant for all type of startups.

In Polymath Ventures, multiple startups are simultaneously in their early years of development, which provides a unique perspective for observing common challenges. Building and iterating a methodology, sharing solutions across ventures, and surrounded by world-class multi-disciplinary talent, gives us a privileged vantage point.