AI chatbot fallback messages are the words a bot uses when it cannot answer: the “sorry, I did not understand” moment. It is the least glamorous part of a chatbot and often the most important, because it is the message a visitor reads right when they are already a little frustrated. This guide gives you the principles, sample wording for each situation, and a way to test what you wrote.
The advice applies to any chatbot, but the examples assume an assistant like Mio that answers only from your own content and passes the chat to a person when it cannot help.
What a Fallback Message Actually Is
A fallback is any reply a bot sends when its normal path fails. In older rule-based bots, that meant “I didn’t get that, please pick an option.” With an AI assistant that reads your website and documents, the failure looks different. The bot understood the words but could not find the answer in the content it was given, or the question is one it should not answer at all.
That gives you at least five distinct situations, and each deserves different wording:
- No answer in the content. The question is reasonable but your site does not cover it.
- A question the bot should not answer. Legal advice, medical advice, a promise about delivery dates, a discount that was never published.
- The visitor asks for a person. A handoff request should never be argued with.
- A complaint or an order-specific question. These need a human with account access.
- The team is offline. Handoff is impossible right now, so the message has to set expectations honestly.
Treating all five with one generic “Sorry, I can’t help with that” is the most common mistake. It tells the visitor nothing about what happens next.
Why Fallback Wording Matters More Than It Seems
Every fallback is a fork. The visitor either continues, by rephrasing or waiting for a person, or leaves. Two things push them towards leaving: a message that sounds like a dead end, and a message that pretends the bot did something useful when it did not.
There is also a trust argument. An assistant that says plainly “I don’t have that information, let me bring in a colleague” is more believable than one that produces a confident guess. This is the core of hallucination control: the safest AI answer to an unknown is an honest handoff, not an invention (the general problem is described in this overview of AI hallucination). Mio is built on that principle. It answers from your content and never invents prices or policies.
Five Principles for Writing Fallbacks
1. Say what happened, in one short clause
“I couldn’t find that in our information” is enough. Do not apologise three times and do not explain how language models work.
2. Say what happens next
The most useful sentence in a fallback is the one that names the next step: “I’m connecting you with a member of the team” or “Leave your e-mail and we’ll reply by tomorrow morning.” A visitor who knows what happens next will wait. A visitor who does not will leave.
3. Never loop
If the same fallback appears twice in a row, the bot has failed twice. After the second miss, offer the human route directly rather than asking the visitor to rephrase a third time.
4. Match your brand voice, not a template
A dental practice, a B2B software vendor and a fashion shop should not sound the same. Match the register of your greeting; the guidance in writing live chat greeting messages applies here as well.
5. Do not pretend to be human
Avoid fake typing delays and phrases like “let me check that for you” when nothing is being checked. If you are unsure about disclosure, the article on AI chatbot disclosure covers the reasons to be open.
Fallback Message Examples by Situation
These are starting points. Rewrite them in your own voice and check them against what your team can really deliver.
The answer is not in your content
“I couldn’t find that in what I know about us. I’ll pass this to the team so you get a correct answer. Meanwhile, could you tell me a little more about what you need?”
The follow-up question gives the human a head start and keeps the visitor engaged while the handoff happens.
The visitor asks for a person
“Of course. I’m getting a member of the team for you now.”
No questions, no attempts to talk them out of it. Mio hands over when a visitor asks for a person, which is the behaviour you want.
A complaint
“I’m sorry this went wrong. I’m bringing in a colleague who can look into it properly, and they’ll see everything you’ve written so far.”
The last clause matters. The fear behind every complaint is having to explain the problem again.
An order-specific question
“For anything about a specific order I need a teammate who can see your account. I’m connecting you now, and it helps if you have the order number handy.”
A question the bot must not answer
“I can’t advise on that, and I’d rather not guess. Our team can talk you through it. Would you like me to connect you?”
Business instructions in Mio’s settings let you state what it must never promise, for example “never quote delivery dates, hand order questions to the team”. The fallback should echo the same boundary in a friendlier form.
The team is offline
“Our team is away right now. Leave your e-mail and your question, and we’ll reply by e-mail as soon as we’re back, usually within one working day.”
Only write “usually within one working day” if it is true. In Talkmio, when the whole team is offline, visitors are asked for an e-mail before their first message, and the reply from the Inbox goes out as an e-mail. Your wording should describe exactly that flow.
Comparison: Weak vs Strong Fallbacks
| Situation | Weak fallback | Stronger fallback | Why it works |
|---|---|---|---|
| Not in content | “Sorry, I didn’t understand.” | “I couldn’t find that in our information. I’m passing it to the team.” | Honest, names next step |
| Repeated miss | Same apology again | “Let me get someone who can help directly.” | Ends the loop |
| Person requested | “Can I help you with something first?” | “Of course, connecting you now.” | Respects the request |
| Offline | “Try again later.” | “Leave your e-mail and we’ll reply by e-mail.” | Keeps the lead |
| Sensitive topic | A confident guess | “I’d rather not guess. Our team can advise.” | Avoids a wrong promise |
Where Fallbacks Are Configured in Practice
Different products expose different controls. In Talkmio, handoff behaviour is built in: Mio hands the chat over when it cannot answer from your content, when the visitor asks for a person, complains or asks about an order. The conversation gets a “needs human” badge in the Inbox, a browser notification fires, and if nobody is online an e-mail and a mobile push notification go out. You shape the wording through the business instructions, the welcome and offline texts, and the knowledge you provide. You do not build a flowchart of failure branches.
Some competing tools give you more granular, visual control over each fallback branch, with different messages per intent. If you want to script precise dead-end handling per topic, a flow builder does that better than a knowledge-first assistant. The trade-off is that you then maintain the flows yourself. For background on the wider category, see the general overview of chatbots. The comparison of AI chatbots and rule-based chatbots explains where each approach fits.
Reduce the Number of Fallbacks You Need
The best fallback is the one that never fires. Most misses come from gaps in the source content, not from the AI. A monthly review loop keeps them shrinking:
- Open conversations where Mio handed off to a human because it could not answer.
- Group them by topic. Three visitors asking about the same thing is a content gap.
- Add or improve a page, a Q&A pair or a document, then re-read the source.
- Ask the same question in Try Mio and check which knowledge pieces were used.
- Repeat next month.
What to write in the first place is covered in what to put in a knowledge base for AI chatbots, and the audit method in auditing and improving chatbot answers.
Language and Tone Across Markets
Mio replies in the visitor’s language, and questions in one language can find answers written in another, so a Lithuanian visitor can get an answer from an English FAQ. The widget UI is translated too. Your own custom offline text and welcome message are yours to write, so check them in each language you serve. A fallback that is warm in English and blunt in German, or the reverse, reads as careless. Have a native speaker glance at the two or three messages that matter most.
How to Test Your Fallback Messages
Do this before you go live, then again after any big content change.
- Ask something unrelated. “What’s the weather in Vilnius?” should not produce a guess.
- Ask something related but missing. Pick a plausible question your site does not cover.
- Ask for a person, twice. Check that the bot does not argue.
- Complain. Type an annoyed message and see whether it hands over.
- Ask about an order. It should not invent a status.
- Test offline. Set your status to offline and confirm the visitor is asked for an e-mail and told when to expect a reply.
- Test on a phone. A long fallback paragraph is worse on a small screen. Keep it to two or three lines.
Also read the first few fallbacks in your live chat history. Real visitors phrase things in ways nobody on your team predicted.
Common Fallback Mistakes
- Apologising in every line. One “sorry” is honest; four is theatre.
- Offering an option that does not exist, such as a phone number nobody answers.
- Promising a response time the team cannot meet.
- Asking the visitor to rephrase forever.
- Sending a wall of links instead of a person.
- Hiding the handoff path. If a visitor wants a human, make it obvious how.
Frequently Asked Questions
What is a fallback message in a chatbot?
A fallback message is the reply a chatbot sends when it cannot complete the normal path, for example when it has no answer in its content or the visitor asks for something it should not handle. A good one says what happened, names what happens next, and offers a human route instead of leaving the visitor at a dead end.
How many times should a chatbot ask a visitor to rephrase?
At most once. If the first attempt fails, one rephrase request is reasonable. After a second miss, offer the human route directly, either by connecting the visitor to a person or by collecting an e-mail address. Asking for a third rephrase almost always ends with the visitor leaving the chat.
Should a fallback message apologise?
Once, briefly. A single short apology acknowledges the problem, but repeated apologies read as filler and delay the useful part, which is what happens next. Put the apology in one clause and spend the rest of the message on the next step, such as connecting a person or collecting an e-mail.
What should an AI chatbot say when the team is offline?
It should say honestly that nobody is available, ask for an e-mail address and a description of the question, and state a realistic time for the reply. Only promise a response window your team meets. In Talkmio, visitors are asked for an e-mail when the whole team is offline, and your reply goes out as an e-mail.
Can a fallback message be different in each language?
Yes, and it should read naturally in each. Mio replies in the visitor’s language, but custom texts such as the offline message and welcome message are written by you. Have someone fluent read the messages for each language you serve so tone and formality match your brand in every market.
How do I reduce how often the chatbot falls back?
Review the conversations that were handed to a human because the bot could not answer, group them by topic, and add or improve the matching page, Q&A pair or document. Then re-test the question and check which knowledge pieces were used. Most fallbacks trace back to a gap in the content, not to the AI.
The Bottom Line
Good AI chatbot fallback messages are short, honest and specific about what happens next. Write a different one for each of the five situations: no answer, forbidden topic, request for a person, complaint or order question, and offline team. Test them with awkward questions before launch, and shrink the number of fallbacks over time by fixing the content gaps behind them. Mio is designed around this idea, answering only from your content and handing over when it cannot, so you can try the behaviour with the free plan at app.talkmio.com.
