There is a number that appears in almost every AI support vendor's pitch deck: "ticket deflection rate." It is usually somewhere between 30% and 70%, it is always presented as proof that the product is working, and it is one of the most misleading metrics in customer support operations.
Deflection rate counts tickets that never became tickets — customers who submitted something through a bot or widget, got pointed at an article or FAQ, and did not immediately file a follow-up ticket. The numerator is "tickets we avoided." The denominator is "tickets we avoided plus tickets that still got filed." The metric sounds useful. The problem is what it does not count: the customers who closed the bot chat, waited 15 minutes in frustration, and submitted the ticket through a different channel. Or the ones who submitted it right away and just never responded to the deflection. Or the ones who did not submit a second ticket because they gave up entirely and canceled.
Deflection, as a metric, measures compliance with a process. It does not measure whether the customer's problem was solved.
The anatomy of a deflected ticket
Here is the typical flow when an AI chatbot deflects a ticket. A customer submits: "I was charged twice this month." The bot receives this, classifies it as a billing inquiry, and responds with: "Here's our billing FAQ and some common reasons for unexpected charges. Does this help?" The customer clicks through the FAQ, does not find anything that addresses their specific situation (because it was a double-charge, not a general billing question), and closes the chat.
In the deflection model, that interaction is a "deflection" — the ticket never reached an agent queue. The deflection metric ticks up. The customer experience was: I reported a problem, got pointed at an article that didn't help, and now I have to try again. In many cases the customer will submit again via email or phone. In some cases, especially for small charge amounts, they will just absorb the frustration and not retry. Both outcomes are bad, and neither shows up as a deflection problem.
Compare that to a resolution flow. The customer submits the same double-charge ticket. The system classifies it, queries the billing API, confirms a duplicate charge exists, issues a credit, and replies: "We found a duplicate charge from [date] and have issued a credit of $X to your account. You will see it within 2-3 business days." Ticket closed. Problem solved. Customer did not have to wait for a human, did not have to explain the situation again, did not have to submit twice.
That is resolution. The ticket did not get deflected — it got closed, by the system, with the actual action the customer needed.
Why deflection metrics look good even when the product is not working
Deflection metrics are easy to game, often unintentionally. If you deploy a bot that presents a CAPTCHA-style friction layer before a customer can submit a ticket, your deflection rate will be high. If you make your contact form harder to find and add a pre-contact FAQ interstitial, your deflection rate will be high. Neither of these things indicates that customers got better support.
The more honest measurement is CSAT delta. What happened to your CSAT scores after AI deployment, segmented by ticket type? If your CSAT went up on billing inquiries specifically, the automation is probably working. If CSAT went flat or down, you deflected tickets but did not resolve problems. The deflection rate looks good. The customer satisfaction does not.
We are not saying deflection is always bad or that steering users toward documentation is never appropriate. For pure discovery questions — "how do I export my data," "where is the keyboard shortcut for X" — an article link genuinely solves the problem. But for any question that involves the customer's specific account state, a system action, or a transaction, documentation is not a resolution.
What CSAT actually measures in automated support
CSAT surveys sent after AI-automated interactions have a measurement problem: customers who were deflected and then filed a ticket via another channel will rate the second interaction, not the first. The bot interaction that failed them may never get rated at all because no survey fires for a chat that ended without resolution. This means your deflection-oriented bot can appear to have neutral-to-positive CSAT while actively degrading the customer experience.
The cleanest CSAT signal for evaluating automation quality is the first-contact resolution rate paired with post-resolution CSAT. First-contact resolution (FCR) measures whether the customer's issue was closed in a single interaction without them needing to follow up. When automation is working, FCR should go up — because the ticket gets resolved in the first automated pass rather than bouncing through human queues. CSAT measured after a high-FCR interaction consistently scores higher than CSAT measured after multi-touch interactions, regardless of resolution speed.
In our work building Replixa, we track resolution rate, not deflection rate, as the primary effectiveness metric. A ticket is resolved when the customer's stated problem is addressed by a concrete action — an API call, a status confirmation, a setting change, a credit issued — and the ticket is closed without follow-up. Deflection does not count. Sending a link and hoping the customer goes away does not count.
The confidence threshold question
One objection we hear to resolution-oriented automation: "What if the AI gets it wrong?" This is the right question. Incorrect automated resolutions are genuinely worse than incorrect deflections, because the wrong action on an account causes real harm — a wrong credit amount, a permission granted to the wrong user, a setting changed incorrectly.
The answer is not to avoid resolution. The answer is to build a confidence threshold below which the system does not attempt resolution and instead escalates with context. In Replixa, every ticket gets an intent classification pass with a confidence score. High-confidence classifications that map to automatable resolution types proceed to resolution. Low-confidence or ambiguous tickets route directly to a human agent with the classification metadata — intent label, confidence score, extracted entities — so the agent does not start from zero.
This means the system is never trying to resolve what it is uncertain about. It is not deflecting those uncertain tickets, either — it is genuinely routing them to humans with useful context. That is a different thing from deflection. It is triage.
The measurement framework we recommend
If you are evaluating any AI support tool — including Replixa — here is the measurement framework we recommend for the first 90 days of deployment. Track four numbers: resolution rate (percentage of tickets closed autonomously with a concrete action), first-contact resolution rate across all channels, CSAT delta segmented by ticket type, and escalation rate by intent category. The last one matters because a high escalation rate on a specific intent category is a signal that either the automation is not configured correctly for that type, or the KB does not have what the model needs.
Do not optimize for deflection rate. It is a vanity metric dressed up as an efficiency metric. The actual efficiency is agents spending their time on tickets that require judgment — escalations, complex account issues, relationship conversations — rather than closing routine requests that a well-designed system should handle autonomously. That reallocation of agent time is the real ROI of automated support, and it only happens if the automation is actually resolving tickets, not pointing people at articles and hoping for the best.