Product Data Your Shop Assistant Can Reliably Answer From

A shop assistant looks convincing in the demo and disappoints three weeks later in daily use. The cause is rarely the language model and usually the catalogue: ask for the width of a mobile pedestal and no reliable answer comes back if the width sits inside a descriptive clause instead of a field with a number and a unit. How expensive that gap becomes shows up in the returns. On average 11% (Bitkom) of online purchases in Germany are sent back, and 67% (Bitkom) of respondents give the size of the product not fitting as a reason. This article works through the data fields an assistant can actually answer from: measurements with units, variants and what separates them, compatibility and accessories, delivery time and shipping, curated synonyms. And it describes how to check a catalogue against them before go-live.

Enlarge graphic

Labels in the illustration

• Product group: mobile pedestal
• varies by width and colour
• 40 cm, anthracite
• in stock
• 40 cm, light grey
• 2 working days
• 50 cm, anthracite
• in stock
• Attributes with units
• value, unit and field name kept apart
• Width
• 40 cm
• Height
• 58 cm
• Load capacity
• 25 kg
• Delivery time
• 3 working days
• Free text in the description
• compact build, fits in with
• common office furniture
• Assistant answers with:
• a paraphrase without a figure
• Attribute in its own field
• Width: 40, unit: centimetres
• Variant: anthracite, stock: 12
• Assistant answers with:
• 40 centimetres, in stock

Product data an assistant can use

Why an assistant fails on product data, not on the model

A language model does not invent centimetres. It phrases what the data says, and when the data holds nothing solid, the result is exactly the answer nobody can use: a polite paraphrase without a figure. In practice an assistant asked about installation width summarises the description text, and the description text says "compact build, fits in with common office furniture". The customer wanted to hear forty centimetres, or fifty. She gets an adjective and puts the item aside.

For an assistant, the difference between a sentence of free text and an attribute is the difference between guessing and looking up. An attribute has a name, a value, a unit and a data type. It can be compared, filtered, sorted and built into a follow-up question. A sentence of free text can only be repeated. That is why the work on a durable shop assistant shifts almost entirely away from wording the system rules and towards the catalogue. What exists as a field, the assistant can evidence; what exists as prose, it can only quote.

A second effect comes on top, and it is addressable in the catalogue just as well. When details are missing, part of the customer base simply orders the uncertainty along with the product: 29% (Bitkom) of respondents have deliberately ordered more than they actually needed, for instance clothing in several sizes. Every measurement stated unambiguously in the data set therefore works against two cost blocks at once: the return and the precautionary double order. That is why catalogue maintenance pays off faster than most expansion stages of an assistant.

Measurements, weights, quantities: value, unit, own field

The first rule is unspectacular and still broken in many catalogues: every dimension gets its own field, a numeric value and a unit. Not "approx. 40 x 60" in a text field, but width as a number, height as a number, unit centimetres. Not "pack of five", but content as a number with the unit piece. Only then can an assistant compare two items, answer the follow-up question about installation depth and apply a filter without interpreting text. Six points decide the quality of the answers here.

• Field name and value kept apart: width, height, depth, diameter, weight and load capacity each sit in their own numeric field with a unit, rather than combined inside one text field.
• One unit per field: centimetres or millimetres, kilograms or grams. Mixed units inside the same attribute make every comparison useless and every filter rule wrong.
• Name the tolerance instead of hiding it: where a dimension varies for manufacturing reasons, the tolerance belongs in its own field and therefore in the assistant's answer.
• State the reference point: with furniture and built-in appliances, external dimensions are not installation dimensions. Both values carry their own fields, otherwise a particularly expensive kind of misunderstanding follows.
• Carry the packaging dimensions: for freight items, the packed size decides whether the delivery fits through the stairwell. An assistant can only answer that if the value is maintained.
• Keep the unit price computable: fill quantity and unit as numeric fields allow automatic calculation. The Price Indication Ordinance requires the unit price alongside the total price (Section 4(1) of the German Price Indication Ordinance).

The last point is where technology and law coincide. Anyone offering consumers prepackaged goods by weight, volume, length or area has to state the unit price alongside the total price, unambiguously, clearly identifiable and legible (Section 4(1) of the German Price Indication Ordinance). A shop that meets this duty cleanly already carries fill quantity and unit as separate numeric fields, which is precisely the structure an assistant needs to answer a quantity question. The effort does not arise twice, it is simply used twice. How those fields play out in conversation is shown on the product page for the shop assistant.

Mandatory details that belong in the data set anyway

It pays to look at catalogue maintenance from the legal side once, because a list already sits there that the assistant will need later. In distance selling, consumers must be given the main characteristics of the goods to an extent appropriate to the medium (Article 246a Section 1(1) point 1 of the Introductory Act to the German Civil Code). The General Product Safety Regulation adds four clearly visible details for distance offers that translate directly into catalogue fields.

For catalogue maintenance that means, in concrete terms: the manufacturer's name with postal and electronic address, the responsible person in the Union, information allowing identification of the product and any warnings are fields, not footnotes. An assistant meant to answer a question about the manufacturer or about safety information reaches for exactly those. If the same detail sits as an image inside a scanned data sheet instead, it cannot be read, and the answer falls back to a pointer. For customers, a pointer is the signal to leave the page.

Variants: group, difference, stock

Variants are the point where maintained and laborious catalogues part ways. An item in four sizes and three colours is either one product group with twelve clearly described variants, or it is twelve loose items whose connection is only hinted at by the product name. For an assistant the difference is considerable. In the first case it can say which width is in stock in anthracite. In the second it searches by textual similarity and returns neighbouring hits that almost fit. How a guided selection grows out of this is described in the article on guided selling in chat.

Once that structure is in place, answer quality changes visibly, because the assistant can argue from a selection instead of from a text. It names the available combination, shows the price of the concrete variant and, on request, puts together a cart in the chat with it, without the customer switching between product page and chat. What that handover looks like in the window is shown by the product cards in chat, and the article on product cards and basket in chat describes the sequence in detail.

Compatibility and accessories: does this fit my device?

After measurements, compatibility is the second large group of questions in shop chat, and it is the question where an assistant without clean data can do considerable damage. Saying a filter fits a device when it does not produces a return and an unhappy piece of feedback at the same time. Compatibility therefore belongs in a maintained relationship between items and not in a sentence in the description. Four fields carry that relationship.

• A list of compatible models or product lines per item, maintained as references to item numbers rather than free text with model names in varying spellings.
• A field for the restriction: from which year of manufacture, up to which serial number, with which adapter. Without that condition a correct statement turns into a wrong one.
• The reverse direction: the device states which accessories fit. The assistant can then answer the question from both sides and offer accessories actively.
• A date for the statement. Compatibility lists age as soon as a manufacturer changes a product line. A date field makes visible which statement should be reviewed.

Delivery time and shipping: the field behind many follow-up questions

The delivery time question is one of the first in shop chat and one of the worst maintained in the catalogue. Legally it is clearly anchored: the payment, delivery and performance terms and the date by which the trader undertakes to deliver the goods are part of the distance-selling information duties (Article 246a Section 1(1) point 10 of the Introductory Act to the German Civil Code). Anyone keeping that date only as running text on a shipping page has effectively not provided it to the assistant. The comparison below shows what the difference means in practice.

Two fields are particularly worthwhile here. First the order cut-off, because it turns a vague statement into a checkable one. Second the stock location, as soon as more than one warehouse or branch ships. Once stock is maintained per location, an assistant can also offer collection and answer the question about the nearest branch. How an assistant is split across several locations without the answers drifting apart is described in the article on answers per branch.

Synonyms: the customer's language inside the catalogue

Catalogues are written in the language of purchasing, questions are asked in the language of everyday life. Between "sanitary silicone" and "bathroom joint sealant" there is no product difference, only a vocabulary difference. An assistant bridges some of that, but it does so more reliably when the catalogue carries a synonym field: common designations, regional terms, abbreviations, the widespread misspellings. The same maintenance improves search inside the shop, and there the effect is directly measurable. How chat catches a search that ends in nothing is described in the article on shop search without results.

What an assistant must not derive from product data

Maintained data tempts you into letting the assistant calculate. That is exactly where the errors arise that have to be explained later. The width and height of a shelf do not imply its load capacity. A material field implies no statement about allergies. The note "dishwasher-safe" implies no temperature recommendation. An assistant should reproduce and connect fields, but not derive properties nobody has verified.

In practice that means writing three limits into the system rules and storing them as test cases. No statement about fitness for a specific purpose where the data field for it is missing. No calculated figure that does not exist as a value in the catalogue. No commitment to a delivery date beyond what the delivery-time field carries. What the assistant does instead has to be defined just as clearly: name the limit, show the values that do exist and hand over to a person. Why a maintained data foundation works effectively against invented answers is described in the article on hallucinations and the knowledge base.

The third point concerns images. A considerable share of product information sits in photographs, exploded views and scanned data sheets, and for a text-based assistant that share is invisible. Where a detail exists only inside an image, there are two routes: it is transferred into a field, or the answer points to the document and names what it contains. The second route is the stopgap, because it sends the customer out of the conversation.

The catalogue check before go-live

An assistant does not go live because the integration works, but because the answers hold up. The workable route there is a list of real customer questions from the past months of support, drawn across the assortment areas. Twenty questions are enough for a first pass. Every question is put to the data set, not to the assistant, and for every question you note which field the answer comes from. Questions without a field are the result: they are the data maintenance backlog.

In the second pass the same list runs against the assistant, with a clear rule: an answer passes when it names the value and evidences where it came from. An answer that sounds plausible but names no field counts as failed, even when it happens to be correct. That strictness in the test procedure is the point where the quality of an assistant is decided. How such test cases are written down and made repeatable is shown in the article on acceptance and test cases before go-live.

Maintenance: who updates which field, at what interval

Product data decays quietly. A delivery-time field untouched since spring is misinformation with a timestamp by autumn. For a catalogue to stay dependable, every field needs a responsible role and an interval. The following order has proven itself as an entry point, because it starts with the fields most often needed in conversation.

• Stock and delivery time per variant: automatically from the merchandise management system, daily. Manual maintenance fails here on frequency, not on goodwill.
• Price, unit price and shipping costs: automatically, with a check step against empty fields. An empty unit price field is a legal and a substantive problem at once.
• Measurements, weights and material details: when the item is created, then on every change by the supplier. Purchasing owns this, because that is where the data sheets arrive.
• Compatibility lists: quarterly, plus whenever a new product line appears. A date field makes visible which list needs a review.
• Synonyms and search terms: monthly, from searches without hits and from conversation logs. This maintenance typically shows its effect after only a few passes.

What matters is that these responsibilities are written down rather than held in people's heads. A catalogue with clear roles survives a change of staff; a catalogue without roles drifts within a quarter. The body of text alongside the catalogue needs the same mechanism. How to set up a maintenance process for it is described in the article on keeping the knowledge base up to date.

What maintained product data changes in practice

The effect that shows first is the length of conversations. An assistant that reads measurements, variants and delivery times from fields answers the question in one go instead of across four follow-ups. The second effect sits in the return rate, and the third in support, because a considerable share of tickets consists of exactly the questions the catalogue could answer. What else an assistant takes on in retail is summarised in the article on the AI assistant for online shops.

The approach is not limited to retail. Wherever information comes out of an inventory, the field structure decides answer quality: for appointments, for courses with prerequisites and start dates, for services with a defined scope. What that looks like for training providers is shown in the article on the assistant for course providers. Anyone who wants their own catalogue reviewed before the start finds the way in via the contact page; the first step is the list of twenty questions, not the integration.

Frequent questions