Ask a support leader whether their chatbot works and you get a number: deflection rate. Ask a customer who used it and you get a story about typing "agent" four times.
Both are accurate, and the gap between them is the entire subject.
Deflection and resolution are not the same thing
A chatbot's job, as usually configured, is to stop a conversation reaching a human. It answers from a knowledge base, offers links, and escalates when it cannot match the question.
That is deflection, and it is measurable, which is why it became the metric. The problem is that a conversation can be deflected without the customer's problem being solved. They gave up. They found the answer elsewhere. They emailed instead and now appear as a separate ticket.
An agent is defined by doing something. Not "here is the refund policy" but the refund processed, the address changed, the subscription paused — actions against your systems, on the customer's behalf.
Resolution is harder to measure and it is the number that matters. A support system that deflects most conversations and resolves few is generating dissatisfaction efficiently.
What actually separates them
Scripted chatbots follow a decision tree someone authored. Every path was anticipated. Say something outside the tree and it either loops or escalates. Cheap, predictable, and brittle — and everyone has learned to distrust them, which is a real cost that predates whatever you deploy next.
Retrieval bots search your documentation and answer in natural language. A genuine improvement: they handle phrasing nobody anticipated and they scale with your knowledge base rather than with authored paths. But they still only tell. Ask one to cancel your order and it explains how to cancel your order.
Agents have tools. They can look up the order, check eligibility, issue the refund, and confirm it. The conversation ends with the problem gone rather than with instructions.
The distinction is not intelligence. It is write access, and everything difficult follows from that.
Fig. — The jump that matters is from telling to doing.
What each costs
Scripted bots are cheapest to run and most expensive to maintain. Every product change means editing trees, and the maintenance burden grows with coverage until someone quietly stops updating it and the answers go stale.
Retrieval bots invert that. Higher per-conversation cost, far lower maintenance — improving the answers means improving your documentation, which you wanted to do anyway. For most teams this is the best value tier and the one they skip past on the way to agents.
Agents cost more per conversation and considerably more to build, because the integration work is real. Each action needs an API, permissions, error handling, and a decision about what requires confirmation. The payoff is proportionate: resolving a refund end to end saves a whole ticket rather than a first reply.
The economics hinge on ticket mix. If most of your volume is questions, a good retrieval bot captures most of the available value. If most of it is requests for actions, only an agent moves the number.
Where agents earn their keep
Look for high-volume, low-judgement, reversible actions: order status, address changes, subscription pauses, appointment rescheduling, password and access issues, small refunds within policy.
Reversible is the operative word. An agent that issues a refund inside a defined threshold is making a decision you can undo. One that cancels an enterprise contract is not, and no confidence score justifies giving it that.
The practical pattern most teams settle on: the agent handles anything below a value threshold and inside policy, and hands everything else to a person with the context already gathered. That handoff is where a lot of the value hides — a human picking up a conversation where the account is identified, the order located, and the policy checked starts several minutes ahead.
The knowledge base is the actual product
Whatever tier you deploy, quality is bounded by what the system can read, and this is where most deployments underperform for reasons that have nothing to do with the technology.
Support knowledge in most companies is scattered: some in a help centre written two years ago, some in a shared document, a great deal in the heads of the three people who have been there longest. A retrieval bot pointed at the stale help centre will confidently give stale answers, and everyone will conclude the bot is bad.
The unglamorous prerequisite is auditing what your documentation actually says against what your team actually tells customers. Pull the twenty most common questions, read the documented answer, then ask an experienced agent how they really answer it. The differences are the gap your system will fall into.
This work pays off regardless of what you deploy — better documentation makes human agents faster too. Teams that do it first get a working assistant. Teams that skip it get a fluent one that is wrong, which is worse than none at all.
The mistakes that cost you customers
Hiding the escape hatch. Every deployment should have an obvious route to a person, triggered by the obvious words. Systems that trap people generate anger that outlasts whatever you saved.
Letting it guess. An agent that invents a policy or a delivery date creates a commitment your team has to honour or explain away. Constrain answers to retrieved facts and make "I don't know, let me get someone" an acceptable outcome rather than a failure.
No memory across channels. A customer who explained the problem in chat and then calls should not start again. This is unglamorous plumbing and it dominates satisfaction scores.
Measuring the wrong thing. If deflection is the target, you will get deflection. Measure resolution, repeat contacts within a week, and how often people ask for a human — that last one is the honest quality signal.
How to choose
Pull a hundred recent tickets and sort them into three piles: questions answerable from documentation, requests for an action, and genuinely complex cases needing judgement.
The first pile sizes your retrieval bot. The second sizes your agent, and tells you exactly which integrations to build first. The third is what your team should be spending its time on, and the point of the whole exercise is to give them more of it.
Most teams find the first pile is bigger than they assumed, which is good news — it is the cheapest tier to deploy well. Start there, measure resolution rather than deflection, and add tools for the two or three most common actions once the answering half is genuinely working.
