When to run a root cause analysis

A complaints root cause analysis template is worth using when a specific complaint recurs: the same issue across many reviews, at one store or many, over weeks rather than days. One-off complaints get a good reply. Recurring ones get an analysis, because replying to them one by one will never stop them.

The template

  1. Issue statement: one sentence, specific and measurable. "Customers at mall stores in Pune complain about waiting at billing on weekends."
  2. Evidence: number of reviews, share of reviews in the period, stores affected, start date, trend. Attach five to ten representative reviews.
  3. Scope: where it does not happen. Which comparable stores, times or channels are free of it?
  4. Why chain: ask why until you reach something the business controls (see below).
  5. Likely cause: the cause that best explains both where it happens and where it does not.
  6. Test: what evidence would confirm or rule out the cause? Check it.
  7. Action: what will change, where, from when.
  8. Owner: one accountable person.
  9. Baseline and follow-up: the measure today and the date to look again.
  10. Result: filled in at follow-up. Worked, did not work, or not enough evidence.

Running the why chain

The five whys technique is a simple way to move from symptom to cause. The number five is a guide, not a rule; stop when you reach something the business can change and that explains the evidence.

  1. Why do customers complain about waiting at billing on weekends? Queues are long between 5 and 8 pm.
  2. Why are queues long then? Only one of the two billing counters is open.
  3. Why is only one open? The second cashier's shift ends at 5 pm.
  4. Why does it end then? Weekend rosters copy the weekday pattern.
  5. Why? Nobody reviewed weekend rosters after footfall changed.

The cause is the roster, not the cashier. The action is a weekend roster review, owned by store operations.

Testing the cause against the evidence

A good cause explains the pattern, including where the complaint does not happen. If weekend rosters are the cause, stores whose rosters already cover the evening should have fewer billing complaints. Check that before committing to the fix. If they have the same complaints, the cause is something else, perhaps the billing system itself.

Read the reviews again

Customers often name the cause in passing: "only one counter open", "the card machine kept failing", "they had to call the manager for every exchange". Search the reviews for these details before running workshops.

A filled-in example

Issue: exchange complaints at the 12 Mumbai stores, 11% of reviews from July to September, up from 4%. Evidence: 96 reviews; most mention being sent to another store or told to wait for head-office approval. Scope: not seen in Pune or Bengaluru. Likely cause: a July policy change in Mumbai requiring head-office approval for exchanges above a set value. Test: the complaints started the week of the change and are concentrated on higher-value exchanges. Action: delegate approval to store managers up to the threshold, from 1 October. Owner: Head of Customer Service Policy. Follow-up: 15 December, compare exchange complaints with Pune stores.
Root cause analysis record

Free review snapshot

Want this done for your own reviews?

No commitment. We use your details only to send your snapshot and follow up. Privacy policy

Where causes usually sit

  • Staffing and rosters: too few people at the times customers come.
  • Policies: rules that make sense centrally and frustrate customers at the counter.
  • Process: steps that require approvals, systems or people who are not there.
  • Product and supply: availability, quality or sizing problems from upstream.
  • Systems: billing, payment or app failures.
  • Training: staff who do not know a policy or a product.
  • Communication: what customers were told versus what happened.
Examples

Root cause analysis examples from customer service.

Root cause analysis for customer service examples

Closing the loop

An analysis without a follow-up is a report. Put the follow-up date in the record, look at the issue's share of reviews then, and compare with stores where nothing changed.

Measuring change

How to tell whether the fix worked.

Did the fix work measuring change after an action

Pitfalls

  • Stopping at a person. "The cashier was slow" is rarely a root cause; ask why the queue depended on one cashier.
  • Choosing the cause before looking at evidence. Workshops tend to confirm what the most senior person already believed.
  • Ignoring where the complaint does not happen. That contrast is often the strongest clue.
  • Fixing several things at once. You will not know which change worked.
  • No owner for the action. An analysis that ends with "the team will look into it" has not ended.

Doing this with Falcon

Falcon labels each topic in scope as needing attention, emerging or a strength, from its negative and positive counts and the change against the previous period. Each insight names the issue, why it matters (from the summary of the most-mentioned issue in scope) and a next step that names the taxonomy owner. Actions can be tracked to done, and because reviews keep arriving, the same signals show whether the issue's negative share falls afterwards.