Everyone has been trapped by a support bot that would not let them reach a person. The design decisions that separate helpful automation from infuriating automation are not subtle, and most companies get them wrong for the same reason: the system was optimised to deflect contacts rather than to resolve problems.
The deflection trap
If the measure of success is the share of enquiries handled without a human, you will build something that makes reaching a human difficult. The metric will improve.
What it will not show is the customer who gave up, the one who is now describing the experience to colleagues, or the one whose simple problem became a complaint because nobody would engage with it.
A better measure is resolution: what share of customers got their problem solved, and how satisfied were they. That metric rewards a bot that escalates quickly when it cannot help — which is what you want.
Always offer the exit
The single most important design decision. A visible, immediate route to a person, at every point, without conditions.
Counter-intuitively, this reduces the number of people who take it. When customers know they can reach a human, they will try the automated route first. When they suspect they are being trapped, they will fight for a person from the first message — including for questions the system could have answered.
Be honest about what it is
Say plainly that it is an automated assistant. Customers work it out within two exchanges anyway, and discovering it after being misled converts a neutral interaction into an adversarial one.
Under EU transparency expectations this is also increasingly a requirement rather than a courtesy.
Answer from your actual documentation
A support assistant should answer from your policies, product documentation and procedures — retrieved and cited — not from a model's general impressions.
This matters commercially as well as technically. An assistant that invents a returns window or a warranty term has made a statement your customer will reasonably rely on. Tie answers to source material and make the source visible.
Know what it must never handle
Define this explicitly before launch. Typically: complaints that reference legal action, anything involving a vulnerable customer, data protection requests, cancellations, and anything where the customer is plainly distressed.
These should route to a person immediately, without an attempt to resolve. A bot attempting to handle a legal complaint creates a worse problem than the one it was addressing.
Hand over properly
When escalation happens, the person receiving it must get the full conversation. Asking the customer to repeat everything is the moment that converts mild irritation into real anger, and it is entirely avoidable.
The receiving agent should also be able to see what the assistant told the customer, because they may need to correct it.
Start narrow
The reliable pattern is to begin with a small set of common, low-risk, well-documented enquiries — order status, opening hours, how to perform a routine action — and escalate everything else. Widen the scope as you observe what it handles well.
Starting broad and narrowing after complaints means learning in public, at the expense of customers who did not volunteer for it.
