When a chatbot should stop and hand off to a person

An automated assistant is judged mostly by how it stops. Answering easy questions is the simple part; problems arise when the system keeps answering in situations where it should have handed off. The damage isn't an imprecise answer about opening hours: it's a confident answer about a contractual term, or about a fault that could have been dangerous.

The limits are written down beforehand, together with the people who do the job. They aren't discovered in production, by reading conversations that went wrong.

The questions it must not handle

The first list isn't about what the system knows, but about what it must not do even when it could answer.

• Commitments: off-list prices, promised deadlines, contractual terms, exceptions. These are things that bind the company.
• Safety and health: any suspected risk to people or to equipment must be taken to a person, not handled with instructions.
• Personal data and cases: requests involving someone's identity, payments, or documents.
• Complaints: someone writing in angry doesn't want a procedure, they want a person. Insisting only makes an already bad situation worse.
• Cases that require judgment: if answering requires seeing, testing, or deciding, it isn't a job for an assistant.

This list is also the most effective way to get the project accepted within the company: anyone afraid the system will say something foolish on their behalf needs to see in writing what it won't touch.

The handoff conditions

Beyond the excluded cases, there are situations where, given how the conversation is going, it needs to be closed and handed off.

The third row is the one that gets forgotten most often and it's the most useful, because it doesn't depend on any internal estimate from the system: if a person rewords the same question, the previous answer didn't work, whatever the logs say.

What to hand off to the agent, and what not to

The handoff is useful if the person receiving it doesn't have to start from scratch. It's harmful if it dumps half an hour of conversation on them to read.

• Needed: the initial request in the user's own words, the data already collected, what the assistant already tried, and why it stopped.
• Needed: where the person is coming from, that is, the page or channel, because it explains the context of the question.
• Not needed: the full transcript when it's long. A summary, with the complete text available on request, works better.
• Must not be passed along: information collected for other purposes and data the agent doesn't need to see in order to respond.

The user needs to be told what's being transferred. It's both a courtesy and a safeguard: someone who knows their words are being passed on isn't surprised to be called back about what they wrote.

The handoff has to land with someone

This is the point where these projects fail most often, and it has nothing to do with technology.

1. Establish where the handoff lands — a queue, a mailbox, an internal chat — and who watches it during working hours.
2. Establish what happens outside business hours: if no one will answer until the next day, the user needs to know before the conversation closes.
3. Record when the handoff is taken on: without it, no one knows whether the handoff succeeded or fell into a void.
4. Count the handoffs that go unanswered. It's the only number that tells you whether the promise "we'll connect you with a person" is true.

Three conversations, three outcomes

• Resolved. "Do you also service equipment installed by someone else?" The information is in the authorized sources: the assistant answers, points to the page the answer comes from, and suggests the next step.
• Clarification. "It stopped working." The question is too vague: the assistant asks once which product is involved. If the answer stays generic, it hands off to a person instead of trying to guess.
• Handoff. "Will you give me a discount if I order ten?" This falls under commitments. The assistant doesn't negotiate: it says the request will go to a salesperson, collects the minimum details, and confirms what will happen next.

When a human handoff isn't the answer

• If almost every conversation ends in a handoff, the assistant isn't helping: it's just adding a step before the phone call. It's better to narrow it down to the few things it does well, or drop it.
• If there's no one who can take it on, the feature should be removed: promising a person who never shows up costs more than not promising one.
• If the problem is that the public information is incomplete, the handoff hides the cause instead of fixing it, and the load just shifts onto support.

What this guide doesn't cover

Here we cover limits, handoff, and continuity: when to stop, what to transfer, how to verify that someone picks it up. The choice of which paths to offer customers — assistant, help center, agent — comes before this decision. And the way you verify that answers are correct, with repeatable tests, is a separate job this guide doesn't replace.