What Should an AI Chatbot Do When It Does Not Know the Answer?
Direct answer: It should not guess. A well-designed chatbot should acknowledge the limit, ask one focused clarifying question when that could resolve the uncertainty, offer a bounded answer only when its source supports it, and route the conversation to an appropriate human or service process when the issue is high-risk, unresolved, or outside scope.
“I don’t know” is not a failed conversation. It is a control point. The goal of an unknown-answer fallback is to keep the user moving without creating a confident-sounding fiction. This guide presents a practical decision process for customer-service teams, solo operators, and no-code builders evaluating an AI chatbot.
Why uncertainty needs an explicit workflow
Generative chatbots produce language, not certainty. They can combine a relevant source with an unsupported inference, misunderstand a short question, or answer outside the business’s approved knowledge. Treating every prompt as a request for a complete answer makes the system’s most important decision invisible: whether it has enough evidence to respond.
A useful design separates answering from routing. Answering means giving a response grounded in approved content. Routing means deciding whether to clarify, decline, create a ticket, transfer to a person, or direct the user to a safer channel. NIST describes its AI Risk Management Framework as voluntary guidance for incorporating trustworthiness into the design, development, use, and evaluation of AI systems, and its generative-AI profile identifies actions for managing risks specific to generative systems.[1] You can apply that mindset even to a small chatbot: define the boundaries before you optimize the wording.
A simple unknown-answer decision tree
Use the following sequence for each uncertain question. The labels are an original operating tool, not a certification or a guarantee.
- Can the bot cite an approved answer? If yes, answer briefly and identify the relevant help article, policy page, or account workflow. If no, continue.
- Could one clarification materially change the answer? Ask one specific question, such as the product version, order status, or general issue type. Do not interrogate the user with a long form.
- Is the request sensitive or consequential? For billing disputes, account security, safety concerns, accessibility barriers, complaints, or questions that call for legal, tax, medical, employment, or other regulated judgment, use the designated human process rather than improvising.
- Can the system create a useful handoff? With the user’s permission and according to the organization’s current data-handling rules, capture the minimum context needed for a person to continue. Otherwise, provide a safe contact route without asking for unnecessary details.
- Can the user make progress without a bespoke answer? Offer a general, clearly bounded next step, such as a troubleshooting checklist or a link to the official status page. If not, say that a person needs to review it.
This tree favors reversible actions. A clarifying question can be corrected. A ticket can be reviewed. An invented answer may send someone down the wrong path and be difficult to notice later.
Four fallback patterns that work together
1. Transparent limitation
State the boundary plainly: “I can help with product setup and the published support articles, but I cannot verify that account-specific detail here.” Avoid vague statements that sound like a temporary outage if the real issue is scope. The OECD AI Principles call for transparency about when people are interacting with AI and for understandable information about capabilities and limitations.[2]
2. Focused clarification
Ask a question that has a purpose. “Is the error appearing during sign-in or after payment?” is better than “Can you provide more information?” If the answer would not change the route, skip the question and hand off. Also give the user an easy way to correct the bot’s assumption.
3. Bounded alternative
Offer only what the approved material supports. A bounded alternative might be a link to a setup guide, a list of ordinary diagnostic steps, or an explanation of what information a support specialist will need. Do not fill a gap with a plausible policy, deadline, price, eligibility rule, or account status.
4. Human handoff or ticket creation
Handoff should be a real operational path, not a decorative sentence. Tell the user what happens next, what channel to use, and whether they should expect to repeat the issue. If the system can open a ticket, include a concise summary, the relevant conversation context, a timestamp, and a confidence or reason code for internal review. Give the user a reference number only if the system actually created one.
When the bot should stop trying
Set hard stops for situations where a mistaken answer could cause disproportionate harm or where the user needs authority the bot does not have. Examples include suspected account takeover, requests to change ownership or payment details, threats to safety, urgent accessibility problems, formal complaints, and disputes requiring a review of records. A bot may explain the available process, but it should not pretend to be the decision-maker.
Children and other vulnerable users deserve additional care. In September 2025, the U.S. Federal Trade Commission said it was seeking information from major chatbot companies about how they measure, test, monitor, and mitigate potential negative impacts on children and teens, including disclosures about capabilities, intended audience, risks, and data practices.[3] That announcement is not a universal implementation checklist, but it is a useful reminder to test the experience for users who may over-trust a conversational system.
For a safety-related message, use a predefined escalation script and the organization’s current emergency or safeguarding process. Do not ask the chatbot to diagnose the situation or promise that a human is monitoring every message. If a topic touches a legal, tax, medical, employment, privacy, or consumer-protection decision, keep the article and the bot’s response general and refer the person to a qualified professional or the current primary rule.
How to write the fallback response
A dependable fallback usually has five parts: recognition, limitation, next action, handoff option, and correction path. For example:
“I’m not able to verify that account-specific answer from the information available to me. If you tell me whether this is about sign-in, billing, or delivery, I can point you to the right general guide. For a record-specific review, please use the support form and include the order or ticket reference—do not send passwords or full payment details. You can also ask for a support specialist.”
The exact wording should match the actual capabilities. Remove the ticket reference instruction if no ticketing system exists. Remove any response-time statement unless the organization actively measures and maintains it. Never describe the bot as “always available,” “fully accurate,” or able to resolve every issue.
Implementation checklist for a small team
Start with a written scope list. Name the sources the bot may use, the actions it may take, the questions it must refuse or route, and the human queue for each escalation class. Keep the scope versioned so that a support lead can see what changed.
Next, create a test set from real-looking categories rather than only polished examples. Include misspellings, missing context, contradictory details, unsupported products, angry complaints, repeated questions, prompt-injection attempts, and requests for another person’s information. Record whether the bot answered, clarified, refused, or handed off, and whether that route was appropriate. NIST’s framework emphasizes managing risks across the AI system lifecycle, so review the fallback after changes to prompts, retrieval sources, integrations, or escalation staffing.[1]
Finally, inspect the handoff transcript. A good handoff preserves the user’s question without copying irrelevant or sensitive material. It should make uncertainty visible to the reviewer, not hide it behind a polished summary. Access controls, retention, and data-sharing choices depend on the tools and jurisdiction involved; check the current primary rules and obtain qualified advice where those choices are consequential.
Original decision tool: the FOCUS check
Before allowing an uncertain response to proceed, score the situation with FOCUS:
- F — Facts: Is there an approved source that directly supports the answer?
- O — Outcome impact: Would a wrong answer affect safety, access, money, records, rights, or a formal complaint?
- C — Clarification: Would one answerable question reduce the uncertainty?
- U — User control: Can the person correct the bot, choose a human route, and avoid sharing unnecessary sensitive details?
- S — Signal: Will the system record why it answered, clarified, refused, or escalated?
If Facts is no and Outcome impact is high, route to a human process. If impact is ordinary and Clarification is yes, ask one focused question. If the facts are supported but the user may misunderstand the limits, answer with a short source-based explanation and a correction path. Any failed User control or Signal check is a reason to pause the automation and fix the workflow.
What to monitor after launch
Review a sample of fallback conversations on a regular schedule. Look for unsupported answers, repeated clarification loops, handoffs that lose context, users who cannot find a human route, and sensitive details unnecessarily copied into tickets. Track categories and examples rather than treating a single aggregate score as proof of quality. When a failure appears, update the source, scope rule, test case, or routing process—not just the sentence that the bot says.
The best unknown-answer experience is deliberately modest. It gives the user a truthful boundary, a practical next step, and a reliable path to review. That combination is more useful than a fluent answer whose evidence and authority are unclear.
