This is a composite, illustrative walkthrough, not a specific client's confidential engagement. The scenario, numbers and architecture reflect the pattern and the kind of results this type of automation work typically produces — written to show the method, not to claim a named case.
The problem — a growing retailer processing orders by hand
The client in this scenario: a mid-market home and lifestyle goods retailer, around £14m in annual revenue, selling direct through Shopify plus two marketplaces. Order volume had grown roughly 40% year on year, handled by four people in order operations plus a slice of the support team's time answering "where is my order" questions.
The pattern is common in mid-market retail and it's rarely one broken thing. It's a sequence of small manual steps that were reasonable at a tenth of the volume:
- Orders arriving through the storefront and two marketplaces, in different formats, into different places
- Someone re-keying order data between the storefront and the OMS
- Manual address and fraud checks before labels were printed
- Stock allocation decided by a person reading two screens
- Warehouse handoff to the 3PL by spreadsheet and email
- Exceptions — split shipments, backorders, address problems — handled by whoever spotted them
- Tracking numbers copied back into the storefront and into customer emails by hand
The economics of this are unforgiving. Support tickets, orders and operational complexity grow at roughly the same rate as revenue, so team costs scale linearly with sales — which makes growth progressively less profitable. The trigger here was the run-up to peak season: the team had covered the previous two Black Fridays with overtime and temporary staff, and the operations lead didn't want to do it a third time.
What the audit found
Before building anything, we mapped the pipeline as it actually ran — including the exceptions people handled without thinking about them.
The baseline we measured, over a representative four-week period before peak season:
| Measure | Before |
|---|---|
| Orders per week | ~2,400 |
| Average manual handling time per order | 6.0 min |
| Total hours per week on order processing | ~240 hrs |
| Error / rework rate | 4.5% |
| Exception rate (non-standard path) | 13% |
| Order-to-dispatch cycle time | ~29 hrs |
| Order-status contacts per 100 orders | ~11 |
| People involved | 4 full-time, plus seasonal temps |
The exception rate was the number that determined the design. The client's own estimate going in was around 5%. Measuring it properly during the audit put it at 13% — a lot of "standard" orders were quietly being hand-adjusted for reasons nobody had written down, including an informal practice of expediting orders from a handful of repeat customers. That gap changed the scope of the build: automating only the textbook-standard path would have left over an eighth of volume untouched.
We also identified what not to automate: gift orders with handwritten notes, and any order flagged by the existing fraud rules — both stayed with a human, by design, rather than being forced through the pipeline for the sake of a higher automation number.
What we built
The design principle throughout: deterministic rules wherever the logic was knowable, AI only where the input was genuinely unstructured or the judgement genuinely fuzzy.
1. Intake and normalisation. Orders from Shopify and both marketplaces into one canonical format before anything else touched them.
2. Validation. Address verification, fraud screening against the existing rule set, and stock checks — all deterministic, with thresholds carried over from the rules the team already trusted.
3. Enrichment and routing. Allocation logic across warehouse locations and shipping method selection, both rule-based.
4. Exception handling. Anything outside the standard path — split shipments, backorders, the gift and fraud-flag categories above — escalated to a person with the relevant order context attached, rather than a bare ticket number.
5. Fulfilment handoff. Integration with the 3PL's WMS for label generation and tracking capture.
6. Customer communication. Proactive status updates at dispatch and at any delay — this stage alone accounted for a large share of the drop in order-status contacts, since most of those questions were preventable with earlier, clearer communication rather than faster support replies.
7. Write-back and reconciliation. Everything written back into the storefront and OMS as the system of record, so no report downstream had to know an automation was involved.
Where AI was used, and where it wasn't: address formatting, allocation and routing ran entirely on deterministic rules — none of that needed a model. The one place a small classifier earned its keep was triaging free-text exception notes from the warehouse and inbound marketplace messages into the right queue with the right context attached, because that input was the only genuinely unstructured part of the pipeline.
Guardrails: idempotency keys so a retried step could never create a duplicate order or a second refund, human approval required on any refund or reship above a set value, and a full audit log of every automated decision and what triggered it.
The hard parts
The 3PL's WMS had no clean webhook for dispatch confirmation — we had to poll and reconcile instead, which introduced a lag the exception queue had to be designed around rather than assume away.
Peak-season volume broke an early assumption in the exception-routing step: it had been sized for steady flow, and a promotional spike arrived in bursts large enough to overwhelm the queue depth we'd planned for. That meant adding backpressure — rate limits and a defined behaviour for what happens when the queue saturates — rather than letting it run at full speed into a step that couldn't keep up.
What nearly went wrong: in the second week of shadow mode, a SKU-mapping mismatch between Shopify and the OMS caused the system to under-allocate stock for a fast-selling line during a flash sale. The QA gate caught it before anything shipped incorrectly, but it reset part of the exception logic and delayed rollout by a week — a reminder that shadow mode exists precisely to catch this class of error before it touches a real customer.
The results
Measured over the four weeks following full rollout, against the pre-build baseline:
| Measure | Before | After |
|---|---|---|
| Orders per week | ~2,400 | ~3,400 (+42%) |
| Total hours/week on order processing | ~240 hrs | ~72 hrs (−70%) |
| Straight-through rate (no human touch) | 0% | ~88% |
| Exception rate | 13% | ~12% |
| Error / rework rate | 4.5% | ~0.9% |
| Order-to-dispatch cycle time | ~29 hrs | ~6 hrs |
| Order-status contacts per 100 orders | ~11 | ~4 |
| Cost per order processed (labour) | ~£1.85 | ~£0.62 |
The exception rate held roughly steady, which is expected — automation changes how exceptions get handled, not how often they occur. The 70% reduction is the total-hours figure across the whole function, measured even as volume grew 42% over the same window.
What the freed capacity was used for: hours saved aren't money until someone decides what happens to them. In this scenario, one person moved to customer experience work, one moved to a returns-quality initiative that hadn't had dedicated ownership before, and the planned peak-season temp hires weren't needed.
Running cost: roughly £1,400 a month in infrastructure, API and model usage — the exception-triage classifier is the only part of the running cost tied to model usage; the rest is deterministic and cheap to run.
What we'd do differently
Measure the exception rate properly during the audit rather than accepting the client's estimate. The gap between the assumed 5% and the actual 13% was the single biggest driver of scope, and finding it three weeks into the build cost time that a more sceptical audit would have saved.
Is your operation shaped like this one?
This kind of build works well when volume justifies it, the exception rate is measurable and not extreme, the systems involved have usable APIs, and someone internally owns the process well enough to say what "correct" looks like.
It works less well when the process changes every week, the exception rate is very high, volume doesn't justify the build, or nobody internally can define the standard path. Worth finding that out on a call before committing to a build, not after.
Have an order-processing operation that looks like this? Get in touch.
