Teaching a support bot the house rules

When a bot answers as a brand, its small mistakes read as the brand's mistakes. A perfume retailer runs a customer-support bot on WhatsApp, and most of its answers were fine. The wrong ones were quiet: an emoji that didn't match the brand's voice, a branch reply that implied a store had never existed, a return offered on an item the customer had clearly used. None of those are crashes. All of them are the brand saying something it wouldn't say.

We fixed them by writing house rules — small, explicit rules about tone, facts, and eligibility — and by putting one of those rules above the individual conversation flows. That last decision is the interesting one, and it carried a cost we'll be honest about.

TL;DR: A support bot that speaks as a brand needs house rules for tone and facts, plus a shared eligibility rule that outranks every flow. Because the shared rule touches all six flows, changing it forced a full regression across every one.

A bot that speaks as the brand can be subtly wrong in ways a test suite doesn't catch.

The bot passed its happy paths. Customers asked about returns, exchanges, and deliveries, and it answered. But three patterns kept producing answers that were technically responsive and still wrong for this brand.

The obvious fix is to patch each flow. Add an emoji instruction to the return flow. Add a branch-fact note to the store-info flow. Add a "was it opened?" check to the exchange flow. Repeat for every path.

That approach fails for the eligibility rule specifically. "Did the customer use the item?" is not a return question or an exchange question — it's the same question in both, and in wrong/missing, damaged, and complaint conversations too. If the check lives inside each flow, you copy it six times, and the six copies drift. One flow learns that "I wore it once" means opened; another doesn't. The bot then contradicts itself depending on which door the customer walked through.

Tone and facts have the same shape at smaller scale. If every flow carries its own emoji instruction, one flow will miss the update and the voice cracks there. Rules that are meant to be true everywhere shouldn't be stored per-flow.

We wrote house rules and gave one of them priority over the flows.

Underneath all of it, the bot still has to emit valid JSON, stay gender-neutral, and avoid banned words on every turn. Those constraints don't move; the house rules sit on top of them.

The shared eligibility rule sits above the six business flows and runs first.

A message comes in and gets routed toward one of six flows: Return, Exchange, Wrong or Missing item, Damaged item, Delay, or Complaint. Before that flow executes its own steps, the shared eligibility rule reads the customer's language. If the customer signals the item was tried, used, or disliked, the rule marks it opened and blocks return or exchange — regardless of which flow the customer is in. Only if the rule doesn't fire does the flow run its normal steps.

The picture is one gate over six branches, not six gates:

                incoming message
                       |
        +--------------+--------------+
        |   SHARED ELIGIBILITY RULE   |   <- evaluated first
        |  tried / used / disliked?   |
        |     => opened => ineligible |
        +--------------+--------------+
                       | (passes)
   +--------+--------+--------+--------+--------+--------+
   | Return |Exchange| Wrong/ |Damaged | Delay  |Complaint|
   |        |        |Missing |        |        |         |
   +--------+--------+--------+--------+--------+--------+

The eligibility rule is the box every flow passes through. It's stored once, in the shared return/exchange logic, and each flow inherits it. That's the whole point: one rule, one place, every flow bound by it.

Putting the rule in shared logic is what makes it correct. It's also what made the change expensive.

Because the eligibility rule lives in shared return/exchange logic, it touches every flow. So a change to that one rule isn't a one-flow change — it's a change to all of them. We couldn't test Return, ship it, and call it done. Editing the shared rule meant re-testing everything that depends on the shared rule, which is everything.

So we ran a full regression in fresh chats: all six business flows — Return, Exchange, Wrong/Missing, Damaged, Delay, Complaint — plus every edge case: bot identity, discount, talk-to-human without a circular loop, off-topic, out-of-hours, other languages, and gibberish. Fresh chats matter because a bot carries conversation state; testing inside an existing thread hides bugs that only appear on a clean start.

The surprise, stated plainly: shared logic trades local cost for global cost. Writing the rule once saved us from six drifting copies, but it also meant every edit paid a full-regression tax. That's the deal you sign when you centralize a rule — cheaper to keep consistent, more expensive to change.

The bot now holds the brand's voice and facts where it used to slip.

It uses only the brand's emojis, so tone no longer drifts with each customer. Its branch reply states that a former branch has closed instead of denying it existed — the factual claim is now correct. Used, tried, or disliked items are turned away from return and exchange consistently, in whichever flow the customer enters, because the eligibility rule is checked before the flow's steps. Chats that need a person are labeled for direct handling, and that handoff is documented for the team.

We verified this the only way that's honest for a stateful bot: a full regression pass across all six flows and every edge case, each in a fresh chat, confirming valid JSON, gender-neutral wording, and no banned words throughout. The measurement wasn't a metric dashboard — it was a re-test of every path the shared rule can reach.

Five lessons from teaching an LLM support bot to speak as a brand:

1. Voice is a rule, not a vibe. "Use only the brand's emojis" is a house rule you can enforce. Mirroring the customer hands your tone to strangers — write the rule down and make the bot follow it.

1. Wrong facts and missing facts are different failures. "That branch closed" and "we were never there" both sound plausible; only one is true. For a brand-voice bot, precise wording on real-world facts is part of correctness.

1. A rule that's true everywhere belongs in one place, above the flows. Eligibility isn't a return question or an exchange question — it's a shared question. Store it once and let it outrank the flows, or watch six copies drift apart.

1. Centralizing a rule moves the cost, it doesn't remove it. One shared rule is cheaper to keep consistent and more expensive to change. Know which trade you're making before you make it.

1. Change shared logic, regress everything — in fresh chats. If a rule touches every flow, editing it means re-testing every flow, and a stateful bot hides bugs inside old threads. Start clean, test all of it, every time.