When the bot hands off to a person

The question I get asked most about the bot is when it stops answering and a person shows up. The short answer is that there are three paths, and all three end in the same place. The model can ask for the handoff with a tool. A rule can force it even if the model did not ask. And when the model produced nothing that can be sent, the platform hands the chat over on its own.

In all three cases the conversation changes hands, and the bot does not write again.

What a handoff is

The store handles its chats in Chatwoot, the inbox where WhatsApp and Instagram messages land. Every conversation there has a status. While the bot is handling it, it is “pending”. A handoff switches it to “open”, assigns it to one of the store’s teams, and leaves a private note the customer never sees. The note has three lines: the reason, a summary with everything the bot already found out, and the customer’s last message. A reconstructed one:

Reason: technical service

Summary: a 13 bought at the store in March, cracked screen, asking whether the warranty covers it.

Customer’s last message: “the screen broke, I bought it there in March, is it under warranty?”

The agent opens the chat and knows why it came in and what is missing, without reading from the beginning. The summary matters more than it looks: if the bot already asked for model and storage, the person does not have to ask again.

There are four kinds of handoff, and the kind decides two things: which team it goes to and which farewell goes out with it. Technical service goes to the technical team. Restock goes out with the waiting list confirmation. A trade-in evaluation is the only farewell that carries an amount, because the indicative quote is exactly what the customer takes with them. Everything else is general.

Path 1: the model asks for it

The bot has four tools, and one of them is hand off to a human. It takes two texts: the reason and the summary. It is a function that does nothing on its own. It returns a marker that the platform detects when it reads what happened in the turn, and that marker is what triggers the handoff.

Making it a tool and not a sentence is the underlying decision. A model can write “let me pass you to an agent” at any moment, and that sentence, by itself, notifies nobody. The customer waits for someone who does not know they are supposed to come. With the tool, the handoff is a piece of data the platform sees, not an intention you have to guess at by reading the text.

The instructions tell the model when to call it. Anything that is sales it handles alone: prices, stock, comparisons, ordinary installments, the first round of haggling. What goes to a person is what is not its job: repairs and warranties, complaints, specific bank promotions, invoicing, a payment receipt, photos of a device to be evaluated, and any customer who asks to talk to a person. That last case always applies, whatever else is going on. WhatsApp’s messaging policy requires a business that automates to have a clear path to a human, and that rule is that path.

After calling the tool, the only thing the model has to write is the farewell: one or two sentences confirming the handoff, with no prices and no questions. The no-questions condition has a concrete reason. After the handoff the bot is switched off, and if the farewell ends with “which storage do you want?”, the customer answers into the void. If the written farewell breaks any of those conditions, the platform discards it and sends a fixed text.

Path 2: a rule forces it

The model does not always call the tool when it should. Sometimes it announces the handoff without doing it, sometimes it answers something that was not its job, and sometimes it misses a fact the platform can see. For those cases there is an ordered table of rules, and each one forces a handoff with its own reason. Today there are twelve. The ones that do the most work:

• A payment receipt attached. When the customer sends a photo, a model that describes images turns it into text before the turn, and that description says whether it is a receipt. If it is, the turn ends in a handoff, whatever the model said. The bot cannot verify that a payment cleared, so there is nothing it can answer on its own.
• A handoff announced without the tool. If the draft says “let me pass you to an agent” and the tool was not called, the announcement is honored: the chat is handed over anyway. The alternative was worse. The customer read the promise and nobody on the other side found out.
• A handoff offered. “Would you like me to pass you to an agent?” is not a handoff, and it is not an answer either. That draft is rejected and the model rewrites it: if the handoff is warranted, it does it; if not, it does not mention it. The house rule is that a handoff is done or it is not named.
• Technical service by text. “Battery price for the 13” read as a sales inquiry, and the bot searched the catalog for batteries. A rule reads the message, recognizes the technical request and forces a handoff to the technical team. Before that, a customer with a cracked screen landed with the sales team.

The order of the table is part of the contract. The payment receipt goes before the rules that read text, because it is a fact of the turn and not an interpretation. Technical service goes before the announced handoff, because the specific reason beats the generic one and decides the team.

Path 3: there was no reply

In the post about guards I explained that a guard is a hard rule that reviews the draft, and that if it rejects it twice the reply is discarded and the chat goes to a person. The same happens when the model returns nothing, because of a timeout or a provider that is down. What I did not tell is what the bot did with the customer before it worked that way, and why it changed.

Until August 25, a turn with no reply ended in a generic follow-up question: “what is your budget, or do you have a brand in mind?”. The bot stayed in charge and the conversation stayed “pending”. Nobody at the store found out it had failed, unless they opened that chat by hand.

On August 24 a customer asked to be put on the waiting list for a model that was out of stock. The bot asked for their name and phone number, the customer sent them, and the confirmation reply never got composed. What the customer received was the budget question. Their details sat in the chat and nowhere else. Someone at the store saw them two hours later, going through chats by hand, and added them to the list. When the store called two days after that, the customer had already bought elsewhere.

The next day, a turn with no reply became a handoff, the one I described in that post: the conversation opens in the store’s queue with a note saying what failed. A bot failure is now visible, and being visible was the part that was missing.

And then, silence

A handoff that is not honored is worse than a handoff that never happened. And the most common way of not honoring it was the bot continuing to talk.

The customer’s messages do not reach the bot one at a time. They wait in a work queue, and those that arrive in a burst are grouped for thirty seconds. The conversation’s status traveled with each message, as it was at the moment it arrived. In those thirty seconds the status went stale. The previous turn handed the chat to an agent, the next message still said “pending”, and the bot replied after having said “let me pass you to an agent”. When I measured it, in the week ending September 8, it happened in one out of every twenty-five handoffs.

The practice that stuck is that every turn, before doing anything, asks Chatwoot who is handling that conversation right now. If it is no longer “pending”, the bot does not write, and the message is left for the person. If Chatwoot does not answer, whatever the message carried stands: a slow inbox cannot silence the bot. It is one more call per turn, and it is the one that makes the handoff real.

A handoff does not stay alive forever either. When the agent resolves the chat and the customer writes again days later, the conversation goes back to the bot. If the customer carries on with the technical topic, the model tended to reply “wait for the agent to get back to you”, without calling the tool. Nobody found out. Today that sentence, without the tool in the same turn, also forces a handoff. An agent only learns about a chat if that chat went through the handoff, and referring someone to an agent nobody notified is leaving the customer waiting all over again.

Of all the replies the bot gives, the handoff is the only one that does not allow a half error: either a person finds out, or the customer is talking to nobody.