Guardrails for Your Customer-Facing Chatbot (So It Never Quotes a Price It Shouldn't)

Three controls, roughly half a day of work, and your support bot stops making promises you'd have to honor.

If you've put a chat widget on your site — or you're about to — the failure mode that actually costs you money isn't the bot being unhelpful. It's the bot being too helpful: inventing a 20% discount, waiving a restocking fee, agreeing to a same-day install you can't staff, or confidently quoting last year's price. Customers screenshot that. Then you're negotiating from behind.

Your bot's words are treated as your words

This isn't hypothetical. In February 2024, British Columbia's Civil Resolution Tribunal ruled against Air Canada after its website chatbot told a customer he could apply for a bereavement discount retroactively — which contradicted the airline's actual policy. Air Canada argued, among other things, that the chatbot was a separate legal entity responsible for its own actions. The tribunal rejected that and ordered the airline to pay the customer damages and fees totalling roughly C$812, as the BBC reported at the time.

C$812 is nothing to an airline. The point isn't the payout — it's that "the bot said it, not us" was tested in front of a tribunal and lost. For a small business, the equivalent isn't a lawsuit; it's a customer standing at your counter with a screenshot, and you deciding in three seconds whether to eat the discount or the review.

The fix is not a better prompt. Prompts are instructions, and a language model can drift from them. What you want is a layer of dumb, deterministic checks around the model. n8n's guide to LLM guardrails describes the same split we use in practice: checks that run on the way in (before the model sees the message) and on the way out (before the customer sees the reply), covering things like keyword and regex filters, topical alignment, PII, and jailbreak attempts (n8n's guardrails guide). Which ones you reach for is an engineering judgement, and here's ours — stated as opinion, not benchmark: keyword and regex checks are the cheap ones, because they run in your own code rather than costing an extra model call on every message. Using a second model as a judge is more flexible, but you pay for it in latency and API calls. For an SMB support bot, three cheap controls cover most of the risk.

Control 1: an allowed-topic list, not a banned-topic list

The instinct is to list what the bot mustn't discuss. That list is infinite. Invert it.

Write down the five to eight things your bot is allowed to handle. For a typical service business that's: hours and location, booking or rescheduling an appointment, order or job status, what's included in a named service, return and warranty policy as written on your policy page, and how to reach a human.

Everything else — pricing beyond your published list, custom quotes, discounts, complaints, anything involving "can you make an exception" — is out of scope by default and routes to a human. This is a topical-alignment check, and you can implement the first pass with keywords before the model ever runs: if the inbound message contains discount, deal, price match, cheaper, refund, compensation, lawyer, complaint, manager, cancel my contract, don't answer it. Acknowledge it and hand off.

One more rule that does a lot of work: the bot may only state a price that it retrieved from your price list, never one it composed. If your prices live in a spreadsheet or your booking system, the bot looks them up and quotes verbatim. No lookup result, no number.

Control 2: a price-and-promise blocklist on the way out

The input filter catches the obvious asks. The output filter catches everything else, including the polite customer who never said "discount" but got offered one anyway.

Before any reply is shown, scan it for:

• Money patterns: any currency symbol, any number followed by "%", the words free, no charge, waive, waived, credit, refund, comp, on the house.
• Promise patterns: guarantee, guaranteed, we'll honor, we can make an exception, I'll ask them to, same day, by tomorrow, no problem, definitely.
• Policy invention: our policy is, you're entitled to, within 90 days — any policy statement that isn't a verbatim quote from your policy page.

If a reply trips a pattern and the number didn't come from a verified lookup, the reply never ships. The customer gets one canned line instead: "I don't want to give you the wrong number on that — let me get a person. What's the best email or phone for you?" Then it becomes a ticket.

That swap is the whole trick. A blocked reply is not a broken bot; it's a lead with contact details attached.

Control 3: a handoff trigger that fires before the customer asks for one

If your bot only hands off when the customer types "agent," you're firing too late — by then they're annoyed. Fire earlier, on any of these:

1. Output filter blocked a reply (control 2).
2. Two consecutive turns where the knowledge lookup returned nothing useful — the bot is now guessing.
3. The customer repeats the same question in different words.
4. Any message containing complaint, legal, safety, injury, or chargeback language.
5. Any message about an active job or invoice above a threshold you pick — say $2,000 — where the cost of a wrong answer is real.

Handoff needs a destination that exists at 9pm. If nobody's watching chat, the handoff is: collect name, contact, and a one-line summary, write it to your inbox or CRM with a clear subject, and tell the customer when someone will reply — then make sure someone does.

A worked example (illustrative — our own arithmetic, not a client)

Hypothetical six-van plumbing company. Every number below is invented to show the shape of the math; none of it is measured from a customer.

Say the site chat handles 500 conversations a month. About 8% of them drift into pricing, policy, or "can you do better on that" — call it 40. If the bot invents something wrong in 2% of those, that's just under one bad promise a month: call it ten a year.

Each one costs, generously, $150 in honored discount or unbillable work, plus 20 minutes of the owner's time smoothing it over. That's about $1,500 and three and a half hours a year, before you count the one that turns into a public review. Against that: the three controls above are static lists and pattern checks. On an existing bot we'd budget about half a day of build time — price that against your own developer's day rate — and there's no ongoing per-message model cost, because keyword and regex checks run in your code, not through an API.

It pays back in the first prevented incident. That's the reason to do it before launch and not after your first screenshot.

The 15 minutes a week that keeps it honest

Log every conversation, every blocked reply, and every handoff. Once a week, read ten transcripts — pick the longest ones, they're where things go wrong — and check two things: what got blocked that shouldn't have (add it to your allowed topics), and what slipped through that should have been blocked (add the phrase to the blocklist).

Also re-check your price lookup any time you change prices. A guardrail that quotes verbatim from a stale spreadsheet is a guardrail that's confidently, precisely wrong.

None of this is sophisticated. It's a whitelist, a pattern scan, and a routing rule. But it's the difference between a bot that generates leads and a bot that generates liabilities.

---

Want a second pair of eyes on your chatbot before it says something expensive? Book a strategy call — bring your bot's current instructions and a handful of real transcripts, and we'll tell you which of the three controls you're missing and what it would take to add them.