AI chatbot handoff: when and how to bring in a person

An AI assistant should hand the conversation to a person in three cases: when someone asks for one, when it has tried to understand and couldn’t, and when the topic is outside what it can solve. In the first case, the handoff happens right away, with no questions in between. In the others, the assistant offers it itself. And the handoff only works if the person on the team gets the context, so the customer doesn’t have to tell the whole story again.

When to bring in a person

The Nielsen Norman Group study on site-specific chatbots calls this handoff willingness. Its firmest rule is simple: if someone asks to talk to a person, the bot honors the request immediately. It doesn’t ask them to explain why first.

Beyond the direct request, the same article points to the signals that should make the assistant offer a handoff:

it can no longer answer in a useful way;
the person shows frustration;
the person rephrases the same question several times, which signals extra effort;
the request falls outside the scope the company set for the bot.

One participant in the study compares feeling stuck to a hamster on a wheel. They also complain about bots that, in the end, just tell you to call a phone number, which is what they wanted from the start.

Before handing off, try to repair

Not every misunderstanding needs a person. NN/g suggests a sequence for when the conversation stalls, in four steps that get more active as they go:

Admit the doubt instead of guessing at some answer.
Say what it understood and what it didn’t.
Offer options to pick from, instead of asking the person to rewrite everything.
If the attempts fail, bring in someone from the team.

The order matters. An assistant that jumps straight to step four is a phone menu with a new name. One that never gets there traps the person in a loop.

The balance between cost and trust

NN/g itself acknowledges the business case. Every conversation that never reaches a person saves support hours. The article compares this to the old phone tree dilemma: a system built to save money becomes a wall between the customer and the help they need.

The text also points to the risk on the other side. Handing off too fast erodes trust in the bot and raises staffing costs. But refusing when the person asks, or when the bot isn’t helping, is worse. It undercuts the reason the assistant exists and drives away people who’d otherwise use it again.

Empathy doesn’t replace the handoff. According to the same article, a bot that acknowledges frustration and solves nothing still frustrates. When it can’t help, the kindest reply is to bring in someone who can.

What the handoff needs to carry

Whoever takes over needs to know what’s already been said. NN/g’s guide to customer-service chat calls it annoying when an agent asks again for what the customer already typed to the bot. For the customer, one chat window is one conversation, even if there’s a bot and a human on the other side.

The same guide asks for honesty from the start. Say the chat starts with a bot and that a person takes over if the bot can’t help. People who know they’re talking to a bot adjust their language and expectations, with more direct phrasing.

The wording of the limit matters too. The 2026 study compares a vague refusal, which only says the bot can’t help, with a reply that names the data it doesn’t have and offers someone who does. The second one explains the limit and already shows the next step.

While the person is on the way

Waiting in front of a screen is hard, especially on a phone. The customer-service chat guide recommends three things:

give a time estimate, which helps more than a place in the queue;
show a timestamp on each message, so the wait is visible;
say when people are available, if human support isn’t around the clock.

If the chat drops, the context needs to be saved. A customer who comes back shouldn’t have to start over.

On WhatsApp, offering a way out is a rule

If you use automation on WhatsApp Business, there’s a written rule about this. The WhatsApp Business Messaging Policy, updated on September 23, 2026, lets you reply with automation inside the 24-hour customer service window. That window opens and resets with every message the customer sends. Alongside automation, the business must offer prompt, clear and direct escalation paths.

The same policy lists the accepted paths:

transfer to a human agent within the chat;
a phone number;
email;
support on the business website;
a visit to the store or branch;
a support form.

How it works at Vexor

Vexor is my assistant product for WhatsApp. There, the assistant answers, books and hands the case to a person when the script runs out. There’s also a fixed topic limit: it doesn’t answer health questions. In that case, it books, confirms, reminds and passes the case to someone on the team.

The handoff works in the other direction too. Whoever handles the client writes a note on their card in the panel, such as a time agreed on the phone. The assistant reads that note before replying, so what the team knows enters the conversation. What the team edits on the client record is marked as confirmed by them, and the assistant doesn’t overwrite it.

The panel shows how many times the assistant handed the case to a person, next to the total conversations handled and slots confirmed. The same number shows up in the hourly summary. That way, the handoff stays in view for the business owner, alongside the other numbers.

Where the sources disagree

Does a phone number count as a way out? The WhatsApp policy accepts a phone number and email as escalation paths. The NN/g participant complains precisely about bots that end by telling you to call a number. Following the rule doesn’t guarantee a good handoff.
Speed versus care. In NN/g’s 2018 chatbot study, participants found customer-service bots less helpful than people, but saw an advantage in speed. The same participants said having humans on support shows the company cares.
Savings versus trust. The 2026 study acknowledges that avoiding handoffs saves staff hours. And it concludes that refusing the handoff costs more, because it drives away people who’d use the bot again.

The common mistake

The common mistake is to measure handoffs only as a cost and push that number down at any price. The result is a bot that asks for a reason before calling someone, repeats the same answer and hides the exit. A high handoff count is a signal to look at which requests the assistant can’t solve. The fix is to adjust its scope or content, not to lock the door.