Sooner or later, every IT service desk manager with an AI assistant gets asked for one number: how many tickets is it saving us? Deflection rate is the standard answer, and it's a reasonable one. The assistant handles a conversation, no ticket gets opened, and an analyst gets that time back.
The trouble starts when someone asks what's behind the number. A conversation that ended without a ticket might have ended because the employee's VPN came back. It might also have ended because they gave up, closed Teams, and walked over to ask the colleague who always knows. Most deflection rates count both as wins, so the figure on the slide can be accurate and still impossible to explain.
An honest deflection rate is entirely possible. It comes down to what you count, where you count it from, and whether the counting rule is written down where IT leadership can read it.
Key Takeaways
- A ticket deflection rate counts conversations that ended without a ticket. It doesn't show whether the problem was solved, so an employee who gave up counts the same as one who got an answer.
- Confirmed resolution, measured from the employee's own answer to "did this solve it?", is the number that holds up when a CIO asks what's behind it.
- A defensible rate shows its denominator and its counting rule, and every percentage can be traced back to the conversations it came from.
What Is Ticket Deflection?
Ticket deflection is the share of support requests resolved through self-service, a knowledge base, or an AI assistant before anyone opens a ticket. In IT, it's the main way to show that self-service is reducing service desk workload. CRM teams call the same idea case deflection. The usual formula looks simple:
Deflection rate = conversations that ended without a ticket ÷ all in-scope conversations × 100
The metric comes from customer support, where self-service portals were judged on how many contacts they kept away from the phone queue. IT service management adopted it with the shift-left movement, which aims to move routine work to the cheapest level that can handle it, ideally the employee. It became the default because it's so easy to count. Every chatbot log already knows whether a ticket was created at the end.
But a conversation that ends without a ticket hasn't necessarily solved anything.
What Does a Deflection Rate Leave Out?
Take five conversations that all ended without a ticket. In the first, the employee followed the steps and their password reset worked. In the second, they said thanks and left. In the third, they stopped replying halfway through. In the fourth, they decided the problem could wait until Monday. In the fifth, they phoned the service desk anyway, and that call was logged on a different channel.
A standard deflection rate counts all five as deflected. Only the first one is a confirmed resolution. The second is probably fine. The other three range from unknown to a problem that has simply moved somewhere less visible.
Customer service research shows how big that gap can get. As we read Gartner's August 2024 release, a survey of 5,728 customers conducted in December 2023 found that only 14% of customer service issues were fully resolved in self-service (Gartner). That's external customer service, not IT, so the percentage shouldn't be carried over. The pattern carries over well, though: plenty of self-service sessions end, and far fewer of them end with the problem gone.
For the person reporting the number, that's a real risk. If the deflection rate goes up while the queue stays the same size, IT leadership will ask why, and you'll need to show which conversations the rate was based on.
Deflection, Containment, and Resolution: Which Number Can You Defend?
These three terms are often used as if they meant the same thing. They count different things, so it helps to be clear about which one you're reporting.
Deflection Rate
The share of in-scope conversations that ended without a ticket. It measures workload avoided at the moment of the conversation. On its own, it can't tell a solved problem from an abandoned one.
Containment Rate
The share of conversations that stayed with the assistant and were never handed to a person, whether through a live chat transfer, a phone callback, or a ticket. Containment comes from contact-center analytics and usually counts the handoff itself. So a conversation can be contained (no transfer) and still not deflected (the employee filed a ticket in the portal ten minutes later). Containment is stricter than deflection about handoffs, but it doesn't tell you whether the problem was solved either.
Confirmed Resolution Rate
The share of in-scope conversations where the employee said the problem was solved:
Confirmed resolution rate = conversations where the employee confirmed it was solved ÷ all in-scope conversations × 100
This is the number to lead with when you report to IT leadership. It's lower than the deflection rate, and it has the advantage that every point of it traces back to an employee saying yes.
Recontact Rate
The share of resolved or deflected conversations followed by a ticket or a new conversation about the same issue within a set window, such as 72 hours. It's the check on the other two. A deflection rate that rises alongside recontact is workload that has moved somewhere else.
Escalation Quality
The escalation quality metric rarely makes it into a dashboard, which is a pity. When the assistant can't resolve a question, the ticket it produces can either save an analyst time or cost them time. A ticket that arrives classified, prioritized, and listing what the employee already tried is a smaller piece of work than a one-line "VPN broken." Deflection rates ignore escalations entirely, even though every escalated ticket ends up with an analyst. A well-prepared ticket saves time at each step after that: triage, routing to the right team, and the first reply to the employee.
One Set of Conversations, Counted Three Ways
The clearest way to see the gap is to count the same conversations under different rules. The numbers below come from one run of the Squirro IT Helpdesk Deflection Agent demo, which uses sample data for a fictional company called Northwind. They're demo figures, included here because the demo shows the full breakdown behind its rate.
The assistant swept 21 conversations. Three were out of scope (one employee asked whether the canteen was open on Friday, which is a question every helpdesk log will recognize) and were excluded. The remaining 18 broke down like this:
| How the conversation ended | Conversations | Counted as deflected? |
|---|---|---|
| Employee said it was solved | 9 | Yes |
| Employee replied, but not with a yes or no | 1 | Yes |
| Employee didn't answer the check | 2 | Yes |
| Employee said it was not solved | 1 | No |
| Ended in a ticket | 5 | No |
Under the standard rule, that's a 66.7% deflection rate: 12 of 18. Count only the employees who confirmed the fix and it becomes a 50% confirmed resolution rate: 9 of 18. Both numbers are correct. They just answer different questions. The difference between them is three conversations: one unclear reply and two employees who never answered the check. If you report 66.7%, expect to be asked about those three.
In the demo, the counting rule is shown directly under the rate: a conversation counts as deflected when no ticket was filed and the employee didn't say no, so a conversation with no answer counts as deflected too. That's a generous rule. Showing it next to the number means anyone reading the dashboard can see how the rate was calculated and decide how much weight to give it.
Is There a Gartner Benchmark for IT Service Desk Deflection?
We could not find one. Searches for a Gartner IT service desk deflection rate are common, and vendor blogs regularly credit Gartner with ranges such as 20% to 30%, or 40% to 60% for AI-assisted programs. In our review, none of those figures linked back to a Gartner publication. The Gartner figure we could trace, the 14% self-service resolution rate above, measures external customer service and doesn't measure deflection at all.
So what can you benchmark against? Your own baseline is the most defensible option. Measure ticket volume per category before the assistant goes live, then track confirmed resolution and recontact afterwards, with one counting rule applied throughout. Benchmarks from other organizations are usually based on different counting rules, so they're hard to compare with your own numbers. If a Gartner figure shows up in a business case, ask for the link.
What Makes a Deflection Rate Defensible?
A deflection rate is calculated from the assistant's conversation log, so it can only be as reliable as what that log records. In our experience, four things make a rate much easier to defend.
The outcome is recorded by the employee. An assistant that ends every answer with the same check ("Did this solve your problem? A simple yes or no is enough.") gets the outcome from the employee directly. A thumbs-up widget that few users bother to click, or an outcome the model inferred from the tone of the conversation, is much less reliable.
The denominator is on the screen. "66.7% deflected" is hard to judge on its own. Next to "12 of 18 in-scope conversations, 21 swept" and the time of the last sweep, it's clear how many conversations the rate is based on. Out-of-scope questions are excluded and counted separately, so they don't push the rate up.
Every percentage opens into conversations. A reviewer can click "didn't answer the check" and read the two conversations behind it. Being able to check the underlying conversations is what makes the rate credible.
Nothing on the dashboard is estimated. The Squirro demo's analytics view deliberately has no cost-avoided tile and no satisfaction score, because neither is measured there. Cost estimates are useful, but they're better kept in a business case where the assumptions can be written out.
What the Architecture Changes for the Employee, the Analyst, and the Person Reporting the Number
The capabilities behind an IT helpdesk assistant are easier to judge by asking who benefits from each one. Here's how they map onto the three people who work with the assistant every day.
For the Employee Asking the Question
- Answers from your own documentation, with sources. The assistant answers from the organization's IT knowledge base and cites the articles each step comes from. The instructions match the organization's own systems, and the employee can check where they came from. This is AI grounding applied to a helpdesk: the retrieval layer decides what the assistant can say, and every answer can be traced back to its source.
- A clear answer when it doesn't know. When the documentation doesn't cover a question, the assistant says so instead of improvising. A confident wrong answer that ends without a ticket would be counted as a deflection, and the employee would leave with the wrong fix.
- Describing the problem only once. If a ticket is needed, the assistant drafts it from the conversation and asks for any missing details up front, so nobody has to follow up days later for the same information.
- Updates in the same place. Employees can check on a ticket's status in the chat where they first asked the question.
For the Analyst Who Gets the Escalation
- A ticket that's ready to work on. Escalated tickets arrive in service desk tools like Jira and ServiceNow with a summary, a category, a suggested priority, and what the employee already tried, routed to the right team.
- Classification IT controls. Categories come from a service taxonomy that IT owns, and the same taxonomy classifies every ticket, so routing doesn't depend on the model's judgment. It's a small, practical version of a semantic layer: one agreed set of definitions that the assistant, the tickets, and the analytics all share.
A person approves every write. The assistant can draft a ticket, but a person approves it before anything reaches the service desk. Only the part of the system responsible for escalation can file tickets at all, a common pattern in auditable agentic AI, where permissions limit what each agent is able to do. Every conversation is kept in an audit trail with its answer, its sources, and the steps the agents took. Approval gates and audit trails are where AI governance gets enforced in day-to-day use.
For the Person Reporting the Number
- Counts based on what actually happened. Every figure on the dashboard is counted from the conversation log and the ticketing tool, with no estimated values.
- A list of documentation gaps. Escalations grouped by category show which topics the knowledge base doesn't cover yet, which gives whoever owns the documentation a clear list of what to write next.
- Privacy in the audit trail. Conversations can be reviewed using roles and pseudonyms, without exposing the names of the employees who asked.
- A knowledge base someone owns. New content becomes available to the assistant when someone adds it, and resolved tickets don't change what the assistant says without review. There's always a person accountable for the content.
This approach has a limit. An assistant that only answers from documentation is only as good as that documentation. Where runbooks are thin or out of date, it will escalate more often in the first months, and its deflection rate will start lower than that of an assistant willing to improvise answers.
Those early escalations still do useful work. Each one reaches the service desk as a complete ticket, so analysts spend less time collecting information before they can start. The categories that escalate most show where the documentation needs attention, and as those gaps are filled, more questions get answered directly. Because the rate is based on answers employees have confirmed, the improvement over time is one you can explain.
Where Else Does the Same Pattern Apply?
The IT helpdesk is rarely the only internal desk answering the same questions every day. Look at the out-of-scope column in any IT assistant's log and you'll see the others: the canteen, parking permits for the Berlin office, a remaining holiday balance. Employees will ask the IT assistant about anything, which tells you what other questions people would like answered.
The same architecture carries over wherever four conditions hold: the answers live in documents someone maintains, the questions repeat, there's a case or ticket tool to escalate into, and someone has to report on the load. Teams that tend to meet all four include:
- HR service centers, for leave, benefits, and policy questions. Personal data such as an individual's holiday balance sits in HR systems and needs its own access controls, so the documented policy is the natural starting point.
- Finance shared services, for expense, travel, and approval-matrix questions that interrupt analysts throughout the month.
- Procurement, for purchasing thresholds, supplier onboarding steps, and which form applies to which spend.
- Workplace and facilities, for room equipment, access badges, and office services.
- Compliance and policy desks, for gifts and entertainment rules, conflicts of interest, or regulatory guidance, where a cited answer and an audit trail are even more important.
In the Squirro demo, the knowledge base, the agents, the ticket queue, the analytics, and the audit trail form one platform layer configured for IT, and the same layer runs Squirro's HR and regulatory demos. The Agent Catalog includes related agents for expense and budget policy, employee policy and benefits, and regulatory document search. The measurement questions in this article apply to each of them, because the counting rule works the same way whether the questions are about VPNs or expense claims.
In our experience, the second deployment is cheaper than the first, because connections, permissions, and the governance review are already in place. Our post on proven starting points for AI agents in manufacturing shows how that played out at Bühler.
What Should You Measure in the First 90 Days?
If you're about to launch an AI assistant on your IT helpdesk, or you've inherited one with a rate nobody can explain, these checks will make the number easier to defend:
- Baseline before go-live. Record ticket volume by category for at least a month, so later comparisons are made against your own service desk.
- Write down the counting rule. Decide whether silence counts as deflected, how out-of-scope questions are handled, and what the recontact window is. Put the rule on the dashboard.
- Report confirmed resolution next to deflection. Showing both numbers, and the gap between them, gives IT leadership a much clearer picture than either one on its own.
- Read the escalated tickets. Once a month, check whether escalations arrive complete enough to work. The fields most often missing tell you what to fix in the intake form.
- Treat the escalation list as a writing plan. The categories that escalate most are the runbooks to write or update next quarter.
- Check recontact by category. A category with high deflection and high recontact needs a closer look.
None of this needs an AI assistant, strictly speaking. It's easier with one that records outcomes and shows its working.
Want a deflection rate you can defend? See how the Squirro IT Helpdesk Deflection Agent answers employees from your knowledge base with cited steps, turns the questions it can't answer into ready-to-approve tickets in service desk tools like Jira and ServiceNow, and shows exactly how every deflection is counted. Try the interactive demo, no sign-up required.
