AI support vendors lead with deflection rate. It is the number in the headline, in the ROI calculator, in the business case your team puts together to justify the purchase. Deflection rate is easy to understand, easy to measure, and easy to report upward. It is also almost always the wrong primary metric, and optimizing for it often leads you directly away from what you actually want, which is customers who got help with their problems.
This is not a subtle distinction. The difference between deflection rate and resolution rate can be large enough that a tool with a high deflection rate is making your support quality worse, not better. Understanding the relationship between these two metrics is the difference between buying an AI that helps your customers and buying an AI that keeps your customers away from humans while leaving their problems unsolved.
What deflection rate actually measures
Deflection rate is the percentage of incoming tickets that received an AI response without a human agent becoming involved. A ticket counts as deflected if the AI responded and the customer did not escalate or reopen. That is it. The metric contains no information about whether the customer's problem was resolved. It measures whether the ticket was closed, not whether the issue was addressed.
A customer who asks a question, receives an AI response that does not address their actual question, and closes the ticket in frustration without replying counts as a deflected ticket. The AI "handled" it by any metric definition. The customer is no more informed than before they submitted the ticket. That interaction was counted as a success.
This failure mode is more common than vendors acknowledge, because customers often do not re-open tickets. They give up, work around the problem, or quietly decide your support is not worth the effort. They do not generate a signal that shows up as a deflection failure. They just churn, or they tell their colleagues your product is hard to get support for.
What resolution rate measures and why it is harder to get
Resolution rate is the percentage of AI-handled tickets where the customer's problem was actually resolved. It is harder to measure because resolution is not a field in your helpdesk. You have to infer it.
The best proxies are: did the customer come back with the same or a closely related question within a reasonable window? Did they give a clear positive signal in follow-up (not just close the ticket, but reply with something like "great, that worked" or leave a high CSAT specifically noting the answer was helpful)? Did the topic recur in their account within the following weeks?
None of these are perfect, and building a reliable resolution-rate measurement requires connecting ticket data across sessions, which is data engineering work. That is why most teams fall back to deflection rate: it is there out of the box. Resolution rate requires investment to measure.
The investment is worth it. A deflection rate metric with no resolution rate check is like measuring a surgery by whether the patient left the operating room, without checking whether they recovered. You need both.
The optimization trap
When teams optimize for deflection rate without tracking resolution rate, they reliably produce a specific outcome: the AI's confidence threshold gets lowered until more tickets are answered automatically, answer quality in the deflected cohort decreases, and customers start to see the AI as unhelpful or worse, actively misleading. That reputation is hard to recover from once it is established.
The way to avoid this trap is to treat resolution rate as a constraint, not a secondary metric. You want a high deflection rate, but only in a universe where the deflected tickets were actually resolved. A useful internal target is something like: improve deflection rate while holding the recurrence rate of deflected tickets below a threshold that indicates real resolution is happening. If recurrence starts climbing as you push deflection higher, you have crossed the quality line.
The specific thresholds that work for your product depend on your support domain and your customer base. There is no universal number. What there is, is a direction: deflection rate goes up as a result of better answer quality and better knowledge coverage, not as a result of lowering the bar for what counts as a handled ticket.
How to actually improve resolution rate
The inputs to resolution rate are the same as the inputs to AI answer quality: documentation coverage, documentation freshness, and the quality of your closed ticket training data. A narrow, well-covered topic area where the documentation is current and the closed ticket examples are strong will have a high resolution rate. A broad, poorly-documented topic area with thin ticket history will have a low one.
Improvement is therefore mostly a content investment, not a configuration investment. You cannot tune your way to a high resolution rate on topics the AI does not have good source material for. You have to either improve the documentation or explicitly exclude those topics from AI handling until you do.
This framing is actually more operationally useful than the deflection-rate frame, because it tells support leaders exactly what to fix. "Our resolution rate on integration setup questions is low" is a diagnostic statement that points to a documentation gap. "Our overall deflection rate is 42 percent and we want it at 55" is a target without a mechanism. The path from 42 to 55 through documentation improvement is a real path. The path from 42 to 55 through threshold tuning is a false path that produces a 55 percent deflection rate and a low resolution rate on everything that got pushed across the new threshold.
