Ecommerce support: what to automate first

Start with the questions that are lookups rather than judgements, and where being wrong is cheap to correct. In most stores that means order status, policy questions and returns eligibility. Leave anything that moves money, makes a promise about a carrier, or requires looking at a photograph. The ordering matters more than the technology, because the wrong first intent produces a system that costs more than it saves.

The first automation decision in a store is not which tool. It is which of the twenty things people write in about.

Key takeaways

Count your own contact mix before choosing. The right first intent is different in a fashion store and a parts distributor.
Rank by three things at once: volume, whether it is a lookup, and what a wrong answer costs.
Order status is the correct starting point in most stores, and it is less trivial than it sounds.
Four intents look automatable and are not: goodwill, damage claims, delivery promises and anything touching fraud.
The work is nearly all integration. The model is the smallest part of the build.

Who this applies to

You run an ecommerce operation with enough support volume that the queue is a cost, and you are deciding where an assistant should start. Whether to build it or buy an app is a separate question, answered in Shopify AI app or custom integration and, more generally, in build or buy AI customer support. This article assumes that decision is made and asks what the thing should do first.

Count the mix before you choose

Export ninety days of tickets, classify them by reason, and sort by volume. This takes an afternoon and it routinely surprises people, because the intents that feel most painful are rarely the most numerous. Painful and frequent are different problems, and only one of them pays back an automation.

Do not use a published industry breakdown for this. A fashion store with free returns, a parts distributor with fitment questions and a subscription brand with billing cycles have almost nothing in common in their contact mix, and the whole point of the exercise is your own numbers. The method is the same one used to build an eval set from real tickets, and doing it once serves both purposes.

Three axes, not one

Volume alone picks the wrong intent. Rank each contact reason on three:

Is it a lookup or a judgement? A lookup has a correct answer in a system you can query. A judgement weighs things and could reasonably go two ways. Lookups automate cleanly. Judgements need a gate or a person.

What does a wrong answer cost? Wrong tracking information means one annoyed customer and a correction. A wrongly promised refund means money, a policy exception you now have to honour, and a precedent. These are not the same risk and should not sit behind the same threshold.

Can the answer be checked? If the assistant cites the order record or the policy page, a customer catches the error. If it asserts from nowhere, nobody catches anything until it is a complaint.

The intents that score well on all three are where to start. That is usually a smaller list than the one in the project brief.

Most briefs rank on the first axis only, which is why they start with returns. The other two decide whether the automation holds once real orders reach it.

The three tiers

Tier	Typical intents	What it needs
Automate now	Order status, policy questions, returns eligibility, product specifications, opening hours, delivery options	An order lookup, a carrier lookup, and content that is actually current
Automate behind a gate	Address change before dispatch, order cancellation before picking, size and fitment advice, subscription pause	The same, plus a confidence threshold and a hard rule on the cutoff time
Leave with people	Refunds and goodwill, damaged or missing item claims, fraud and chargebacks, anything already escalated once	Nothing. These need judgement, and the system’s job is preparation

The third tier is not a permanent exclusion. It is where the assistant drafts, retrieves and summarises for a person who decides, which is frequently worth more than automating the intent outright.

Order status is not as simple as it looks

It is the right first intent and it is four different situations wearing one question.

Before dispatch. The answer is your own data and it is easy. The trap is the cutoff: a customer asking to change an address at 15:58 for a 16:00 pick deserves a different answer from one asking at 16:30, and the assistant needs to know which side of that line it is on.

In transit with fresh tracking. A carrier lookup and a plain summary. Also easy.

In transit with stale tracking. Nothing has scanned for four days. This is the situation customers actually write in about, and the honest answer is that it looks stuck and here is what happens next. An assistant that repeats the last scan event as though it were news makes the contact worse, and the customer writes again.

Marked delivered, customer says not received. This is a claims process wearing the clothes of a status question. It should be recognised and routed, never answered with the tracking status. Getting this one wrong is the most common way an ecommerce assistant loses a customer’s trust in a single message.

If your system handles the first two and treats the second two as the same thing, it will look excellent in testing and generate complaints in production, because testing is done on healthy orders.

The top two are the demo. The bottom two are the queue, because a healthy order rarely generates a contact at all.

Four that look automatable and are not

Goodwill and discretionary refunds. The decision depends on customer history, margin and a judgement about the relationship. Give the assistant a bounded, published rule if you want it involved at all - and see the action tiers in confidence thresholds and escalation design, because a refund is an irreversible action rather than an answer.

Damaged or missing items. These need a photograph assessed, and often a decision about whether to claim against the carrier. The useful automation is collecting the evidence properly first time, not making the call.

Promises about delivery dates. You do not control the carrier. An assistant that says “it will arrive tomorrow” has committed you to something a third party decides, and the customer remembers who said it.

Anything near fraud. Address changes on high-value orders, repeated refund requests, mismatched details. These need to route quietly to a person, and the routing rule belongs in code rather than in a prompt.

The work is integration, not the model

The part that takes the time in these builds is unglamorous: reading the order system, reading the carrier, knowing the warehouse cutoff, knowing whether a return has been booked, and knowing which of these is stale.

Two specifics that decide quality more than any model choice:

Freshness. If the assistant answers from a nightly export, it will confidently describe yesterday’s state of an order that shipped this morning. Status answers need live reads, and the ones that cannot be live need to say when they were last updated.

Identity. The assistant must know which customer it is talking to before it reads an order, and the check has to be real. This is the ecommerce version of the permission problem described in RAG permissions, and it is more often wrong on a public storefront than inside a company.

Bar lengths are illustrative. The model is the part everyone scopes and the smallest part of the work, which is why these projects overrun on the integrations.

What we tell merchants, including against ourselves

We start every ecommerce build with order status and policy questions, and we push back on starting with returns, which is the request we get most often. Returns feel like the expensive queue, and a meaningful share of returns contacts are judgements rather than lookups, so the automation covers a smaller fraction of that queue than it appears to and the exceptions land on the same people as before.

The recommendation that costs us work is the volume threshold. Below a few hundred support contacts a month, the honest answer is a good help centre, better order-status emails and a saved-replies setup - and no assistant. It is a smaller engagement than the one that was being scoped, and it is the correct answer often enough that we would rather say it than build something that never repays its own maintenance. That maintenance is a real line: content that has to stay current, an evaluation set that has to grow, and integrations that break when a carrier or an app changes.

Where we have been wrong: we have shipped status handling tested only against healthy orders. It performed well in review, and the first week in production found the stale-tracking and marked-delivered cases immediately, because unhappy orders are exactly the ones that generate contacts. Now the evaluation set is built from the messy ones deliberately.

When this is not worth it

Low contact volume. Under a few hundred a month, fix the emails and the help centre first.

A catalogue that changes faster than anyone maintains it. If specifications and stock are wrong in your own systems, an assistant broadcasts that inconsistency at speed. Fix the data first, because this is the one failure that damages the brand rather than just the queue.

A single-person operation where the founder answers everything. The answers are the relationship, and automating them removes the thing customers are buying.

Frequently asked questions

Should the assistant handle pre-purchase questions too?

Different problem, and usually a better commercial one. Pre-purchase answers convert rather than deflect, so measure them on conversion rather than on resolution, and expect the content gaps to be in your product data rather than in your policies.

How do we handle multiple languages?

Decide per language whether you can support the escalation as well as the answer. An assistant that answers fluently in a language nobody on the team reads produces escalations nobody can action, which is worse than not offering it.

Does this work on a helpdesk we already pay for?

Often yes, and it is usually the cheapest starting point. The ceiling is what the helpdesk can read from your order system, which is the same question as in the build-or-buy article.

What should it do during a peak like Black Friday?

Answer the lookups and get more aggressive about escalation on everything else. Peak is when the exception rate rises and the human queue is longest, so it is exactly the wrong time for the assistant to be attempting judgements.

How do we know it is working?

Cost per resolved contact, not deflection - the argument for that is in measuring cost per resolved task - plus the contact rate for the specific intents you automated, which should fall while the others hold steady.

Next step

If you want to know which of your contact reasons will repay automation, that is an afternoon with ninety days of tickets and it does not need a project. AI for ecommerce starts with that classification, and the answer is sometimes that two intents are worth doing and the rest are not.