Short answer: A well-built AI chat widget should say it is not sure, avoid guessing, and offer a route to a person — capturing enough detail that the handoff is useful. A badly built one invents a plausible answer, which is worse than saying nothing because the customer acts on it. What happens at the edge of knowledge is the single clearest signal of whether a chatbot was designed by someone who cared.
Why does the not-knowing moment matter most?
Any widget can answer "what are your opening hours." The difference between tools shows up on the question your website never addressed.
Two things are at stake. Trust, which survives an honest "I do not know" and does not survive a confident wrong answer. And the lead, because a question the widget cannot answer is often a question from someone close to buying — the specific, awkward, high-intent question is exactly the one your marketing pages never anticipated.
Think about who asks the hard question. Not the browser skimming your homepage. It is the person who has read three pages, decided you might be right, and now has one obstacle left. Do you take my insurance. Can you do it before Friday. Is this covered if the part fails. That obstacle is the last thing between them and booking.
Handled well, not knowing becomes a conversion event. Handled badly, it is a lost customer plus a bad answer in writing.
The three ways it goes wrong
Fabrication. The model produces something plausible and unsupported. This is the expensive failure, and grounding answers in your own content is the defence. There is a fuller diagnosis in why chatbots give wrong answers.
Dead-ending. "I do not have information about that." Full stop. Honest, and useless. The visitor has been told no and given nowhere to go, so they leave.
Loop-and-deflect. The widget restates its capabilities, offers a menu, and asks the visitor to rephrase. Repeatedly. This is the classic rule-based failure mode and it reads as evasion even when it is not.
There is a fourth, quieter failure: the confident half-answer. The widget answers the easy part of a two-part question and silently ignores the hard part. The visitor reads it as a full answer, acts on it, and discovers the gap later, usually at the worst moment.
What does good fallback actually contain?
Four elements, in order.
An honest signal. Brief and unhedged. "I am not sure about that" is better than a paragraph explaining the limits of the system.
A partial answer where one exists. Most unanswerable questions are partly answerable. If someone asks about pricing for an unusual configuration, saying what standard pricing looks like and flagging that theirs needs a quote is far more useful than a flat decline.
A concrete next step. Not "please contact us" — an actual route. Leave a message for the team, request a callback, book a slot.
Capture. If the visitor takes the route, collect what makes the follow-up good: the question in their words, their contact detail, any context already given. Nobody should have to repeat themselves to the human.
Clerkzo's guardrails prefer an honest "I'm not certain" over an invented answer, and human handoff is included on every plan, so the route to a person exists whether or not someone is watching the inbox right now. (The glossary's fallback response entry has the compact definition; this post is about designing that moment well.)
What do the four failures sound like side by side?
One question, a dental practice, five replies. The question: "Do you do sedation for nervous patients, and is it covered by my insurance?"
Fabrication. "Yes, we offer full sedation and most major insurers cover it." Nothing on the site said either thing. The patient books, arrives, and finds out neither is true.
Dead end. "I do not have information about that." Correct and worthless. They close the tab.
Loop and deflect. "I can help with appointments, opening hours and treatments. Could you rephrase your question?" They rephrase. It says the same thing.
Confident half-answer. "Yes, we treat nervous patients." True, and it quietly ignored both sedation and insurance, which were the actual question.
Good fallback. "We do treat nervous patients and offer options for anxiety, though I am not certain which sedation methods are available or how your specific policy would cover it. Those depend on the dentist and your insurer. Would you like me to pass this to the practice so they can confirm both before you book?"
Then, if yes: "Of course. What is your name, the best number to reach you, and which insurer you are with?"
The fifth reply concedes the limit, keeps the honest part of the answer, offers a real route, and ends with a lead that arrives already containing the question, the insurer and a number. Reception can answer it in one call instead of three.
Why do grounded systems fail more gracefully?
A widget answering from passages retrieved out of your own content has a built-in signal for not knowing: retrieval came back with nothing relevant. That is a concrete, checkable condition, not a vibe.
Systems answering from a model's general memory have no such signal. The model does not experience the absence of knowledge — it produces the most plausible continuation, and plausible is exactly what a fabricated answer looks like. This is the practical argument for retrieval-augmented generation beyond accuracy: it makes uncertainty detectable.
The practical consequence for you is that scope is a safety feature, not a limitation. A widget confined to your own pages, kept on topic by guardrails, has a much smaller surface on which to be wrong.
Not knowing is your content backlog
Every unanswered question is a research finding. Your customers are telling you, unprompted, what your business has failed to explain.
Read the conversations that ended in a decline or a handoff. Group them. Anything appearing more than twice is worth a permanent fix, and there are two ways to make one. Write the answer into a page, which helps your human readers too. Or use the corrections loop — flag the weak answer, type what it should have said, and that becomes an authoritative override for similar questions.
The two fixes are not interchangeable, and choosing between them takes about five seconds once you know the rule. If the answer belongs in public, because customers are searching for it and it would help anyone reading your site, write the page. If it is a phrasing problem, an edge case, or something you would rather not publish, correct it. And if it is genuinely internal, upload it as a file instead.
You can also add material that was never meant to be public. Knowledge file uploads take ten file types at up to ten megabytes each, so an internal policy document can close a gap without you publishing it. This backlog is what chatbot training looks like in practice: not tuning a model, but answering the questions your customers keep asking.
Doing this once a month is enough. Twenty minutes of transcript reading, three corrections, one new page. That cadence compounds faster than any amount of configuration.
What should never be answered?
Some questions should be declined even when the widget could produce an answer.
Anything requiring professional judgement — medical, legal, financial specifics. Anything about an individual customer's account or order that the widget cannot verify. Anything committing you to a price, a date or a term that a human has not approved. Anything a visitor is clearly fishing for through manipulation.
For these, declining is correct behaviour, not a limitation. Configure them as deliberate boundaries with a warm handoff attached, so the visitor is redirected rather than refused.
The distinction worth holding onto: a refusal says no and stops. A boundary says this needs a person, and moves. Same restriction, opposite outcome.
How do you test your own edge?
You cannot evaluate fallback behaviour by asking easy questions. Write down ten questions your website genuinely does not answer — the pricing exception, the unusual request, the thing customers ask that you have never published — and run them through the playground that mirrors the live widget.
If ten feels like a lot, borrow them. Your five most recent phone enquiries, two questions from your reviews, and three from the last email thread that started with "quick question" will do.
Judge three things. Did it avoid inventing? Did it offer a real next step? Would you be happy for a prospect to read that exchange?
Then run the same ten again after you have made your corrections, and check that the fixes held without breaking anything that already worked. That second pass takes five minutes and catches the case where a correction was written too broadly and now fires on questions it should not.
If the answer to all three is yes, your widget handles the hardest part of its job well. If you are still evaluating tools, this is the test that separates them — more than any feature list. Our guide to choosing an AI receptionist covers what else to look at.
Frequently asked questions
Is it bad if my chatbot says it does not know?
No. It is the correct behaviour when your content does not support an answer. What matters is that it also offers a route to a person.
How do I stop it guessing?
Ground answers in retrieved passages from your own content, scope it to your business, and configure explicit uncertainty behaviour instead of leaving the model to fill gaps.
Should every unanswered question trigger a handoff?
Offer the option every time. Whether the visitor takes it is up to them, but a decline without a route is a dead end.
How do I find out what it could not answer?
Read saved conversations and sort by thumbs-down ratings and handoff events. Repeated gaps are your content to-do list.
How often should it be saying it does not know?
Occasionally is healthy, constantly is a content problem. If a large share of conversations end in a decline, the fix is on your website, not in the widget settings.
Does a handoff need someone sitting there?
No. A handoff is a flagged conversation with the visitor's details attached, delivered by email, webhook or Telegram. Someone reads it when they next look. What matters to the visitor is that the route existed and somebody will call.
Will admitting uncertainty make my business look bad?
The opposite, in most transcripts you will read. "I am not certain, let me get someone to confirm" reads as careful. A confident wrong answer reads as careless the moment the customer discovers it, and by then it is in writing.