The three things load-shedding actually breaks
Talk to ten couriers about load-shedding and you will hear thirty problems. Underneath, almost all of them collapse into three.
Power at the dispatcher's desk. Dispatchers cannot plan, print, or chase exceptions if their workstations and printers are down. UPS units carry them for an hour. Stage 6 wipes that out by lunchtime.
Connectivity between dispatcher and driver. Even if the dispatcher has power on a laptop, fibre and LTE coverage at the depot can drop. The driver in Centurion can have signal while the dispatcher in Roodepoort cannot.
Customer trust. The shipper checking their tracking link sees a blank. The recipient who paid for next-day sees nothing. The courier brand absorbs the cost of “load-shedding” in customer perception even when the parcel is genuinely on its way.
What “resilient” really means in courier operations
Resilience here is not about generators. Generators help. They do not change the architecture.
Resilience is three things.
The dispatcher can keep working from a phone, a tablet, or a different building when the main desk goes dark. The dispatch surface has to be web-first, mobile-friendly, and not stuck on a single Windows machine in the depot.
The driver app holds enough state to keep working with no signal. Routes already on the phone, proof-of-delivery captured locally, status changes queued for later sync. When connectivity returns, everything reconciles.
The customer-facing tracking page survives the gap. Cached aggressively. Refreshed by the courier's webhooks the moment events flow again. No spinning loaders, no stale “preparing” status that lingers for hours.
A short checklist for stage-6 days
If your goal is to keep deliveries moving through a four-hour cut, audit:
- Where the dispatcher works from when the depot is dark. Real answer, not “they have a UPS”.
- Whether a driver can complete a full delivery cycle (arrive, capture POD, mark complete) with no signal at all. Test it physically. Most apps cannot.
- What the customer sees when the courier's status webhook is queued and not flowing. A frozen “in transit” is a customer-service problem, not a tech problem.
- Where the printers live. Printers are quiet single points of failure. A label that cannot print is a parcel that cannot ship.
- Who can pick up the dispatcher role from a phone if the main person loses connection. Cross-training matters more than redundant hardware.
What CouriB tries to handle automatically
The product targets the architectural side of resilience, not the generator side.
Dispatch is web-first and works on a phone in a pinch, so the dispatcher is not pinned to one workstation. Delivery records, parcel context, driver assignments, and the calendar all live on the same record, so a colleague can take over dispatch from a different device.
The driver app on Android and iOS is being built around offline-first capture: route on the phone, proof of delivery local, status events queued and synced when signal returns. The driver-app features page is the right next read on this side, and the broader operating-context framing is on the features overview page.
CouriB does not promise zero downtime. CouriB promises that the architecture takes load-shedding seriously, and that the FAQ is honest about what is and is not handled today. Honest scope matters more than a “100% uptime” badge a vendor might paste on a pricing page.