AI and workflow automation in ecommerce operations

Most AI-in-ecommerce writing starts from the technology and works towards a use case. That produces demos. Starting from the operation produces systems that are still running a year later.

The question worth asking is narrow: which repetitive work in your business has a clear input, a checkable output, and a failure mode you can live with? Everything that qualifies is worth automating, with or without a model involved. Everything that does not qualify will produce something impressive that quietly gets switched off.

This article is about telling those apart, and about building the second kind so it fails safely.

The test

Four properties. A task needs all four.

1. Volume — It happens often enough that the time saved exceeds the time spent building and maintaining it. A task done twice a month is a task to document, not automate.
2. A clear input — The information needed to do it is available in a system, not in somebody's head. If a human asks three colleagues before answering, that is a process problem first.
3. A checkable output — You can tell whether the result was right — ideally automatically, at minimum by spot-check. Without this you cannot know when it starts failing, and it will.
4. A tolerable failure mode — The worst realistic wrong answer is recoverable. A mis-tagged product is recoverable. A wrong price sent to ten thousand customers is not.

The fourth is the one people skip, and it is the one that decides whether a system survives contact with reality. Language models are probabilistic; over enough runs they will be confidently wrong. Designing for that is the whole job.

What actually pays back

Two patterns run through the safe column and they are worth naming.

Draft, do not publish. Almost every safe use writes to a reviewable state rather than to the live system. That single decision converts an unacceptable failure mode into an acceptable one, and it costs a review step.

Classify, do not decide. Routing a ticket to the right team is low-risk and high-value. Answering it directly is high-risk and only slightly higher-value.

What does not pay back

Automate confidently

• Repetitive data work with an inspectable output.
• Classification into a fixed set of categories.
• Drafting anything a human will approve before it ships.
• Moving and reshaping data between systems — usually plain code, no model needed.
• Monitoring and alerting on patterns nobody has time to watch.

Do not automate, or not with a model

• Pricing decisions. A wrong price is immediate revenue loss or a legal obligation to honour it.
• Stock commitments. Overselling costs more than the manual work it replaces.
• Unreviewed customer communication. One confidently wrong answer about a delivery or a refund undoes months of trust.
• Anything with a compliance implication — tax, age restrictions, regulated product claims.
• Rare, high-judgement decisions. Low volume, expensive failure. Exactly the wrong ratio.

Support chat deserves a specific note because it is the most-pitched use case. Autonomous customer-facing chat that answers policy questions from a model is a real risk: it will occasionally invent a returns window or a delivery promise, and a customer who was told something by your website will reasonably expect it to be honoured.

The version that works is narrower and duller: retrieve the actual policy text, answer only from it, cite which document, and hand to a human whenever confidence is low or the topic is on an escalation list. That is a retrieval system with a language interface, not an autonomous agent, and it is the difference between a support tool and a liability.

Agents, and where they genuinely fit

"AI agent" now covers everything from a scripted workflow to a system that plans its own steps and calls tools. The distinction that matters operationally is who decides the sequence.

• A workflow has a sequence you wrote. The model does one bounded job at each step — classify this, extract that, draft this. Predictable, testable, debuggable.
• An agent decides its own sequence. More flexible, and its failure modes are open-ended, which makes it much harder to test and much harder to reason about when something goes wrong at 3am.

For ecommerce operations, workflows are right for the large majority of cases. The tasks are known, the steps are known, and predictability is worth more than flexibility.

Agents earn their place where the path genuinely varies — an investigation across several systems, say, where the next query depends on the last answer. Even then: give them read access rather than write access, cap what they can call, log every step, and make a human the one who commits the change.

Building it so it fails safely

1. Automate the process before you automate the judgement — Most "AI opportunities" turn out to be integration problems. If two systems exchange a spreadsheet weekly, connecting them properly saves more time than any model, and it never hallucinates.
2. Write down the acceptance criteria first — What does a correct output look like, and how will you know? If that cannot be answered before building, it cannot be answered afterwards either.
3. Keep a human in the loop where output leaves the building — Anything a customer sees, anything that moves money, anything that changes stock. Review is cheap; a public wrong answer is not.
4. Make every action reversible and logged — Store what was changed, by which run, from which input. When it goes wrong — and it will — you need to find and undo the affected records, not audit the whole catalogue.
5. Measure quality continuously, not once — Sample outputs weekly and score them against the criteria. Model behaviour, supplier data and your own catalogue all drift; a system verified once at launch is unverified.
6. Budget and cap spend per run — Token costs scale with volume and a retry loop can multiply that quietly. Cap per run and alert on anomalies.
7. Design the fallback explicitly — When the provider is down or an answer fails validation, what happens? "Queue it for a human" is a fine answer. Silently doing nothing is not.

Data readiness: the precondition nobody checks

Automation projects fail on data far more often than on models, and the failure is usually visible in advance to anyone who looks.

Before scoping anything, check four things about the data the automation would consume.

The fourth is the one that quietly ruins projects. Automation applied to bad data produces bad results faster and at greater volume, and it launders them: an output that came out of a system looks more authoritative than the spreadsheet it was derived from, so it gets questioned less. If stock levels are wrong 5% of the time today, an automation built on them is wrong 5% of the time with more confidence and less oversight.

The honest sequencing is that a large share of what gets scoped as an AI project is really a data project, and doing the data work delivers most of the value on its own. That is not a reason to avoid the automation — it is a reason to sequence it second.

Build, buy, or configure

Three routes, and the choice is usually clearer than it looks once the criteria are stated.

The connector-platform row is worth expanding, because it is where most teams start and where a lot of quiet pain accumulates. These tools are excellent for proving a workflow is worth having. They are poor as permanent infrastructure at volume: per-task pricing scales badly, error handling and retries are usually shallow, and the logic ends up in a web interface that nobody can review, test or roll back.

Use them to validate. Once a workflow is load-bearing — meaning somebody notices when it stops — move it into code you own. That transition point is worth planning for at the start rather than discovering during an outage.

How to run a pilot that tells you something

Most automation pilots produce a demo and no decision, because they were never designed to be conclusive. A pilot worth running is set up like an experiment.

1. Pick one task, and the second-most-annoying one — Not the biggest. The biggest is usually the hardest and the most political, and failing there kills the programme. A visible, irritating, medium-sized task proves the mechanism.
2. Measure the manual baseline first — How long it takes now, how often it is wrong now, what it costs now. Without this, any result is unfalsifiable — and the current error rate is frequently higher than anyone assumed, which is useful on its own.
3. Define what success and failure look like, before building — A number, agreed in advance, with a date. "It feels faster" cannot be argued with and cannot be acted on.
4. Run it in parallel, not in place — The automation produces output, a human does the work as usual, and the two are compared. This is the only way to measure quality against reality rather than against expectation.
5. Sample and score the outputs by hand — Fifty items scored properly beats a thousand skimmed. You need to know the failure pattern, not just the failure rate — patterns are fixable, rates are not.
6. Decide on the number, and be willing to stop — A pilot that concludes "this does not pay back" is a successful pilot. The failure mode is one that produces neither a rollout nor a decision, and quietly persists as a half-used tool.

On cost: model usage is priced per token, so the running cost scales with volume and with how much context each call carries. That is usually modest against the labour it replaces, and it has two ways of surprising people — a retry loop multiplying calls, and a prompt that grew as features were added. Cap spend per run, alert on anomalies, and re-check the figure quarterly rather than assuming the launch estimate still holds.

A worked example

Product data enrichment, because it is the highest-value case for most catalogue businesses and it illustrates every principle above.

The problem. Supplier feeds arrive with inconsistent titles, missing attributes and descriptions written for a trade catalogue. Someone rewrites them by hand, which is why 4,000 products are still sitting unpublished.

The workflow.

1. Normalise the incoming feed against a schema. Deterministic code, no model. Anything failing validation is quarantined rather than guessed at.
2. Extract structured attributes — material, dimensions, compatibility — into typed fields, with a confidence score per field.
3. Draft customer-facing copy from the structured attributes, not from the supplier's prose, so the output is grounded in checked data.
4. Write everything to a draft product. Nothing reaches the storefront yet.
5. Auto-approve only where every extracted field is above the confidence threshold and passes validation. Everything else goes to a review queue.
6. A merchandiser reviews the queue — which is now minutes per product rather than thirty.
7. Log the source, the run and the fields written, so a systematic error can be found and reversed as a set.

Note what the model does and does not do here. It extracts and it drafts. It does not decide what is published, it does not set a price, and it never touches a live record. The safety comes from the workflow design, not from the model being good — which is what makes it still correct when the model changes underneath you.

That shape — normalise deterministically, extract with confidence, draft to review, approve on threshold, log everything — transfers to most of the table above.

Key takeaways

• The test is four properties: volume, clear input, checkable output, tolerable failure mode. All four, or do not build it.
• Draft rather than publish, and classify rather than decide. Those two patterns cover most safe automation.
• Pricing, stock commitments and unreviewed customer communication are where automation goes badly wrong.
• Workflows beat agents for known operational tasks. Agents suit genuinely variable paths, with read access and human commit.
• Most "AI opportunities" are integration problems. Connect the systems first.
• Safety comes from workflow design, not from the model being good.

We build these as ordinary software with a model inside, which is why they keep working. If you have a repetitive process and want to know whether it passes the four-part test, describe it to us — our automation work usually starts by ruling out the half that turns out to be plumbing.