A chatbot should hand over when the customer asks for a person, when it has failed to answer the same question twice, when the topic is on your never-alone list (complaints, refunds, safety, health, bereavement), when the customer sounds frustrated, when the stakes are high, or when it has no source to answer from. Set these as explicit rules, not as the bot's judgement.
The rules are the easy half. The half that goes wrong is what happens after the handover. If nobody is there to pick it up, the customer has been passed from a bot to silence, which feels worse than never having a bot. So every handover rule needs a matching answer to "who receives it, on which channel, and how soon", including evenings and weekends.
Seven triggers, with thresholds you can set
| Trigger | Threshold | Example the bot should catch |
|---|---|---|
| Customer asks for a person | Once, clearly; or twice, in any wording | "Can I talk to someone real?" |
| Failed answers | Two attempts at the same question | Customer rephrases the same question a second time |
| Never-alone topic | Any mention | Complaint, refund, damage, injury, illness, a death |
| Frustration | One strong signal or two mild ones | Capitals, "this is useless", "I've already said" |
| High stakes | Your own value or size limit | A group booking for six rooms; a corporate account |
| No source | Answer isn't in the knowledge it was given | "Is the pool heated in October?" when the FAQ doesn't say |
| Vulnerability | Any sign the customer needs extra care | Confusion, mentions of disability or distress, a child writing |
Two of these deserve a closer look because they're where most small-business bots go wrong.
The two-attempt rule. If a customer asks something, gets an answer, and asks again in different words, the first answer didn't help. A second try is reasonable; a third is a loop. Here's a before-and-after from an illustrative campsite's chatbot:
Before: Customer: "Can we arrive after 9pm?" Bot: "Check-in is from 2pm to 8pm." Customer: "Yes but we'll be late, is that OK?" Bot: "Check-in is from 2pm to 8pm. Late arrivals should contact us." Customer: "I AM contacting you." Bot: "I'm sorry, I didn't understand. Check-in is from 2pm to 8pm."
After: Customer: "Can we arrive after 9pm?" Bot: "Check-in is from 2pm to 8pm. Late arrivals are possible by arrangement." Customer: "Yes but we'll be late, is that OK?" Bot: "I'll pass this to the office so they can arrange it. Can I take your booking name and the time you expect to arrive? They'll reply by 10am tomorrow, or sooner if you're arriving today."
The no-source rule. A bot given your FAQ will still try to answer questions the FAQ doesn't cover, drawing on general knowledge or plain invention. Tell it that anything not in its sources is a handover, not a guess. It's the single rule that prevents most wrong answers.
What goes on your never-alone list
Some conversations should go to a person at the first mention, however well the bot might cope. The list differs by business, so write your own. Four illustrative versions:
- A guest house: complaints, refunds, any problem with a current stay (no hot water tonight is not an FAQ), allergies and dietary needs at breakfast, accessibility questions.
- A holiday-let manager: damage, leaks, lockouts, gas or electrical smells, deposit disputes, owner enquiries (property owners asking about their income belong with the manager, not the guest bot).
- A members' club: cancellations (a person may keep the member), disputes between members, complaints about staff, anything about fees owed.
- A church office: funerals, bereavement, pastoral care, safeguarding concerns, anything that sounds like someone in crisis.
Put safety at the top of every list. If a message mentions fire, gas, flooding, injury or someone at risk, the bot should give the emergency instruction first ("If anyone is in danger, call the emergency services now") and then pass the conversation on, marked urgent.
Frustration signals a bot can actually detect
You can't ask a bot to "notice if the customer is unhappy" and expect consistency. You can give it signals to watch for. Strong signals mean hand over at once; two mild ones mean hand over.
- Strong: swearing, "complaint", "ridiculous", "useless", "let me speak to", a threat to leave a bad review or cancel.
- Mild: capitals, repeated question marks, "I already told you", "that's not what I asked", very short replies after long ones, the same booking reference sent twice.
A realistic miss shows why the list matters. In this invented but typical case, a boutique hotel's bot handled a guest who wrote, politely, "The room is lovely but it's very cold and the heating doesn't seem to be doing anything." The bot replied with instructions for the thermostat. The guest tried them and wrote back "Still cold." The bot sent the instructions again. Nothing in either message was rude, so no frustration rule fired, and the guest called reception an hour later, much less politely. The fix was to add "problem with the room during a stay" to the never-alone list: any live issue with a current stay goes to the duty manager, because it needs someone to go and look.
Setting a high-stakes line in numbers
"High stakes" only works as a rule if it's a number the bot can check. Base it on what a normal enquiry is worth to you, and on the enquiries where a person closes the sale better than a bot.
Run the numbers for a hypothetical boutique hotel: its average booking is two nights at about $190 a night, so roughly $380. The owner set the line at three times that, about $1,140, which in practice means four or more room-nights in one enquiry, plus anything mentioning a wedding, a corporate account, exclusive use or a private dinner. Those enquiries go to the manager straight away, during the day by live chat and in the evening by a callback promise. The reasoning is simple: a person who replies quickly and asks good questions wins more of those bookings, and one extra group booking a month is worth more than the time saved by letting the bot handle it.
For a guest house with six rooms, the line might be three rooms, because that's half the house on one decision. For a members' club, it might be any enquiry about corporate or family membership. For a campsite, it's group bookings and rallies, where pitch layout and noise rules need a conversation. Write the number into the bot's instructions, not "large bookings", which each model will interpret differently.
Handing over well: what the person taking over needs
A handover that makes the customer repeat everything wastes the bot's work and annoys the customer. Have the bot write a short summary for the person taking over, and tell the customer what happens next.
An illustrative handover note generated by a guest house's bot:
HANDOVER - reason: customer asked for a person (2nd request)
Customer: [name], booking ref [ref], arriving Fri 14th, 2 nights
Wants: to bring a second dog; FAQ allows one dog per room
Bot already said: one-dog policy, $15/night charge
Mood: polite, a bit impatient
Promised: reply by email before 6pm todayAnd what the customer sees:
"I've passed this to the owners with your booking details, so you won't need to explain again. They'll email you before 6pm today. If it's urgent, you can call the house on [number] until 8pm."
Three things make that message work: it confirms the details have been passed on, it gives a specific time rather than "soon", and it offers a faster route for urgent cases. Compare the common version, "A member of our team will be in touch shortly", which promises nothing and often arrives outside working hours.
Handover when nobody's on shift
Most small businesses can't staff live chat all day, and that's fine, as long as the bot doesn't pretend otherwise. Out of hours, a handover becomes a promise with a time:
- Collect what the person will need: name, contact details, booking reference, the question in the customer's words.
- Say when they'll hear back, based on your real hours ("by 10am tomorrow"), and keep the promise.
- Give an urgent route for genuine emergencies, such as an out-of-hours phone number, and describe what counts as urgent.
- Tell the bot your hours, including holidays, so it doesn't promise a same-day reply on a public holiday.
A holiday-let manager shows why the urgent route matters. Guests arriving at 9pm to a key safe that won't open aren't going to wait until morning. The manager's bot now treats "can't get in", "no power" and "water leak" as urgent at any hour, gives the out-of-hours number immediately, and sends the handover note to the on-call phone by text.
Handing back: stop the bot talking over your staff
The handover that nobody plans for is the one going the other way. Once a person has joined a conversation, the bot must stay quiet on that thread. Otherwise it picks up the customer's next message and answers from its FAQ, contradicting whatever the person just agreed.
Here's how that showed up at an illustrative guest house. The owner took over the two-dog conversation above and agreed, as a one-off, that the guests could bring both dogs. The next morning the guest asked, in the same chat, whether there was a dog bowl in the room. The bot answered, and added a helpful reminder that "our policy allows one dog per room". The guest, understandably, asked which answer was true.
Three settings or rules prevent it:
- A pause after a person replies. Many tools let you pause the bot on a conversation once a team member has joined. If yours has a time option, 24 to 48 hours is a sensible default.
- Agreed exceptions written into the conversation record, so that if the bot does resume later it can see "owner agreed two dogs for this booking".
- A clear hand-back line when the person finishes: "I'll leave you with our assistant for any other questions; it knows about the arrangement we've made." Only use this if the bot really can see that note.
Writing the rules into the bot
Most chatbot tools accept written instructions; some also have settings for handover, such as a "talk to a person" button or a list of topics that trigger escalation. Use both where available. A starting instruction block:
HAND OVER TO A PERSON when any of these happen. Do not try to answer first.
1. The customer asks for a person, a human, staff, the owner or a manager.
2. You have answered the same question twice and the customer asks again.
3. The message mentions: complaint, refund, compensation, damage, injury,
illness, allergy, death, funeral, safeguarding, or a problem during a
current stay.
4. The customer shows frustration: swearing, "useless", capitals, "I already
said", a threat to cancel or review.
5. The request involves [your high-stakes list, e.g. 4+ rooms, events, corporate].
6. The answer is not in the information you were given. Never guess.
7. The customer seems confused, distressed or vulnerable.
EMERGENCIES (fire, gas, flood, injury, someone at risk): first say
"If anyone is in danger, call the emergency services now", then hand over as URGENT.
WHEN HANDING OVER: write a summary (reason, customer details, what they want,
what you already said, anything promised). Tell the customer who will reply,
on which channel, and by when, using our hours: [hours].Instructions alone aren't a guarantee, which is why the testing below matters. A related set of rules, about stopping the bot making offers you don't make, is in chatbot guardrails. And if you sell to customers in the EU, the bot's first message must make clear it's AI; the wording options are in what to tell customers at the start of a chat.
Test the handover before customers do
Write one test conversation for each trigger and run them all before launch and after every change to the bot's instructions. A filled-in test sheet, with made-up results from a members' club:
| Test message | Expected | Result |
|---|---|---|
| "Can I speak to the secretary?" | Hand over | Pass |
| "When are the courts open?" then the same question reworded twice | Hand over on third ask | Fail: answered three times |
| "I want to cancel my membership" | Hand over | Fail: sent cancellation form link |
| "Someone has fallen in the car park" | Emergency line, then urgent handover | Pass |
| "Do you do a family membership for grandparents?" | Not in FAQ, so hand over | Fail: invented a price |
| "THIS IS THE THIRD TIME I'VE ASKED" | Hand over | Pass |
| Message at 11pm Saturday asking for a person | Take details, promise Monday reply | Fail: promised "within the hour" |
Four failures out of seven is a normal first run. The invented family-membership price was the most serious, and it came from the bot reading a web page about junior memberships and extrapolating. The fix was to restrict its sources to the FAQ and add the no-guessing line. After two rounds of fixes, all seven passed. A fuller pre-launch routine is in testing a customer chatbot before it goes live.
Too early, too late: reading your handover log
After launch, review a sample of conversations every week, including every handover. You're looking for two opposite problems:
- Too late: the customer asked for a person and didn't get one, the bot looped, or a never-alone topic was answered. These are the serious ones, because the customer has already had a bad experience.
- Too early: the bot handed over questions its sources could answer, such as a question about parking that the FAQ covers. These cost staff time but rarely upset anyone. Usually the fix is a better FAQ entry, not a looser rule.
Track the handover rate weekly, and alongside it the reasons. For a hypothetical guest house, the first month's 212 chats produced 71 handovers (33%). Twenty-six were "no source", and most of those were five questions: late checkout, breakfast for early departures, cot availability, bike storage and walking routes. Adding those to the FAQ took the next month's rate to 21%. The owner stopped there, happy that the remaining handovers were the conversations they wanted to have themselves. Don't chase the rate to zero; a bot that never hands over is usually one that customers can't get past. For the wider set of numbers worth tracking, see how to measure whether your chatbot works.
A chat assistant can speed up the weekly review. Export the week's handed-over conversations, remove customer names and contact details, and ask:
Here are this week's chatbot conversations that were handed to a person.
For each, give: the handover reason | whether the handover was necessary
(yes / no, the FAQ covers it / no, the bot should have answered) | the
question the customer actually wanted answered.
Then list the questions that caused more than one handover, most frequent first.An illustrative result for the guest house's first week: 17 handovers; 11 necessary (complaints, a current-stay problem, two requests for the owners, a group booking); 6 avoidable, of which four were about cots and high chairs, which the FAQ didn't mention. That one line of output told the owners exactly which FAQ entry to write next. Read a few of the conversations yourself as well, because the summary will sometimes call a handover unnecessary when the customer was plainly upset.
A quick check for your own bot
Open your chatbot now and try five things: ask for a person; ask a question you know isn't in its sources; ask the same question three times; mention a complaint; and send a message outside your working hours. If any of those doesn't end with a clear handover, a named next step and a realistic time, fix that before anything else. Those five cover most of the conversations where a bot does more harm than good.
Handover questions owners ask
What's a normal handover rate for a small business chatbot?
There isn't a useful universal figure, because it depends on how many of your questions are routine. Track your own rate weekly. A high rate in the first month is normal and tells you which answers to add. A rate near zero is a warning sign that customers can't reach a person, not proof the bot is brilliant.
Should the chatbot always offer a 'talk to a person' button?
Yes, visibly and from the first message. Some businesses hide it to push customers towards the bot, and it backfires: frustrated customers leave, or come back angrier on the phone. A visible option also makes customers more willing to try the bot first, because they know they aren't trapped.
Can the bot hand over to WhatsApp or phone instead of live chat?
It can, and for a small team that's often more realistic than staffing live chat. The bot collects the details and a summary, then the customer gets a message or a call back. Say clearly which channel and roughly when, and make sure the summary reaches whoever answers that channel.
Who is responsible if the bot gives a wrong answer before handing over?
Generally the business that runs the chatbot, not the customer. That's a strong reason to hand over early on anything involving money, safety or promises. For your own situation, especially if a wrong answer has already caused a loss, ask a solicitor rather than relying on general guidance.
Further reads
- Who Is Liable When Your AI Chatbot Gets It Wrong? — Who carries the risk when the bot gets it wrong.
- Can a B&B Use an AI Chatbot and Keep the Personal Touch? — Keeping a personal feel when a bot answers first.
- Can a Hotel Chatbot Take Bookings or Only Answer Questions? — Whether a hotel bot should take bookings at all.
- 9 AI Chatbot Mistakes That Lose Small Businesses Customers — Other chatbot errors that quietly lose customers.
- How to Measure Customer Reaction After Introducing AI — Four signals, survey wording that doesn't lead, a conversation-sorting prompt and a decision rule for reading small-business numbers honestly.
- What to Do When AI Gets Something Wrong With a Customer — The first hour after an AI error reaches a customer: whether to honour what it said, apology wording for email and phone, and how to stop it happening again.
- AI Mistakes That Damage Customer Trust, and How to Avoid Them — Nine AI mistakes customers notice, why each one stings, how to prevent it, and a 20-minute monthly check that catches problems before customers do.
- Best AI Chatbots for Small Shopify Stores (2026) — Shopify Inbox now has a free AI agent. When it's enough, when Tidio or Gorgias earns its fee, and a 30-question test to pick the right one.
- AI Booking Systems for Appointment Businesses: What to Check — A 24-point checklist for choosing an AI booking system, grouped by risk, with how to verify each item and a two-hour test script to run before you sign.
- How to Set Up an AI Phone Line for Takeaway Orders — Seven steps from counting your calls to a tested AI phone line that takes takeaway orders into your till, with the three routes compared.
- How to Automate Pre-Arrival and Post-Stay Emails With AI — A six-message guest email timeline, the templates to write with AI, the rules for who gets what, and how to let AI draft replies safely.
- How Wedding Venues Use AI for Viewings, Enquiries and Follow-Ups — Use AI at three points in a venue's sales pipeline: the first reply, the notes after each viewing, and follow-ups timed around provisional holds.
- How Day Spas Can Take Bookings From Instagram DMs With AI — Three ways to put AI in a spa's Instagram inbox, the knowledge sheet it needs, when to hand over to a therapist, and a 20-message test before launch.
- How Boutiques Can Answer Customer DMs Within an Hour Using AI — A three-layer system for boutique DMs: automatic acknowledgement, AI-drafted answers from a fit-and-stock sheet, and a rota that keeps replies under an hour.
- AI Tools and AI Development: The Complete 2026 Guide — the AI hub, including every tutorial in the AI-for-business series.