Your Chatbot Just Promised a Refund. The Transcript Is the Policy Now.

When your chatbot tells a customer shipping is free or a refund is approved, that promise exists in a transcript the customer can quote. The policy page does not override it. The fix is guardrails on what the bot can say, not a better policy page.

The promise the bot made

The pattern is always the same. A customer asks the chatbot a question about shipping, returns, or a discount, and the bot answers confidently with a policy the store does not have. Free shipping on all orders. A full refund, no questions asked. A 20 percent discount for the inconvenience. The customer screenshots it, or the transcript saves it, and the support team discovers the promise when the customer arrives to collect it. The bot did not lie on purpose. It generated the most plausible answer to the question, and the most plausible answer was a policy that does not exist.

The cost is not the single refund. It is the precedent: once a customer has a transcript showing the store promised free shipping, every future customer who sees that transcript expects the same, and the support team has to decide, case by case, whether to honor a promise nobody authorized. The bot is fast, available, and wrong in exactly the way that creates work for humans, which is the worst combination for a support tool.

Why the transcript beats the policy page

The policy page is what the store intends. The transcript is what the customer was told, and in a dispute, what the customer was told wins. A customer who was told shipping is free and then charged for shipping has a screenshot, and the screenshot is more persuasive than the policy page, to the customer, to the payment processor, and to anyone else who looks at the dispute. The store can argue that the bot was wrong, but the argument concedes that the store put a tool in front of customers that invents policies, which is the problem, not the defense.

The same logic applies to prices. A chatbot that quotes a price the store never set creates a price the customer expects to pay, and the gap between the quoted price and the real price is a dispute waiting to happen. The bot does not need to be malicious to cause this. It needs to be confident about a fact it does not have, which is what language models do by default. Confidence without a source is the failure mode, and the source is the guardrail.

The three guardrails that actually work

First, ground the bot in the policy, not in its training. The bot should answer from a retrieved copy of the current return policy, shipping rates, and discount rules, and it should refuse to answer when the retrieval finds nothing. A bot that says I do not have that information is a bot that does not invent a policy. Second, fence the money: the bot must not approve refunds, apply discounts, or quote prices it cannot verify against the live catalog. Those actions go to a human, or to a system call that checks the real data, never to the language model alone. Third, log every answer with the source it used, so the support team can see what the bot told the customer and what it based the answer on. A transcript without a source is an argument. A transcript with a source is an audit trail.

Test the guardrails the way a customer would, not the way a developer would. Ask the bot for a discount, for free shipping, for a refund on a final-sale item, and for a price on a product that does not exist. The bot should refuse or escalate on all four. If it answers any of them with a confident yes, the guardrails are decoration. Run that test after every change to the bot, because a prompt change that improves the tone can quietly remove the fence.

What to do with the refunds already promised

Honor the ones that are already in transcripts, and treat the cost as the price of the lesson. Arguing with a customer who has a screenshot costs more in time and reputation than the refund, and it teaches the customer that the store argues with its own promises. Then fix the bot before the next customer arrives, because the promises keep coming until the guardrails are in place. The bot is a support tool, and a support tool that invents policies is a liability with a friendly tone. Ground it, fence it, log it, and test it like a customer would, because the customers already are.

Frequently asked questions

Can a chatbot promise create a binding obligation?

It creates an expectation the customer can quote, and in a dispute the transcript is strong evidence of what the store told them. Whether it is legally binding varies by jurisdiction, but the practical cost is the same either way: the store has to honor it or argue about it.

Why do chatbots invent policies?

Because language models generate the most plausible answer to a question, and when they do not have the real policy, the plausible answer is an invented one. Grounding the bot in retrieved policy documents is the fix.

Should the bot be allowed to approve refunds?

No. Refunds, discounts, and price quotes should go to a human or to a system call that checks live data. The language model should never be the only thing standing between a customer and money.

How do I test whether my chatbot invents policies?

Ask it for a discount, free shipping, a refund on a final-sale item, and a price for a product that does not exist. It should refuse or escalate on all four. If it answers any with a confident yes, the guardrails are not working.