AI & ML

Where AI Actually Works in Ecommerce (And Where It Doesn't)

Alexander Mercer

Sep 1, 2026

9 min read

There is no shortage of AI features you can add to an ecommerce store, and a shrinking amount of patience for the ones that do not pay for themselves. The useful distinction is not between clever and simple. It is between features where being occasionally wrong is cheap and features where being occasionally wrong is expensive.

That single test explains most of what follows. Language models are probabilistic. Deploy them where a wrong answer costs a shrug, and they are transformative. Deploy them where a wrong answer costs a refund, a compliance breach or a customer, and you have built a liability with a chat interface.

Search is the clearest win

Standard storefront search matches keywords. A customer searching for "something warm for hiking in november" gets nothing, because none of those words appear in your product titles. Semantic search — embedding your catalogue and matching on meaning — returns the insulated jackets.

It works because the failure mode is benign. A slightly odd result is a mild annoyance, identical to the mild annoyance of a keyword search returning nothing, and the upside is that a whole class of natural-language queries starts converting instead of bouncing.

It is also unusually easy to measure. Zero-result search rate and search-to-purchase conversion are both already in your analytics. You can prove the value in a fortnight, which is more than can be said for most AI features.

Support triage, not support replacement

Fully autonomous support agents are where most ecommerce AI projects go wrong. The model does not know your returns policy is different for sale items, confidently says otherwise, and now you are honouring a policy you do not have — or arguing with a customer holding a screenshot.

Triage is where the same technology earns its keep quietly. Classify the incoming ticket, pull the relevant order, draft a reply, and put it in front of a human who approves or edits it. The human stays accountable and the throughput roughly doubles.

Retrieval matters more than the model here. An assistant grounded in your actual policy documents and this customer's actual order history is useful; one relying on the model's general knowledge of how returns usually work is a hazard. If you take one architectural point from this piece, make it that: ground the answer in your data, and make it cite what it used.

Deploy AI where being wrong costs a shrug. Avoid it where being wrong costs a refund.

HelloDevs

Product content at catalogue scale

Generating descriptions for four thousand SKUs imported from a supplier feed is a genuinely good use of a language model, with two conditions. The input has to be real structured attributes rather than the product title alone, and the output has to be reviewed before it goes live.

Without the first, the model invents specifications, and invented specifications on a product page are a returns problem and, depending on the category and jurisdiction, a legal one. Without the second, you have published four thousand pages of unverified claims under your own brand.

The realistic gain is not zero-effort content. It is turning a task that would take a copywriter six weeks into one that takes them one week of editing. That is still an excellent trade — it is just a different claim from the one usually made.

Where we advise against it

01

Autonomous pricing

A pricing model with a bug is a revenue incident that runs at machine speed. Rules with human approval are less exciting and considerably cheaper to be wrong about.

02

Unreviewed customer-facing claims

Anything asserting a fact about a product — materials, compatibility, safety, compliance — needs a human between the model and the page.

03

Recommendations on a thin catalogue

Under a few hundred products with modest traffic, a hand-curated "goes well with" beats a model that has too little signal to learn from.

04

Chat as the primary navigation

Customers who know what they want are slowed down by a conversation. Offer it alongside, never instead.

05

Anything without an evaluation set

If you cannot say what a good answer looks like on fifty real examples, you cannot tell whether the feature is working or quietly degrading.

The cost nobody models

Inference cost is usually the smallest line. The real ongoing costs are evaluation, monitoring and the quiet drift that comes from a catalogue changing underneath a set of embeddings nobody scheduled a refresh for.

There is also a latency budget that gets ignored until launch. A recommendation call adding four hundred milliseconds to a product page is a conversion cost, and it can easily exceed whatever the recommendation earned. Anything on the critical rendering path needs to be cached, precomputed or moved off it.

Build the measurement before the feature. An AI feature with no evaluation set is not a feature you own, it is one you hope about.

Choosing which of these is worth building for a specific store is most of what our AI integration work actually involves — often the recommendation is to build two of them and skip the rest.

The short version

Search, support triage and catalogue content are where we see AI reliably pay for itself in ecommerce. They share a shape: high volume, tolerant of imperfection, easy to measure, and with a human in the loop wherever a mistake would be expensive.

The features that disappoint are the ones sold as replacing a person rather than accelerating one. Aim for the acceleration, measure it honestly, and the technology is genuinely worth the effort.

If you are weighing up which of these is worth it for your store, tell us what you are working with.

AIEcommerceShopifyMachine Learning

Alexander Mercer

Senior Tech Writer at HelloDevs

Alexander covers software engineering culture, design systems, and frontend developer experience. When not writing, you can find him debugging React or exploring typography design.

TwitterGitHubLinkedIn

Share this on

Stay Updated

Get raw, honest dev-first tutorials and tech blog articles delivered straight to your inbox once a week.

Our guide

A Shopify development agency builds and maintains the parts of a store Shopify does not give you out of the box. That means custom themes, apps, integrations with your other systems, and ongoing fixes. HelloDevs does all of this and also publishes its own Shopify apps.
Yes. We work with merchants across North America, Europe, and Asia. Our process is async-first with scheduled overlap hours, so time zones have never been a blocker for a project.
It depends on scope. Theme customisations typically start in the low four figures; custom apps and full builds range higher. After a free audit we give you a fixed quote — no hourly surprises.
Absolutely. Private (custom) apps are a large part of our work — from small workflow automations to full ERP integrations that only your store uses.
Every project ships with a support window, and most clients stay on a maintenance retainer: monitoring, Shopify update compatibility, and a direct line to the same developers who built it.
Continuity and coverage. An agency gives you review processes, backup when someone is unavailable, and accumulated platform experience across many stores — with one point of accountability.

Didn't Got your answer?

If you still have questions or need further assistance, feel free to reach out to our team. We're here to help you every step of the way.

Contact Support

Our talk

Let's Connect!

Tell us your requirements and get a professional developer response.

HelloDevs brand mark