Handle more orders without a bigger ops team.
Every extra order brings returns, exceptions, claims and listings that someone has to handle. We look for the workflows where agents can apply your policies case by case, with checks that stop a wrong refund or a bad listing before it happens, and people keep the judgment calls.
Six workflows that scale with order volume.
These are the workflows we would examine first in an online retailer, D2C brand or marketplace. In most teams they run through a helpdesk, the order management system, the payment provider and a lot of copy and paste.
| Workflow | Manual today | AI-native version | Stays human | Verification check |
|---|---|---|---|---|
| Returns and refunds | An agent reads the request, looks up the order, checks the return window and photos, then issues the refund in the payment provider. | An agent checks order, policy, return reason and customer history, then prepares the decision. In-policy, low-value refunds go through within set limits. | Out-of-policy cases, high-value items, fraud flags and goodwill gestures. | Refund can't exceed the amount paid on that line minus earlier refunds. One refund per return ID. |
| Order exceptions | Ops works a queue of failed addresses, payment holds, stock-outs and split shipments in the OMS. | An agent classifies each exception, proposes the fix and drafts the customer message. | Substitutions with a price impact and cancellations above a value limit. | The proposed OMS status change must be a valid transition. The message must match the order data. |
| Delivery issues and carrier claims | Staff check carrier portals for "where is my order" contacts and file lost or damaged claims by hand, often late. | An agent tracks shipments, answers status questions and assembles claim packs with evidence. | Claims above a set value and disputes with the carrier. | Claim value must match the invoice. A deadline timer runs for every claim. |
| Chargebacks and payment disputes | Someone gathers order, tracking and contact history into the processor's portal before the deadline. | An agent assembles the evidence pack for the card network reason code and tracks the response deadline. | Deciding to fight or accept disputes above a set amount. | Evidence must match the reason code. No submission after the deadline. Disputes past due are escalated. |
| Seller and catalog onboarding | Merchandising fixes attributes, maps categories and checks restricted products line by line. | An agent normalizes attributes, maps categories and flags restricted or non-compliant items. | Restricted-category approvals, brand claims and seller acceptance. | Every listing passes the category schema and prohibited-item rules before it can go live. |
| Price and promotion changes | Spreadsheets are uploaded to the shop platform, and promotions stack in ways nobody intended. | An agent prepares price and promotion changes from your rules and simulates the effect on margin. | Changes outside the agreed band and new promotion mechanics. | Margin floor, minimum advertised price and promotion stacking rules are checked before publishing. |
Six numbers that show whether it worked.
The Audit measures these before anything is built. The Pilot is measured against the same numbers.
| Metric | Definition |
|---|---|
| Ops minutes per order | Total people time spent on post-purchase work, divided by orders shipped. |
| Return cycle time | Days from return request to refund or exchange completed. |
| Refund error rate | Wrong, duplicate or excess refunds per 1,000 refunds issued. |
| Exception rate | Orders that need a person to intervene, per 1,000 orders. |
| Disputes and claims past deadline | Chargebacks and carrier claims lost because nobody answered in time. |
| Listing time to live | Days from a product or seller submission to a compliant, live listing. |
What can go wrong in e-commerce, and the control for each.
An agent that issues money back or publishes prices must be held to stricter rules than a person. These are the failures we design against first.
| Failure mode | Control | How we'd detect it |
|---|---|---|
| Wrong refund issued | Refund capped at the amount paid on that line, net of earlier refunds. An idempotency key per return ID stops double refunds. | Daily reconciliation of refunds against the payment provider. |
| Duplicate order created or shipped | Deduplication on payment reference and order ID before fulfillment is released. | Alert on any two orders with the same payment reference. |
| Fraudulent return accepted | Rules on return history and value route risky cases to a person. High-risk refunds wait for warehouse inspection. | Sampled inspection audits and a running count of returns per customer. |
| Wrong price or promotion published | Margin floor and stacking rules checked before publishing. Large changes need approval. | Diff alert on every price change against the previous version. |
| Customer told something untrue | Replies are drawn from your policy text and the order record. Commitments such as refunds and dates use fixed templates. | Weekly QA sample and tagging of complaints about wrong information. |
| Personal data exposed | Agents see only the fields a task needs. Self-hosted, EU-hosted deployment is possible. | Access logs per agent and per task. |
Returns and refunds, from diagnostic to pilot.
Illustrative example — not a client result. The numbers below are assumptions chosen to show the method and the arithmetic. Your Audit replaces them with measured values.
| 01 | Diagnostic | Suppose a fashion retailer picks "returns and refunds" on the E-commerce track. The Snapshot might show a High leverage signal with Medium confidence, friction at the Decision and Execution stages, and Level 3 (workflow redesign) as the indicated AI depth, because policy decisions and exceptions are part of the work. |
| 02 | Audit | Suppose the Audit measures 2,000 returns a month at 6 minutes each. That is 2,000 × 6 = 12,000 minutes, or 200 hours a month, about 1.25 FTE at 160 hours. It also finds that about 20% of returns are out of policy, high value or flagged, and need a person. |
| 03 | Pilot | Suppose the 80% in-policy returns go through with a person sampling 10% of them for 5 minutes each, and the 20% exceptions take 8 minutes each because they are the harder cases. The Pilot measures whether that holds. |
| Line | Assumption | Hours per month |
|---|---|---|
| Baseline | 2,000 returns × 6 min | 200.0 |
| In policy, after | 1,600 returns, 160 sampled × 5 min | 13.3 |
| Exceptions, after | 400 returns × 8 min | 53.3 |
| After, total | 13.3 + 53.3 | 66.7 |
| Difference | 200.0 − 66.7 (about 0.8 FTE) | 133.3 |
At an assumed loaded cost of €40 an hour, 133 hours is about €5,330 a month. The Audit would also measure refund errors and cycle time, because faster, accurate refunds reduce "where is my refund" contacts. It would also count the new costs: compute, the payment provider integration and exception review. If the numbers don't hold, the recommendation is "don't proceed".
Where our proof comes from.
We'll be plain about this. Our production proof is in AdTech, not e-commerce. We have not yet run these e-commerce workflows for a client.
The architecture is the same one that runs in AdTech production: typed intake, deterministic checks before any action touches money or customers, bounded retries, then a person. Real-time invalid-traffic scoring and partner reconciliation are close cousins of return-fraud screening and refund reconciliation. The AdTech page and case studies show that work.
That is why e-commerce engagements start with the Audit. It measures your own baseline first, so any decision rests on your numbers, not on ours.
Questions e-commerce operators ask first.
Will an agent issue refunds without a person?
Only if you decide it should, and only inside limits you set: in policy, under a value cap, with no fraud flags. Everything else goes to a person. The cap and the rules are checked by deterministic code, not by the model.
Do we need to change our shop platform or helpdesk?
No. We work with the systems you have, through their APIs. The Audit records which systems hold the data and where it is re-keyed.
Isn't this what our helpdesk's AI feature does?
Helpdesk AI usually drafts replies. We look at the whole workflow, from request to refund to reconciliation, and put checks on the actions, not just the words.
Find out which post-purchase workflow is worth redesigning.
Start with the free diagnostic on the E-commerce track. Move to the Audit only if the Snapshot points to something worth measuring.
| 01 | Free AI Operational Diagnostic | 10 steps, 8–12 minutes, E-commerce / Marketplace track. Snapshot on screen and as a PDF. |
| 02 | Operational Leverage Audit, from $1,500 | Fixed fee, one workflow, 10–15 working days after data access. Measured baseline, benefit model with stated assumptions, go / no-go. |
| 03 | Pilot implementation, from $6,000 | Fixed scope. The workflow built and run in your environment, measured against the Audit baseline. Typically 4–8 weeks. |