E-commerce Fulfillment System
A DTC health & beauty brand scaled from 50 to 500 orders a day using humans as the integration layer. We rebuilt the spine so the next 5× happened without adding headcount.
A regional 3PL with 400+ daily shipments ran dispatch through a spreadsheet, a call rota, and the judgement of three senior planners. We replaced the judgement with an engineered decision layer.
System view — not vague business talk.
Dispatch was a human judgement layer wrapped around a spreadsheet. Every order above standard weight, outside standard geography, or tagged as time-sensitive dropped out of the automated lane into a manual one. At 400+ shipments a day, the manual lane dominated.
Order data lived in three order-management systems. The WMS had a fourth view. No system agreed on what a shipment was until a planner had manually reconciled it.
Carrier selection, service-level selection, label generation, and booking were four separate steps, executed in four tabs by three different roles. Each handoff cost 4–8 minutes per shipment.
Nobody could answer 'how many shipments are stuck in carrier selection right now' without a 40-minute spreadsheet audit. Exceptions were discovered when customers called.
Eight carrier portals, two SaaS shipping tools, one internal sheet. Each carrier had a different logic for when a booking failed, and the failure modes were invisible to the caller.
Three planners became a queue. 60% of their day was carrier selection. When any one was sick, dispatch time doubled within four hours.
Workflow as it existed, with failure points marked.
The workflow on paper was six steps. In practice, it contained at least twenty-two implicit decisions — all made by humans, none recorded, all re-made from scratch the next time a similar shipment arrived.
up to 45 min lag · 3 source systems
manualjudgement call · no rule record
bottleneckprice × SLA × capacity · phone calls
bottleneck8 portals · no idempotency
manualwarehouse staff · occasional mis-prints
manualSlack + WhatsApp · no audit trail
brokenTrigger · Decision · Execution · Data · Observability.
A single dispatch pipeline fronted by one canonical order event, a carrier-selection decision layer, an idempotent execution layer talking to every carrier, and an observability layer that made the queue state visible to the team in real time.
Canonical order events in, regardless of source
Shopify / BigCommerce / WMS webhooks normalised into a single `order.created` event
A bulk-import endpoint for back-dated shipments and peak-season surges
Carrier + service-level selection, as code
Rules for weight, geography, SLA, dangerous goods, customer tier
Scores each carrier on price, SLA, capacity and historical reliability; deterministic and replay-safe
Shipments that fall outside policy are routed to a named planner with an SLA timer
Idempotent bookings across eight carriers
One adapter per carrier, each with explicit retry, timeout, and dead-letter policies
Labels generated once, attached to the shipment record, reprintable on demand
Carrier response recorded as a first-class event; failures fire a dedicated exception topic
Append-only shipment event log as source of truth
Every state transition persisted; snapshot views are projections, not the record
Current-state projection, queryable for ops and customer-service
Live queue state, SLO dashboards, alerting
Queue depth per stage, shipment age, SLA breaches in real time
Booking success rate, latency p95, and failure reason breakdown per carrier
Paged on symptoms — queue depth, error rate — not on specific integrations
Three source-specific ingestors emitting a single canonical order event. Schema-versioned, replayable.
TypeScript rule module compiled from an internal DSL. Changes ship via PR + staging replay against yesterday's shipments.
Eight carrier adapters behind a single interface. Idempotency keys, retries, circuit breakers, dead-letter queue.
LLM-based classifier for free-text shipment notes, gated by policy — never selects a carrier, only narrows the candidate set for a human approver.
Live queue view by stage, with drill-down into any shipment's full event timeline. Replaces the shared spreadsheet.
Symptom-based alerts, routed to the duty planner. Paging on queue depth, not on individual booking failures.
Numbers out of the production system — not testimonials.
Median time from order intake to carrier-confirmed booking.
Share of daily shipments that move through the pipeline with zero human touch.
Net cost per shipment including planner time, peak-season temp labour, and platform fees.
Shipments that require a human intervention to complete, as a share of all shipments.
The real shift was not automation. It was moving carrier selection out of three people's heads and into a decision layer anyone could reason about. The automation fell out for free once the decision was codified — and peak season stopped needing twelve temps to survive.
A DTC health & beauty brand scaled from 50 to 500 orders a day using humans as the integration layer. We rebuilt the spine so the next 5× happened without adding headcount.
A 40-person creative agency in London was losing 1.5 FTE of project-management time to coordination that wasn't coordination. We rebuilt the intake-to-invoice spine.
Every case on this site started as an audit. If this study described a system that looks like yours, the fastest next step is a formal operations diagnostic.