When the same service problem returns, repeating the immediate fix may not be enough. Root cause analysis helps a team investigate why a problem occurs so it can choose a more useful response. This guide from GREEZA Academy & Consultancy, LLC uses an original, fictional example of delayed customer replies.
What problem should the team investigate?
Start with a specific observation. Suppose a team finds that 18 of 60 customer requests in one reviewed week received their first reply later than its agreed target. These numbers are illustrative, not academy performance results.
Define “first reply,” the target time and which requests are included. Separate automated acknowledgments from substantive responses if that distinction matters. Without a consistent definition, people may compare different things and reach conflicting conclusions.
What information should you collect?
For the example, review arrival times, assignment times, first replies and handoffs. Look for patterns across request types and working periods. Include the people who handle the work so the recorded process can be compared with what actually happens.
Avoid collecting customer details that are unnecessary for the investigation. Use the minimum information needed to understand the workflow and follow the organization's access rules.
How can you explore possible causes?
ASQ describes tools such as the Five Whys as ways to explore causes. Repeated questions can help move a discussion beyond the visible symptom, but a plausible explanation still needs evidence. A cause diagram can also help a team organize several possibilities before choosing what to investigate.
In this fictional case, the team might ask why requests waited before assignment. One possibility is that requests reaching a shared mailbox have no named owner during a shift change. Another is that some requests require information from a second team. These are separate hypotheses; do not force them into one story.
How can you test an explanation?
Compare delayed and timely requests. Did the delayed requests actually arrive during the shift change? Was an owner missing? Were similar requests handled promptly when ownership was clear? Look for evidence that could contradict the explanation as well as support it.
If the pattern does not match, revise the hypothesis. “People need to work harder” does not identify a process condition you have demonstrated or a change you can evaluate.
What action could the team try?
If the records support an ownership gap, test a clear handover rule with a named backup and a visible queue. Define the scope, owner and review date before beginning. Explain the change to the people doing the work and ask what difficulties they anticipate.
The action in this example is a suggestion for a test, not a proven solution for every service team. A different cause would require a different response.
How can you check whether the change helped?
Use the same definition of a late reply before and after the trial. Note request volume and mix so a quieter week is not mistaken for a successful change. Also check whether the new process creates extra work, missed requests or rushed responses.
If the evidence supports keeping the change, document the routine and assign responsibility for monitoring it. If results are mixed, examine what happened and decide whether to adapt the action or investigate another cause.
Where can you learn more?
The Lean Six Sigma Tools course listed by GREEZA Academy & Consultancy, LLC references root cause analysis and other improvement tools. Review the current syllabus, access and completion requirements here:
https://greezaacademycourses.learnworlds.com/course/lean-six-sigma-tools
Reference resources:
https://asq.org/quality-resources/root-cause-analysis
https://asq.org/quality-resources/five-whys
Contact info@greezaacademy.com for course details.