The pitch is now standard and the numbers behind it are real.
The median AI customer service programme in 2026 deflects 41.2% of Tier-1 contacts, with the top quartile reaching 58.7%. Cost per resolution runs $0.99–$2.00 against $6–$12 for a human-handled ticket. Companies report average returns of $3.50 for every $1 spent, with first-year returns around 41% climbing past 124% by year three. Salesforce reports 66% of service organisations running AI agents, up from 39% a year earlier — figures collated across 2026 vendor and analyst benchmarks.
Take a support desk handling 3,000 tickets a month at $8 each: $288,000 a year. Deflect 41% at $1.50 and you have saved roughly $95,000 annually.
That calculation is correct, it is what gets the budget approved, and it is not the decision you are actually making.
Deflection is the wrong KPI
Here is the problem with optimising for deflection rate, stated as plainly as we can:
Deflection measures conversations that did not reach a human. It does not distinguish between a customer who got an answer and a customer who gave up.
Those two outcomes look identical in the dashboard. One saved you eight dollars. The other cost you a customer and a review.
And the incentive it creates is worse than neutral. A team measured on deflection is a team that will make it harder to reach a person, because every escalation is a number going the wrong way. That is precisely the failure mode that makes people hate support bots — not that the bot is stupid, but that it will not let them past.
The variance in the data says the same thing more politely. In the same 2026 benchmarks, deflection for straightforward intents — refunds, password resets, order status — exceeds 70%, while nuanced complaints rarely reach 25%. A blended "41%" is the average of two completely different businesses. Reporting it as one number hides exactly the information you need.
Measure instead: resolved without the customer trying to escalate. It is harder to compute and it is the only version of the metric that cannot be gamed by hiding the exit.
The intent map
Before any tool decision, sort your last thousand tickets into four boxes. Two axes: how often does this come up, and what does it cost if the answer is wrong.
| Cheap to be wrong | Expensive to be wrong | |
|---|---|---|
| Frequent | Automate fully. Opening hours, order status, how-to, policy lookups, password resets. This is where the money is. | Automate the retrieval, gate the answer. Billing, account changes, anything touching money or identity. The agent drafts; a person approves. |
| Rare | Automate loosely. Long-tail questions answered from documentation, with an easy exit. Low volume, low risk. | Do not automate. Route fast. Complaints, legal, safety, cancellations at risk of churn. Every second spent in a bot here makes it worse. |
Most failed deployments come from treating the whole grid as one problem. The top-left box alone usually accounts for half of ticket volume and carries almost no downside risk. Ship that, measure it for a quarter, and expand only where the data says you can.
The top-right box is where the interesting engineering lives, and it is the one most vendors skip.
What we actually build
Two examples from our own products, because the design choices are the transferable part.
The Bronjoy help bot answers customers, business owners and visitors in Uzbek, Russian and English. Four decisions define it:
- It answers from a knowledge base imported from the product documentation, not from general knowledge. If it is not in the docs, it does not get asserted.
- It holds no write tools at all. It cannot change an account, move a booking or issue a refund. Its entire capability is retrieval and explanation.
- Billing and account replies are held for human approval before they are sent — the top-right box, handled exactly as above.
- It escalates on request, after repeated unhelpful answers, and on error. Three separate triggers, because the customer asking is only one of the ways a conversation goes wrong.
That third trigger is the one to steal. An agent that escalates when it is failing — not only when the customer complains — catches the silent abandonments that deflection metrics count as wins.
The Knigopoisk admin assistant goes further because it has real power: tools for orders, products, content, media, users and statistics inside the back office. When the model proposes an action that needs sign-off, the run pauses, the proposal is recorded, and the agent only resumes after an admin approves or rejects it — leaving an audit trail of what was proposed and what was actually done.
Pausing mid-run is more work than asking for confirmation up front, and it is the difference between an assistant and a liability. The audit trail is what makes it defensible six months later when someone asks why an order was changed.
The rollout that does not blow up
Most failed deployments fail in the same four weeks, in the same way: the assistant goes live across all intents, gets a run of embarrassing answers, someone senior sees a screenshot, and it is switched off permanently. The technology was never the problem; the sequencing was.
A rollout that survives:
Weeks 1–2 — shadow mode. The assistant answers nothing. It drafts a reply to every incoming ticket and files it beside the agent's real answer. Nobody sees it but you. At the end, you have a few hundred paired answers and an honest read on where it is already better than your median response and where it is dangerous. This is the step everyone skips and the one that makes every later argument evidence-based.
Weeks 3–4 — suggest mode. Agents see the draft and either send it or rewrite it. Measure the edit rate per intent. An intent where drafts go out untouched 90% of the time is ready to automate. An intent with a 60% rewrite rate is not, and now you know which is which without guessing.
Week 5 — go live on the top-left quadrant only. The frequent, cheap-to-be-wrong intents. Nothing else. Keep the exit to a human one tap away and unhidden.
Week 9 — review the transcripts, then expand by one intent. Not by ambition, by evidence.
The shadow phase is also your negotiating position with a vendor. A tool that looks impressive in a demo but disagrees with your agents 40% of the time on your own historical tickets has told you something a procurement process never would.
The cost side nobody quotes
The $3.50-per-$1 figure is a return on the software. The project has four costs, and two of them are permanent.
| Cost | Typical shape |
|---|---|
| Build and integration | One-off. Our AI integration work starts at $299 with a 1–3 week delivery |
| Knowledge base preparation | One-off, and usually the part that slips — your documentation is probably worse than you think |
| Evaluation and tuning | One-off then periodic. We budget a dedicated phase for it: testing against real conversations and fixing the answers it gets wrong |
| Ongoing maintenance | Permanent. Prices change, policies change, the model version changes |
That last row is where deployments quietly die. An assistant trained on last year's refund policy is not a neutral asset — it is actively misinforming customers with your brand's authority. Budget for maintenance from day one or do not start.
There is also a fifth cost that never appears in a business case: the escalation tax. Every conversation that bounces off the bot and reaches a human arrives with a frustrated customer and no context. That is a longer, worse ticket than if it had gone to a person directly. The fix is to pass the transcript and the context across on handoff — which is why every assistant we ship has a handoff path that carries the conversation with it, rather than dumping the customer into a fresh queue.
The honest version of the business case
Rewrite the calculation with all of it in:
- 3,000 tickets/month at $8 = $288,000/year
- 45% of volume is top-left-box, deflected at 85% success = ~1,148 tickets/month
- Saving: 1,148 × ($8 − $1.50) × 12 = $89,544/year
- Less maintenance (a day a month of someone's time, plus inference): call it $12,000/year
- Less escalation tax on the ~172 failures: 172 × $4 extra × 12 = $8,256/year
- Net: roughly $69,000/year
Still an excellent return. Still worth doing. But notice that it came from 45% of volume in one quadrant, not from an ambition to automate support. The businesses that get burned are the ones that promised the board 60% deflection across the board and then had to hide the exit to get there.
Four things the vendor will not volunteer
The benchmark is not your business. A 41.2% median is an average across companies whose ticket mixes look nothing like yours. If 70% of your volume is complex, your ceiling is structurally lower and no product changes that. Ask any vendor to run their tool against your last thousand tickets before you sign, and read the refusal as an answer.
Deflection and satisfaction can move in opposite directions. They will report the first and not the second. Insist on a satisfaction measure segmented by whether the conversation touched the assistant, and look specifically at the group that escalated — that is where the damage shows up, and it is small enough to be invisible in an aggregate.
The knowledge base is your job and it is most of the work. Vendors demo against clean documentation. Yours is out of date, contradicts itself in two places, and lives partly in a colleague's head. Budget for writing it; that effort produces value even if the assistant is never switched on.
Per-resolution pricing changes the incentive. If you are billed per AI resolution, the vendor profits from the assistant answering rather than escalating — the same misalignment as measuring deflection, now with money behind it. Read how "resolution" is defined in the contract, and check whether a conversation that ends in a human handoff still counts as one.
None of this means do not buy. It means the questions that protect you are about measurement and definitions, not about model quality — which is the thing every sales conversation would rather discuss.
Where the second-order value is
One last thing, and it is the argument we make most often.
The transcripts are worth more than the savings. A support agent that logs every question, every failure and every escalation reason produces a continuously updated list of everything your product, your pricing page and your documentation fail to explain. Most companies have never had that list. It is the highest-quality product research available, it arrives for free as a byproduct, and almost nobody reads it.
Read it monthly. Fix the top three. Watch ticket volume fall for reasons that have nothing to do with AI.
Tell us what you need. You get a fixed price and a delivery date back — free, and with no obligation to proceed.
Frequently asked questions
Will customers accept talking to an AI agent?
They accept it for the top-left box and resent it everywhere else. The determining factor in every study is how easily they can reach a person when they want one. Make the exit obvious and satisfaction holds up; hide it and you convert a cost saving into a churn problem.
How do we stop it inventing answers?
Ground it in your own documents and give it no general-knowledge fallback, so "I do not know, let me get someone" is a valid and frequent output. Then restrict what it can do: an assistant with no write tools cannot cause damage even when it is wrong.
How long before it pays back?
For a well-scoped first deployment, usually within the first quarter, because the build is measured in weeks and the savings start immediately on the highest-volume intents. Scope creep is what extends payback, not the technology.
Should we build or buy?
Buy if your support is generic and your knowledge lives in a standard help centre. Build if the assistant needs to touch your own systems, work in languages an off-the-shelf product handles badly, or enforce approval rules specific to your business. The dividing line is integration depth, not size.
What about voice?
Harder, and worth being specific about why. Our own AI voice receptionist works end to end as a browser demo and is switched off in production behind a feature flag, with no telephony leg built yet. Voice adds latency budgets, speech quirks and a whole class of failures text never has — we found bugs that only appeared in Uzbek, including prices read as nonsense because a thousands separator was voiced as a word. Start with text.
