ForgeQubit.
← Case Studies/E-commerce Systems/CS-02

E-commerceFulfillmentSystem

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.

/headline-outcome
3.2M ops / yrautomated operations
/industryE-commerce Systems
/system-typeFulfillment
/outcomeThroughput
/read-time12 min read
/context

Context.

A UK-based direct-to-consumer health & beauty brand, fulfilling out of two 3PLs (UK + EU), running growth campaigns and subscription renewals in parallel. The order volume had grown ten times. The ops team had doubled.

/businessDTC · health & beauty · UK+EU
/scale50 → 500 orders/day in 18 months
/team-before5 ops coordinators + 1 returns lead
/engagementBlueprint + Automation Forge + Retainer · 20 weeks
/existing-stack
  • ·Shopify Plus (orders, subscriptions)
  • ·Klaviyo (lifecycle email)
  • ·2 × 3PL warehouses (different APIs)
  • ·Gorgias (customer support)
  • ·Xero (finance)
  • ·Google Sheets (returns, reconciliation, reporting)
/problem

Problem.

System view — not vague business talk.

Order-to-fulfillment was not a system — it was eleven tools stitched together by ops coordinators doing copy-paste, cross-referencing, and inbox-diving. Every 5× growth triggered by marketing bent the operation closer to breaking.

  1. /01

    Eleven manual touchpoints

    From 'order placed' to 'customer receives', eleven distinct human actions were required on the exception path, and four were always required on the happy path.

  2. /02

    No canonical order state

    Shopify, the UK 3PL, the EU 3PL, and the returns sheet each held a different slice of the truth. Reconciliation was the returns lead's full-time job.

  3. /03

    Returns were an email thread

    Returns started in Gorgias, moved to a shared inbox, were logged in a sheet, and eventually re-entered into Shopify by hand. Average resolution: 9 days.

  4. /04

    No anomaly detection

    A warehouse picking the wrong SKU for 48 hours was discovered by a Reddit thread, not a dashboard. There was no signal layer.

  5. /05

    Growth bent the team, not the tools

    Every promo week, three additional temps were brought on. The ops team and the temp team never shared the same view of what had happened.

/before-system

Before.

Workflow as it existed, with failure points marked.

A dozen systems pretending to be one operation. The 'system' was the ops team's collective memory plus six active Slack channels.

/before-state · manual · unobserved
  1. 01

    Order hits Shopify

    subscription + first-time flagged differently · no unified event

    manual
  2. 02

    Coordinator triages shipping region

    UK vs EU 3PL · by postcode rules in a sheet

    manual
  3. 03

    Order forwarded to 3PL portal

    two portals · different schemas · no idempotency

    manual
  4. 04

    Warehouse picks + packs

    no visibility until despatched

    blind
  5. 05

    Tracking number copied back to Shopify

    by hand · up to 6h lag

    manual
  6. 06

    Returns begin in support inbox

    Gorgias ticket · no state machine

    broken
  7. 07

    Finance reconciled weekly

    3-way cross-check · usually missed items

    bottleneck
/after-system

After. Forged architecture.

Trigger · Decision · Execution · Data · Observability.

A single order spine. One event stream, two warehouse adapters, a state-machine-backed returns flow, and a signal layer watching the ratios the team used to rely on memory to notice.

/L-01

Trigger

Unified order events across Shopify + subscriptions

  • · node
    Order normaliser

    Shopify orders, subscription renewals, and back-orders collapsed into a single canonical event schema

  • · node
    Region router

    Postcode-based region assignment moved from a sheet into versioned config

/L-02

Decision

Routing, prioritisation, and policy

  • · node
    Warehouse picker

    Selects UK vs EU 3PL by region, inventory, and SLA; resilient to either warehouse going dark

  • · node
    Priority policy

    Expedited / standard / subscription tiers encoded explicitly, with measurable SLA contracts

  • · node
    Returns policy engine

    Decides refund / replacement / store credit by cost, reason code, customer history

/L-03

Execution

Idempotent writes to every downstream system

  • · node
    3PL adapters

    One adapter per warehouse, idempotency keys, retries, dead-letter queue

  • · node
    Tracking sync

    Tracking numbers pushed back to Shopify, Gorgias, Klaviyo from a single source

  • · node
    Returns workflow

    Temporal-backed state machine: requested → approved → received → resolved — with human-gated steps

  • · node
    Finance sync

    Daily event batch to Xero, fully reconcilable against the event log

/L-04

Data

Single order-event log + projections

  • · node
    Order event log

    Every state change for every order, append-only, 7 years retention

  • · node
    Ops snapshot store

    Current-state view used by the dashboard and by support tooling

/L-05

Observability

Live ratios, anomaly detection, alerts

  • · node
    Ops dashboard

    Orders in flight, by stage, by warehouse, by region

  • · node
    Anomaly signals

    Alert when picking error rate, refund rate, or warehouse latency drift beyond thresholds

  • · node
    Customer-impact view

    A single screen showing customers currently affected by an in-flight incident

/what-we-built

Components.

/c-01Event pipeline

Unified order spine

Shopify + subscriptions + back-orders collapsed into a canonical event stream. Schema-versioned, replayable end-to-end.

/c-02Integration layer

3PL adapter pair

Two warehouse adapters, idempotent, resilient to either warehouse's API going offline for hours.

/c-03Workflow engine

Returns state machine

Temporal-backed flow covering six states from request to resolution, with human-gated approval under a defined SLA.

/c-04Observability

Anomaly signal layer

Streaming detectors on picking error rate, refund rate, warehouse latency, and carrier SLA — paging ops before customers do.

/c-05Internal surface

Ops dashboard

Replaces four spreadsheets and three tabs. Queue view by stage, drill-down by order, customer, or warehouse.

/c-06Data pipeline

Finance batch

Daily reconcilable batch into Xero, driven entirely by the event log. Closes the prior week's books by Monday 09:00.

/outcomes

Outcomes. Measured.

Numbers out of the production system — not testimonials.

/m-01
3.2Moperations automated per year

Discrete state transitions executed by the system rather than a human.

/m-02−92%
0.4% → 0.03%order error rate

Orders requiring manual correction post-despatch, measured across a rolling 12 weeks.

/m-03−97%
22min → 45sorder → warehouse lead time

Median time from order placed to warehouse task queued.

/m-04−92%
9d → 18hreturns resolution

Median time from return requested to refund or replacement executed.

/system-insight
The team never needed more hands. They needed the operation to stop requiring hands to hold it together. Once the order spine was real, every downstream 5× — in orders, in SKUs, in geographies — cost engineering hours, not headcount.
/keep-reading

Adjacent systems.

CS-01Logistics Systems

Logistics Dispatch System

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.

48h → 2hView system
CS-03Agency Systems

Agency Ops System

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.

/next

Want your system redesigned?

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.