Photo: free stock photography (Unsplash licence) — see imprint
The demo is always brilliant. The demo is not the product.
Since November every second customer call has opened with some version of the same sentence: can we put this thing in our shop. It is a fair question. The demo really is astonishing — you type a rough note about a garden hose and thirty seconds later you have a paragraph that reads better than the one a junior wrote last spring. We were as impressed as everyone else, and we spent the winter finding out where that impression survives contact with a live shop and where it does not.
The short answer: it is a very good writer and a very bad clerk. Everything it did well was a task where the correct answer was a matter of language. Everything it did badly was a task where the correct answer was a matter of fact — a stock level, a delivery date, a price for this customer group. It never once said 'I do not know'. That is the whole story, and the rest of this post is the detail.
What actually earned its keep
Product copy drafting works, with a caveat. Feed it the attributes you already have in the shop — material, dimensions, compatible models, the two things the supplier datasheet says — and ask for a first draft. What comes back is roughly the quality of a tired copywriter on a Friday: structurally fine, factually only as good as your input, and always in need of a human pass. That pass is not optional. But rewriting a mediocre draft is genuinely faster than staring at an empty field, and for a catalogue of a few hundred items that difference is measured in weeks.
Ticket summarising surprised us. A support inbox where customers write four paragraphs about a broken zip, and the agent needs to know in one line what happened and what they want. That is a compression job with no facts to invent — the facts are all in the text you handed over. It has been reliable enough that the support lead noticed the queue moving faster before anyone told her why. Same with translating an internal note into a polite customer reply, or turning a bug report into something a developer can read.
- First drafts of product copy from attributes you already store — then a human pass.
- Summarising long support tickets into one line an agent can act on.
- Rewriting a blunt internal note into a reply you can send.
- Category and meta descriptions where nobody had the time to write any.
- Regex, SQL and boilerplate you would otherwise look up — you still review it.
What embarrassed us in front of a customer
We wired a prototype assistant into a staging storefront for a tools retailer. Nothing ambitious — answer questions about the catalogue. A colleague, playing customer, asked whether an item was in stock. The model said yes, four units, usually ships within two working days. All three numbers were invented. It had no connection to the inventory table at all; it had simply learned that this is the shape of a sentence a shop says. It was fluent, confident, well-punctuated and completely wrong.
That is the part people underestimate. A wrong answer that sounds unsure gets checked. A wrong answer delivered in the calm voice of a competent employee gets believed, acted on, and turned into a complaint three days later when the parcel does not arrive. In Germany a stated delivery date is not a vibe — it is close to a promise, and you do not want a machine making promises on your behalf about facts it cannot look up.
The rule: it may never state a fact it cannot look up
This is the line we now hold in every project, and it is simpler than the architecture diagrams suggest. Anything the customer could hold you to — stock, price, delivery date, order status, warranty terms, whether a part fits their machine — is not a language problem. It is a database query. The model is allowed to phrase the answer; it is not allowed to know the answer. If the query returns nothing, the correct output is a handover to a human, not a plausible sentence.
Once you accept that, the useful applications sort themselves. Drafting, summarising, rephrasing, classifying an incoming mail into a queue — safe, because being wrong costs a rewrite. Answering a customer about their order — not safe, unless you have built the retrieval part properly, and the retrieval part is most of the work. The model is the cheap bit. The plumbing to your product data, your ERP and your stock is the project, and it is the same plumbing you would have needed without any of this.
What we would tell a shop owner asking today
Do not start with the chatbot. The chatbot is the most visible use and the most expensive to get right, and a bad one is worse than none — it trains customers to distrust your site. Start where a mistake is invisible and cheap: internal drafting, backlog descriptions, the 800 products that have never had a text. You will learn what the tool is and is not in two weeks, for the price of two weeks.
And be honest about the second-order cost. Every generated text still needs someone who knows the product to read it, and that person is usually your bottleneck already. If you have no capacity to review 800 drafts, you do not have an AI opportunity — you have 800 drafts. The tool moves work from writing to checking. Checking is faster, but it is not free, and nobody selling you a licence this year will mention that.
| Task | Verdict | Why |
|---|---|---|
| Draft product copy | Use it | Language task; a wrong draft costs a rewrite |
| Summarise a support ticket | Use it | All facts are in the text you supplied |
| Answer 'is it in stock?' | Never alone | It will invent a number and sound sure |
| Quote a delivery date | Never | A stated date is close to a promise |
| Classify incoming mail | Use it | Wrong queue is annoying, not costly |
- It is a good writer and a bad clerk — give it language work, not lookup work.
- A confident wrong answer costs more than no answer, because nobody checks it.
- The model is the cheap part; connecting it to your real data is the project.
- Start where a mistake is invisible, not on the customer-facing chatbot.
Frequently asked questions
It can write the first draft, not the final text. Quality tracks your input: give it real attributes and it produces something usable; give it a product name and it produces confident filler. Every draft needs someone who knows the product to check it, and that review capacity — not the writing — is usually the real constraint in a catalogue of any size.
Because it has no connection to your database and was never told it does not know. It predicts the sentence a shop would plausibly say, and 'in stock, ships in two working days' is an extremely plausible sentence. The fix is not a better prompt. The fix is that a real query answers those questions and the model only phrases the result.
Probably not as your first project. A customer-facing bot is the hardest thing to get right and the most damaging when wrong, and most of the effort goes into the data plumbing rather than the model. If your product data, stock and order status are not already accessible through a clean interface, build that first — you need it regardless, and you can decide about the bot afterwards.
The model access is close to noise. The cost is people: someone to build the attribute export and the prompt, and someone to read every result. Budget a couple of weeks to find out whether the output is good enough for your catalogue before you commit to anything larger. If the answer is no, you have spent two weeks and learned something concrete.
We do this for a living — Shopware, Node.js, React, ERP integration and automation for B2B.
Talk to an engineer