Getting Process Findings Out of QA Data
Much of what QA discovers is not an agent problem. Routing those findings to people who can fix them is the highest-value output.
Quality data is treated as being about agents. Much of it is about systems, knowledge, policy and product, and that portion is worth more.
The findings that are not about agents
Long silences concentrated in one system. The agent is waiting.
The same question asked repeatedly across many agents. The knowledge base does not answer it.
Compliance failures clustered on one script. The script is unworkable as written.
A category rising after a release. Something broke.
Repeated customer confusion about the same document. The document is unclear.
Transfers concentrated between two teams. The boundary is wrong.
Handle time driven by a specific step. The step is badly designed.
Each of these appears in QA and analytics data and none is fixed by coaching an agent.
Why they go nowhere
No owner. QA reports to operations, and the fix belongs to product, IT or policy.
No route. There is no defined path from a QA finding to a backlog item.
Wrong framing. The finding arrives as a quality score rather than as a problem statement with a cost.
No quantification. "Agents struggle with this" does not compete for engineering time. "This step appears in 4,000 calls a month with an average of 40 seconds of silence, costing X hours" does.
Building the route
A defined intake. Where does a process finding go, and who triages it.
A quantified format: what happens, how often, what it costs in handle time or repeat contact, which calls demonstrate it.
Named owners by domain. Knowledge, systems, policy, product.
A feedback loop. The originator learns whether it was fixed. Without this, people stop raising findings.
A standing forum, monthly, where the top findings are reviewed with the owners present.
Quantifying a finding
The step that determines whether it is acted on.
Frequency, from analytics across full coverage. This is what analytics is for and it is far more persuasive than a QA sample.
Cost per occurrence, in handle time, repeat contact or escalation.
Total, which is the number that competes for attention.
Evidence. Three call recordings that demonstrate it. A product owner who hears three customers struggling with their form is more moved than by any chart.
That last item is underrated. Recordings are unusually persuasive to people who never hear customers.
The knowledge base as the recurring finding
Across operations, the single most common process finding is that agents cannot find the answer.
Measured by: silence duration, hold usage, transfer rate, and repeated questions across agents.
Fixed by: rewriting the specific articles the data points at, not by a general knowledge base project.
Analytics identifies which articles, which turns an unbounded improvement effort into a list of twelve.
Reporting it upward
Separate the agent findings from the process findings in every report.
Lead with the process findings. They are larger, they are fixable once rather than repeatedly, and they demonstrate that the programme is not merely a monitoring function.
Track fixes made, and the measured effect. A QA programme that can name six process problems it caused to be fixed, with the saving, is a programme that does not get cut.
The finding template
A standard format that makes a process finding competitive for engineering attention.
What happens, in one sentence, from the customer's or agent's perspective.
How often, from full-coverage analytics, with the period.
What it costs — agent seconds, repeat contacts, escalations — with the arithmetic shown.
Which calls demonstrate it. Three, with timestamps to the relevant segment.
What is suspected as the cause.
Who owns the fix.
What would confirm it is fixed, and by when it will be re-measured.
Seven fields on one page. A finding in this format competes with other backlog items on their terms. A finding expressed as a quality score does not, which is why so many die in the QA report.