What to automate in an ecommerce business first
Start with internal, invisible automation where a mistake is caught before a customer sees it: product description drafts, inventory syncing and order routing. These pay back immediately and fail safely. Customer-facing automation such as a support assistant is higher effort, slower to pay back and expensive when it gets something wrong.
Almost everything written about AI in ecommerce is vague enough to be useless. This article names specific automations, ranks them by effort against payback, and says which ones we recommend against.
Why the first automation should not be a chatbot
It is what most people ask for first, and it is close to the worst place to start.
A customer-facing assistant is the most visible AI project available, which is exactly the problem. It sits in front of customers, where mistakes are expensive and public. It is high effort to build properly, because doing it well requires retrieval over your own content rather than a generic model. And it pays back slowly, because deflection rates take months to establish.
The highest-return first automation is nearly always internal and invisible. Nobody sees it. It saves hours every week from the day it ships. And when it makes a mistake, somebody catches it before a customer does.
The ranking
| Automation | Build effort | Payback speed | Risk if it fails | Start here? |
|---|---|---|---|---|
| Product description first drafts | Low | Immediate | Low — caught in review | Yes |
| Inventory sync between systems | Low–medium | Immediate | Medium — oversells | Yes |
| Order routing and exception flagging | Medium | Fast | Medium — delayed orders | Yes |
| Search-gap reporting | Low | Slow | None | Yes, cheap |
| Alt text generation for catalogue images | Low | Slow | Low | Yes, cheap |
| Review response drafting | Low | Slow | Low | Later |
| Product recommendations | Medium | Medium | Low | Later |
| Customer support assistant | High | Slow | High — customer-facing errors | Not first |
| Automated pricing decisions | High | Unclear | Very high | No |
The last two rows are the two things clients most often ask for first.
The three to start with
Product description first drafts
Given real product data and three example descriptions in your house style, a model produces usable first drafts at a fraction of the time writing them from scratch takes.
Given only a product name, it produces plausible fiction — which on an ecommerce site means inaccurate claims about a physical object you then have to ship. That is a commercial and legal problem before it is an SEO one.
Every generated description needs a human pass before publication, and we build that step into the workflow rather than leaving it to discipline.
Inventory sync
Usually no language model at all. A webhook fires on order creation, logic decides what updates where, and systems stay consistent. Shopify Flow and WooCommerce’s Action Scheduler handle much of this natively.
Payback is immediate and obvious: it removes a recurring manual reconciliation and it stops overselling, which costs real money in refunds and goodwill.
Order routing and exception flagging
Rules decide fulfilment destination; anything unusual gets flagged for a human rather than silently processed. The value is less in the routing than in the flagging — surfacing the twenty orders a week that need attention, out of the two thousand that do not.
What we will not automate
Stated plainly, because the boundary matters more than the capability list:
- Pricing decisions. Automated repricing without oversight fails in ways that are expensive and public.
- Final customer-facing copy without review. First drafts yes; publication no.
- Anything with legal or safety consequences — returns entitlements, product safety claims, regulated categories.
- Fraud or chargeback decisions on model output alone.
- Support escalation. A customer asking for a human gets a human, immediately, every time.
Retrieval, and why it decides quality
If you do build a customer-facing assistant, the architecture question that matters is whether it answers from your content or from the model’s general knowledge.
Retrieval-augmented generation means the system searches your own policies, product data and documentation first, then asks the model to answer using what it found. That is the difference between an assistant that quotes your actual returns policy and one that invents a plausible-sounding policy you are then held to.
For any customer-facing use, retrieval is not an optimisation. It is the requirement.
Data handling
Worth being explicit, because it is every buyer’s unspoken second question.
Name which provider processes what before building anything. Do not send customer personal data to a model unless the task genuinely requires it, and minimise the fields when it does. Build retrieval over content you control. Confirm each provider’s retention and training terms in writing during scoping, because those terms change.
As data controller, the compliance obligations remain yours. Our job is to document the processing accurately so your records are correct.
Measure it, or lose it
Agree before building: what does this replace, and how will we know it worked? Hours saved per week, tickets deflected, error rate against the manual baseline. Record the baseline first.
That number is what defends the automation the first time it gets something wrong — and it will get something wrong. Automations without a number attached get switched off within a quarter, usually after one visible failure that nobody can weigh against the invisible successes.
How to scope an automation properly
Most automation projects go wrong at scoping rather than at build. These are the questions we work through before quoting anything.
What exactly does a person do today? Step by step, including the judgement calls. If nobody can describe the manual process precisely, it is not ready to automate — you would be encoding a process nobody understands.
How often, and how long does it take? This produces the hours-saved figure that decides whether the work is worth doing. “It takes ages” is not a number.
What does the input look like, really? Not the ideal case. The messy supplier feed with inconsistent units, the orders with missing fields, the customer messages that contain three questions at once. Automation fails on the edge cases, and the edge cases are where the current manual effort actually goes.
What happens when it gets it wrong? Who notices, how quickly, and what does it cost? This determines how much review the workflow needs, which is often the largest part of the design.
What is the fallback? Every automation needs a manual path for when it fails or is switched off. Building something the business cannot operate without, that nobody can operate manually, is a fragility you do not want.
Who owns it afterwards? Automations need occasional attention — an API changes, a format shifts, a provider deprecates something. An unowned automation degrades silently.
The four categories, and how they differ
Grouping automations by where they sit clarifies both effort and risk.
Content generation. Product descriptions, alt text, category copy, translation. Low risk when reviewed, immediate payback, and the quality is entirely determined by the quality of the input data. Covered in detail in AI product descriptions.
Data movement. Inventory sync, order routing, catalogue imports, reporting pipelines. Usually no language model at all — this is integration work. Highest reliability, most predictable payback, least glamorous.
Customer interaction. Support assistants, order enquiry handling, recommendations. Highest risk because errors are public, highest effort because doing it properly requires retrieval over your own content, slowest payback.
Analysis. Performance summaries, anomaly detection, search-gap reports, sentiment analysis on reviews. Low risk, slow payback, genuinely useful for the person running the store. Frequently the most under-appreciated category.
A sensible sequence works through those roughly in order: content, then data, then analysis, then customer interaction last.
What good looks like six months in
If automation is working, six months later you should be able to say:
- Which specific tasks stopped being done manually, named
- How many hours a week that represents, measured rather than estimated
- What the error rate is, compared against the manual baseline
- Who owns each automation and when it was last reviewed
- Which ones you switched off and why
That last one matters. Some automations do not earn their keep, and being willing to remove them is what stops the automation stack accumulating the way app subscriptions do.
If instead the answer is “we have AI now” with no numbers attached, the project did not have a measure defined at the start, and it will be difficult to defend the next time somebody reviews costs.
Cost, and how to think about it
We deliberately have not quoted figures for individual automations, because the range within each category is wider than the gap between categories. A product-description workflow for two hundred products and one for forty thousand are different projects.
What is stable is the shape of the cost:
Build cost scales with how messy the input data is, not with how clever the automation sounds. Clean, structured product data makes a description workflow straightforward. Inconsistent data spread across three systems makes the same workflow largely a data-cleaning project.
Running cost is per-operation for anything involving a model, and effectively zero for rules-based integration work. This is one reason we push toward the latter where it will do the job.
Review cost is ongoing and frequently forgotten. If every output needs a human pass, that time is part of the automation’s real cost and it should be in the comparison.
The useful calculation is not “what does this cost” but “what does this cost against the hours it removes, including review”. An automation saving four hours a week is worth considerably more than one saving four hours a month, regardless of which was cheaper to build.
Starting from where you are
If you have never automated anything, the sequence that works:
- List the repetitive tasks. Anything somebody does the same way every time.
- Time them honestly for a fortnight. Estimates are consistently wrong.
- Pick the one with the highest hours and the lowest risk. That is almost always internal.
- Record the baseline — time taken, error rate, volume.
- Build the smallest version that works. Not the complete vision.
- Measure after a month and decide whether to extend or stop.
That sixth step is what most automation programmes lack, and it is why so many end up with a stack of half-used tools nobody can justify.
Two things worth saying plainly
Most ecommerce businesses do not need AI to automate their biggest time sinks. Inventory reconciliation, order routing and report generation are integration problems solved with scheduled jobs and API calls. They are less interesting to talk about and they save more hours than anything involving a model.
And an automation nobody owns will decay. APIs change, formats shift, providers deprecate endpoints. Every automation needs a named owner and an occasional review, exactly like the plugins and apps that accumulate on a store. Building one and walking away produces something that works until it quietly does not, which is worse than not building it.
Where to begin this week
Spend an hour listing the tasks somebody on your team does the same way every time. Not the interesting ones — the repetitive ones nobody mentions in meetings.
Time the top three honestly over a fortnight. Then pick the one with the most hours and the least customer-facing risk, and build the smallest possible version of it.
That sequence has a much better record than starting with the automation that sounds most impressive, and it produces a number you can point at when somebody asks what the investment returned.
A closing note
The businesses that get the most from automation are not the ones with the most sophisticated tooling. They are the ones that measured a manual process, replaced a specific part of it, checked whether that worked, and then did it again.
That is unglamorous and it compounds. Buying an impressive tool without the measurement rarely does.
