Chatbot Fallback Messages: What to Say When the Bot Has No Answer

Nobody forms an opinion of a chatbot from the answer it got right. They form it from the moment it failed, because that is when they find out whether the thing in front of them is a tool or a wall.

Most fallbacks are written as an apology and nothing else. "I'm sorry, I didn't understand that. Could you rephrase?" That sentence does one useful thing - it admits failure - and then stops, leaving the entire burden of recovery on the person who is already stuck. Asked to rephrase a question they thought was perfectly clear, most people either repeat themselves with different punctuation or leave.

A fallback has one job: give the user a next move that is not their own rewording. Everything below is about what that move should be, and how it should change as the conversation keeps failing.

The three questions a good fallback answers

• Did you hear me? Reflect something back so the user knows input was received.
• What can you do? Offer options, not an empty prompt.
• How do I reach a person? Always visible by the second failure, never buried.

What the numbers look like

Fallback rate is one of the few chatbot metrics with a clear meaning, and one of the least watched. A bot with narrow scope and good content typically sits in the low teens as a percentage of turns. Above roughly a quarter, something structural is wrong - usually missing content rather than a weak model.

The more useful number is what happens next.

Why apologising is the default

Because it is the honest first instinct and nobody revisits it. The apology gets written during the build, when the focus is on the happy path, and it is never read again because the team testing the bot asks questions the bot can answer.

The single biggest improvement available is to stop using the same fallback twice. A bot that says the same sentence three times has told the user it is a loop, and people leave loops. Escalate the response each time input fails.

Strike one: narrow, do not apologise

Assume the question was reasonable and you missed it. Offer the three or four things you actually handle.

I can help with orders, returns, delivery times and account questions. Which is closest?

No apology, no request to rephrase. The user gets a map of what is possible.

Strike two: offer the exit alongside the options

Still not finding it. You can pick from the list above, or I can pass you to someone on the team - they usually reply within a few minutes.

The exit is now explicit. Crucially the options remain, so a user who spots their topic can still self-serve.

Strike three: stop asking and act

Let me get a person. What is the best email for them to reply to?

By the third failure the bot has proven it cannot help. Continuing to offer menus is stubbornness. Collect what a human needs and end the loop.

Why three

One failure is noise - a typo, an unusual phrasing. Two is a pattern. Three is a bot wasting someone's time. Escalating faster frustrates users who would have got there; slower loses them entirely.

What changes at each strike

Detecting frustration should shorten the path

Certain signals should skip straight to strike three regardless of the count: profanity, repeated identical messages, all caps, or an explicit request for a person. A user who has typed "AGENT" twice does not need a menu, and continuing to offer one is the behaviour that generates screenshots on social media.

Resetting the counter

A user who fails once, succeeds, then fails again should get strike one. Carrying the count across a recovered conversation punishes someone for an earlier typo and escalates a conversation that was going fine. Reset on any successful match.

These are written to be pasted and edited. The principle behind each is noted, because the principle survives when the wording does not fit your brand.

When you know the topic but not the intent

I can see this is about a delivery. Do you want to track one, change an address, or report something missing?

Reflect what was understood. Partial understanding is far more reassuring than none.

When the question is out of scope

That one is outside what I can check. The team handles it directly - want me to pass it over?

Say it is out of scope rather than implying the user was unclear.

When the user is clearly frustrated

I am not getting this right. Let me hand you to someone who can sort it properly.

Skip the menu entirely. Detected frustration should shorten the path, not lengthen it.

When it is out of hours

The team is offline until 9am. Leave your question and an email and they will pick it up first thing - or try one of these in the meantime.

Set the expectation before asking for details.

When the user typed one word

Got it - "refund". Do you want to start one, check where yours is, or read the policy?

Treat a keyword as a topic, not as a failure.

Phrases to delete

• "I'm just a bot" - excuses the failure without fixing it.
• "Please rephrase your question" - hands the work back.
• "Invalid input" - form language in a conversation.
• "Oops!" - cheerful about wasting someone's time.
• The same sentence twice - the loop signal.

Two more worth having

When the user asks something you deliberately do not handle

I do not have access to account balances - that one needs the team so they can verify who you are first. Want me to put you through?

Give the reason. "I cannot do that" invites an argument; "I cannot do that because it needs identity verification" does not.

When the user has asked two things at once

Two things there - let me take the delivery question first, then the refund one. Where is your order going?

Split rather than fail. Multi-intent messages are a common fallback trigger and are usually salvageable.

Why apologies stop working

An apology is a transaction: it costs the speaker something and buys goodwill. Repeat it three times without changing behaviour and it costs nothing, buys nothing, and signals that the system has a stock response rather than a solution. The second apology is worth less than the first and the third is worth less than nothing.

Writing several fallbacks and rotating them is standard advice, and the usual reason given - that repetition feels robotic - undersells it.

The real reason is diagnostic. Identical repeated text is how a user concludes they are in a loop with no exit, and that conclusion is what ends the session. Varied wording, even when the underlying options are the same, reads as a system still trying. That buys you the extra turn in which the escalation offer lands.

Rotate the wording, but escalate the substance. Three differently worded versions of "I didn't understand" is still a loop. The variation belongs on top of the three-strike structure, not instead of it.

What to vary and what to hold

Three or four is enough

A handful of variations per strike level covers any realistic conversation. Writing twenty is effort spent where nobody will ever see the difference, since few users hit the same strike more than twice in one session.

Every fallback fire is a logged question your bot could not answer, in the user's own words. That is the most valuable content backlog you will ever get, and most teams never read it.

What to record

• The raw user message that triggered it.
• Which strike it was.
• What the user did next: chose an option, escalated, or left.

What the pattern tells you

Repeated near-identical questions mean a missing intent - add it. A spike after a release usually means new terminology users have adopted that your flow has not. A high rate of leaving on strike one means the options offered do not match what people arrive wanting.

Read the list weekly and fix against real failures. Guessing at what users might ask produces flows that answer questions nobody asked, which is how a bot ends up with wide coverage and a high fallback rate at the same time.

The weekly review, concretely

Thirty minutes. Sort last week's fallback triggers by frequency, read the top twenty in the customer's own words, and ask of each: is there an answer anywhere in our content? If yes, this is a retrieval or phrasing problem. If no, it is a content gap and belongs to whoever owns the help centre.

That single distinction directs almost all the work, and it is why fallback logs are more useful than any dashboard. They are unprompted, unfiltered questions in the language customers actually use - the same material that should be shaping your help content and your flow design.

Watch the trend, not the number

An absolute fallback rate is hard to interpret without context. A rate that climbs week over week always means something: new terminology after a launch, content that went stale, or a change in traffic mix. Set a threshold and review when it moves rather than staring at the number daily. This is the kind of thing that only happens if someone owns it - see who should own your chatbot.

A fallback that ends in a handover is only as good as the handover. Three things decide whether it feels like help or a hot potato.

Carry the transcript

Nothing destroys goodwill faster than a human opening with "how can I help?" after the user has already explained twice. The agent should see the whole conversation before they type.

Say what is happening, in text

Announce the transfer in words rather than signalling it with an avatar change. That is also an accessibility requirement - a colour and an icon reach only the users who could already tell.

Set the wait honestly

"Someone will be with you in about three minutes" is better than a spinner, and far better than silence. If nobody is available, say so and take a message rather than queueing indefinitely.

If you are designing that transition, live chat handover covers the mechanics and the handoff guide covers the routing decisions.

Out of hours is most hours

A nine-to-five support desk covers roughly a quarter of the week. The fallback that ends in "let me get someone" is therefore usually firing when nobody is there, and the flow has to say so rather than queueing silently into a void.

The team is offline until 9am tomorrow. I can take your question and an email address and they will reply first thing - or if it is urgent, here is the number.

What the agent needs

• The full transcript, not a summary.
• What the bot could not answer, stated plainly.
• Anything already collected - order number, email - so the customer is not asked twice.

Asking a customer to repeat what they typed three messages ago is the moment a handover stops feeling like escalation and starts feeling like being passed around.

Structurally, the three-strike pattern needs a counter and three branches. Increment on each failed match, and route to a different response at each level with the escalation as the terminal state.

Two things worth getting right while building:

• Reset the counter on success. A user who fails once, succeeds, then fails again should get strike one - not strike two. Carrying the count across a recovered conversation punishes people for a single earlier typo.
• Never let the terminal branch dead-end. If no human is available, collect an email. A flow whose last node is an apology is the loop you were trying to avoid, with extra steps.

In a visual builder this is visible on the canvas, which is the main practical argument for building it there - a branch with no exit is obvious as a shape long before anyone tests it. The support and FAQ templates ship with the pattern already wired, and the free plan is enough to test it against real traffic.

The shape on the canvas

A counter, three branches and a terminal state. What makes it robust is what happens at the edges rather than in the middle.

Fallbacks in AI-answered flows

With a model answering from a knowledge base, the fallback is not triggered by failed keyword matching but by the model having nothing grounded to answer from. That only works if the system prompt tells it explicitly what to do in that case - without the instruction, it will produce a plausible answer instead of handing over, which is worse than any fallback message. Grounding it properly in an AI knowledge base is what keeps the fallback meaningful, and model choice affects how reliably a model refuses rather than guesses.

Before rewriting the message, it is worth understanding what produced it, because roughly half of fallbacks are avoidable rather than genuine scope limits.

The five causes, in rough order of frequency

Vocabulary is the one teams underestimate

Organisations develop internal language and then write help content in it. Customers use different words entirely - "my payment did not go through" rather than "transaction declined", "cancel my thing" rather than "terminate subscription". A bot trained on internal vocabulary fails on customer vocabulary, and the fallback log is precisely where you discover the gap.

The fix is not a better model. It is adding the customer's phrasing to your content, which is why reading the raw triggers weekly does more for answer rate than any configuration change.

The half you cannot fix

Some fallbacks are correct behaviour. A question about something you genuinely do not do should fall back, and trying to eliminate those produces a bot that answers questions it should refuse. The target is not zero - it is that every fallback either recovers the conversation or routes it cleanly, which is what the three-strike structure is for.

Fallback improvements are easy to make and easy to believe in without evidence. Three numbers tell you whether the rewrite helped.

Why escalations rising is often good

Teams treat handovers as a cost and optimise them down. Early on, a rising escalation rate after a fallback rewrite usually means people who would previously have left are now reaching a person - which is the outcome you wanted. Watch abandonment alongside it; escalations up and abandonment down is the pattern to look for.

A small experiment worth running

Change strike one only, leave everything else, and compare two weeks against the two before. It is the highest-leverage message in the sequence because every fallback passes through it, and isolating it is the only way to know whether the change or the traffic did the work. The analytics guide covers setting that up.

A fallback is the visible symptom of decisions made elsewhere. Improving the message helps; improving what causes it helps more.

If your fallback rate is very high

Above roughly a quarter of turns, stop editing messages and look at scope. Either the bot is being asked things it was never built for - in which case the opening message is over-promising - or the content is not there. When not to use a chatbot covers the cases where the honest answer is that the flow should not exist.

Starting from something that works

The three-strike pattern is wired into the support and FAQ templates, which is a faster starting point than a blank canvas. Build it in the visual builder where a branch with no exit is visible as a shape, deploy it to your website or any other channel, and test against real traffic on the free plan.

Failure states are where brand voice usually collapses, because they are written last and by whoever was closest to the deadline. A bot that is warm when it succeeds and institutional when it fails has two voices, and the seam is visible exactly when trust is most fragile.

Write these first, not last

Drafting the failure messages before the happy path forces the voice to survive contact with bad news. It is the only real test of a tone of voice, and it takes an hour.

Register by situation

The cheerfulness trap

Playful copy reads well on a happy path and badly on a third failure. "Oops! My bad!" after wasting two minutes of someone's time reads as not taking the problem seriously. Keep the personality, drop the exclamation marks as the strike count rises.

One voice across channels

The same fallback appears on your website, WhatsApp and Telegram. Writing them once and deploying everywhere keeps the voice consistent and halves the maintenance - which matters more than it sounds, because inconsistency between channels is exactly what makes an operation feel improvised.