The Five Whys of Diagnosing Customer Problems

The Five Whys is an iterative technique to reveal the root cause of any given problem. Originally developed in the manufacturing processes at Toyota, the Five Whys has expanded into other practices including Kaizen, lean manufacturing, and Six Sigma.

In the case of diagnosing customer service problems, the Five Whys technique will help you get to the root cause of a breakdown in customer service faster. Taking from the example used in Customer Experience for Dummies, to deploy the Five Whys technique to solve a specific customer experience issue, follow these steps:

1. Gather some smart people who know a bit about the problem together in a room
2. Write down the problem on a flip chart or whiteboard
3. Ask for agreement from the group that this is, in fact, the problem (gain consensus)
4. Ask why the problem occurs and write down all of the answers you get from the group
5. For each of the answer recorded, ask "why" again
6. After several rounds of this, ask the group whether they think that they have identified the root cause of the problem

The Doctor is In

It's like going to your primary care physician complaining of shoulder pain and then being sent home with a prescription. That pain is a symptom of a potentially larger problem that only a specialist could diagnose. Going through the Five Whys is like seeing a specialist, just within a team of focused, customer-caring people who want to solve the customer experience breakdown.

So when your team gathers together to assess the problem, instead of trying to fix a symptom or piece of the larger problem and failing at the result, they can actually provide a proper diagnosis that identifies the root cause so the appropriate action will achieve a customer-satisfying result.

By asking why at each stage of diagnosing the problem—five times (or more if necessary)—your team will not only understand the root cause of the problem, but it will often reveal the steps needed to resolve or eliminate the problem and possibly even create better efficiencies for your organization. Don't give up too early in your deep dive into the whys; the problem often lies where you least expect it.

"These Instructions Suck!"

Here is an example of going through the Five Whys method. Say the problem is that customers are complaining about the poor quality of installation instructions that come with their product. As a result, customers are calling the customer support line and asking how to do a specific step that is unavailable in the product's manual.

Start with clarifying the first why, which sets off the Five Whys method. Setting up the first question correctly is key to getting to the true root cause, so carefully consider that you are asking the right question in the first place. Each subsequent question then restates the answer to the prior 'why' response and so on, until you arrive at a root cause you can clearly identify.

• "Why are customers complaining about the instruction manual that comes with our product?" Because it doesn't tell them how to install the product in older models or in odd-size situations.
• "Why doesn't our installation manual cover older model or odd-size installation instructions?" Because we are using an outdated product manual that was borrowed from a product we discontinued two years ago.
• "Why are we using an outdated product manual from a product we no longer sell?" Because no one in product development created a new one that supports the new product specifications and installation recommendations.
• "Why didn't product development create a new manual for the new product?" Because product development never got the technical specs from the design department responsible for that product.
• "Why didn't product development get technical specs from the design department?" Because the design department never got requirements based on all-case scenarios from the outsource division that builds the product.

And so on. So you can see by going through this iterative process you can quickly identify where breakdowns have occurred and set about fixing them. As in this example, it was one root cause (the design department never getting requirements based on all-case scenarios from the outsource division that actually builds the product) that set into motion a series of cascading events that resulted in a negative experience for customers.