Product claims assembled from verified attributes onlyStatutory rights routed to a human, alwaysNever touches cardholder data, by designFixed fee — not per seat, not per conversation

AI systems for retail and e-commerce brands

Most of what lands in an e-commerce inbox is a question the system already knows the answer to. Where is my order. Can I change the size. Why has my refund not appeared. The information exists in the carrier's API and your order record — it just hasn't been joined up to the person asking.

01The problem

Where the day actually goes

Forty-seven emails asking where an order is when the tracking page already says out for delivery. A returns backlog nobody has assessed. The same jacket showing available on one channel and sold out on another.

01

“Where is my order?”

The single largest category of inbound contact in most e-commerce businesses, and the one where the answer already exists in a system you're paying for. Every one of those replies is a person looking up a tracking number and retyping the same sentence.

Usually the fastest win to prove
02

Returns admin on both sides of the parcel

A request, an authorisation decision, a label, an inbound receipt, a condition assessment, a refund or exchange, a stock adjustment — plus a customer conversation before and after. Returns rates in some categories make this a full-time role nobody budgeted for.

03

One product, five sets of data entry

Every channel wants product information in a different shape: different attributes, different specs, different character limits, different image rules. A seasonal refresh across a few hundred SKUs becomes a permanent backlog.

04

Stock that disagrees with itself

Selling across a website, two marketplaces and a shop floor means reconciling stock positions that drift apart daily. The reconciliation is manual, the overselling is expensive, and the customer finds out before you do.

02What we'd build

What we'd build for a retail or e-commerce brand

Bespoke, running on your data, integrated with your storefront and carriers — rather than another subscription with a per-conversation meter running.

Build 01

Order status resolution

Reads the enquiry, resolves the order, pulls live carrier status and answers with the actual position plus a next step. Anything genuinely lost, damaged or outside your service promise escalates with the full history attached.

Typical setup 2–3 weeks.
Build 02

Returns triage

Classifies the reason, applies your policy deterministically, drafts the response and generates the label where the request qualifies — flagging serial returners, high-value items and anything asserting a statutory right for human handling.

Build 03

Product content from one source of truth

One structured product record becomes channel-specific copy, attributes, bullets and alt text. The system can only use attributes that exist in your data — it is structurally unable to invent a claim.

See the limits below. This constraint is the point.
Build 04

Listing and feed error resolution

Marketplace rejection messages are cryptic and endlessly repetitive. The system reads the rejection, diagnoses the missing or malformed attribute, and drafts the fix.

Build 05

Stock discrepancy investigation

Daily reconciliation across every channel, with the investigation written up — not just an alert raised. The useful output is “here's what happened and where”, not “these numbers differ”.

Build 06

Chargeback evidence packs

Assembles the order record, delivery evidence, communication history and policy into the format your acquirer wants, inside the response window — a deadline businesses routinely miss.

03Governance

Consumer law is the constraint that matters here

Retail's regulatory risk isn't a licence or an inspection — it's what your automated system says to a customer, and what it claims about a product.

Full governance, data residency and EU AI Act position →

04Hard limits

What we won't automate in retail

Most of these come down to the same principle: automation is fine for the routine, and unacceptable where someone's rights, safety or money are genuinely at stake.

✕ 01

Generating product claims

“Hypoallergenic”, “waterproof”, “organic”, “made in Britain”, allergen content, sustainability claims. A model that can invent an attribute will eventually invent one that's untrue and enforceable against you. Our content builds are constrained to verified attributes by design.

✕ 02

Deciding a statutory rights claim

If a customer asserts a right to reject or cancel, that's a legal entitlement, not a policy question. A person handles it — and the system's job is to recognise the assertion and route it fast.

✕ 03

Handling a product safety report

Injury, a faulty electrical item, a choking hazard, an allergic reaction. Immediate human escalation, no automated reply, because these can trigger recall and reporting obligations with real deadlines.

✕ 04

Blocking accounts or making fraud decisions alone

Refusing service based on automated profiling is a decision with significant effects on a person, requiring human review and a route to contest. The system flags patterns; a person decides.

05Questions

Common questions.

Can AI handle e-commerce customer service?

+

It can handle the routine majority — order status, delivery timing, size and stock questions, returns initiation — by resolving the actual order and answering from live data rather than guessing. What it should not handle is anything involving a statutory right, a product safety issue, a vulnerable customer, or a complaint with real emotion behind it. A good build is judged on how reliably it recognises those cases and hands them over, not on how many tickets it closes.

Can AI write product descriptions that comply with UK advertising rules?

+

Yes, if it is structurally prevented from inventing attributes — and no, if it isn't. The compliance risk in product copy is claims: material composition, safety, health benefits, origin, environmental credentials. We build content systems that assemble copy only from fields that exist in your verified product data, so the model has nothing to hallucinate from. Descriptive tone still gets a human read before publication.

Bespoke system or an off-the-shelf AI chat widget — which do we need?

+

A widget is the right answer if your questions are generic and your volume is low; it's quick, cheap and requires nobody's attention. A bespoke system earns its place when the answers depend on your actual data — live order state, carrier status, stock across channels, your returns policy — because that's precisely what a generic widget can't reach. The practical test: if a good answer requires looking something up in your systems, a widget will disappoint you.

Why fixed fee rather than per conversation?

+

Because per-conversation pricing charges you most in your worst week. Peak season, a delivery failure, a courier strike — exactly when volume spikes and you least want a bill that scales with your problems. We price the build and the running of it, so the cost is predictable and the incentive is to deflect contact rather than to meter it.

Will this replace our customer service team?

+

No. It removes the repetitive share — typically the order-status and returns-initiation traffic that requires no judgement — which is what makes the rest of the job survivable at peak. The teams we've built for haven't shrunk; they've stopped spending their mornings retyping tracking information and started handling the conversations that actually need a person.

Related sectors

Start here

Start with the order-status inbox.

It's the highest-volume, lowest-judgement work in most retail businesses, which makes it the fastest thing to prove. Tell us roughly how many of those you get a week.