AI assistants for online stores: what works today and what is still too early

Two different products are sold today under the label „AI assistant for your online store". One talks to your customer on the storefront: suggests a size, narrows the choice, walks them to the basket. The other works in your back office, on data the customer never sees, meaning descriptions, feeds, returns and support tickets. Almost every enquiry we get is about the first one. The second pays back sooner, for a reason that has nothing to do with model quality. An advisor can only repeat what it finds in your catalogue, and most catalogues cannot carry that weight yet.

Two products travel under one name

This distinction sounds academic right up to the moment you start collecting quotes. Then three vendors answer the same brief with three different things: a chat widget on the product page, a recommendation engine wired to user behaviour, and a set of automations inside your admin panel. All three are called an AI assistant. Each is priced differently, ships on a different timeline and pays back in a completely different line of your accounts.

Settle which one you are discussing first. Half of all confusion ends with that single question.

Advisors repeat exactly what sits on the product record

A language model knows nothing about your assortment beyond what you hand it. When the record has no selling unit, your advisor cannot tell a single item from a case pack. When the variant lives inside the product name instead of an attribute, it cannot narrow by size, because size does not exist for it as a field. When the delivery window is a sentence in the description, it answers with a sentence and your customer wanted a date.

We took this apart field by field in our piece on what an AI agent sees in your store. The same list applies here, because a human-facing advisor reads the very same record as an agent arriving to buy.

That is catalogue work, not model work. Which is why a quote promising an assistant in two weeks tells you more about the vendor than about your store.

Blast radius sets the deployment order

Every assistant is wrong sometimes, and that assumption is worth accepting before you sign rather than after the first complaint. The practical difference lies in who sees the mistake first.

Our own comparison, based on the scope of the AI Automation stage. The order follows who carries the cost of a mistake, not technical difficulty.

This asymmetry drives the deployment order harder than budget does.

Recommendation engines solve a completely different problem

Recommendation engines and shopping advisors land on the same wish list while feeding on different material. Recommendations run on behaviour: what others viewed, what sold together, what got abandoned. They need traffic rather than conversation, and in a small store they simply have nothing to learn from. An advisor runs on intent stated out loud and needs a described catalogue instead of purchase history. A store doing a thousand orders a month usually has too little data for useful recommendations and a good enough catalogue for a simple advisor. At fifty thousand orders that ratio flips.

Back office is ready sooner, because the data is already yours

In the back office an assistant works on material you already hold and are allowed to show it: the product records, order history, customer correspondence, pricing rules. You do not have to tidy the catalogue before starting, because tidying that catalogue is often the assistant’s first job. We described four such Monday morning situations in our piece on AI agents in your store admin, and broke out the most measurable case, the „where is my parcel" questions, in a separate piece on automating order support.

• Descriptions and translations for new items, drafted for an editor to approve before publication.
• Support replies prepared as drafts, ready to send once an agent has read them.
• Feed consistency checks before export to channels: currency, unit, availability.
• Detection of price drift between your store and a sales channel.
• Preparing product data for campaigns and for visibility inside model answers.

Three cases where a customer-facing advisor earns from day one

That ordering has exceptions and it is fairer to name them than to pretend an advisor always waits its turn.

• Configurable products. When a customer assembles an order from parameters instead of picking a finished variant, an advisor replaces a form nobody understands anyway. Here the data is structured by definition, because a configurator without structure does not run.
• Catalogues where the selection criterion is hard to name. Spare parts, technical chemicals, lighting, building materials. Your customer knows what they want to achieve and has no idea which parameter to filter by.
• Repeat B2B ordering. A buyer orders the same thing every month and wants it done in thirty seconds. That account’s order history is better material for an assistant than your entire catalogue. More on this in our piece on the B2B ordering portal.

One hour catalogue readiness test

Run this test yourself before you ask anyone for a quote. Pick twenty random items, ideally the ones customers ask about most, and check in the data rather than on the page whether each of them carries a complete set of information.

• Selling unit and multiple: piece, case, running metre, minimum quantity.
• Variant attributes as separate fields rather than a fragment of the product name.
• Price with a currency and a note on whether tax is included.
• Availability as a number with a refresh timestamp, instead of wording like „only a few left".
• Delivery window as a comparable value rather than a sentence in the description.
• Return terms stored as data rather than a link to your terms page.

If fewer than fifteen of those twenty come back complete, a shopping advisor will be guessing in every fourth conversation. Sort the data first, then have the assistant conversation.