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 the not-knowing moment matters 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.
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.
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.
What good fallback actually contains
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 is configured to say it is not sure rather than guess, and human handoff is available on every plan, so the route exists whether or not someone is watching the inbox right now.
Why 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.
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.
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.
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.
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.
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?
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.