Mike HeapMike is an experienced Product Manager who focuses on all the “non-development” areas of My AskAI, from finance and customer success to product design, copywriting, testing and more.
Table of Contents
- What is ticket deflection?
- How does ticket deflection actually work?
- How long should the no-ticket counting window be?
- Does an article view count as a deflection?
- How is deflection different from containment and resolution?
- The Three Exits: where does a deflected contact actually go?
- Exit 1: Answered
- Exit 2: Diverted
- Exit 3: Abandoned
- What is a good ticket deflection rate?
- When is a high deflection rate a warning sign?
- What does ticket deflection look like in real rollouts?
- Swytch: 81% AI deflection
- Honeygain: 90% AI resolution with 78% AI CSAT
- A premium accessories brand: 64% with 85% AI CSAT
- What should I do this week to check my deflection rate?
- When is deflection the right number to chase?
- The takeaway
- FAQs
Created time
Sep 4, 2026 01:30 AM
Title length (<60)
Author
Last optimised
Ecomm?
Image
Publish date
Aug 14, 2026
Video
Slug
ticket-deflection-explained
Featured
Type
Article
Ready to Publish
Ready to Publish
Deflection counts the contact that never happened. It cannot tell you whether that person was helped, or whether they simply gave up.
Every self-service pitch you have ever sat through leads with deflection, the share of incoming questions that get answered before anyone opens a ticket. If somebody has put a deflection target in front of you, the field median to anchor against is around 70%, and a rate far above it is worth checking before you trust it. The number is recorded at the point of non-contact, so a solved problem and a customer who gave up without a word are counted the same way.
I understand why it leads. It is the one number that puts a figure on work your team never had to touch.
A help center article answers the question. A chatbot answers it in the widget, and the ticket never arrives. When it works, that is cheaper, faster and better for the customer.
That is the catch I keep running into. At the moment of measurement, "I got my answer", "I phoned instead" and "I gave up" look identical. What the number means is not settled until later.
I'm Mike, co-founder of My AskAI. We run AI customer service for 200+ businesses, on Zendesk, Intercom, Freshdesk, Freshchat, Gorgias and HubSpot.
A deflected contact ends up in one of three places, and only one of them is a customer who got their answer.
What is ticket deflection?
TL;DR: Ticket deflection counts a support contact that never turned into a ticket, because the answer got to the person somewhere else first. It records the absence of a ticket, and stays silent on whether the problem got solved.
The published definitions agree on what it means. Deflection is resolving a customer's issue through self-service, automation or something proactive, before it becomes a ticket an agent has to touch.
I've seen pages describe it as diverting a query to another channel before it escalates. Others describe the tools you put in the way: the FAQ, the knowledge base, the chatbot, the community forum.
That definition is fine. If your help center answers ten thousand questions a month that would otherwise have landed in your inbox, that is real work removed and real money saved.
I have no argument with the ambition.
The gap opens up when you compare what the definition promises with what the metric records. Almost every version I have read uses the word "resolving".
The measurement checks only that a ticket did not appear.
Those two things diverge exactly when you would most want to know.
A customer who reads your refund policy and accepts it is a deflection. A customer who reads it, gives up and charges back (no ticket, no complaint) is also a deflection. Both land in the same row of your report.
So the working definition I use is narrower. Ticket deflection is a support contact that never opened, because the answer reached the person on another surface first.
Whether it was the right answer is a separate question. We keep it as a separate number.
How does ticket deflection actually work?
TL;DR: A deflection is recorded when someone reaches a self-service surface, finds an answer, and opens no ticket inside a set window. Three things decide your number: which surfaces you count, how long the window runs, and what happens to contacts on channels you are not watching.
Deflection is a family of events created on different surfaces, and the first decision I ask teams to make is which surfaces count.
Most teams count at least the help center: a search that returns results, or an article that gets read. Then add the AI agent answering in the widget before a ticket is created. Then the in-product answer, the community thread, and the auto-reply that lands before any human sees the message.
Every one of those is defensible. Which combination you pick will move your number by tens of points, and no two vendors pick the same set.
That is one reason I distrust two published deflection rates sitting side by side.
How long should the no-ticket counting window be?
The second decision is time. In my experience it is the one nobody makes deliberately.
A deflection event only becomes a deflection once a chosen period passes with no ticket from that same person. Metabase's metric documentation for deflection rate states the mechanic and offers 72 hours as the pragmatic default.
That is long enough to catch the delayed ticket, and short enough that an unrelated one weeks later does not erase a good outcome.
Move that dial and the same month of traffic scores differently. At 24 hours you count people who were still typing.
At seven days you erase good deflections, because somebody wrote in about something else entirely (a shipping question three days after a returns question, say).
Windowing also needs an identity that joins up. The help center visit, the bot conversation and the help desk ticket all have to point at the same person, or you have no way of knowing whether they came back.
Anonymous traffic cannot be windowed at all.
Does an article view count as a deflection?
The most common way I see this go wrong is counting article views as deflections. A view tells you only that somebody arrived.
That is how a team reports 90% deflection while ticket volume keeps climbing. Both facts sit in the same weekly report. I have sat in the meeting where nobody notices they contradict each other.
You see the same softness in the worked examples people publish. One widely repeated version counts 1,000 community visitors, notes that 600 left without escalating, and calls that a 60% deflection rate.
There is no window, no identity join, and nothing that tells me whether those 600 got anywhere.
How is deflection different from containment and resolution?
A ticket that opened and was then closed by AI counts as containment or resolution, sitting on a different part of the journey. Once the contact happens, the question becomes what the AI did with it.
The three-way decoder lives in our post on containment versus deflection versus resolution, with containment rate covered on its own.
Resolution is the number I care most about, because it at least implies an issue got solved. Deflection only tells you a ticket did not open.
The arithmetic is straightforward: self-service resolutions over total demand. Our explainer on deflection rate carries the formula, the denominator choices and a worked example.
The Three Exits: where does a deflected contact actually go?
TL;DR: Every deflected contact leaves by one of three doors: Answered, Diverted or Abandoned. Deflection counts all three identically, because at the moment of measurement they are identical. They only separate afterwards.
I built the three-exit framework around one structural problem in the metric.
Deflection is recorded at the instant of non-contact. At that instant, a happy customer, a customer who went elsewhere and a customer who quit on you produce exactly the same data.
They separate afterwards, in ways you can see if you go looking. So I think of a deflected contact as leaving through one of three exits. Your deflection rate is the sum of all three.
Exit | What happened to the customer | What deflection records | What it costs you | How you detect it |
Exit 1: Answered | Found the answer, with no reason to write in | One deflection | Nothing. This is the saving deflection promises | No contact on any channel inside your window, plus a positive signal on the session |
Exit 2: Diverted | Contacted you on a channel you were not counting | One deflection | The same work again, at a higher cost per contact | Reopened-as-ticket rate, and deflection rising while total contacts stay flat |
Exit 3: Abandoned | Gave up. No contact, no purchase, no renewal | One deflection | Revenue, with no row in any support report to show it | Deflection rising while conversion, renewal or repeat purchase softens |
None of this is tool-specific. We built the framework to work on Zendesk, Intercom, Freshdesk, Freshchat, Gorgias or HubSpot, with the reporting you already have.
Exit 1: Answered
The person got what they needed and had no reason to write in. This is the exit deflection is meant to be measuring. When it dominates your number, deflection is doing exactly the job it promises.
The signal is quiet by nature, so I want two things in place. First, no contact from that customer on any channel inside your window. Second, self-service satisfaction holding steady over the same period.
Anything that gives you an explicit success marker will do: a thumbs-up on the article, a CSAT score on the bot conversation, a resolved tag on the session.
Pair the closed window with a positive signal, and Exit 1 becomes the one exit I can actually measure.
Exit 2: Diverted
The contact happened somewhere you were not counting.
A phone call. An Instagram DM, or a second email to an address that does not feed your help desk. A chargeback with the bank, or a one-star app store review your team reads about a week later (the one I check first when a launch goes wrong).
The work moved, and it usually moved to a channel with a higher cost per contact and worse reporting.
Every one of those contacts is countable if the channel routes into your help desk. The fix is coverage: get every channel feeding your help desk before you go looking for the leak.
I measure this with the reopened-as-ticket rate: deflected people who file the same question as a ticket shortly afterwards. A rising deflection rate next to a flat total contact count means the work moved without going away.
That gap is Exit 2.
Pulling the numbers is less work than it sounds. We use the same report ourselves: contacts by requester, over a date range.
That covers every channel the help desk routes for you, so an Instagram message counts exactly as much as an email. Join that list to your deflected sessions, and the diverted share falls straight out of it.
Exit 3: Abandoned
They gave up. No contact, no purchase, no renewal, or a refund request that turns up three weeks later with no supporting history.
This is the most expensive exit. I worry about it more than the other two. It is also the only one that is completely invisible in a support report.
A support report can only see contacts, and Exit 3 is defined by the absence of one. The first sign of it lands in revenue.
The signal lives outside support, so that is where I go looking. Watch for deflection climbing while conversion, renewal or repeat-purchase rate softens. Falling self-service satisfaction next to a rising deflection rate is the same warning in a smaller frame.
The first person to notice is usually not in support. Finance notices refunds creeping up, or growth notices trial conversion softening, in exactly the weeks your deflection chart looked its best.
We see this in our own resolution numbers. When reaching a person is easy, the split between the three exits is accurate by construction. Whatever the self-service layer cannot settle goes to a human.
When reaching a person is hard, the barrier that lifts your number is the same one manufacturing Exit 3.
What is a good ticket deflection rate?
TL;DR: The field median sits around 70%. Treat it as an anchor, never a target: published numbers are best-case, the labels underneath them are not the same metric, and how well your own policies are written down moves the figure a long way.
Our own benchmark study covers 195 rated deployments, and the median AI-handling rate lands at 70% whatever label the vendor puts on it. That is the number I give people when they ask what normal looks like.
Three reasons to check it against your own tickets first.
First, almost every rate you see quoted is a best case. It is the number a vendor got on a well-configured account with good documentation behind it, published because it was the good one.
The only way to find out what you would get is to run your own content through a trial and look. Take anybody else's headline with a grain of salt until you have.
Second, the variance between companies is enormous. Most of it comes from your own setup.
Two ecommerce brands with the same ticket mix can land a long way apart, and most of that gap comes down to how well their own policies are written down. Buy for the headroom a tool gives you, and treat any figure a vendor shows you today as marketing (ours included).
Third, these are all a point in time. Models improve, your documentation improves, your ticket mix changes with your product. A rate is a reading, taken on a given day, of a system you are still changing.
One median is enough. I am wary of publishing a spread, because the flattering percentile becomes the target and the rest gets ignored.
Every figure inside that spread came from a different setup, with different documentation behind it, so check the one anchor against your own trial.
The figure you eventually budget against is your own cost per resolution.
I hit the same arithmetic trap every time people start comparing figures. A number labeled "deflection" and a number labeled "resolution" count different events, at different points in the journey, so the gap between them means nothing.
In our own corpus the label attached to a figure moves the median on its own. A vendor quoting 85% deflection against a rival quoting 72% resolution is not evidence of anything.
When is a high deflection rate a warning sign?
TL;DR: A deflection rate can be driven to 100% by making it impossible to reach a person. That is why the number needs a second number beside it, and why a rate well above the field median deserves a check before it goes in the board pack.
You could have a perfect 100% deflection rate tomorrow by making it impossible to speak to anybody.
Strip the contact form. Hide the email address, and put the chat widget behind six clicks of article suggestions (none of which answer the question). Nothing would resolve, your customers would be furious, and the metric would be spotless.
Teams do this to themselves by accident, one reasonable-sounding decision at a time. That is the version I see far more often.
Somebody adds a required article read before the contact form. Somebody moves the "talk to a human" button below the fold. Each change nudges the number up, everybody is pleased, and Exit 3 fills up (with no row in any report to show it).
So a high deflection number with no verified resolution behind it buys you deferred work. Exit 2 comes back as a phone call at a higher cost per contact. Exit 3 comes back as churn you will attribute to something else six weeks later.
Both come back somewhere other than the cost-to-serve line you were trying to cut, so I price them into the deflection saving before I believe it.
The check takes fifteen minutes. From a cold session, as a customer who has never used your product, count the steps between landing on your site and reaching a human.
More than two steps and part of your deflection rate is manufactured. No amount of dashboard staring will tell you which part.
On our side this is what Handover & Escalation Guidance is for. You write the rules in plain language, and the agent hands the conversation to a person when it needs to.
That covers the obvious cases: it cannot answer, it picks up frustration, the customer asks for a human, or the ticket lands on a topic you have flagged for escalation. The rules sit in the dashboard and you can change them without a developer.
What does ticket deflection look like in real rollouts?
TL;DR: Swytch runs at 81% AI deflection on Zendesk, Honeygain at 90% AI resolution with 78% AI CSAT, and a premium accessories brand at 64% with 85% AI CSAT. A second measure, CSAT or response time, makes each headline number worth trusting.
Our own customers land in very different places, on different helpdesks and with different ticket mixes.
Swytch: 81% AI deflection
Swytch sells e-bike conversion kits and runs support on Zendesk. Their AI agent handles 4,050+ tickets a month entirely on its own, at an 81% AI deflection rate. Response times across the board went from days to minutes.
The volume is what makes that figure meaningful. At four thousand tickets a month a single bad week barely moves the rate (at a few hundred, one bad week is most of the figure).
Their ticket mix is the ordinary ecommerce one too: order status (the WISMO pile), plus the fit and compatibility questions that come with a conversion kit. Our Swytch case study has the full rollout.
Honeygain: 90% AI resolution with 78% AI CSAT
Honeygain runs a consumer rewards app on Zendesk, with roughly 3,400 tickets a month. Their AI agent resolves about 90% of them, and holds 78% AI CSAT while doing it.
A resolution figure with a satisfaction figure beside it tells you the tickets ended, and that the people on the other end were reasonably happy with how it went. That pair is what I look for before I believe a rollout number.
78% on a consumer app with a difficult ticket mix is a strong result. Our Honeygain case study covers how they got there.
A premium accessories brand: 64% with 85% AI CSAT
The third is a premium accessories brand running Gorgias, at roughly 2,900 tickets a month. The AI agent handles 64% of them, at 85% AI CSAT.
64% is the lowest number of the three. It sits below the field median and carries the highest satisfaction score of the set.
The second number is the one I check first, on all three of these.
Swytch is the only one of the three measured as deflection, and the other two report resolution, so the three headline figures do not sit on one scale. On whether the customer got somewhere, all three are working.
What should I do this week to check my deflection rate?
TL;DR: Sort last month's deflected contacts by which exit they took, then stop reporting the number on its own.
Three things, none of which need a new tool and none of which are about raising your rate.
- Sort last month by exit. Pull your deflection-flagged sessions and join them to any contact from the same customer, on any channel, in the following seven days (a full week, so a delayed email still counts). If your team tags by ticket reason, sort the joined list by tag and the pattern lands faster. Budget around two hours, and expect the Exit 2 share to come back higher than your team guesses.
- Give the number two companions in the weekly report. The two I ask for are total contacts across every channel, and resolution rate with satisfaction attached to the resolved set. Around thirty minutes to wire up. If deflection climbs while total contacts stay flat, you moved work without removing any, and now you can see it happening.
- Run the escalation test. From a cold session, count the steps to reach a person. Do it once on a weekday and once at the weekend (cover is thinnest then, and the path to a human is usually longest). Fifteen minutes a quarter, and more than two steps means part of your number is manufactured.
Sorting the exits will not move your deflection rate. It will tell you which part of it you can trust.
Cutting repeat contacts is different work: finding the ticket reasons that keep coming back, writing the answers properly, and putting them where customers already are. Our guide to reducing repetitive support tickets covers that job.
When is deflection the right number to chase?
TL;DR: Three cases where deflection is exactly the metric you want: anonymous pre-ticket traffic, seasonal capacity planning, and contacts that never needed to happen.
Deflection needs a chaperone most of the time. Three cases are the exception, where I am happy to let it stand on its own.
- Anonymous pre-ticket traffic. On a public help center you usually have no identity to join anything to. A resolution rate cannot be computed for somebody who never identified themselves, so deflection is the only signal that exists. Keep it as a separate, clearly labeled estimate, well away from your logged-in figures.
- Capacity planning. Heading into a seasonal peak, the useful question is how many contacts did not arrive, regardless of how each person felt about it. Deflection answers that directly, which makes it the right input for a ticket-to-headcount model.
- The contact that never needed to happen. "Where is my order" answered by a tracking link is a real removal, and nothing about it comes back later. In ecommerce that class of question is a large slice of total volume, and deflecting it costs the customer nothing.
The last case has a real limit. A team where reaching a human takes one step gets an accurate deflection number by construction, because nobody is trapped.
If that is you, the manufactured-Exit-3 risk mostly does not apply. Your deflection rate is then as trustworthy as I think this metric can be.
The takeaway
TL;DR: Deflection tells you a contact did not open. Sorting those contacts into Answered, Diverted and Abandoned is what makes the number worth reporting.
Deflection counts the contact that never happened. It counts it at the one moment when a solved problem and an abandoned customer look the same.
It is a good number that cannot travel alone.
The Three Exits are how I keep it straight. Answered is what you are hoping for, Diverted is work that moved without going away, and Abandoned is the one that costs you real money while staying invisible in a support report.
Your rate is the sum of all three.
If you do one thing, sort last month's deflected contacts by exit. Two hours of joining sessions to later contacts will show you where your deflection number actually comes from.
If you are still untangling which of the three metrics belongs in the board pack, our breakdown of containment versus deflection versus resolution settles it.
FAQs
What does call deflection mean?
Call deflection is the same event in a voice or contact center setting: a call that never reached an agent, because the answer arrived somewhere else first. That might be an IVR self-service branch, an SMS with a tracking link, a callback that resolved the question, or a web answer the caller found while waiting.
The mechanics are identical to ticket deflection, including the window and the identity problem. A caller who hangs up because they got their answer and a caller who hangs up after a long wait on hold both count as deflected. Either way, the counter goes up.
What does case deflection mean?
Case deflection is the same event again. Some vendors call a support ticket a "case", so case deflection counts a case that was never opened because a knowledge article or a community answer resolved the question first.
Check what surfaces each one counts before you compare the numbers (the two seldom line up).
What is self-service deflection?
Self-service deflection is the narrower subset, created on your help center and in-product surfaces. Article views that resolve, search results that answer, contextual help that appears at the point of confusion.
It is narrower than ticket deflection as a whole, which also picks up AI agents answering in a widget, community threads and auto-replies. I see teams report the two interchangeably. The self-service-only figure is usually the lower of the two.
How do I calculate ticket deflection rate?
The arithmetic is self-service resolutions divided by total demand. Total demand is self-service resolutions plus tickets created, and the Metabase metric definition sets out the same denominator.
The interesting decisions are all in the inputs: what counts as a self-service resolution, how long your no-ticket window runs, and whether you can join a person's help center visit to their later ticket. Our explainer on deflection rate walks through each of those with a worked example.
What is the difference between containment rate and deflection rate?
Deflection counts a contact that never opened. Containment counts a contact that did open and stayed inside the channel it arrived on, without being escalated to a human.
Metric | What it counts |
Deflection | A support contact that never turned into a ticket |
Containment | A contact that opened and stayed in its channel, with no escalation to a human |
Resolution | A contact whose issue got fixed |
Resolution is the third of the set, and the one to put in front of a board, because it implies an issue was actually solved. Our decoder on containment versus deflection versus resolution takes all three apart, and we have a separate piece on containment rate if that is the one you need.
What are the best ticket deflection strategies?
The short answer is that they are all one strategy. Work out which ticket reasons keep coming back, write those answers properly, and put them in front of the customer before they reach the contact form.
Our guide to reducing repetitive support tickets covers the ticket-reason analysis, the content work and the ordering.
