Chapter 5
How to operate and measure logistics notifications: the metrics that matter, what detention and missed alerts cost, a maturity model, and how to decide whether to build or buy.

Last updated: July 2026
Building the system is half the job. Running it and justifying it is the other half: what to measure, what getting it wrong costs, and whether to build or buy at all.
For operational notifications, open and delivery rates are the wrong headline metric. They tell you the plumbing works, not whether the system is doing its job. Track these instead:
The through-line is that these measure whether the right person acted, not whether a server sent bytes.
The clearest cost data in trucking is detention, the time a driver waits at a shipper or receiver beyond the agreed window, and it's a good proxy for what poor visibility and late notifications cost the whole chain. The American Transportation Research Institute's 2024 research, on 2023 data, found drivers were detained on 39.3% of their stops, adding up to 135 million lost hours. ATRI put the cost at $11.5 billion in lost productivity plus $3.6 billion in direct expenses. And while 94.5% of fleets charge detention fees, they collect on fewer than half the invoices.
To put a unit on those hours: ATRI's 2024 operational cost analysis pegs the cost of running a truck at $90.89 an hour. Idle time at a dock is burning roughly that, before a single detention fee is argued over. A notification that lets a dispatcher or a warehouse act 30 minutes sooner isn't a nicety, it's about $45 a truck, every time, at scale.
The most striking finding is a safety one: trucks that were detained drove, on average, 14.6% faster than trucks that weren't. Drivers who lose hours waiting make them up on the road. That reframes notification timing as more than a cost lever. A dwell alert that lets a dispatcher intervene before detention runs long, or an early heads-up that lets a warehouse clear a dock, isn't just saving fees, it's taking pressure off a driver who would otherwise be speeding to recover. Getting notifications right is, at the margin, a road-safety intervention.
Most teams move through the same stages. Knowing where you are helps you pick the next investment rather than boiling the ocean.
| Stage | What it looks like | The limitation |
|---|---|---|
| 1. Manual | Dispatchers make check calls and send texts by hand | Doesn't scale; nothing is logged |
| 2. Single-channel automation | Automated email or SMS on a few events, one recipient type | No fan-out, no digests, quickly noisy |
| 3. Multi-channel, multi-audience | Events fan out to the right roles on the right channels | Often still hard-coded; brittle to change |
| 4. Preference- and severity-aware | Recipients tune their own signal; digests and tiers in place | Usually single-tenant |
| 5. Multi-tenant and observable | Per-customer branding and scoping, escalation, full delivery visibility | The target for a platform |
The jumps that pay off most are stage 2 to 3 (fan-out, which kills the manual check calls) and stage 4 to 5 (multi-tenancy, which is what lets a platform serve customers without a data-leak risk or a per-customer code fork).
You can build all of this yourself, and for some teams that's the right call, usually when notifications are core to the product's differentiation or requirements are unusual enough that no platform fits.
Be clear-eyed about what building means, though. You're taking on:
That's a standing system with its own on-call, not a one-time build. Most teams find that the notification layer isn't where they want their differentiation, and that the months spent building it are months not spent on routing, pricing, or whatever actually makes their product worth buying. The honest version of build-vs-buy is: build the parts that are your edge, buy the parts that are everyone's table stakes, and notification infrastructure is almost always the latter.
By now the shape of the problem is clear. One freight event fans out to a driver, a dispatcher, a shipper, a warehouse, and a customer, each needing different content on a different channel with different urgency. The driver can't be texted while driving and is only reachable around their HOS clock. The shipper wants a digest, not a firehose. The cold chain alert has to escalate until someone answers. And every customer you send on behalf of needs its own branding and its own walled-off data.
Courier is built for exactly this, and the way its pieces map to the problem is the reason it fits logistics so cleanly:
That's not a coincidence of features. Tenants plus Inbox plus preferences is the exact combination the logistics companies already building on Courier reach for most, because it's the combination the fan-out problem demands. You bring the events. Courier handles the fan-out.
For operational notifications, track acknowledgment rate and time to acknowledge (did the right person see it and act), escalation rate (was the first recipient the right one), opt-out or mute rate by role (the fatigue signal), and exceptions resolved before they became claims (the business outcome). Delivery and open rates confirm the plumbing works but don't tell you the system is effective.
Build if notifications are core to your differentiation or your requirements are genuinely unusual. Otherwise, buying is usually faster and cheaper once you account for everything a real system needs: multi-channel providers, preferences, template versioning, retries, per-tenant branding, digests, escalation, and observability, all with their own ongoing maintenance.
It varies by tier and organization, so the useful move is to baseline your own and watch the trend. For critical alerts, you want acknowledgment approaching 100% within your escalation window; a low or slow rate means the alert isn't reaching the right person on the right channel.
Ready to ship logistics notifications? Talk to a solutions expert or get started for free.
Related resources:
© 2026 Courier. All rights reserved.