Courier ↔ Warehouse

one process, two systems.

The loading bay is not a good middleware layer. Couriers should subscribe to warehouse state.

Problem

Pickers finish. Packers finish. Then someone becomes the integration: booking collections, printing labels, WhatsApping drivers, updating the shop.

System

Warehouse events — packed, ready, held, collected — drive courier consignments and return tracking into the order record. Exceptions (failed collection, short ship) have an owner.

Outcome

Dispatch is a process, not a scramble. Tracking is available to staff, to Bud, and to the customer without a treasure hunt.

Courier ↔ warehouse is the general form of the DPD problem. It also covers mixed fleets, own vehicles, and “the driver who just turns up”.

We map how you actually release work to the door: cut-off times, cage locations, who is allowed to book a collection, what happens when a SKU is short.

Then we connect the courier tools you already pay for, instead of adding another portal that operations will ignore.

Questions about this system

Can this include customer tracking emails?

Yes, when that is in scope. The important part is that the notification fires from warehouse/courier state, not from a person remembering to send it.

What if we use more than one courier?

Routing rules are part of process design — weight, service, destination, customer promise. The warehouse remains the authority for “ready”.

We build systems that power growth.

AI agents, integrations and operational software—built around your business.