Quality and Call QA: Root Cause
Objective. Open Root Cause and read error patterns as hypotheses to validate and coach against - not as proven causes, and not as additive savings.
Root Cause groups quality failures into recurring patterns. This screen answers 'what keeps going wrong, and where should coaching focus?' - the bridge from scattered findings to targeted improvement.
See it in the demo
What this screen answers
Root Cause clusters failed rubric items and findings into recurring error categories. It answers 'what is systematically going wrong, not just on one call?' A CSM uses it to turn scattered low scores into a focused coaching theme; Sales uses it to show that the loop finds patterns leads can act on, rather than coaching anecdotes from the last bad call anyone happened to hear.
The task
Scope to the team and period and read the ranked error patterns. Open one, follow it back to the interactions and rubric items behind it, and check the pattern is a real recurrence, not a labelling artefact. The task is to pick the one or two patterns worth a coaching experiment and name the evidence behind each, so coaching targets the errors that actually recur.
How to read it
Two linked misreads to avoid. First, overlapping categories cannot simply be summed into a savings or impact claim - the same interaction can sit under several patterns, so adding them double-counts. Second, a root-cause pattern is a hypothesis, not proven causality - it shows what co-occurs with low scores, not that it caused them. Confidence depends on consistent categorisation, which in turn depends on calibration and a clear rubric. Read the ranking as 'where to look and test first', then validate the cause with the underlying evidence before you commit to it or quote an impact.
Honest limits
This screen inherits every upstream caveat - a biased sample or an uncalibrated rubric produces misleading patterns. It identifies candidates for improvement, not confirmed causes or guaranteed savings. Confirm with product how categorisation, tagging and any AI-assisted clustering are configured and entitled; the demo shows the mechanism on seeded data.
Interpretation check
A root-cause pattern is a hypothesis to validate, not proven causality - and overlapping patterns cannot be summed into a savings claim because one interaction can sit under several.
In the field
KnackGlobal (RCM): a recurring documentation-gap pattern across many claims is a far stronger coaching target than one flagged call - but it is a hypothesis to validate against evidence, not a proven cost figure to put in a deck.
Practical task
Open the Root Cause screen, pick the top pattern, follow it to two underlying interactions, and write a one-paragraph hypothesis plus the coaching experiment you would run - then note why you did not add the top patterns together.
Self-check
The top three error patterns each show a value. Can you add them for total impact?
No. Overlapping patterns share interactions, so summing double-counts. Treat each as a candidate to validate, not an additive total.
A pattern correlates strongly with low scores. Is it the cause?
Not proven. The screen shows co-occurrence; causality needs validation against the underlying evidence before you coach to it or quote impact.
What upstream conditions make a root-cause pattern trustworthy?
Consistent categorisation, which depends on a clear rubric and calibrated reviewers, plus a representative sample. Garbage in, misleading pattern out.
What is the right output of reading this screen?
One or two patterns worth a coaching experiment, each with named evidence - not a tidy savings figure summed across categories.
Verified vs demo. Screen is live in the demo at /#/analytics/root-cause; exact controls and figures are SME-validation-pending.