ForgeQubit.
← Case Studies/Logistics Systems/CS-01

LogisticsDispatchSystem

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.

/headline-outcome
48h → 2hdispatch lead time
/industryLogistics Systems
/system-typeDispatch
/outcomeTime Reduction
/read-time11 min read
/context

Context.

A regional third-party logistics operator in Northern Europe, running 400+ daily shipments at peak season across eight carriers. The business was growing, the dispatch team wasn't.

/businessRegional 3PL · Northern Europe
/scale400+ shipments/day · 8 carriers
/team-before3 planners + 12 peak-season temps
/engagementBlueprint + Automation Forge · 14 weeks
/existing-stack
  • ·Shopify, BigCommerce (order intake)
  • ·Custom WMS (warehouse)
  • ·8 carrier APIs + 2 manual carrier portals
  • ·Shared Google Sheet (master dispatch log)
  • ·Slack + WhatsApp (exception coordination)
/problem

Problem.

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.

  1. /01

    Fragmentation

    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.

  2. /02

    Manual handoffs

    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.

  3. /03

    No observability

    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.

  4. /04

    Tool sprawl

    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.

  5. /05

    Bottleneck at senior planners

    Three planners became a queue. 60% of their day was carrier selection. When any one was sick, dispatch time doubled within four hours.

/before-system

Before.

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.

/before-state · manual · unobserved
  1. 01

    Order imported into sheet

    up to 45 min lag · 3 source systems

    manual
  2. 02

    Planner triages shipment class

    judgement call · no rule record

    bottleneck
  3. 03

    Carrier selected by planner

    price × SLA × capacity · phone calls

    bottleneck
  4. 04

    Booking submitted to carrier portal

    8 portals · no idempotency

    manual
  5. 05

    Label printed + attached

    warehouse staff · occasional mis-prints

    manual
  6. 06

    Exceptions resolved by phone

    Slack + WhatsApp · no audit trail

    broken
/after-system

After. Forged architecture.

Trigger · 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.

/L-01

Trigger

Canonical order events in, regardless of source

  • · node
    Order ingest

    Shopify / BigCommerce / WMS webhooks normalised into a single `order.created` event

  • · node
    Replay input

    A bulk-import endpoint for back-dated shipments and peak-season surges

/L-02

Decision

Carrier + service-level selection, as code

  • · node
    Shipment classifier

    Rules for weight, geography, SLA, dangerous goods, customer tier

  • · node
    Carrier policy engine

    Scores each carrier on price, SLA, capacity and historical reliability; deterministic and replay-safe

  • · node
    Exception router

    Shipments that fall outside policy are routed to a named planner with an SLA timer

/L-03

Execution

Idempotent bookings across eight carriers

  • · node
    Carrier adapters

    One adapter per carrier, each with explicit retry, timeout, and dead-letter policies

  • · node
    Label pipeline

    Labels generated once, attached to the shipment record, reprintable on demand

  • · node
    Booking confirmation

    Carrier response recorded as a first-class event; failures fire a dedicated exception topic

/L-04

Data

Append-only shipment event log as source of truth

  • · node
    Event log

    Every state transition persisted; snapshot views are projections, not the record

  • · node
    Shipment store

    Current-state projection, queryable for ops and customer-service

/L-05

Observability

Live queue state, SLO dashboards, alerting

  • · node
    Dispatch dashboard

    Queue depth per stage, shipment age, SLA breaches in real time

  • · node
    Carrier SLOs

    Booking success rate, latency p95, and failure reason breakdown per carrier

  • · node
    On-call alerts

    Paged on symptoms — queue depth, error rate — not on specific integrations

/what-we-built

Components.

/c-01Event pipeline

Order-ingest normaliser

Three source-specific ingestors emitting a single canonical order event. Schema-versioned, replayable.

/c-02Decision service

Carrier policy engine

TypeScript rule module compiled from an internal DSL. Changes ship via PR + staging replay against yesterday's shipments.

/c-03Integration layer

Carrier adapter set

Eight carrier adapters behind a single interface. Idempotency keys, retries, circuit breakers, dead-letter queue.

/c-04AI agent (bounded)

Exception routing agent

LLM-based classifier for free-text shipment notes, gated by policy — never selects a carrier, only narrows the candidate set for a human approver.

/c-05Ops interface

Dispatch dashboard

Live queue view by stage, with drill-down into any shipment's full event timeline. Replaces the shared spreadsheet.

/c-06Observability

On-call alerting

Symptom-based alerts, routed to the duty planner. Paging on queue depth, not on individual booking failures.

/outcomes

Outcomes. Measured.

Numbers out of the production system — not testimonials.

/m-01−96%
48h → 2hdispatch lead time

Median time from order intake to carrier-confirmed booking.

/m-02+82pts
87%automation coverage

Share of daily shipments that move through the pipeline with zero human touch.

/m-03incl. staffing
−64%cost per shipment

Net cost per shipment including planner time, peak-season temp labour, and platform fees.

/m-04from 3.4%
0.11%exception rate

Shipments that require a human intervention to complete, as a share of all shipments.

/system-insight
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.
/keep-reading

Adjacent systems.

CS-02E-commerce Systems

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.

3.2M ops / yrView 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.