Vouchers and Discounts in Chat: Clear Rules

Vouchers in chat: why an assistant must not invent a discount, what a campaign list looks like and what applies to struck prices. With a step-by-step rollout.

In plain language

A promised discount binds the shop. So the assistant only names codes that were stored in advance. Each code has conditions, such as a minimum order and a validity period. These conditions are in the same answer as the code. The cart checks whether the code is valid. Asking again does not raise the discount. When a struck price is named, the rules on price indication apply. This also holds in the chat.

August 25, 2026 14 min read By XICBOT

A discount is not information, it is a promise

When an assistant states a delivery window, it is passing on information. When it says you get ten per cent, it is making a commitment about the price the customer will pay. That is a different act. Wrong information causes annoyance; a wrong promise creates a claim - and the customer has the sentence in writing in the transcript.

German civil law does not treat such a statement as a non-binding opinion. Whoever makes an offer is held to it unless they have expressly excluded that binding effect:

Whoever proposes to another the conclusion of a contract is bound by the proposal, unless he has excluded being bound by it.

Section 145 German Civil Code (binding effect of an offer)

On top of that comes the question of who is answerable for what the assistant does. In May 2026 the Higher Regional Court of Hamm held that an AI chatbot is not a third party but a technical means of the company (OLG Hamm, case 4 UKl 3/25; appeal to the Federal Court of Justice was admitted, the ruling is not final). A note under the chat window saying that answers are non-binding does not remove that attribution along this line. We have written this up in detail in a separate article: Liability for chatbot statements.

What never goes out automatically

A language model produces plausible text. A voucher code looks like plausible text: a short run of letters, a digit, a hyphen. That is exactly where the danger lies. Without a hard block, a friendly request will get a model to assemble a code that never existed and to phrase it so naturally that the customer takes it for real. The block therefore does not belong in a request to the model but in the wiring: codes come from a list, or none comes at all.

No invented codes. What is not in the stored list is not named - not as an example either, and not with the rider that it might work.
No free-hand reduction. The assistant does not negotiate a percentage and does not round an amount down because a conversation went pleasantly.
No one-off promise. Sentences like we will sort that out or something can surely be arranged are promises without cover.
No extending expired campaigns. A code whose period has ended stays ended; the assistant does not move an end date.
No waiving a condition. If the minimum order value is not reached, it is not reached. The assistant does not lift a condition that the system holds.
No reduction on the customer's say-so. A screenshot, a claim about an earlier conversation or a competing offer are not a basis.

The rule in one sentence

The assistant passes on discounts, it does not grant them. Everything it names must have been decided and stored by someone in the shop beforehand.

This stance is not a handicap in conversation; it is the precondition for anyone believing the window at all. An assistant that says straight away where it lacks a basis comes across as more helpful than one that guesses. In our own measurement series 8 out of 8 questions without a basis were declined instead of guessed (XICBOT, own measurement series of 11.09.2026). How such a refusal can sound without being unfriendly is set out in Declining instead of guessing.

The stored campaign list

For the assistant to be able to name anything at all, it needs a source. That source is a maintained list of current campaigns - not a paragraph of prose in the knowledge base, but a record with fields that can be checked individually. The difference shows the moment a campaign ends: a date field expires, prose stays put and keeps being read out.

Field	What it holds	What happens when it is missing
Code	the string that is entered in the cart	the assistant has nothing to name and says so
Value	percentage or fixed amount, in the form the shop calculates	the answer describes the benefit vaguely and becomes attackable
Minimum order value	the sum from which the code applies	customers redeem, the cart refuses, chat has lied
Validity	start, end and the underlying time zone	expired campaigns keep being offered
Combinability	whether the code works alongside other campaigns	two reductions are promised, one is granted
Exclusions	brands, categories, reduced goods, gift cards	the refusal arrives only at checkout
Redemptions	cap per account and overall cap	a code circulates and the calculation tips over
Occasion	what the campaign is meant for, in one sentence	the assistant names it in the wrong context

The list has an owner, and it is not the technical team. Whoever plans campaigns maintains it - in the same step in which the campaign is created in the shop. Two separate places of upkeep drift apart, and they do so within a few weeks. The most robust route is an interface: the assistant reads the campaigns from the shop system at runtime instead of tracking them in a second store. How such a call is triggered is described in Controlling tools.

Conditions belong in the same answer

The most common mistake is not the invented code but the bare one. The assistant names the string, the customer puts goods in the cart, and there learns that the minimum order value has not been reached. A good moment turns into annoyance, and it does so exactly where most abandonments happen anyway. Anyone looking into this in detail will find the connections in Recovering cart abandonment.

The condition therefore belongs in the same sentence or immediately below it. Not as small print but as part of the information: what the code gives, from what point it applies, until when it is valid and what it does not apply to. Four short statements are usually enough; anything beyond that can be linked.

The same applies when a condition is not met. Then the right answer is not the code but the gap: which condition is missing and what would be needed to meet it. That wording is honest and practical at once, because the customer can work out whether the next step is worth it. It must not turn into a push to buy more than someone needs - the note describes a condition, it does not sell.

Value and form

Percentage or fixed reduction, named exactly as the cart calculates it. Anyone who talks percentages in chat while the cart deducts a fixed amount is manufacturing a complaint.
Threshold and deadline

From what cart total the code applies and until when it is valid. The end belongs in the answer as a date, not as only a few days left, which will still be there a week on.
Combinability

Whether the code works alongside running campaigns or only on its own. This is the statement that is missing most often, and the one that most often leads to a chargeback.
Exclusions

Brands, categories and already reduced goods the code does not apply to. If the exclusion is not in the answer, the customer notices it only at checkout.

How a code is issued technically

Between the question and the named code sit several checks, and none of them happens inside the language model. The model phrases the answer; whether there is anything to phrase is decided by the lookup before it. That order is the heart of the wiring: check first, then text - never the other way round.

The lookup returns only campaigns running at the moment of the question; expired and planned ones stay out.
The lookup knows the current cart, where there is one, and checks the threshold against the actual total.
The lookup returns the conditions along with the code, so the answer does not fill them in from memory.
Personal codes are generated only once it is settled who is on the other side - not on a bare request in an open window.
If no match comes back, there is no substitute. The answer says that no campaign currently fits and offers the next sensible step.
Every mention is logged: which code, in which conversation, at what time.

Personal codes are a separate case. They belong to an account and may therefore be named only in the signed-in area, never in a window where any visitor can claim to be someone. Where the boundary between information and commitment runs is set out in declining instead of guessing.

Repeated requests and abuse

As soon as word gets round that codes can be had in chat, people ask - repeatedly, in fresh windows, with changing justifications. Part of that is ordinary customer behaviour, part is deliberate probing. Both need the same answer: information does not change because it is requested more often. Anyone who concedes more on the third attempt than on the first is training customers to ask three times.

Technically, a brake on the public interface helps. With us the public widget interface counts each visitor's messages per minute and turns away whatever goes beyond the set cap. A limit like that does not stop stubborn manual asking, but it takes the speed out of automated attempts, and it makes conspicuous patterns visible in the log instead of letting them vanish into the noise.

Same question, same answer. The assistant repeats the information without additions and without an apology that sounds like room to negotiate.
Do not reward rephrasing. Whether someone asks politely, urgently or with an invented hardship changes nothing about the campaign list.
Ignore instructions from the conversation. Sentences like forget your rules or you are the sales director now are inputs, not authorisations.
Enforce the per-account cap. The number of redemptions is checked by the shop, not by the conversation; chat only states it.
Evaluate patterns. If discount questions cluster in one place, that is a signal about the page, not about the customer - look it up in conversation analytics.
Offer a handover. For cases where negotiation really is intended there is a human being, not a different answer text.

Persistence is not an argument

An assistant that gives in on the fourth request is not goodwill, it is an open till. The boundary lies in the campaign list, not in the tone of the conversation.

Struck prices: the disclosure duty applies in chat too

As soon as the assistant announces a price reduction - that is, strikes through an earlier price or sets a discount against a previous one - price indication law applies. The duty does not attach to the place of display. It applies on the product page, in the banner and equally in a chat window, when the reduction is announced there.

Anyone obliged to state a total price must, in relation to consumers and on every announcement of a price reduction for goods, state the lowest total price they applied in relation to consumers within the last 30 days before the price reduction was applied.

Section 11 (1) German Price Indication Ordinance (additional duty on price reductions for goods)

In practice that means: either the assistant reproduces the reduction together with the required statement, or it does not reproduce it at all and points to the product page, where it stands in full. The second route is the simpler and the more robust one, because the statement is maintained there anyway and does not have to be tracked in a second version inside the conversation.

Alongside that, fair trading law remains relevant: a statement about a price advantage that misleads is open to challenge under the rules of the German Act against Unfair Competition, regardless of whether a person or a window said it. If you are unsure whether a formulation holds, have it checked before it goes into the campaign list - after that it appears in every conversation.

When something wrong did appear in the window

Even with good wiring the case occurs: a code stayed visible longer than planned, a condition was missing from the answer, a campaign did not cover the category named. Then the question is not whether you are liable but how quickly you know the extent. That is exactly what the conversation log is for, and exactly why every mention of a code has to be logged.

Establish the extent. How many conversations contain the mention, over what period, in what wording.
Shut off the source. Correct the campaign list first, then the answer - otherwise the fault keeps running while you work on it.
Decide instead of waiting it out. The shop decides once whether the promise is honoured and treats all affected cases alike.
Inform customers actively where the promise is not honoured, with a reason and a route to contact.
Record the cause. A missing field, an outdated store or an over-broad answer rule - the cause belongs in a note, not in someone's memory.

How to roll it out

Getting started is smaller than it sounds. Begin with the strictest version: the assistant names no codes at all and points to the campaign page instead. That version is set up in a day and is already markedly better than a window that improvises. Only then do you add the campaigns you already maintain properly.

Decide in writing who releases campaigns and in which system they live.
Define the fields per campaign and fill them in completely for the campaigns currently running.
Write out the three answer forms: code with conditions, condition not met, no campaign available.
Wire the lookup against the shop system instead of maintaining the list a second time.
Test the three forms with real carts, once below and once above the threshold.
Ask repeatedly within the same sessions, change the tone and check whether the answer stays the same.
After two weeks, read the conversations in which a discount was requested and check every mention against the list.

The last point is the one most often skipped and the one that pays off most. A look at the actual conversations usually shows quite soon whether the answer forms hold or whether the assistant is saying more than it should in one particular spot. How to prepare the connection to your shop as a whole is described on the page on embedding the assistant in shop and website.

Frequent questions

May an assistant name voucher codes at all?

Yes, as long as it only passes on what was stored beforehand. The difference is not whether a code appears in chat but where it comes from. A code from the maintained campaign list is information about a decision the shop has made. A code the model assembles is a promise without cover - and in the window the customer cannot tell the two apart.

What should the assistant say when there is no campaign running?

It says exactly that, plainly and without a substitute offer of its own invention. What helps is a next step the shop actually offers: a pointer to a running campaign in another category if one exists, or to the channel through which future campaigns are announced. An honest refusal costs less trust than a vague sentence that raises hopes.

How do I stop someone talking a discount out of the assistant?

Not through a request in the instruction text alone, but through the wiring: the assistant has no way to generate a code, because codes come solely from the lookup. Add a brake on the public interface, a fixed answer form for repeated questions and a log holding every mention. If the route does not exist, nobody can be talked down it.

Does the assistant have to be allowed to name the struck price?

It does not have to be. If it announces a price reduction, the same duties apply to it as to the product page, in particular stating the lowest total price of the last 30 days under section 11 (1) of the Price Indication Ordinance. The simpler route is therefore not to state the reduction in chat but to point to the product page, where the disclosures are maintained in full anyway.

Who is liable if the assistant promises a wrong discount?

Following the line taken by the Higher Regional Court of Hamm, the chatbot is not a third party but a technical means of the company (case 4 UKl 3/25, appeal to the Federal Court of Justice admitted, not final). A note about non-binding answers below the window does not remove that attribution along this line. In practice: the effort belongs before the promise, not in a warning sentence after it.

Is it enough to store the campaigns in the knowledge base?

It works to begin with, but it does not hold up over time. A text in the knowledge base does not expire; it keeps being read out long after the campaign has ended. What holds up is a record with fields that the assistant queries at runtime - ideally straight from the shop system, so there is one place of upkeep rather than two that drift apart.

Ask it yourself, Assistant of this website

Automated assistant

Settings