What a fallback message actually is
A chatbot fallback message is the bot's response when it cannot satisfy a request. It fires in three situations: retrieval finds no chunks above the confidence threshold, the question is outside the bot's declared scope (someone asks your support bot for stock-picking advice), or a safety rule trips (the visitor asks the bot to do something it has been instructed not to do). All three look the same to the visitor: the bot did not answer the question.
The naming is slightly misleading. "Fallback" sounds like a special error state, but in a content-grounded chatbot it is just another reply, generated by the same pipeline as every other reply. The difference is that the system prompt or the retrieval scorer tells the model "you do not have the information to answer this; respond with the configured fallback pattern instead of guessing." The model then writes a reply that follows that pattern.
That distinction matters because it tells you where the fallback lives in your stack. It is not a separate code path that fires on exception. It is a configurable instruction inside the same prompt that produces every reply. Which means you can change it, you can A/B test it, you can localize it, and you can make it as much a part of your brand voice as your homepage copy.
The category got here in three stages. Rule-based bots had a literal fallback intent ("default" or "noMatch") that fired when the input did not match any defined intent. Intent-classification bots (Dialogflow, Rasa, classic Watson) added a confidence-threshold fallback: if the top intent scored below a cutoff, return the fallback response. Retrieval-augmented LLM bots (the current generation) have a softer version of the same: if the retrieved chunks are weak or absent, the system prompt steers the model toward a refusal pattern. The user-visible artifact is the same in all three eras. Only the trigger has gotten more nuanced.
Why fallback messages matter more than people think
Operators tend to treat the fallback as a one-time configuration step. They write something polite, paste it in, and never look at it again. That is a mistake for three reasons.
First, visitors see the fallback far more often than operators realize. On a fresh deployment, before content gaps are filled, ten to thirty percent of conversations hit a fallback at some point. Even a mature bot on a well-documented site sees five to ten percent of sessions trigger at least one fallback. If the fallback feels like a wall, that is the experience a meaningful slice of your visitors take away from your site.
Second, the fallback is doing search engine optimization for your support funnel whether you intended that or not. A visitor who gets a useful redirect ("I do not have that, but our pricing page covers exactly this question") learns where to look next. A visitor who gets a dead end leaves and probably does not come back.
Third, the fallback is where a chatbot earns trust or burns it. The bot that confidently makes up an answer fails by hallucination. The bot that admits the gap and hands the visitor something useful fails gracefully, which is barely failing at all. Anthropic's own anti-hallucination guidance is explicit on this: explicitly tell the model it is allowed to say "I do not know," and you cut the hallucination rate dramatically. The fallback message is the user-facing surface of that instruction.
Put those three together and the fallback is not a corner case. It is one of the highest-frequency, highest-stakes copy decisions you will make in the whole product. Worth more than fifteen minutes of attention.
The 4 fallback patterns
Across thousands of chatbot deployments, the patterns operators actually pick from collapse to four. Ranked by visitor experience, worst to best for a typical FAQ-style support bot.
- Pure refusal: the bot says it does not know and stops.
- Refusal plus redirect: the bot says it does not know and points at nearby topics it can answer.
- Refusal plus lead capture: the bot says it does not know and asks for contact details so a human can follow up.
- Refusal plus human handoff: the bot says it does not know and offers an immediate live-chat handover.
There is no single best pattern. The right choice depends on whether your site is support-led (use pattern 4 for high-stakes queries), sales-led (pattern 3 captures the lead before the visitor leaves), or content-led (pattern 2 keeps them browsing). Most mature deployments use pattern 2 as the default and escalate to pattern 3 or 4 when the visitor's intent signals commercial or urgent.
Pattern 1: pure refusal ("I don't know") and why it loses
The simplest fallback is the bare "I do not know" reply. Examples in the wild:
"Sorry, I cannot answer that."
"I do not have information about that."
"I am not sure."
Operators reach for this pattern because it feels safe. It does not promise anything, it does not hallucinate, and it does not commit the operator to a follow-up. From a defensive standpoint, it looks fine.
From the visitor's standpoint, it is a wall. They asked a question, they got a non-answer, and the conversation has nowhere to go. The "loop of doom" pattern (the visitor rephrases, gets the same fallback, rephrases again, gets the same fallback again, leaves) starts here.
The deeper problem is what pure refusal signals about the operator. It says: the operator built this bot, knew the bot would fail sometimes, and did nothing to plan for those failures. That reads as carelessness even if it is not. The cost of upgrading from pure refusal to refusal plus redirect is one extra clause of copy. There is no reason to ship pure refusal except as a temporary placeholder.
The one place pure refusal is defensible: hard safety refusals where any redirect would muddy the message. "I cannot help with that request" is the right reply when someone tries to coax the bot into something it should not do. The signal needs to be unambiguous. But for the everyday "I do not have that information," pure refusal underperforms every other pattern.
Pattern 2: refusal plus redirect (the recommended pattern)
The refusal plus redirect pattern admits the gap in a short sentence, then points the visitor at the next useful thing. The "next useful thing" is typically two or three related topics the bot can answer, drawn from the same content area as the original question.
Template:
"I do not have information about that based on my training. Try asking about [topic A], [topic B], or [topic C] instead."
The strength of this pattern is that it converts a dead end into a hub. The visitor who asked the wrong question now sees three adjacent right questions they can ask. Even if none of the three matches their original need exactly, the visitor learns the shape of what this bot does cover, which calibrates their expectations for the rest of the session.
A subtle but important detail: the three topics should be drawn from your indexed content, not from your imagination. The pattern only works if the bot can actually answer the suggestions when the visitor clicks them. Some products surface the suggested topics as buttons that pre-fill the input. Others let the model freeform write the suggestions based on the categories present in the bot's training data. Both work. What does not work is suggesting topics the bot cannot answer, which puts the visitor right back in the loop of doom.
The refusal plus redirect pattern is the recommended default for most operators because it has the best visitor experience across the widest range of intents. It works for support, for sales, for documentation. It is the pattern ChatRaj ships by default.
Pattern 3: refusal plus lead capture (gates contact info before redirect)
For sites where the primary funnel goal is to capture leads, the refusal plus lead capture pattern trades visitor convenience for operator follow-up. Instead of pointing the visitor at nearby topics, the bot asks for contact details so a human can answer the question directly.
Template:
"I do not have a confident answer to that question. If you leave your email, our team can follow up within one business day with a real answer."
The strength of this pattern is that every fallback becomes a captured lead instead of an abandoned session. For a B2B site where the typical deal size justifies a human reply, this is the right trade. The weakness is that visitors who just wanted a quick answer feel pressured into giving up their email, and some of them will simply leave.
The smart variant runs both patterns in sequence. First, the bot tries the redirect ("Try asking about pricing, features, or integrations"). If the visitor rejects the redirect or asks a second out-of-scope question, the bot escalates to lead capture. This mirrors how a good human salesperson behaves: try to answer first, ask for the contact only when the question genuinely requires a human.
Lead capture fallbacks should never ask for more than name and email at the fallback moment. Phone, company, role, job title: all of those can come later, in the follow-up email or call. Asking for them at the fallback is friction at the worst possible moment.
Pattern 4: handoff to human (live-chat handover)
For sites where the primary goal is to resolve the visitor's problem fast (most paid customer support contexts), the refusal plus human handoff pattern offers an immediate live-chat handover. The bot tells the visitor it cannot help, and offers to connect them to a person.
Template:
"I do not have a confident answer to that. Would you like me to connect you to a person? Our team is online now."
The strength of this pattern is the resolution rate. Visitors who reach the fallback get a real answer from a real human within minutes. For high-stakes queries (a paying customer with a billing problem, an enterprise prospect with a security question), this is the right pattern. The visitor's last memory of the experience is "I got my problem solved," not "the bot did not help."
The weakness is cost. Human handoff is expensive (a human agent's time runs roughly fifty to two hundred dollars per hour fully loaded), and the bot will route some questions to humans that the bot could have answered if the retrieval had been tuned better. A high handoff rate is usually a signal to invest in better content indexing rather than a sign of healthy fallback behavior.
Human handoff also has a coverage problem: the human is only available during business hours. Outside of those hours, the fallback should degrade gracefully ("Our team is not online right now, but we will reply by 9am tomorrow if you leave your question and email"). The worst variant of this pattern offers a handoff that goes nowhere because the human queue is empty, which combines the slowness of waiting with the disappointment of no answer.
8 fallback templates worth using (with copy)
Copy you can steal and adapt. The bracketed parts are placeholders for your topics, contact channel, or brand voice.
-
Refusal plus redirect (general). "I do not have information about that based on my training. Try asking about [topic A], [topic B], or [topic C] instead."
-
Refusal plus contact link (low-friction). "I cannot answer that confidently. You can email us at [team@yourdomain.com] and we will follow up directly."
-
Refusal plus suggested rephrase. "I did not find a confident match for that question. Try rephrasing it, or ask about [topic A] or [topic B]."
-
Refusal plus lead capture (B2B). "Good question, but it is outside what I can answer with confidence. If you leave your email, our team will follow up within one business day."
-
Refusal plus live-chat handoff (support-led). "I do not have a confident answer to that. Want me to connect you to a person? Our team is online now."
-
Out-of-hours handoff fallback. "I cannot answer that, and our team is not online right now. Leave your question and email and we will reply by 9am tomorrow."
-
Out-of-scope refusal (hard topic boundary). "That is outside what this assistant covers. I focus on questions about [product or domain]. Try asking about [topic A] or [topic B]."
-
Hallucination-prevention refusal (low-confidence retrieval). "I do not see a confident answer in our documentation. Rather than guess, I would point you at [help center URL] or connect you to our team."
The pattern across all eight: short opening sentence that admits the gap, followed by exactly one next step. Two opening sentences is too long. Three next steps is too many.
Common failures (apology fatigue, infinite loop, generic-sounding)
The three failure modes operators fall into.
Apology fatigue. Excessive apologizing reads as performative and amateur. "I am so sorry, I really wish I could help with that, unfortunately I do not have that information, my apologies for the inconvenience" buries the actual useful content under three layers of theatrics. One short "I do not have that" is enough. Save the apology for moments when the bot actually broke something.
The infinite loop. The bot returns the same fallback message every time the conversation hits an unanswered question. The visitor rephrases, gets the same canned reply, rephrases again, gets the same canned reply, leaves. Better implementations vary the fallback on repeat (first time: redirect; second time: lead capture or handoff). At minimum, after the second consecutive fallback in a session, the bot should change behavior, not repeat itself.
Generic phrasing. "I could not find that" sounds like every other chatbot in the category. Generic copy is forgettable copy. The fix is to write the fallback in the same voice as the rest of your site. If your homepage says "Get started in 30 seconds," your fallback should sound like the same person wrote it, not like it was lifted from a Microsoft Bot Framework tutorial. Voice consistency across regular replies and fallback replies is one of the cheapest wins available to operators who care.
A fourth, less common failure: hallucinating in the fallback itself. Some bots, when the system prompt is weak, write fallback messages that promise things that are not true ("I will create a ticket and have someone follow up" when there is no ticket integration). The fallback should only promise what the operator has actually wired up.
Where ChatRaj fits
ChatRaj's default fallback uses pattern 2 (refusal plus redirect): the bot admits when retrieval did not find a confident match, then suggests two or three related topics drawn from the bot's indexed content. Operators can customize the exact phrasing on the Customize page, including switching to lead-capture or human-handoff patterns for sites where those fit better. The fallback message is treated as first-class brand copy in the dashboard, not buried under a developer settings menu, because the assumption is that operators will iterate on it after they see how visitors react.