Resolution rate and deflection rate get treated as synonyms in vendor decks and internal updates. They are not. One counts what happened inside conversations you already have. The other estimates contacts that never became tickets. When you report one number under the other word, you are not refining the story — you are changing the claim.
This matters because the two numbers move for different reasons, break under different gaming strategies, and imply different next actions. A team that thinks it measured deflection when it measured resolution will keep optimising the wrong loop.
What each word actually claims
Resolution rate asks: of the conversations that started, how many ended without a human needing to finish the work? It is a conversation-level outcome. Useful, limited, and close to what most products call answer rate.
Deflection rate asks: of the tickets that would have been filed, how many never were because self-service got there first? It is a displacement claim. You cannot observe the counterfactual directly, which is why honest deflection needs a before-and-after on ticket volume, not a ratio of bot chats to total chats.
Why the mix-up is so common
- Resolution is easy to compute from product analytics the day you launch.
- Deflection needs weeks of baseline data you may not have recorded.
- Both can be expressed as percentages, so they look interchangeable on a chart.
- Leadership often asks for “how much load we took off the inbox,” and resolution is offered as if it answered that.
None of that makes the substitution honest. A chat that would never have become a ticket can still “resolve.” Counting it as deflected invents savings. The existing post on why deflection rate is overstated walks through that arithmetic; this one is about keeping the two labels apart so the arithmetic can stay honest.
What each number is good for
| Metric | Question it answers | What it cannot prove |
|---|---|---|
| Resolution / answer rate | Did conversations end without a person? | That tickets fell, or that answers were correct |
| Deflection (honest) | Did normalised ticket volume fall after launch? | That every bot chat was a saved ticket |
| Satisfaction beside either | Did the change cost trust? | Why a single conversation failed |
| Refusal / content-gap list | What should we write next? | How much cost you saved last month |
Use resolution when you are tuning coverage, refusals, and handoff behaviour. Use deflection when you are justifying cost or headcount impact. Use both when you are deciding whether the programme is working — but never as substitutes for each other.
A shape that makes the difference visible
relative index
Illustrative, not measured: resolution can look strong while ticket volume barely moves, because many widget chats were never tickets.
The point of that shape is not a target. It is a reminder that a healthy product can resolve most of the conversations it gets and still only displace a smaller share of inbox volume. Reporting the first as the second invents a business case.
How to keep the language clean in reports
- Label conversation outcomes as resolution or answer rate — never as deflection.
- Reserve “deflection” for before/after normalised ticket volume, with the window stated.
- Put CSAT or your equivalent on the same slide as either number.
- Add the refusal list so “unresolved” turns into a content plan rather than a shrug.
If someone insists on one headline percentage, ask which claim they want to defend in a month. Cost impact needs deflection done properly — the measure deflection guide is the long form. Product quality needs resolution next to refusals and satisfaction — reading analytics honestly covers that pairing.
The shortest version
Resolution tells you how conversations ended. Deflection tells you whether tickets disappeared. Mixing the words does not create a smarter metric; it creates a number that cannot be challenged because it no longer means one thing. Keep the labels strict, and the debate gets shorter because everyone is arguing about the same claim.
