Chatbot Fallback Handling: What Happens When It Doesn't Know the Answer

In February 2024 a Canadian tribunal ordered Air Canada to compensate a passenger because its chatbot had invented a bereavement fare policy that did not exist. The airline argued the bot was a separate entity responsible for its own statements. The tribunal disagreed, finding the airline had not taken reasonable care to ensure the chatbot was accurate, and awarded damages of about CA$812.

The interesting part is not the money. It is that the bot was never asked to make anything up. It was asked a question its knowledge base did not cover, and nothing in its design told it what to do with that.

Chatbot fallback handling is the answer to that question, and it is the part of a deployment that gets the least attention and causes the most damage. Every bot meets questions it cannot answer. What separates a support asset from a liability is entirely what happens in the next three seconds.

What Chatbot Fallback Handling Actually Covers

Fallback is not one message. It is four decisions, and most teams only make the first one.

1. Detection — how the bot decides it does not know, before it starts writing.
2. The response — what the customer sees when the bot admits the gap.
3. The route out — where the conversation goes next, and how fast.
4. The record — what gets logged so the gap gets closed.

Skip the fourth and you have a bot that fails politely forever. Skip the third and you have a dead end with good manners.

Detection is worth understanding because it is where the architecture matters. In a retrieval-based bot, the question is converted into an embedding, the closest passages from your content are pulled back, and the model is instructed to answer from those passages only. If nothing retrieved is close enough, the honest output is an admission — the model has nothing to work from. This is one of the practical arguments for retrieval over fine-tuning, covered in more depth in our comparison of RAG and fine-tuning: a fine-tuned model has no equivalent of "nothing came back", so its failure mode is fluent invention rather than a clean stop.

Not Knowing Has Four Different Causes

Treating every failure the same way is why fallback rates stay high. The four causes need different fixes, and your logs can distinguish them if you read them.

Cause	What it looks like	The actual fix
Content gap	Clear question, nothing in the knowledge base covers it	Write the answer. Half of first-month fallbacks are this.
Phrasing mismatch	The answer exists but the customer used different words	Add the customer's phrasing as a Q&A pair, don't rewrite the page
Out of scope	Account balances, order status, anything customer-specific	Integration or handoff — no amount of content fixes it
Genuinely ambiguous	"Does it work with mine?" with no antecedent	A clarifying question, not a fallback message

That last row matters more than its frequency suggests. Comprehension failures, not knowledge failures, drive the majority of escalations in most deployments. A bot that asks "which plan are you on?" instead of apologising recovers a conversation that would otherwise have been lost.

Rows one and two get confused constantly. If your shipping page says "dispatch occurs within two business days" and the customer asks "when will it ship", that is not a content gap — the content is there and retrieval missed. Adding a third shipping page will not help. Adding the question in the customer's own words will.

What a Good Fallback Message Sounds Like

The default on most platforms is some variant of "I'm sorry, I didn't understand that. Could you rephrase?" It is the worst available option: it blames the customer, offers no route forward, and invites a second attempt that will probably fail the same way.

A fallback message has four jobs, in this order:

1. State the limit plainly. "I don't have information about that" — not "I didn't understand", which is a different and more insulting claim.
2. Say what you do have, if it is close. "I can help with returns and delivery times."
3. Offer the human immediately. First fallback, first offer. Not after three failed loops.
4. Never apologise twice. Repeated apology reads as evasion.

Compare:

"I'm sorry, I didn't quite catch that. Can you try rephrasing your question?"

against:

"I don't have anything on bereavement fares in my documentation. I can connect you to the support team now, or send them your question and an answer by email — which do you prefer?"

The second one is longer, and it is the one that keeps the customer. It also does something the first does not: it tells the truth about the boundary of the system, which is the only thing that makes the bot's confident answers worth believing.

The Handoff Is the Real Fallback

A fallback message without a route to a human is a polite exit door with no handle.

The behavioural data here is unambiguous. Around 77% of consumers want a human after one or two "I'm not sure" responses, roughly two-thirds abandon the site entirely after a third failed attempt, and a majority say they would leave a brand outright if reaching a person were impossible. The window is two exchanges, not five.

Three things make a handoff work:

• The transcript travels. Nothing burns goodwill faster than being asked to explain the problem again to the person the bot just introduced you to.
• The wait is stated. "Someone will reply within two hours" is fine. Silence is not.
• Out-of-hours is handled honestly. Collect the question and an email, confirm it is logged, give a time. Do not simulate a transfer to an empty room.

Set the escalation triggers before launch, not after the first complaint. Account changes, refunds, cancellations, anything medical or legal, and any question that has already failed once — those go to a person by rule, not by the model's judgement. You can configure which categories always escalate in the agent settings.

Track the Fallback Rate, Then Ignore It for a Month

Fallback rate is conversations that hit a fallback divided by total conversations. Published benchmarks for 2026 put under 10% as strong and 10–15% as acceptable, with anything sustained above 15% signalling real coverage gaps. New bots routinely start at 30–40%.

That starting figure panics people, and it should not. A month-one fallback log is the most valuable document your support function will produce all year: it is every question your customers have, in their words, that your website does not answer, ranked by frequency. Most teams have never had that list.

The trap is optimising the number instead of the experience. A fallback rate of zero is not a well-trained bot; it is a bot that has stopped admitting when it is guessing. Watch these together:

Metric	What it tells you	Warning sign
Fallback rate	Coverage of your knowledge base	Falling while complaints rise
Escalation rate	How often humans are needed	Near zero — check the handoff works
Post-fallback abandonment	Whether your exit route works	Above 50%
Repeat fallback in one session	Whether you loop	Any at all, really

If fallback rate drops and CSAT drops with it, the bot has learned to bluff. That combination is worth more attention than either number alone. The ticket-deflection maths only works when the deflected tickets stay deflected.

When a Chatbot Is the Wrong Tool Entirely

Some situations should not have a fallback path because they should not reach the bot.

Anything with money or irreversibility attached. Cancellations, refunds, plan downgrades, address changes on a shipped order. A bot describing the policy is fine. A bot executing the action, or interpreting whether an exception applies, is a bad trade — the downside of a wrong call dwarfs the labour saved.

Regulated advice. Medical, legal, financial specifics. The bot can route to the right person and confirm hours. It should not reason about a case.

Distress. Bereavement, complaints about a serious failure, safety issues. Detect the sentiment and hand over immediately. The Air Canada case was a grieving customer talking to a machine about a bereavement fare, which is the sort of detail that turns an error into a story.

A business whose answers live in a database, not on a website. If most of your inbound is "where is my order" and you have no order-system integration, a content-trained bot will fall back on the majority of conversations and correctly so. Build the integration first, or accept that the bot handles the minority.

Every one of these is a case where the honest position — this needs a person — is also the commercially better one. Support automation earns trust by being narrow and reliable, not broad and occasionally wrong. That principle runs through everything we build at NoCubical.

Getting It Right Costs Almost Nothing

Fallback handling is configuration, not engineering. Write a message that states the limit and offers a person. Set the categories that always escalate. Turn on transcript-passing. Read the unanswered-question log weekly for the first month and write short answers for anything that appears twice — logging is on every plan, including the free tier, because a bot whose failures you cannot see is a bot you cannot improve.

An hour of this work, done before launch, is the difference between a bot that quietly closes its own knowledge gaps and one that invents a refund policy in front of a customer who will screenshot it.

Frequently Asked Questions