They asked an AI first: when customers bring outside answers into your shop chat

“The AI said it also comes in red.” Sentences like this arrive in the shop chat, and they sound less like a question than a statement. Anyone who asked an AI chatbot before buying brings its answer along: a feature the device does not have, a price that stopped applying long ago, a voucher code the shop did not issue, a variant that is not in the range. This article shows how a shop assistant deals with such claims brought along: politely, without reproach and solely from your own catalogue and your own knowledge base. It explains why an assistant should not simply agree, what competition and sales law say about it, where the built-in output check helps and where it does not, and how recurring claims turn into a to-do list for the catalogue.

Enlarge graphic

Labels in the illustration

• BROUGHT ALONG (EXAMPLE)
• CHECK
• FROM YOUR OWN DATA
• Lookup
• own
• source
• only
• Catalogue
• voucher list
• knowledge base
• Voucher code
• “But code SPAR20 is valid.”
• This code does not exist here.
• Voucher list, in cart after confirmation
• Variant
• “It also comes in red.”
• Red is not on record.
• Variants: black, grey
• Feature
• “The battery lasts 30 hours.”
• The catalogue says: 22 hours.
• Source: data sheet, battery
• All values are invented examples. Whether a voucher applies is decided by the shop.
• If there is no entry, the don’t-know answer follows, with an offer to hand over to the team.

Claim brought along, answer from your own data

The answer is settled before the chat begins

Product search no longer necessarily starts in a search engine or in the shop itself. In Bitkom’s study report “Digitaler Handel in Deutschland” (digital commerce in Germany), the statement “When I search for a product, I often use an AI chatbot instead of internet search” applied to 16 per cent (Bitkom) of respondents. Among 16 to 29-year-olds it was 27 per cent (Bitkom). The survey covered 1,120 internet users aged 16 and over in Germany, from late September to early October 2025. How often the answers of such chatbots are correct was not part of the survey, and neither was how many of these searchers end up in a shop chat afterwards.

For the shop, this changes the starting point in the chat. Someone who asked a chatbot beforehand often no longer asks an open question but asks for confirmation: “It does have a laptop compartment, doesn’t it?” The answer brought along may be right. But it may also come from a predecessor model, from another shop or from an outdated text, and the chatbot that gave it knows neither your catalogue nor your prices nor your vouchers. How AI answers shift search and why fewer visitors reach a website at all is described in the article on zero-click search. This one is about those who do arrive, and about what they bring with them.

Five kinds of claims brought along

Claims brought along can be sorted by where in the shop the correct answer is held. For the assistant this is the decisive question, because it can only measure a statement against a store of data it has access to. The examples in the table are invented; they stand for cases that can occur in many product ranges.

What all five have in common is that the answer of an outside program determines nothing for your shop. A chatbot outside your shop usually does not know your offer with its variants, prices and conditions; it assembles what it knows from generally accessible texts. Even if a statement about the product is true, it can be wrong for your offer: the manufacturer makes the red variant, your shop does not stock it. Or the manufacturer changed the specification in the new model year, and the outside answer describes the old one.

Why the assistant does not simply agree

The most convenient answer to “It does have a laptop compartment, doesn’t it?” is yes. It ends the conversation on a friendly note and seems to make the purchase easier. A language model can easily give in to this temptation: it writes fluently, and a question that already contains its answer invites agreement. The damage shows later. The parcel arrives without a laptop compartment, the customer feels badly advised, and the return, the query to customer service and, in the worst case, a poor review land with the shop, not with the chatbot that made the claim first. From the customer’s point of view, the shop confirmed the feature.

Legally, the assistant in the shop is not a neutral third party. It answers on behalf of the shop, on the shop’s site, in a sales conversation. In Section 5(2), the German Act against Unfair Competition (UWG) calls a commercial practice misleading if it contains untrue statements or other statements likely to deceive about certain circumstances. The first of these are the characteristics of the goods:

Availability, execution and accessories are exactly the points where claims brought along typically start: the variant that is supposed to exist, the feature the device is supposed to have, the part that is supposed to be included. If a shop assistant confirms such a statement although it does not apply to the offer, it becomes a statement from the shop’s sales conversation. Whether it is unfair in a given case depends on further conditions, for example whether it is likely to influence a commercial decision. The same list also names, in no. 7, “consumer rights, in particular those based on guarantee promises or warranty rights in the event of defective performance”. This concerns claims brought along about returns and guarantees. Sales law, too, knows statements made before the contract: under Section 434(3) BGB, the quality a buyer can expect is assessed taking into account, among other things,

The wording names the seller, other links in the chain of contracts such as the manufacturer, and statements made on their behalf. A chatbot that the customer consulted on her own is not expressly named there. If it repeats a manufacturer’s statement, that statement may matter through the manufacturer, and the answer of your own assistant comes from the shop in any case. Two things follow for day-to-day operation: the catalogue should match the manufacturer’s information, and the assistant should only confirm what the catalogue supports.

The answer comes from your own catalogue

At XICBOT, the assistant for online shops answers from two stores of data: the product catalogue and the knowledge base built from the shop’s pages and documents. If the shop runs on Shopware Community Edition, the catalogue is taken over from the shop and synchronised on a schedule, and the assistant queries the price and availability of a named item from the shop at answer time; for other shop systems the catalogue is delivered. The assistant is instructed to answer from what the search finds in these stores and not from the model’s general knowledge. This is a rule in the instructions to the model, not a technical lock; answers usually carry a source reference. The product search only suggests items that are in the catalogue; if it finds no match, the don’t-know answer follows instead of an approximation. For claims brought along, this leads to three possible outcomes.

The third outcome deserves attention. “Not on record” does not mean “does not exist”: perhaps the shop does stock the red variant, but it is missing from the assistant’s catalogue. The assistant still does not name it, because it cannot back it up. In the moment this is inconvenient, but it is the answer the assistant can stand behind. In our own measurement series, 8 of 8 questions without a basis were declined instead of guessed; measured were eight questions deliberately outside the material. The series applies to our own assistant on its knowledge base; whether an assistant declines in the same way in your shop only a test question there will show. Why this refusal is a mark of quality is described in the article declining instead of guessing.

Correcting politely: tone and form

Anyone who brings along a wrong claim has not made a mistake but trusted a piece of information. An answer that makes this the topic costs trust, even if it is factually correct. “The AI told you something wrong there” lectures the customer and puts the shop into a dispute with a program that is not even part of the conversation. A better answer states what is on record without judging where the claim came from. If the customer insists or the tone becomes irritated, the route to a person helps; how an assistant recognises this is described in the article on frustration in AI chat.

• State the stored value, do not repeat the wrong one: “According to the data sheet, the battery lasts twenty-two hours” instead of “No, thirty hours is not right”.
• Show the source reference: the source reference below the answer lets the customer check for herself instead of having to take the assistant’s word for it.
• Do not judge the other source: no comment on chatbots, search engines or comparison sites; the answer talks about the item, not about the information.
• Offer an alternative only from the catalogue: if the requested variant does not exist, the assistant can show stored variants or accessories, but it does not invent a similar-sounding one.
• Keep the route to a person open: if the customer insists on her statement, the assistant offers handover to the team, which can check the warehouse or with the manufacturer if in doubt.

Voucher code, price, returns: three special cases

A voucher code from elsewhere. Outside or invented codes are the trickiest case, because they directly involve money. The XICBOT cart assistant only calculates with the codes from the voucher list the shop has stored; the language model itself does not see this list. If there is a cart with at least one item in the chat and the customer names a code, the assistant first proposes applying it. Only when she confirms this proposal is the code checked against the list: type as a percentage or fixed amount, value, minimum order value and validity. If the code is not on the list, it is not applied, and the customer learns that this code does not exist here. Without a cart in the chat or with an empty cart, the code is not checked against the list; the note that follows is that there is no open cart or that an empty cart does not accept a voucher. Even a valid code is not redeemed in the chat; it is carried in the cart, and whether the discount is granted is decided by the shop. How a voucher list should be set up and what must not go out automatically is described in the article on vouchers and discounts in chat.

Yesterday’s price. Prices brought along are often not invented but outdated: an earlier promotional price, another shop’s price, a price without shipping costs. The assistant states the price held in the catalogue; with a connected Shopware Community Edition it queries price and availability from the shop at answer time, without Shopware the fields from the last delivery apply. It does not adopt a price brought along, and a promise to grant an earlier price is not its decision. What an assistant may say about the total price, shipping costs and strike-through prices is described in the article on prices in chat.

A return period at second hand. Statements about returns, guarantees and shipping are not in the catalogue but on the shop’s pages. The assistant answers them from the knowledge base, with a source reference. If a customer brings along a longer return period than the shop grants, the assistant states the one on record. A fixed question-and-answer pair is particularly worthwhile here, because its wording goes out unchanged, without being rephrased by the model. Goodwill beyond the stored conditions is decided by the team, not by the chat.

Pasted texts are data, not instructions

Some customers do not retype the outside answer but paste it in: a whole paragraph with a product comparison, a list of advantages, sometimes with a request at the end such as “Please confirm these details”. For the assistant this is conversation content. XICBOT visibly separates the knowledge excerpt, the visitor’s input and the result of a tool when building the request, and marks them as data, not as instructions. A line such as “Ignore your previous rules” in a pasted text is therefore not meant to change what the assistant answers from. We deliberately attack this defence with injected instructions in our test track.

A pasted text is also not a source. The source reference below an answer points to a section of the knowledge base or to an item in the catalogue, not to what the visitor wrote. For the assistant to confirm something from the pasted paragraph, it must be in your own data; otherwise there is no source reference for it. How attacks via injected instructions work and which guardrails help against them is described in the article on prompt injection.

Where the output check helps and where it does not

Besides the binding to sources, XICBOT has a second safeguard: after an answer, hard details are held against what the answer had available. This means sums of money, percentages, deadlines and periods, quantities with a unit, e-mail addresses, web addresses and phone numbers as well as promise words such as “free of charge” or “anytime”. If excerpts or tool results were available and such a detail appears nowhere in the material, it is usually replaced in the text by “[not backed]”, and the visitor receives a note that the detail is not backed by the stored sources. Without such source material, the text remains unchanged. If the model states a battery life in digits from its own knowledge that is neither in the catalogue nor in the knowledge base nor in the conversation, this check applies, provided excerpts or tool results were available. A colour, a feature or a product name without a figure, on the other hand, is not a hard detail in this sense.

The material checked against, however, also includes what the visitor wrote: the current message and earlier messages in the conversation. That makes sense when someone states a quantity or a date and the answer picks it up. For claims brought along it has a consequence: if the customer writes the battery life as a figure and the assistant repeats it, the figure counts as present. The output check recognises a figure that comes out of nowhere, not one adopted from an outside answer. Against figures brought along, protection therefore comes first and foremost from the binding to catalogue and knowledge base, and test questions show whether it holds.

Recurring claims as a to-do list

If the same claim keeps coming back, it is worth looking into. From the Pro package, the conversation analytics group the questions of a period into topics and count them; answers without a source reference usually create a row in the gap list. The method does not know word meanings, only matches in word forms and character sequences; related topics should therefore be added up when reading. From both you can see which claims brought along are frequent, and each has its own cause.

You create fixed pairs in the knowledge base, ideally with the words customers actually use, for example “Does the backpack have a laptop compartment?”. Missing item details, on the other hand, belong in the catalogue, because a question-and-answer pair does not replace a characteristic that should appear on the product card. Which fields a shop assistant needs to answer reliably is described in the article on product data for the shop assistant.

Limits: what the assistant does not take on

• It does not check what another AI said. It only knows what is in the conversation and measures it against your own data.
• It is as accurate as the catalogue. If a wrong value is stored there, it states the wrong value, but with a source reference where the error can be found.
• It does not promise prices, discounts or goodwill that are not on record, and it does not redeem vouchers.
• It does not reliably recognise whether a claim comes from an AI, a search engine or memory. For the answer, that is not necessary either.
• It is not meant to assess whether a chat answer legally counts as a promise. That is a matter for advice in the individual case.

Frequent questions