A customer asks where an order is. The agent cannot find the order, replies with “I didn’t understand,” and waits. The customer tries again. The same message appears. Chatbot fallback messages are the responses shown when an agent cannot complete a request. One generic fallback is a support failure. The next action has to match the reason the agent stopped.
Google’s fallback guidance recommends combining automation with live support for requests outside the automated flow. That is the right starting point. Treat a fallback as an operating signal, not a piece of copy to write once and forget.
Start with the failure, not the wording
Classify the failure before you write the response. Four causes cover most fallback conversations:
| Failure mode | What happened | The next action |
|---|---|---|
| Misunderstood input | The agent could not map the wording to a supported request | Ask for one retry with concrete examples |
| Out-of-scope request | The request is outside the agent’s supported topics or permissions | Show the supported path or offer human help |
| Ambiguous request | The agent needs one missing detail to answer safely | Ask one narrow question |
| System failure | The agent could not complete an action or retrieve a result | Explain the failure and provide recovery or human help |
Give each label a place in your conversation logs. A single fallback-rate number hides the difference between a customer using unfamiliar wording and an API failing during an order lookup. Those need different fixes.
Your team should be able to filter logs by misunderstood, out_of_scope, ambiguous, and system_failure. The labels do not need to appear in the customer-facing message. They need to make review possible later.
The chatbot fallback decision tree
Use this sequence for every failed turn:
- Identify the failure. Decide whether the request was misunderstood, out of scope, ambiguous, or blocked by a system failure.
- Send the matching message. State what happened in plain language.
- Take the next action. Offer a retry, topic path, clarifying question, recovery path, or human handoff.
- Record the result. Mark whether the customer recovered, tried again, reached a person, or left.
Misunderstood input
The agent does not know what the customer means. Say that directly, then give one or two ways to try again.
I couldn’t match that request to a support topic. You can ask “Where is my order?” or “How do I change my shipping address?”
Retry once. If the second attempt fails, stop repeating the same prompt. Offer human help or a visible topic path. Repeated misunderstanding is evidence that the agent needs better training content, new wording, or an exact Q&A pair.
Out-of-scope request
The customer’s request may be clear, but the agent cannot handle it. Tell the customer what the agent can cover and give them a relevant route.
I can help with orders, returns, and account access. I can’t review employment applications here. If you need help with an existing order, choose Orders below or ask for a support specialist.
Use human handoff when the request needs judgment, a person has to access a protected record, or the customer is already frustrated. AssistLoop human handoff gives the team the full thread and its history in the shared inbox, so the customer does not have to start over.
Ambiguous request
Do not send “How can I help?” again. Ask for the one detail that separates the possible answers.
Do you want to change the delivery address for an order that has already shipped, or for a new order?
The question should narrow the path. Asking for several details at once adds work before the customer knows why the details matter. After the answer, continue the original task or hand the conversation to a person if the case needs one.
System failure
A system failure is different from a knowledge gap. The agent may understand the request but fail to retrieve data or complete an operation. Never imply that the action worked.
I couldn’t confirm your order status right now. No changes were made to your order. You can try again, or ask for a support specialist and we’ll review it with you.
The recovery path depends on the action. For a booking, show another way to contact the team. For an account change, confirm that no change was made. For an order lookup, offer human help with the conversation history attached. Record the error and the point at which handoff should have happened.
What to do instead
Each fallback gets one job:
- Misunderstood input: recover the conversation with a concrete retry.
- Out-of-scope request: set scope and point to a supported topic or person.
- Ambiguous request: collect the missing context.
- System failure: protect the customer from believing a failed action succeeded.
Every message needs a specific next step. The customer should know whether to rephrase the question, choose a topic, answer a clarifying prompt, or request human help.
Keep the agent’s scope visible without blaming the customer. “I couldn’t match that request” reports the agent’s state. “You asked that incorrectly” places the fault on the person using the support channel. The first wording gives you room to improve the system.
Human handoff belongs in more than one branch. Offer it after repeated misunderstanding, during emotionally charged billing or account conversations, for complex requests, and after a failed action that could affect a customer record. A correct sentence from an agent is not enough when the customer needs a decision, a private lookup, or confidence that a change was made.
The Google fallback guidance also supports moving complex or out-of-scope issues to live support. The handoff should be an action in the flow, not a dead-end sentence that tells the customer to find another channel.
Start the weekly review with the highest-volume failure mode in the conversation logs. Read a sample of failed conversations before changing the copy. Classify the cause first. Otherwise, you risk polishing a message for a problem that needs new training content or a working API.
Make one change at a time. Choose the change that matches the cause:
- Add training content when the answer is missing.
- Add an exact Q&A pair when wording must stay precise.
- Add a clarifying question when one detail is missing.
- Change a handoff rule when a person should receive the conversation sooner.
- Fix the action error path when the connected system does not confirm the result.
At the next review, check recovery rate, repeat fallbacks, handoff quality, and unresolved system failures. Read the conversations behind the numbers. A lower fallback rate is not automatically better if the agent is answering uncertain questions instead of handing them to a person.
What to review in conversation logs
Track fallback rate by failure mode. A site-wide number is too blunt to guide a fix. Review these signals instead:
Misunderstood inputs. Look for missing knowledge-base content, unfamiliar customer wording, and questions that need exact Q&A pairs. If customers ask the same thing in three different ways, add the terms they use and test each version.
Out-of-scope requests. Some requests genuinely do not belong in the agent. Others reveal a support topic that should be added. If customers repeatedly ask about a supported part of the business, the fallback is a coverage problem, not a copy problem.
Ambiguous requests. Check whether one missing detail would have resolved the question. If so, write a narrow clarifying prompt. For example, “Which product are you asking about?” is useful when the answer changes by product. “Can you provide more information?” is not.
System failures. Review API errors, incomplete action results, and cases where a person should have received the full thread sooner. A system-failure fallback should make the result clear: completed, not completed, or unknown and awaiting review.
Use the logs to choose one training change, question, handoff rule, or action error path. Then check whether the same failure returns. AssistLoop’s features include conversation review and the agent capabilities needed to improve the next version of the flow.
How to put the playbook into AssistLoop
Start with the content the agent is meant to answer. AssistLoop can train on uploaded files, a website crawl, pasted text, and exact Q&A pairs. Use exact Q&A pairs where a paraphrased answer creates risk, such as refund wording, account rules, or a policy with specific conditions. Training the agent on your data gives the agent a defined source for supported answers.
Turn on human handoff for conversations that need a person. The team receives the full thread and its history in the shared inbox. This matters after a fallback because the customer’s earlier messages explain what the agent understood, what it missed, and what has already been tried.
Use Agent Actions when the request requires a real operation. That can mean booking a meeting, capturing a lead, or checking order status through an API. An action should report success only after the connected system confirms it. If the result is missing, delayed, or returns an error, use the system-failure path and offer recovery.
AssistLoop supports Agent Actions for REST endpoints, including GET, POST, PUT, PATCH, and DELETE requests. The right setup depends on the connected system’s response. The fallback message must describe what the customer can safely assume about the result.
Test one example from each failure mode before publishing the widget:
- Ask a supported question with wording the agent may not recognize.
- Ask for something outside the agent’s scope.
- Leave out the detail needed to choose between two answers.
- Trigger an action with a failed or incomplete result in the test environment.
Check the customer-facing message, the next action, the log label, and the handoff thread for each test. The AssistLoop feature set gives you the broader view of the agent, widget, actions, and conversation tools in one place.
You can create an AI agent and test this playbook on AssistLoop’s Free plan before choosing a paid plan. Free includes 150 message credits and does not include human handoff, so it works for testing the agent’s responses, not for a production handoff workflow.
AssistLoop pricing shows the current message-credit details. Credits count each user message and AI response, and they do not roll over. Create your AI agent to test the four failure paths with your own support content.
Last verified: August 2026.
FAQ
What is a chatbot fallback message?
A chatbot fallback message is the response shown when an agent cannot complete a customer’s request. The right message depends on whether the input was misunderstood, out of scope, ambiguous, or blocked by a system failure.
What should a chatbot say when it cannot answer?
Do not use one generic message for every failure. Ask for a concrete retry when the input was misunderstood, ask one narrow question when it is ambiguous, set scope for out-of-scope requests, and explain the recovery path after a system failure.
When should a chatbot fallback offer human handoff?
Offer human handoff after repeated misunderstanding, for complex requests, during emotionally charged billing or account conversations, and when a failed action could affect a customer record. The person should receive the conversation history so the customer does not need to repeat the issue.
How do you measure chatbot fallback performance?
Review fallback rate by failure mode instead of using one site-wide number. Then inspect repeat misunderstandings, missing context, out-of-scope topics, API errors, incomplete action results, recovery rate, and handoff quality.
Written by