When a Bot Should Say “I Do Not Know”

A customer forwards you a screenshot. In it, your chatbot promises a delivery date your warehouse never agreed to, quotes a discount nobody approved, or explains a returns rule that exists nowhere in your policy. You dig through the knowledge base, the FAQ, the old PDFs. Nothing. The answer came from nowhere, and now you get to decide whether to honour it or tell the customer your own system misled them.

That moment is the whole argument of this article. An admitted gap costs you one follow-up message. A confident wrong answer costs a refund, an escalation, and a piece of trust you will not buy back cheaply. And the difference between the two is not model quality. It is fallback design: deciding in advance what your bot does when it has nothing solid to say.

A confident wrong answer costs more than an admitted gap

Wrong answers never stay where they happen. They generate a second ticket, and that ticket lands on a human agent whose first job is to contradict the company’s own bot. Nobody enjoys writing “I am sorry, our assistant was mistaken.” And customers rarely read it as an isolated glitch. They read it as a signal about how carefully the rest of your operation runs.

Some categories are expensive by nature. Delivery dates. Prices and discounts. Warranty terms, returns, anything tied to a specific account, anything with legal weight. In those areas an invented answer does not just mislead - it can create an expectation you are commercially or legally awkward to refuse. Everything else (opening hours, product descriptions, how a service works) carries far less downside if the bot gets it slightly imprecise.

Customers forgive a bot that says it does not handle something. They do not forgive being told the wrong thing in a confident tone. I have watched small teams lose whole afternoons to cleanup nobody budgeted for. Bigger operations feel it differently: the same wrong answer spreads across chat, voice and email for weeks before anyone connects the reports. Either way, the decision that matters gets made before launch, not mid-conversation. How much of this risk you carry at all depends on the architecture you started from, since rule based and AI bots fail in completely different ways.

Where your knowledge base ends is where the bot should stop

A bot grounded in your uploaded documents, guides and FAQs can only ever be as complete as those files. That is the honest constraint of knowledge base integration, and I would call it a feature rather than a flaw: a gap in the source should surface as a gap in the answer, not get papered over with plausible-sounding filler.

Before going live, write a no-go list - topics the bot must never attempt even if it appears to find something relevant. Then set scope and tone deliberately in the admin panel instead of leaving the assistant to treat every incoming question as its own business. Adjusting the bot scope in the configuration is a lot faster than fixing it later, one bad transcript at a time.

The blind spots repeat across companies. Outdated PDFs that still name last year’s shipping partner. Internal documents written for staff, full of shorthand a customer will misread. And policies that live only in the head of the person who has handled returns since the beginning and has never written any of it down.

Something to do this week: list your twenty most common question topics, mark which ones have a real source file behind them, and treat everything unmarked as refusal territory until someone writes the document.

How to word a refusal that does not annoy people

One sentence of limitation, one sentence of next step. That is the whole recipe. Long apologies read as evasion, and every extra clause makes the bot sound like it is stalling. Two sentences is enough to be clear and short enough to be believed.

Name the boundary concretely. “I do not have order-specific information” tells the customer something true about the system. “I cannot help with that” tells them nothing and lands like a brush-off. The concrete version also quietly teaches people what the bot is good for, which cuts down the next round of impossible questions.

Cut the phrases that irritate: repeated sorries, “as an AI language model”, manufactured empathy, and any hint that the customer phrased their question badly. Voice needs its own wording too. A voicebot reading out a URL or a fourteen-character reference code is a small disaster - push that detail to a channel where it can be read, and keep the spoken refusal conversational.

What the bot should do next

A refusal without a next step is a dead end, and a dead end feels worse to the customer than the wrong answer did in the moment. The fallback is only finished when the person knows where their answer is actually coming from.

A working fallback contains five things:

• The boundary, stated plainly - what the bot does not have, in words a customer understands.
• The original question, preserved - so nobody has to retype it for a human.
• A concrete next step - a person, a form, a page, a callback.
• A realistic time expectation - vague reassurance produces the follow-up ticket you were trying to avoid.
• A way to continue - the customer picks up where they left off instead of starting over.

Handoff to a human, ticket creation and routing rules are standard practice worth designing around your bot, whatever tooling you use for them. The part people underestimate is passing the call to a consultant without dropping the history, because a customer who has to explain everything twice has already stopped counting this as help. Pointing to the right page or document counts as a real answer too, and it beats any queue on speed. For a small team, one clear channel wins over clever routing every time. For a larger operation: decide which refusals go to which queue before volume decides for you.

Not every gap deserves the same answer

Most teams design two responses, answer or refuse, when there are three. The bot can answer fully, answer partially with the limit stated, or decline and route. That middle option is badly underused.

A partial answer gives the general policy and holds back the account-specific part, saying clearly which is which: “Returns are accepted within the standard window from delivery. Whether your particular order still qualifies is something I cannot check.” The customer walks away with useful knowledge and an accurate picture of what happens next.

Before refusing outright, let the bot ask one clarifying question. A big share of apparent knowledge gaps are just ambiguous questions, and one exchange sorts them out. What the bot must never do is fill a gap by inference. No guessed number, no estimated date, no plausible name. Missing data means no data in the reply, full stop.

Test the refusals before your customers do

Teams rehearse the happy path and ship the failure path untested. Flip that. Write a list of questions the bot should refuse and run them deliberately, the way you would test a checkout flow.

Make one pass adversarial. Ask for prices you do not publish. Ask about a competitor. Ask something political. Ask in the second language you support. Ask a question your FAQ answers only halfway, because that is exactly where confident nonsense shows up.

In the first weeks, read real transcripts by hand and mark every refusal as correct, unnecessary or missed. The missed ones are the interesting column. Feed them back into the knowledge base, because a genuine gap is a content task, not a bot task - the fix is almost always a new document, not a cleverer prompt.

Since registering gets you a first voicebot at no cost, this rehearsal is cheap: run the whole refusal list before a single customer sees it. On cadence, a small team can review weekly. A larger operation should hand the review to a named person, or it quietly stops happening by month two.

The bot that admits limits is the one people keep using

The trade is straightforward. A narrow set of reliable answers beats a wide set of uncertain ones, every time, in every channel. Coverage looks better in a demo. Reliability is what survives contact with real customers.

Fallback design is a business decision about what you are willing to promise, wearing the costume of a technical setting. Treat it as the former and the configuration choices get obvious fast.

Then watch the metric that actually matters, which is not resolution rate. Customers come back to a bot that has never lied to them, even when it keeps sending them somewhere else. If you are putting the rest of the failure path in order, the other support automation guides cover the pieces that sit around it.