An AI customer support agent resolves requests end to end: it identifies the customer, retrieves their order or account, takes the action being asked for — a refund, a reschedule, an address change — and closes the ticket. Deflection only answers questions; resolution requires tool access, permissions, and a clear escalation boundary.
Ask a support leader what their AI is doing and you will often hear a deflection number. Ask a customer what happened and you will hear that they were shown an article they had already read before they gave up and opened the ticket.
Both statements are true at once, and that is the whole problem. Deflection measures a cost avoided. It does not measure whether anybody got what they came for.
Resolution needs three things deflection does not
- Identity. The agent must know which customer it is talking to and be confident about it, because everything after this point acts on their account.
- Context. Their order, subscription, previous tickets, entitlements and what they were promised last time.
- Permission to act. A tool that actually issues the refund, changes the date, resets the access — with limits enforced on the tool rather than requested in a prompt.
That third item is what most support AI projects stop short of, usually for a reasonable-sounding reason: nobody wants to hand a model a refund button. The answer is not to withhold the button, it is to shape it — capped, reversible, logged, and narrow enough that the worst outcome is affordable.
Drawing the boundary
The single most useful hour in a support-agent project is the one spent sorting request types into three columns. It is not a technical exercise and it should not be done by engineers alone.
| Column | Rule | Examples |
|---|---|---|
| Agent resolves | Verifiable, reversible, inside policy, low value at risk | Order status, delivery date change, address correction, password reset, plan upgrade, small refund inside window |
| Agent prepares, human approves | Correct action is clear but the cost of being wrong is real | Large refunds, goodwill credits, contract changes, account merges, bulk actions |
| Human owns | Judgement, emotion, risk or regulation | Complaints, safety issues, legal threats, billing disputes, distressed customers, anything about a person's data rights |
Two things about that middle column. It is where most of the value is, and it is where teams get comfortable enough to eventually move items into the first. Starting everything in column two and promoting it after evidence is a far better sequence than starting in column one and retreating after an incident.
Knowing when to stop
An agent that hands over cleanly is trusted with more work over time. One that bluffs through the edge of its competence loses the queue permanently the first time it gets a distressed customer wrong.
- Explicit ask. If the customer asks for a human, the agent transfers. No retention loop, no one more question. This is not negotiable and it costs almost nothing.
- Low confidence. Below a threshold on the answer or the identity check, it escalates rather than guessing.
- Emotional signal. Detected frustration, distress or repeated dissatisfaction routes to a person immediately, with the history attached.
- Repeat contact. A second ticket about the same issue skips the agent and goes to someone who can look at the whole thing.
- Out of scope. Anything not on the resolve list, including anything the agent has no tool for.
Grounding answers in your actual policy
Support answers are factual claims about what your company will do, which makes an unsupported one a commitment you did not make. The defence is retrieval: the agent answers from your own documents and attaches the source, and where it cannot find one, it says so instead of reasoning its way to a plausible policy.
The mechanics of that layer — chunking, retrieval quality, freshness, citation — are covered in RAG and knowledge systems. The short version for support specifically: your help centre is not your policy. Refund windows, eligibility rules and regional differences usually live in an internal document that contradicts the public one in at least two places, and finding those contradictions is a real deliverable of the project.
Where it fits with the rest of the stack
Support is rarely one channel. The same customer emails on Monday, opens chat on Tuesday and calls on Wednesday, and the thing that makes an agent feel competent rather than uncanny is that all three know about each other.
In practice that means one identity resolution path, one knowledge layer, one set of tools, and channel-specific behaviour on top — a voice agent needs different pacing and interruption handling, but it should not need its own idea of what your refund policy is.
Measuring it honestly
- Full resolution rate — tickets closed by the agent with no human touch and no reopen within seven days. The reopen window is the part that keeps the number honest.
- Reopen rate on agent-closed tickets, compared with the human baseline.
- Escalation quality — sampled handoffs scored on whether the human had what they needed.
- Customer satisfaction split by resolution path, not averaged across all tickets.
- Actions taken, with error and reversal counts. Every refund the agent issued, every change it made, and how many had to be undone.
If you track one thing, track reopens. A deflection number goes up when the agent gets worse at helping people, which is exactly the wrong incentive to build a support organisation around.
How to scope an AI support agent in one week
A practical sequence for deciding what the agent should own before any of it is built.
Pull the ticket distribution
Export the last three months of tickets and group them by request type. The top ten types usually account for most of the volume; everything below that is not the first project.
Sort into three columns
For each top type, decide whether the agent resolves it, prepares it for approval, or never touches it. Do this with support leadership in the room, not afterwards.
Find the real policy
For each resolvable type, locate the document that states the actual rule. Note every place the public help centre and the internal policy disagree.
List the tools needed
Write down the exact system call each resolution requires, and the narrowest permission that allows it. Anything without an API is a column-two candidate at best.
Build the evaluation set
Take thirty real past tickets across the chosen types with their correct outcomes. This is what every future change is tested against.
Agree the escalation rules
Write the explicit conditions that end the agent's turn — asked for a human, low confidence, distress, repeat contact, out of scope — and treat them as requirements rather than tuning.