The moment a bot should stop talking

Teams design the answering path first and treat the handover as the thing that happens when answering fails. That ordering produces a predictable result: the answering path is polished, the handover is an afterthought, and the visitors who most need help get the worst experience on the site.

Invert it. Design the handover first, then work backwards to the questions you can answer without it. A handover that is fast, obvious and honest gives you permission to automate aggressively everywhere else, because the cost of a bad automated answer is capped at one wasted exchange. A handover that is slow, hidden or dishonest means every automated answer is a gamble, and you will end up automating almost nothing.

There is a second reason to start here. The handover is the only part of the system that touches your actual operation. Answering is a content problem. Handover is a staffing, hours and expectation problem, and those take longer to change than a page of text does.

The common pattern is to let the assistant try, try again, and only surface a route to a person once it has visibly failed twice. The reasoning is that every conversation handed over is a conversation not deflected, so make deflection work harder first.

This is backwards, and it costs you the thing you were optimising for. A visitor who has been refused twice has already decided the assistant is useless, and by the time you offer them a person they are annoyed rather than neutral. The message they send is longer, angrier and harder to resolve than the one they would have sent at the start.

Offer the route from the first reply. Not as the main action, but present: a line under the answer saying a person can pick this up, with the way to reach them. The visitors who are happy with the answer will ignore it. The ones who are not will take it immediately, and you will get a calm message instead of a frustrated one. Offering early does not increase handovers as much as people fear, because most people who got their answer do not want a conversation with a human being for the fun of it.

A maze is any handover that requires the visitor to guess the magic words, click through a menu that does not contain their situation, or answer qualifying questions before they are allowed to reach a person. Every maze is built for the same reason: somebody wanted to reduce the volume reaching the team, and made the route harder rather than the answers better.

The tell is easy to spot in your own logs. Look for messages where somebody types the word person, human, agent, or someone repeatedly, in increasingly short and increasingly blunt phrasings. Each repetition is a maze wall. If you find a run of them, the handover is not working, and no amount of tuning the answering path will fix it.

The rule worth adopting: an explicit request for a person is honoured on the first ask, every time, with no qualification step in between. Not routed to a suggestion that the assistant try again. Not answered with a link to the contact page. Honoured, immediately, by producing the route or the form.

Handover forms grow. Somebody adds a dropdown for the department, somebody else adds an order number field because it helps triage, somebody adds a category because the reporting looked better with one. Each addition is individually reasonable and collectively fatal, because every field is a chance for the visitor to stop.

The test for a field is not whether it would be useful. It is whether a reply is impossible without it. A way to reach them back is impossible to do without. A description of the problem is impossible to do without. Almost everything else is a preference dressed up as a requirement, and can be asked for in the first reply from a person, where it costs a message rather than a lost enquiry.

Askably's own handover form takes a name, an email address and a message, which is roughly the minimum that makes a reply possible, and stores the submission as well as emailing it so a mail failure does not lose the enquiry. That last part matters more than it sounds: a handover that sometimes silently drops messages is worse than no handover, because the visitor believes they have been heard.

The final line of a handover confirmation is where most teams quietly lie. They write something optimistic because optimistic sounds friendly, and because nobody in the room wanted to be the person who said out loud that Friday afternoon enquiries do not get answered until Monday.

Work out what your slowest realistic case actually is, and state that. If enquiries sent on a Friday evening are answered on Monday, say so. A visitor who is told Monday and hears on Monday has had a good experience. A visitor who is told shortly and hears on Monday has had a bad one, and the difference is entirely in the sentence you wrote, not in the work you did.

Then check the promise against reality on a schedule, because the promise ages. A reply time written when the team had spare capacity becomes a lie the month somebody leaves. Put the sentence somewhere a person owns it, and review it when staffing changes rather than when a complaint arrives.

Nearly all internal testing of a support assistant is done by people who know what it can answer, typing the questions it can answer. That tests the wrong half. The half that matters is what happens when somebody types something it cannot handle and wants out.

Run the test properly at least once. Open the site as a stranger would, on a phone, ask something the material does not cover, then ask for a person. Time it from first message to a confirmed handover. Then check whether the message actually arrived where you think it goes, and who saw it. Teams routinely find the address on the form belongs to somebody who left, or lands in a shared inbox nobody has opened since it was set up.

Repeat the same test out of hours, because the answer changes and the wording should change with it. If the confirmation says the same thing at nine on a Tuesday morning and eleven on a Saturday night, one of those two messages is wrong.