What resolution rate can AI actually reach on support tickets?

On the email and ticket channel, a well-built AI support system resolves roughly 50–70% of incoming tickets without a human. Real deployments land in a band between about 42% and 70%, and where you land inside it is decided by your ticket mix — not by which model you pick. The 90%+ figures in vendor demos are almost always deflection rates on a curated set of questions, which is a different measurement entirely.

This article explains why the two numbers diverge, what actually moves your resolution rate, and how to estimate your own ceiling from your last month of tickets — before anyone builds anything.

Why does the demo say 90% and the deployment say 55%?

Two reasons, and neither is about model quality.

The first is the metric. Deflection counts tickets that never reached a human. That includes the customer who read an unhelpful answer and left. Resolution counts tickets where the problem was solved. A system can deflect 90% and resolve 40% at the same time, and the second number is the one your customers feel.

The second is the test set. Demos run on the requests the system was designed for. Your inbox contains the requests your customers actually send: half-written, in three languages, with a photo attached and an order number in the subject line. The gap between those two populations is the gap between the advertised rate and yours.

What actually decides your resolution rate?

Four things, in this order of impact:

• How much of your volume is repeatable. Five request types covering 60% of tickets is a good starting position. Two hundred one-off questions is not.
• Whether the answer exists somewhere a system can read it. If resolving a ticket requires knowledge that only lives in someone's head, no model will find it.
• Whether resolving requires writing into another system. Answering a question is easy. Issuing a credit note, changing a delivery date or resetting an entitlement means integration, permissions, and a rollback path.
• Your tolerance for a wrong answer. A high confidence threshold sends more tickets to people and lowers the automation rate — on purpose. That is a business decision, not a technical one.

Notice what is not on the list: the model. Swapping one capable model for another moves the rate by a few points. Ticket mix and system access move it by tens.

How do you estimate your own ceiling before building?

Take 200 tickets from last month — a real sample, not the easy ones — and sort each into one of three buckets:

• Answerable from sources a system can read — order status, documentation, past tickets, catalogue data. This bucket is your realistic near-term ceiling.
• Resolvable only with an action in another system — refunds, returns, account changes. Automatable, but each one is an integration with its own scope.
• Needs human judgment — complaints, commercial negotiation, anything where being wrong is expensive. This bucket should stay human, and pretending otherwise is how AI support projects lose trust internally.

The first bucket, as a share of the 200, is a defensible estimate of what automation can resolve in the first phase. If it comes out at 20%, a support automation project is not your best next investment, and you found that out with an afternoon of work.

What do we commit to, and why not more?

We contract 50–70% on the email and ticket channel, measured on your real tickets after go-live, and we say it before you sign rather than after. Promising 90% would win more deals and lose them again at month three. The number that matters is the one still true a year later.

What happens to the tickets it does not resolve?

They reach a person faster and better prepared. Even a ticket the system will not answer gets classified, routed to the right queue and enriched with the customer, the order and the history before a human opens it. On the ticket-creation side of the same pipeline we have measured this in production: at an industrial components distributor, 85% of tickets are now created automatically from inbound email, giving the team back roughly 58 hours a month.

That is a different metric from resolution, and we keep the two apart on purpose. Creating a ticket correctly is a solved problem. Resolving it without a human is not, and any vendor who blurs the two is hoping you will not notice.

Where does this stop being worth it?

Low ticket volume is the obvious case: a queue of thirty tickets a week will not repay a build. Less obvious is the company whose tickets are all genuinely different — project work arriving through a support address. There, the honest answer is to automate the intake and leave the answering to people.

A third case shows up often: the support queue is the symptom, and the cause is a document flow upstream. Fixing the upstream flow removes the tickets instead of answering them. That is the kind of finding you want before a build, not after.

What would your number be?

The free AI Audit takes about five minutes and tells you how AI-ready your support operation is and what to automate first. Want to go through your queue with us? Book a call. The packaged build is Customer Support Automation; the mechanics of routing are in how triage and escalation work.