What an AI support bot has to refuse

The queue latency was the product problem

At a ten-minute average wait, users stop treating support as something that will help them now. That changes what they do next: they abandon the task rather than wait for an answer. The bot was not there to reduce support headcount, it was there to change what a user does in the ten minutes after they get stuck.

Framing it that way decides a lot downstream. If the goal is deflection, you optimise for the bot answering as much as possible. If the goal is that the user completes their task, you optimise for the user getting a correct answer fast from whichever source can give one — and sometimes that source is a person.

Those two framings produce different products. The first produces a bot people learn to route around. The second produces one they use twice.

Write the refusal list before the answer list

The first useful artifact is not a prompt. It is a written list of categories the bot must never attempt: anything touching money, anything about account state it cannot verify, anything with a legal or safety consequence, and anything where being confidently wrong costs more than being slow.

Billing is the clearest case. A support bot that guesses at why a charge appeared is not saving anyone time, it is generating a second, angrier ticket — and the user now trusts the first channel less than before they used it.

The same applies to anything the bot cannot actually see. If it does not have authenticated access to the user's account state, it must not speak as though it does. Plausible answers about data you have not read are the single fastest way to lose a support channel's credibility.

This list is a product decision, not a model tuning parameter, and it should be agreed with the support team who will inherit whatever the bot escalates.

Escalation must not cost the user their context

The moment that decides whether people use the bot again is the handover. If reaching a human means starting over — re-describing the problem, re-stating the order number, repeating what they already told the bot — then the bot has added a step rather than removed one, and users will skip it next time.

Carry the transcript forward. The person who picks up the conversation should open it already knowing what was asked, what the bot attempted, and why it stopped. That is a small amount of engineering and it is most of the perceived quality of the whole feature.

Make the exit visible and unconditional. A user who wants a person should be able to get one at any point, without arguing with an interface about whether their problem is really that complicated. Hiding the escalation to protect the deflection rate optimises a metric at the expense of the thing the metric was standing in for.

Uncertainty has to be a first-class outcome

A support bot needs three outcomes, not two: answer, escalate, and say it does not know. Collapsing the third into the first is how these systems fail, because a model asked to always produce an answer will always produce one.

In practice that means treating low confidence as a routing signal rather than something to be smoothed over in the wording. It is better for the bot to say plainly that it is not sure and pass the conversation on than to hedge its way through an answer that reads as authoritative.

It also means logging the refusals, not only the resolutions. The queries the bot declined are the highest-value dataset the feature produces — they tell you what to build next, and they are the first thing I would look at before extending coverage.

What I would design differently next time

I would build the escalation path first and the answering second. On this engagement they were built in the opposite order, which is the natural order and I think the wrong one.

Building the answering first makes the escalation feel like an error case, and error cases get the least design attention. Building the handover first makes the bot an accelerator on a path that already works — and if the model is disappointing, you still shipped a better support experience than you had.

The result on that engagement was that average response time fell from around ten minutes to about thirty seconds and roughly seventy per cent of queries closed without a human. Those figures come from the client's support queue rather than from anything I measured myself, and I would treat them as directional. The part I would actually defend is the design: what the bot refused, and what happened to the user when it did.