Advice on chatbot handovers tends to fixate on the trigger: the moment the software decides a human should step in. That matters, but it is not where customers get annoyed.
They get annoyed after the trigger. The chat says "connecting you to a member of the team", a person arrives, and the first thing that person types is "Hi, how can I help?" The customer has already explained, in some detail, that the delivery arrived damaged, and now has to explain it again to someone who apparently was not listening.
A good ai handover to a human is judged entirely from the customer's side. The software can work flawlessly and the handover still fail. Here is what separates the clean ones.
Two versions of the same handover
A customer of a furniture shop has a problem with an order.
The poor version:
Visitor: My table arrived with a cracked leg. Order 50821. I want to know what happens now.
Assistant: I'm sorry to hear that. Let me connect you to a member of our team.
Team member: Hi there! How can I help you today?
Visitor: I literally just said.
The clean version:
Visitor: My table arrived with a cracked leg. Order 50821. I want to know what happens now.
Assistant: Sorry, that's frustrating. Damaged items are handled by the customer care team, and someone is available now. Before I pass you over, could you tell me if the rest of the order arrived all right? That way they can sort everything in one go.
Visitor: Yes, the chairs are fine.
Assistant: Thanks. I'm passing this to Sam now with your order number and the details. They'll reply here in a minute or two.
Team member: Hi, it's Sam. I can see order 50821 and the cracked table leg, and that the chairs are fine. I'll arrange a replacement leg or a full swap, whichever you prefer.
Same trigger. Very different experience. The rest of this piece picks apart why.
The four parts of a clean handover
- Recognising the moment early. The visitor above said "I want to know what happens now", which is a request for a decision the assistant cannot make. The assistant did not try to answer from the returns policy and then transfer after three frustrated messages.
- Collecting just enough first. One extra question, relevant and quick. Not a form. The goal is to give the person what they need to reply usefully, without making the visitor feel processed.
- Saying what happens next. Who is coming, roughly when, and where the reply will appear. Uncertainty is what makes people type "hello??" repeatedly.
- Never asking twice. The team member reads the conversation before typing. Their first message proves they did.
That last part is on your team, not on the software. In SpideyChat, a team member marked on duty can take over from the inbox with the full conversation in front of them. Whether they read it is a matter of habit, and worth making an explicit rule.
What the person should receive
Whether the handover is live or later, the human needs the same basics. The table shows the difference between a thin handover and a useful one.
| Information | Thin handover | Useful handover |
|---|---|---|
| Who | "A visitor" | Name, and email or phone if given |
| What | "Question about order" | Order number, the problem, what they want |
| Already tried | Nothing | What the assistant told them, so nobody contradicts it |
| Mood | Not recorded | Obvious from the transcript, but worth a glance before replying |
| Promised next step | Unknown | Exactly what the visitor was told would happen |
The "promised next step" row causes more trouble than any other. If the assistant said "someone will email you within one working day", your team now owns that promise. Keep the wording in your instructions honest about how fast you really reply.
When there is nobody to hand over to
Most small businesses are not staffed at 11pm on a Sunday, and pretending otherwise is the worst possible handover. A button offering a person, followed by silence, teaches visitors that your business does not answer.
When nobody is on duty, the handover becomes a written one. The assistant says the team is away and when they return, collects the details above, and either captures the enquiry as a lead or opens a numbered support ticket for existing customers. The customer leaves knowing that a real person will pick it up, and roughly when.
That is a perfectly good outcome. Arguably better than a rushed live reply from someone half-watching the inbox on their phone at a family dinner. Your morning routine then does the rest; following up on chatbot leads has timings and templates for those replies.
Common ways handovers go wrong
A few patterns turn up repeatedly when businesses review their transcripts:
- The loop. The visitor asks for a person, the assistant offers another article, the visitor asks again. A direct request for a human should be honoured the first time.
- The late transfer. The assistant tries for five messages to answer something it cannot, then hands over a visitor who is now irritated.
- The phantom promise. "Someone will call you shortly" when nobody will, or when the business does not call people at all.
- The cold open. The team member starts from scratch, as in the first example above.
For deciding exactly which situations should trigger a transfer, see when should a chatbot hand over to a human. This piece is about doing it well once the decision is made.
Test your own handover this week
Open your website on your phone and play the customer. Ask something the assistant should not handle, then ask for a person, once during your on-duty hours and once outside them. Time how long it takes for someone to join, read what that person types first, and check what you were told would happen next. Then have a colleague do the same without warning.
If either test produces a cold open or a promise you cannot keep, fix the instructions and your on-duty rota before anything else. If transfer to a human is not yet switched on, starting with no permissions covers when it is ready, and the features page explains the live takeover option.