Deflection rate tells you how many tickets the AI kept away from a human. Resolution rate tells you how many customer problems actually got solved. Those are not the same number, and in regulated support the gap between them is where churn, complaints, and compliance risk live.
Resolution rate and deflection rate are the two metrics most teams use to judge an AI support agent, and they measure opposite things. Deflection rate counts conversations that did not reach a human. Resolution rate counts conversations where the customer's underlying issue was solved. A deflected ticket can be an unsolved one - the customer gave up, got a non-answer, or churned in silence. This guide defines both metrics, explains why deflection can mask bad customer experience, shows how to measure resolution honestly, and covers the role of independent QA and pricing in keeping the number trustworthy.
Deflection rate measures avoidance (no human touched the ticket). Resolution rate measures the outcome (the customer's problem was solved). High deflection with low resolution is the classic failure mode of first-generation chatbots.
A deflected-but-unresolved ticket often costs more than a human-handled one: the customer retries on another channel, escalates angrier, or churns without telling you.
Resolution is only honest when something independent verifies it. Self-reported resolution (the AI grading its own work, or "did the conversation end?") is the most common way the number gets inflated.
Pricing models encode incentives. Per-deflection or per-conversation pricing rewards volume; per-resolution pricing with a customer-held definition of resolution rewards solved problems.
The defensible 2026 setup: define resolution in business terms, verify it with independent QA on 100% of tickets, and pay only for outcomes you would accept on appeal.
Last updated: June 2026
Most AI support vendors lead with a deflection rate because it is the easiest number to make large. Turn off the "talk to a human" button, add a few self-service nudges, and deflection climbs - whether or not anyone's problem got solved. For a marketing site that is a fine headline. For a support leader accountable to a CFO, a head of compliance, or a churn target, it is the wrong number to optimize. The metric that matters is whether the customer left with their issue resolved. This article is a buyer-neutral explainer: what each metric actually counts, why the difference is large in regulated and complex support, and how to build a measurement and pricing setup where the number you report is the number that's true.
What is deflection rate?
Deflection rate is the percentage of inbound support contacts that are handled without a human agent. If 1,000 tickets arrive and 700 never reach a person, deflection rate is 70%. It is a containment metric: it measures what the AI (or self-service layer) kept away from the queue, not what it accomplished.
Deflection rate: the share of inbound contacts resolved or abandoned without human involvement. It counts the absence of a handoff, not the presence of a solution.
Deflection has an honest use. It is a capacity metric. If you are staffing a contact center, knowing that 70% of volume never touches a human tells you how many agents you need. The problem starts when deflection gets reported as a quality or value metric, because it counts two very different events as identical: the customer whose problem was solved by the AI, and the customer who gave up and closed the chat. Both are "deflected." Only one is a good outcome.
There are several ways deflection inflates without any real improvement in service:
Hiding the human handoff. Remove or bury the "talk to an agent" path and deflection rises mechanically. The tickets did not get easier; the exit got harder.
Counting abandonment as success. A customer who reads a non-answer and closes the window is counted as deflected. The system records a win; the customer records a reason to churn.
Channel shifting. The chatbot "deflects" the chat, the customer immediately calls the phone line or emails. One issue, counted as deflected once and as a new contact once. Deflection up, total cost up.
Deflecting the easy 80%. Answering "what are your hours" a thousand times produces a high deflection rate and tells you nothing about whether the agent can handle a disputed transaction or a failed KYC check.
What is resolution rate?
Resolution rate is the percentage of contacts where the customer's underlying issue was actually solved, end to end, without needing further human follow-up. If 1,000 tickets arrive and 650 are genuinely solved by the AI, resolution rate is 65%. It is an outcome metric: it measures what got fixed, not what got contained.
Resolution rate: the share of contacts where the customer's problem was solved to a defined standard, verified independently, with no human follow-up required and no repeat contact on the same issue.
The reason resolution is the honest metric is simple: it is the thing the customer actually wanted. Nobody contacts support to be deflected. They contact support to unlock an account, dispute a charge, change a beneficiary, or understand why a transfer failed. Resolution rate is the only one of the two metrics that maps to that intent.
It is also the harder number to fake, because solving a problem leaves evidence. A resolved dispute has a credit posted. A resolved KYC unlock has a verified identity and an active account. A resolved transfer query has a customer who did not contact you again about the same transfer. Deflection, by contrast, leaves only the absence of a human - which is consistent with both success and abandonment.
The catch is that resolution is only honest if it is measured honestly. There are weak versions of resolution rate that are no better than deflection dressed up:
"The conversation ended" as a proxy for resolution. Conversations end for many reasons, including frustration.
The AI grading its own work. An agent that decides whether it resolved the ticket has an obvious incentive to say yes. This is the single most common way resolution rate gets inflated.
Survey-only resolution with a 5% response rate, where the 95% who did not respond are quietly assumed resolved.
"No reopen within 24 hours" windows that close before the customer has noticed the problem is still there.
A resolution rate is only as trustworthy as the verification behind it. That is the part of the metric most worth scrutinizing.
Resolution rate vs deflection rate: the core difference
The cleanest way to see the difference is a two-by-two. Every contact lands in one of four cells:
Deflected and resolved - the AI solved it, no human needed. The cell you want to grow.
Deflected and not resolved - no human touched it, and the problem is still live. The dangerous cell: it looks like a win on a deflection dashboard and is a loss for the customer.
Escalated and resolved - a human finished it. Counts against deflection, but the customer is served.
Escalated and not resolved - a human touched it and still failed. Rare, but the most expensive.
Deflection rate adds the first two cells together and reports the sum. Resolution rate adds the first and third. The two metrics only agree if the "deflected and not resolved" cell is empty - that is, if deflection never includes abandonment, non-answers, or silent channel-switching. In practice that cell is rarely empty, and in complex or regulated support it can be the largest source of disagreement between the two numbers.
A worked example. Two AI agents each handle 1,000 tickets:
Agent A deflects 800 (80% deflection). On audit, 450 were genuinely solved, 350 were customers who gave up or got a non-answer. Real resolution rate: 45%.
Agent B deflects 650 (65% deflection). On audit, 600 were genuinely solved, 50 escalated cleanly to a human. Real resolution rate: 60%.
On a deflection scoreboard, Agent A wins by 15 points and looks like the better buy. On the metric that matters - problems solved - Agent B is well ahead, and Agent A is generating 350 hidden failures that will resurface as repeat contacts, complaints, or churn. A team that optimizes deflection picks the worse agent.
Why deflection can mask bad customer experience
Deflection's core flaw is that it is silent about the customer. It measures a queue, not a person. The events that destroy customer experience - giving up, getting a wrong answer, being trapped in a loop, repeating yourself across channels - all register as deflection successes. The metric and the experience point in opposite directions.
This matters more as the stakes of the ticket rise. For "where is the gym open until," a deflected non-answer is a minor annoyance. For "my account is frozen and I cannot access my money," a deflected non-answer is a customer who is now frightened, angry, and one tweet away from a regulator complaint. In fintech, healthcare, insurance, and gaming - industries where the contacts are consequential - the cost of a false deflection is highest, which is exactly where leading on deflection rate does the most damage.
Three specific failure patterns deserve naming, because each one improves a deflection dashboard while harming customers:
The containment trap
When deflection is the target, the rational move is to make leaving harder. Hide the human handoff, add friction to escalation, loop the customer through self-service. Containment goes up. So does the number of people who needed help and could not get it. Deflection rewards the behavior that, past a point, defines bad support.
The silent-churn problem
A deflected-but-unresolved customer usually does not file a complaint. They just leave, or they stop trusting the channel and route around it. Because the failure is silent, it never shows up in the deflection number, the CSAT survey (they did not respond), or the escalation count. The damage is real and the dashboard is green. This is the most expensive blind spot deflection creates.
Channel arbitrage
Deflect the chat, the customer calls. The chat counts as deflected; the call counts as new volume; the issue is now handled twice and resolved once, at higher total cost. A deflection metric scoped to a single channel will report progress while overall cost per solved problem gets worse.
None of this means deflection is useless. As a capacity-planning input it is fine. The error is treating a containment metric as a quality or value metric, and buying or optimizing against it.
How to measure resolution rate honestly
Resolution is the better metric, but only if you define and verify it carefully. A resolution rate with a weak definition behind it is just deflection with a nicer label. Four things make the number trustworthy.
1. Define resolution in business terms, before launch
Resolution is not a universal constant; it depends on the workflow. A resolved dispute means a credit posted or a clear denial with the reason stated. A resolved KYC unlock means a verified identity and a usable account. A resolved billing question means the customer understood the charge and did not contact you again about it. Write these definitions per workflow, in plain language, and agree them with the team that owns the outcome (often compliance or operations, not just support). If you cannot state what "resolved" means for a ticket type, you cannot honestly measure it.
2. Verify independently, not with self-grading
The agent that did the work should not be the sole judge of whether the work was done. Independent verification - a separate QA layer that did not generate the answer - is what separates a real resolution rate from a self-congratulatory one. This is where automated QA matters: a second system that reviews the ticket against the resolution definition and flags the ones that do not meet it.
Lorikeet runs this as a dedicated agent. Lorikeet pairs its customer-facing Concierge with Coach, an analytics and quality-assurance agent that performs automated QA on tickets, scores ticket quality, runs root-cause analysis, and verifies resolution - effectively the AI evaluating the AI. Coach is deployable on its own at roughly $0.10 per ticket, including over the top of a human team or another vendor's agent, which means the verification layer does not have to come from the same system that produced the answer.
3. Sample enough to be representative - ideally all of it
Traditional QA reviews 1-3% of tickets, which is too thin to catch rare-but-serious failures, the exact failures that matter most in regulated support. Reviewing 100% of tickets removes sampling error and catches the long tail. Automated QA makes full coverage affordable in a way that manual review never was.
4. Watch repeat contacts and downstream signals
The strongest evidence a ticket was resolved is that the customer did not come back about it. Track repeat-contact rate on the same issue, reopen rate over a window long enough to be meaningful, and where possible the downstream business signal (did the disputed charge get re-disputed, did the unlocked account stay active). These are harder to game than a survey because they reflect what the customer did, not what they said.
A practical note on validation before launch: the most defensible programs test the agent against historical tickets and adversarial scenarios before it goes live, so the resolution rate you report in production is one you already stress-tested. Lorikeet uses simulation and red-teaming pre-launch for exactly this, then layers inbound message checks, outbound guardrails, and 100% post-facto QA. The point is not the specific stack; it is that resolution should be proven, not assumed.
How pricing models shape the metric you get
Metrics follow money. How a vendor charges you determines which behavior the vendor is incentivized to produce, and that shows up in the resolution-versus-deflection gap.
Per-seat and per-conversation pricing
Per-seat pricing (the legacy helpdesk model) is neutral on resolution - you pay for capacity regardless of outcome. Per-conversation pricing rewards volume: the vendor is paid whether or not the conversation solved anything, which quietly aligns the vendor with deflection rather than resolution. Neither model gives the vendor a reason to care whether your customer's problem was actually fixed.
Per-deflection and "outcome" pricing
Pure deflection pricing is the most misaligned: the vendor is paid for keeping tickets away from humans, which is the exact behavior that produces the containment trap. Outcome-based pricing is better in theory - you pay only when the AI fully resolves a case - but the definition of "resolved" is doing all the work. If the vendor defines resolution and grades its own outcomes, "outcome pricing" can collapse back into deflection pricing with extra steps. And any model that pays only on full resolution creates a subtle selection pressure toward easy tickets and away from the hard ones, which in regulated support are the ones that matter.
Per-resolution pricing with a customer-held definition
The model that aligns incentives most cleanly is per-resolution pricing where the customer, not the vendor, defines and can veto what counts as a resolution. That single design choice removes the incentive to inflate: the vendor only earns when the buyer agrees the problem was solved, so padding the number with abandonments or non-answers does not pay.
Lorikeet prices this way. Resolutions run roughly $0.80 for chat, email, and SMS and about $1.00 for voice, Coach QA is about $0.10 per ticket, and escalations are not charged - if the agent hands off to a human, you do not pay for that contact. Critically, the customer holds the veto on what counts as a resolution, so the billed number and the real number are the same number. As a reference point, the Scale plan is 48,000 resolutions for $48,000 a year. Set against a human baseline of roughly $1.25 to $4 per handled ticket, the model lets you compare cost per solved problem rather than cost per contained contact.
The general principle holds regardless of vendor: ask who defines resolution, who verifies it, and what the vendor is paid for. If the answers are "the vendor," "the vendor," and "deflection," the reported number will drift away from your customers' reality.
Where deflection-oriented tools still fit
Deflection-first tools are not a scam; they are built for a different job. FAQ chatbots and self-service deflection layers - and the deflection-rate reporting in platforms like Zendesk AI, Ada, Fin by Intercom, and similar tools - do real work on high-volume, low-stakes, informational queries. For "what are your hours," "how do I reset my password," or "where is my order," a fast self-service answer that keeps the ticket out of the queue is a genuinely good outcome, and deflection rate is a reasonable proxy for it.
The fit breaks down as ticket complexity and stakes rise. When a contact involves an action (move money, file a dispute, change a beneficiary), a multi-step workflow, or a regulated decision, "did it avoid a human" stops being a useful proxy for "did it go well." That is the band where resolution rate, independent verification, and per-resolution pricing earn their keep, and where Lorikeet is built to operate - complex and regulated support across chat, email, voice, SMS, and WhatsApp, with the audit trail to back the resolution claim.
An honest limitation: this approach is heavier than dropping a deflection widget on a marketing site. Defining resolution per workflow, wiring independent QA, and running pre-launch simulation is more setup than flipping on an FAQ bot, and it is overkill if your support volume is mostly simple informational queries. The trade is that you get a number you can defend to a CFO or a regulator, not just a number that looks good on a slide.
A practical checklist for support leaders
If you are evaluating an AI support agent or auditing one you already run, these questions surface the resolution-versus-deflection gap quickly:
What exactly does your "resolution rate" count, and who decided a ticket was resolved - the agent itself, or something independent?
What share of "deflected" tickets resulted in a repeat contact on the same issue within two weeks?
What percentage of tickets get QA review, and is it sampled or 100%?
Show me the resolution rate on the hardest 20% of ticket types, not the blended average.
If I define resolution differently than you do, does the number change - and who has the final say?
What am I billed for: seats, conversations, deflections, or resolutions I agreed to?
What happens to a customer who says "I want a human" immediately - is that a failed deflection or a clean escalation?
The pattern across all seven: push past the headline number to the definition and the verification behind it. A vendor confident in its resolution rate will welcome the questions. A vendor selling deflection will steer you back to the headline.
If you want a resolution number you can defend - one your team defines and an independent QA layer verifies on every ticket - see how Lorikeet measures and prices on real resolution.
Key takeaways
Deflection rate measures avoidance (no human touched the ticket); resolution rate measures the outcome (the problem got solved). They diverge wherever deflection includes abandonment, non-answers, or channel-switching.
Deflection can mask bad CX because giving up, getting a wrong answer, and silent churn all count as deflection wins. The cost is highest in regulated and complex support, exactly where deflection is most often used as the headline.
Resolution rate is only honest with a clear per-workflow definition and independent verification - ideally automated QA on 100% of tickets, not the AI grading itself or a 1-3% sample.
Pricing encodes incentives: per-conversation and per-deflection reward volume; per-resolution pricing with a customer-held definition (and uncharged escalations) rewards solved problems.
Deflection-first tools fit high-volume, low-stakes queries; resolution-first measurement and pricing fit complex, regulated, action-taking support.
