Handing a WhatsApp chat from the bot to a person

Handover is the moment a conversation stops being handled by an automation and becomes the responsibility of a person. Done well, the customer barely notices. Done badly, the bot keeps talking over your colleague and the customer gets two conversations at once.

Handover is the part of chatbot design that the field covers worst, and it is the part customers judge you on. Nobody minds a bot that cannot answer. Everybody minds a bot they cannot get past.

The bug almost every store has

Here is the sequence. Your automation asks the customer a question and waits for an answer. The customer takes ten minutes. Meanwhile someone on your team sees the chat in the inbox and replies manually. The customer then types something — and it is captured as the answer to the bot's question rather than reaching your colleague.

From the customer's side, they answered a person and a robot replied. From your colleague's side, the customer ignored them.

The fix is a separate two-step automation that sends nothing:

The three places handover must exist

1. The failure branch of every lookup. A Google Sheets or API step that finds nothing should reach a person, not apologise and stop.
2. The unanswered branch of every AI step. A knowledge base that does not cover a question is the normal case, not an error, and it belongs with a human.
3. An explicit option on any menu. "Talk to a person" should be one tap away from anywhere in the flow.

A flow with no exit generates complaints faster than it absorbs them.

Make the handover useful, not just polite

Assigning a chat is the minimum. What makes the difference to your team is what arrives with it.

Step	What it does	Why it matters at handover
Assign Chat	Gives it to a team or person	An unassigned chat is nobody's job
Add Internal Note	Leaves a note only your team sees	Carries the answers the bot already collected
Update Conversation Status	Sets open / pending / resolved	Puts it in the right queue
Update Customer Tags	Labels the contact	Lets you find these conversations later

The internal note is the underrated one. If the bot has already collected an order number and a reason, a note saying "Return requested. Order 1042 — damaged" means your colleague opens the chat knowing everything. Without it they re-ask, and the customer answers the same question twice.

What to say to the customer

Three rules, all learned the hard way:

1. Say a person is coming, not that you are "connecting" them. There is no queue and no connection — someone will reply when they can. Set an honest expectation.
2. Give a time if you can. "Someone will reply within the hour" during working hours; "we're back at 9am" outside them.
3. Do not make them repeat themselves. If the bot collected details, the human should use them.

Handover outside working hours

Assigning a chat at midnight to a team that is asleep is fine, as long as the customer knows. Combine handover with a business hours check so the message they get matches reality: "someone will reply shortly" during the day, "we're back at 9am" at night.

Set the conversation status to pending so overnight chats form a queue your team can work through in the morning rather than scrolling for them.

Cost: handover is free

Every message in a handover is a reply to a customer who just messaged you, so it sits inside the 24-hour customer service window. Meta's pricing documentation confirms service conversations have been free and unlimited since 1 November 2024 — so there is no cost argument for making handover harder.

The one thing to watch is the window closing. If a customer goes quiet for more than 24 hours and your colleague then tries to reply with free text, it fails with error 131047 and they will need an approved template instead. Handling chats the same day is not just good service; it is the only way to reply freely.

When not to automate at all

Some conversations should go to a person immediately, without a menu:

• Anything where the customer is already angry.
• A photo of a damaged or wrong item — a keyword rule cannot read an image, so use the If Customer Sent condition to detect attachments and route them.
• Anything about money that is not a standard flow: partial refunds, disputes, chargebacks.
• Wholesale and high-value enquiries, which are worth a person's time.

A useful test: if getting it wrong costs more than a person's five minutes, do not automate it.

During a spike

On a sale day or a launch, handover volume rises faster than everything else. Two adjustments worth making in advance: widen the bot's self-service coverage so fewer conversations need a person at all, and be ready to switch off any flow whose handover your team cannot service. A handover to nobody is worse than a bot that politely says you are busy.

Measuring whether any of this works is covered in measuring whether your automation works.

Handover is not one thing

Merchants tend to build a single "talk to a person" exit and stop there. In practice there are four different handovers, and they want different messages.

Type	Trigger	What the customer should be told
Requested	They tapped "talk to a person"	Someone is coming, and roughly when
Failed lookup	No matching order or row	You could not find it, and a person will check properly
Out of scope	The knowledge base could not answer	Nothing about "not understanding" — just that a person will reply
Escalation	A low satisfaction score, or an angry message	An apology first, then the handover

The third row is worth care. "Sorry, I didn't understand that" tells the customer they phrased something badly, which is both untrue and irritating. "Let me get someone who can help with that" says the same thing without blaming them.

Setting an expectation you can meet

The single biggest determinant of whether a handover feels good is what you promise about timing. Three rules:

1. Never say "connecting you now". There is no queue and no connection — someone replies when they can, and the phrasing sets up a wait that feels like a failure.
2. Give a real window during working hours — "within the hour" if that is true, not "as soon as possible".
3. Outside hours, say when you reopen. Combine the handover with a business hours check so the message matches reality instead of promising a reply at 2am.

What your colleague should find

A handover that assigns a chat and nothing else makes your team re-ask questions the bot already asked, which is the specific thing customers hate about talking to a bot first. Three steps fix it:

• Add an internal note carrying everything collected — order number, reason, what they chose. Your colleague opens the chat already briefed.
• Set the conversation status so it lands in the right queue rather than the general list.
• Tag the contact if you will want to find these conversations later, for example to see how many returns came through the bot this month.

Handover during a rush

On a sale day, handover volume rises faster than anything else in the flow, and a handover to a team that cannot answer is worse than a bot that politely explains you are busy. Two adjustments worth making in advance:

1. Widen self-service before the peak, so fewer conversations need a person at all — order status and policy questions are the two that scale best.
2. Be willing to change the promise. "We're unusually busy, so replies are taking a few hours today" is honest and prevents the follow-up messages that make the backlog worse.

None of this costs anything to run: every handover message is a reply inside an open conversation window, which Meta's pricing documentation confirms has been free and unlimited for service conversations since 1 November 2024. There is no cost argument for making it harder to reach a person.

The rule that covers most of it

If a customer has asked twice for a person, the flow has already failed. Design so the first ask works, and treat any second ask as a bug in the flow rather than an impatient customer.

Get that one right and most of the rest follows.