Ask ten vendors about "AI in e-commerce" and nine will show you a chatbot that answers FAQ questions. It is the most common, cheapest and least valuable use of artificial intelligence in a store — implemented so that an "AI-powered" badge appears on the site, not so that anything changes in the bottom line.
This article is about something else. We present three use cases that we have implemented in production and that work every day in real stores. For each one we describe the same things: what business problem it solves, how it really works underneath (the mechanism, the data required, the integration points), where the return on investment comes from — and, just as importantly, when it is not worth implementing. Because the most honest recommendation about AI is often: "in your case it will not pay off".
Why most "AI in e-commerce" is theatre
An FAQ chatbot is theatre because it has no access to anything that matters. It does not know the stock level, it cannot see the status of the customer's order, it does not know the promotion rules, it cannot calculate a discount. It answers general questions that the customer does not ask anyway — and at the first specific question it refers them to the contact form. The implementation takes a week, costs very little and does not move any metric, because it has not been connected to any process that creates that metric.
Failed AI projects usually fail in one of three ways, and it is worth recognising them before you sign a contract. First: the model is not connected to live data, so it answers with generalities instead of facts from your system. Second: it solves a problem you do not have — it builds an assistant where a good filter would have been enough. Third: nobody defined what was supposed to change, so after the launch it is impossible to say whether anything works. Each of these three mistakes can be avoided — but only before the start, not after.
Our principle is the opposite: we start from the business problem, not from the technology. The question is not "where can we squeeze AI in", but "does AI solve this specific problem better and more cheaply than the alternatives that already exist". If a good search engine with filters does the job, we advise against AI. If three dashboards answer 90% of the board's questions, we advise against an analytics assistant. AI only makes sense where it genuinely takes work off people's hands, shortens the time to a decision or closes a sale you would not otherwise have closed.
A chatbot that has no access to your warehouse, your price list and your order statuses is not "AI in e-commerce". It is a widget. Value only begins where the model gets access to your real data and your real processes.
All three use cases below have one thing in common: the model is connected to the store's live data and does a specific job in a specific process. That is the only kind of AI that brings a measurable return — and the only kind we implement.
Use case 1: A shopping assistant and self-service checkout
The same engine serves two channels: the screen of a self-service checkout in a bricks-and-mortar store and a widget in the online store. We implemented it in production for a retail client.
The business problem
A customer is standing at the self-checkout or browsing the catalogue online and gets stuck: they cannot find the product, they do not know whether it is covered by a promotion, they cannot scan the code, they are not sure whether a given variant is available. In a physical store they call an employee — if one happens to be free. Online they simply leave. Each of these situations is either service time consumed or an abandoned cart.
How it really works
This is not a chatbot glued onto a page. It is a GPT-4 class model embedded in a RAG (retrieval-augmented generation) architecture: the customer's question first goes to a search over the vectorised product catalogue, and the model formulates an answer solely on the basis of what it actually finds in your data. On top of that come function calls to live systems — checking stock levels, order status, promotion rules. Thanks to this the assistant does not "invent" a price: either it knows it from the system, or it says it does not know and directs the customer to support. That single difference — an answer fetched from the system instead of generated by the model — is what separates a production assistant from a decorative chatbot. A customer at the checkout cannot be given a price that the receipt will not accept, or a promise of availability that the warehouse does not confirm. All the engineering in this use case boils down to keeping the model on the short leash of your real data.
What such an implementation needs:
A clean product catalogue — names, attributes, variants, prices, availability. This is the foundation; we write about its quality below and it decides everything.
A price list and promotions API — so that an answer about a discount matches what the till will charge. A discrepancy here is worse than having no assistant.
Stock and order status — availability of a specific variant, shipment tracking.
A point of contact — the self-checkout screen or a widget in the online store. The logic is shared across both channels (omnichannel), only the interface differs.
Where the ROI comes from
In our retail implementation the assistant took around 60% of the time employees had previously spent supporting customers at the tills off their plate in the first months. Those are real staff hours moved to higher-value tasks — not an "improvement", but countable team capacity. Online, the same mechanism closes carts that would otherwise have disappeared at the first "I do not know whether this fits". The return is measurable because we define the metric — service time, abandonment rate — before the start, rather than fitting it to the result afterwards.
When it is not worth it
If you have a small catalogue, low traffic at the tills and effective search with filters, the assistant will not repay its cost — because there is nothing for it to save. If your product data is in disarray, sort out the data first: an assistant based on a junk catalogue will confidently and elegantly give wrong answers, and that is worse than having no assistant at all.
Use case 2: Visual search
The customer searches for products by taking a photo of them instead of describing them in words. We implemented this use case for D2C clients with a rich visual catalogue.
The business problem
The customer has seen a product — a piece of furniture at a friend's place, a jacket in a photo, a lamp in a café — and wants to buy it, but cannot describe it. They type "that kind of wooden retro-style lamp" and the text search returns either far too much or nothing. Purchase intent is high, and the description barrier kills it. This is a sale you lose not on price or availability, but because the customer cannot name what they want.
How it really works
The customer takes a photo. A vision model (CLIP class) encodes that photo into a vector in the same space in which we previously embedded the images of your entire catalogue; a nearest-neighbour search returns the most visually similar products. Prior object detection makes it possible to recognise and narrow the category, so that chairs are not mixed with lamps. We vectorise the catalogue once and then keep indexing with every change in the assortment — otherwise new arrivals cannot be found.
What is critical here:
Consistent, good-quality product photography — this is the fuel of this use case. The richer and more "visual" the catalogue, the more accurate the matches.
A vector index over the catalogue images, updated together with the assortment.
A category taxonomy — for narrowing down and sensibly sorting results.
Convenient upload, especially on mobile — the customer takes the photo on a phone, so it has to be effortless there.
Where the ROI comes from
In look-driven categories — fashion, furniture, interior décor, accessories — search by photo usually lifts conversion by a low double-digit percentage (in our implementations in the range of 12–18% in stores with a rich visual catalogue). The mechanism is simple: you recover the "I saw it somewhere" intent that text search cannot serve, and you shorten the path from photo to cart to a few seconds.
When it is not worth it
With catalogues based on specification rather than looks — screws, cables, B2B components — parametric text search is simply better; a photo will not distinguish anything between two almost identical parts. If the photography is poor or inconsistent, or the catalogue is small, visual search will be a gadget, not a sales tool. And if customers find products efficiently by name or SKU code — you do not have a problem to solve.
Use case 3: An analytics assistant over store data
The person running the store asks about data in plain language instead of writing queries or waiting for a report. We implemented this use case for a B2B client.
The business problem
The owner or the director wants to ask in plain language: "Show me the 10 most profitable products of the last 30 days with a year-on-year trend". Today that means either writing an SQL query, or clicking through four reports, or — most often — filing a ticket with IT and waiting two days. The knowledge is in the data, but access to it is the bottleneck, and because of that some decisions are made on gut feel even though the numbers are sitting in the database.
How it really works
An LLM (Claude or GPT-4) acts as a layer translating natural language into a query against your data. The question is turned into a query against the orders, customers and products database, executed on real data, and the result comes back as numbers plus a concise description. The crucial point: the model does not "know" your sales from its training — it queries your database live. Over the database we place a semantic layer with metric definitions (what exactly "profitability" means), access control (who may ask about what) and logging of all queries.
The conditions without which this will not work:
Reliable, well-modelled sales data — a consistent schema or a data warehouse. Without it the answers will be confident and wrong at the same time.
Pinned metric definitions — otherwise "margin" means something different in every answer and nobody will trust the tool.
Access control and an audit trail of queries — because this is a layer over sensitive financial data, not over product descriptions.
Where the ROI comes from
Here the return is different from the previous two — it is the democratisation of data. Decision-makers get answers without IT as an intermediary and without queuing for an analyst. The value lies in a shortened decision time, not in one impressive percentage; it is harder to attribute to a specific number, but in practice it means decisions that are faster, more frequent and better grounded in data. For a store where someone waits for a report every week, that is a real change in the pace of management work.
When it is not worth it
This is the most demanding of the three use cases — and the easiest to get wrong. If your data is in disarray, you will get the worst possible thing: a model that states a wrong number with full conviction, and that number goes into a board presentation. If you have three reports that answer 90% of the questions and nobody really asks ad hoc questions — do not build this. A hallucinated number in a business decision is more expensive than not having the tool.
The bottleneck is not the model, it is your data
If one pattern comes through from the three sections above, it is this: every time AI fails, the cause is the data, not the model. A shopping assistant is only as good as the catalogue is clean. Visual search is only as good as the photography is consistent. An analytics assistant is only as good as the data warehouse is reliable. GPT-4 or Claude class models are already good enough for e-commerce today — they are not the limitation.
We do not build models from scratch for typical e-commerce applications. Foundation models plus fine-tuning or RAG are cheaper and better than training your own. The real work — and the real budget — goes into putting the data in order, not into the model.
That is why, before we calculate the ROI of AI, we often recommend putting product data in order first — this is exactly the work we do in PIM implementations. Without a clean, complete catalogue every one of these use cases starts below zero, and you pay for a model that has nothing to work with.
The second thing that separates a production implementation from an impressive demo is the engineering around the model:
Monitoring and fallbacks — when the model or the provider's API does not respond, the sales process cannot stop. There has to be a plan B.
API cost control — caching responses, matching the model to the task (a cheaper, smaller model is often enough), hard usage limits.
Security and GDPR — zero data retention configured on the provider's side (OpenAI Enterprise, Anthropic with a BAA), anonymisation of sensitive data before it is sent to the model, a GDPR audit before going to production.
Which use case fits your store
A condensed decision map — what determines whether a given use case will pay off, and when it is better to let it go:
Use caseBiggest return when…Data that must be cleanWhen to let it goShopping assistant / self-service checkoutlarge catalogue, high traffic, many "does it fit / is it available" questionscatalogue, price list, promotions, stock levelssmall catalogue, good filters are already enoughVisual searchlook-driven categories (fashion, furniture, interiors)consistent, rich product photographyspecification catalogue (parts, B2B), poor photographyLLM analytics assistantfrequent ad hoc questions, a long queue to IT / the analystwell-modelled sales database + metric definitionsdata in disarray or dashboards answer 90% of the questions
How much does it cost
We do not give a fixed price here, and we do that deliberately. The cost of an AI implementation depends on three things: the complexity of the use case, the number of integrations and the required level of data security. Roughly speaking it grows in the order in which we described the use cases — the shopping assistant is usually the simplest, and the analytics assistant over a sensitive financial database the most demanding, because access control and auditing are added. On top of the one-off implementation you have to add a steady, predictable cost of API calls — on the order of the monthly cost of one tool in a company stack, not of a separate full-time employee.
Instead of promises we define business KPIs before the start and measure them in a 90-day window. If the goal has not been reached by then, we first look for the cause — it usually lies in the data, not in the model — and we fix it at no extra cost. If it turns out that AI simply does not fit this problem, our contracts provide for returning part of the project value. That is a working definition of "measurable ROI", not a slogan on a landing page.
Summary
AI in e-commerce works precisely when it stops being an ornament and starts being connected to your data and your processes. What the three use cases above — the shopping assistant, visual search and the analytics assistant — have in common is that each of them takes over specific work or closes a specific sale, and that their success depends more on the quality of your data than on the choice of model. Most often the best recommendation is to narrow things down: one use case, one defined KPI, one 90-day window.
If you want to check which of them — if any — will pay off in your store, we describe our approach in more detail on the AI in e-commerce page. And if you would rather talk straight away about a specific problem and the data you have — write to us. We will start with the question of whether AI is the right tool here at all.