Chatbot: what it must refuse to answer

Every page selling a conversational assistant describes what it can answer. That is the easy part, and it is also the part that decides nothing: a recent model answers almost anything, confidently, including when it is wrong.

What decides whether the project survives is the opposite: the list of what the assistant is not allowed to handle alone. That list is short, it can be written in one meeting, and writing it is the only part of the work that genuinely commits anybody.

This article describes what it has to contain, what happens when it does not exist, and the three or four checks you can run yourself before speaking to any supplier — us included.

A general-purpose model asked for your returns policy will produce one. It will be phrased exactly like a real returns policy, with a plausible window and a professional tone, and it will be wrong. That is normal behaviour for these systems: they are built to produce the most likely continuation, not to check that it exists.

The damage is not the error, it is the credibility. A customer whose message your contact page never answers knows they have no answer. A customer told by your assistant that they have fourteen days to change their mind believes they have fourteen, acts accordingly, and discovers otherwise at the moment it costs you most.

The defence is structural, not rhetorical. You do not obtain caution by asking the model to be cautious: you obtain it by grounding it in a closed corpus — your pages, your catalogue, your procedures — and making it return the source of every answer. An answer without a source does not ship.

One point suppliers happily skirt is worth insisting on: you do not get this behaviour by instructing the model to be careful. A directive along the lines of ‘only answer if you are certain’ improves the statistics without removing the case, because the model has no internal measure of its own certainty to consult. What removes the case is cutting the access: no source, no answer, enforced in code.

The list fits on one page and always contains the same families: anything that commits a price, anything that commits a date, anything touching a complaint or a dispute, and anything amounting to regulated advice — medical, legal, financial.

Beside each line there has to be a name, not a department. "Passed to sales" is not a procedure; "passed to whoever holds the delivery calendar, and failing that to the shop manager" is one. Without a name, the handover lands in a shared inbox that everybody treats as somebody else’s.

That page has to be signed before go-live, not discovered after. It is also the document you will re-read in six months to understand why the system does what it does, and the only deliverable of the project that stays legible to somebody who was not there.

The list gets re-read, and the right rhythm is quarterly. It ages in one specific, predictable direction: businesses loosen over time, because each handover visibly costs somebody time while the risk avoided is never seen. A dated review, with the person who picks up the transfers, is what stops the limit dissolving over six months without any decision having been taken.

These systems bill by usage, to foreign suppliers, in currencies you do not earn. The cost depends on the number of conversations, their length, and how much of your content is consulted for each answer — three variables, none of which is known before go-live.

We deliberately put no chart in this section. A per-request price published today is wrong in six months: suppliers revise their tables without notice, withdraw models from the catalogue, and bill in euros or dollars, so a figure dated to one quarter does not travel to the next. A curve would give that instability the appearance of a trend.

What you can insist on instead is a ceiling. A monthly threshold set in advance, an alert before it is reached, and a decided behaviour beyond it — falling back to message-taking rather than an invoice that keeps running. That is a contract clause, not a technical feature, and it is worth more than any estimate. The ceiling bounds usage; what moves the go-live price sits elsewhere, and five scope decisions account for it.

We read your past conversations, we write the refusal list with you, we build the assistant on your content, and we watch it for two weeks before letting it run. We re-read the refusal log with you monthly. That is the whole offer.

The figure we will not give is the containment rate — the share of conversations that end without a human. We have it for the systems we run, it is real, and publishing it as an average would be dishonest: that rate is decided by the mix of questions each client receives, not by the quality of the build. A business whose customers mostly ask about opening hours will get a high rate from any supplier; a business whose customers negotiate prices will get a low one from the best. An average between the two measures our clients rather than our work, and you could do nothing with it.

What we will do instead is measure it at your end, on your own messages, before you have signed anything. And there is one case where we will tell you not to do the project: the one in the previous section. If your five questions fit on a page you have not written, write it — we do not bill for that conversation, and we would rather lose it cleanly than sell a system to compensate for a missing text.