The Constraints That Change the Design

Last updated: July 2026

Logistics notifications carry constraints that ordinary product notifications don't, and most of them aren't optional. This chapter covers the ones that actually change how you build: a federal rule about texting drivers, the hours-of-service clock that governs when a driver is even reachable, consent law when your recipient is also your employee, the alert fatigue that makes ops teams stop reading, driver language, and connectivity.

3.1 Why you can't notify a driver who's driving

Start here, because it's the constraint most notification systems get wrong. In the United States, federal rule 49 CFR 392.80 prohibits texting while driving a commercial motor vehicle, and it prohibits motor carriers from allowing or requiring it. The catch is in the definition: "driving" means operating the vehicle with the motor running, "including while temporarily stationary because of traffic, a traffic control device, or other momentary delays." Sitting at a red light is still driving. The rule only stops applying once the driver has moved the vehicle off the road and stopped somewhere safe.

The penalties aren't trivial. A driver can be fined up to $2,750, and a carrier that allowed or required the texting can be fined up to $11,000, both as adjusted for inflation. Repeat convictions disqualify a driver from operating a commercial vehicle for 60 days on a second offense within three years, and 120 days on a third. There's a narrow exception for communicating with law enforcement or emergency services. And distraction isn't a fringe worry in this industry: it lands in the top 10 concerns in ATRI's annual Top Industry Issues survey, so how you time and channel driver notifications is either part of that problem or part of the fix.

Here's the part almost no notification system accounts for: a commercial driver is not an ordinary app user, and their duty status belongs in your notification logic. If you're building for drivers, treat driving state the way you'd treat quiet hours, except the quiet period is defined by the vehicle, not the clock. (In Courier, that's preferences and quiet hours, so the gate lives in configuration rather than scattered through every send.) Concretely:

• Gate non-urgent driver notifications on ELD duty status.
• Hold them until the driver is on-duty-not-driving, then release.
• Batch what accumulated into a single digest at the next stop, rather than a burst of pings.
• Reserve truly urgent, safety-relevant information for hands-free or in-cab voice channels designed for it.

The design goal is that a driver never receives a notification that tempts them to interact with a phone while the truck is moving. That's better for safety, and it keeps both the driver and your customer's carrier on the right side of the rule.

3.2 Hours of service: timing notifications around the driver's clock

Driving state is the hard legal line. Hours of service is the softer, but just as real, timing constraint layered on top of it. Federal HOS rules give a property-carrying driver an 11-hour driving limit within a 14-hour on-duty window, after 10 consecutive hours off duty, with a required 30-minute break and a weekly cap of 60 hours in 7 days or 70 in 8, resettable with a 34-hour restart.

Why a notification system should care: the driver's clock tells you when they're reachable and when a message is useful versus counterproductive. A few implications:

• The natural, safe delivery windows for non-urgent driver notifications are the required breaks and the off-duty period, which the ELD already tracks. That's when a driver can actually read and act.
• Some of your most valuable driver notifications are about the clock itself: a heads-up that a driver is approaching the 14-hour window, or won't have the hours to make a delivery appointment, is exactly the kind of proactive alert that prevents a violation or a missed appointment.
• Sending a driver a load offer they can't legally complete on their remaining hours is worse than not sending it. If you have the duty-status data, use it to filter offers, not just to time them.

The point is that the ELD feed isn't only a compliance record, it's the signal that tells your notification system when a driver is a person who can respond and when they're a person who shouldn't be touched.

3.3 Consent and A2P 10DLC when your recipient is also your driver

If you send SMS to US phone numbers, you're subject to A2P 10DLC rules, and as of February 1, 2025, the major carriers (AT&T, T-Mobile, and Verizon) block unregistered application-to-person traffic outright rather than throttling it. Unregistered means undelivered. So step one is registering your brand and campaigns through The Campaign Registry, providing clear opt-in, and honoring opt-out keywords like STOP.

The interesting wrinkle in logistics is a consent question the general guides don't touch. The same phone number often belongs to someone who is, at different moments, your employee and your marketplace participant. A dispatch instruction to a driver you employ ("proceed to dock 4") is a very different thing, legally and practically, from a load offer pushed to a driver on your marketplace ("new load available on your lane"), which looks a lot more like solicitation. The first is operational and expected; the second edges toward marketing-consent territory.

The honest answer is that the line isn't always crisp, and it depends on the relationship and how the message reads. The practical move is to model consent per message category rather than per phone number:

• Track separately whether a person has consented to operational messages, to load or marketing offers, and to any other category you send.
• Register distinct 10DLC campaigns for distinct message types, because carriers evaluate traffic by campaign.
• Gate each send on the right category's consent, and keep operational instructions clearly operational.

When in doubt, get explicit opt-in for the offer-style traffic, and don't let a load-matching campaign ride on consent that was only ever given for dispatch. A preference system that models these as separate, per-user, per-category subscriptions is what keeps this manageable as you scale.

3.4 Alert fatigue: why ops teams stop reading

Early supply chain control towers had a predictable failure: they flagged every minor delay as an incident, and teams quickly lost the ability to tell signal from noise. When everything is an alert, nothing is, and the critical warning gets buried in the chatter.

The fix isn't better wording, it's structure. Three pieces:

• Severity tiers. Not every event deserves the same delivery behavior. A tier-one event (accident, temperature excursion, a load about to miss a hard appointment) goes out immediately. A tier-two event gets batched. A tier-three event only shows up in a digest or a dashboard.
• An actionability test. The same event can matter enormously or not at all depending on context. A shipment delay is meaningless if there's buffer inventory at the destination, and critical if it stops a production line or misses a store's receiving window. Run events through a test of "can and should someone act on this right now," and route anything that fails it to a digest instead of a live notification.
• Per-user thresholds. One dispatcher covers reefer loads and cares about every degree of temperature drift; another covers dry van and doesn't. Let each person set their own thresholds so the system earns their trust instead of training them to ignore it.

The goal is that when a notification does reach a dispatcher, it's earned their attention. This is a preferences-and-digest problem more than a content problem, and it's the single biggest driver of whether an operational notification system gets used or muted. (Batching and throttling are the mechanics behind it.)

3.5 Language and locale for driver-facing notifications

Driver-facing notifications frequently need to reach people whose working language isn't English, and this is especially true on cross-border lanes and in major freight hubs. If your notifications only work in English, a meaningful share of the drivers you're trying to reach won't fully get the message, which is both an operational problem and a safety one.

Handle it as a design requirement, not an afterthought:

• Treat locale as an attribute on the recipient's profile, set once and respected everywhere, rather than a decision made per send.
• Localize at the template level, so a single notification definition renders in the right language instead of branching in code for every message.
• Define fallback behavior for when a translation is missing, so a driver gets an understandable message rather than a blank screen or a broken variable.

Getting this right at the infrastructure layer, once, is far cheaper than discovering per-message that half your driver base can't read your alerts.

3.6 Designing for dead zones

Drivers drive through places with no signal. That single fact rules out fire-and-forget push as your only mechanism, because a push sent into a dead zone can vanish without a trace. Design for intermittent connectivity:

• Use retry policies so a transient failure gets another attempt rather than being dropped.
• Configure channel fallback, so a notification that can't land on one channel tries another.
• Back time-sensitive driver notifications with an in-app inbox that syncs when the device reconnects, so the message is waiting rather than lost.

This is the same push-plus-in-app-plus-SMS stack from 2.1: push and in-app for immediacy, SMS as backup for reach, and the inbox as the durable record that survives the gap. Courier's Inbox syncs on reconnect and its channel fallback (push, then SMS) covers the rest. The test is simple: if a driver spends two hours in a dead zone and comes out the other side, everything they needed to know should be there when they reconnect, in the right order, without duplicates.

Frequently asked questions

Can you text a truck driver while they're driving?

No. Federal rule 49 CFR 392.80 prohibits texting while driving a commercial motor vehicle, and "driving" includes being temporarily stopped in traffic or at a light. Carriers can't allow or require it either. Design driver notifications to hold non-urgent messages until the driver is stopped.

How do hours-of-service rules affect driver notifications?

The driver's HOS clock tells you when they're reachable (during breaks and off-duty time the ELD already tracks) and lets you send genuinely useful proactive alerts, like a warning that a driver is running out of hours to make an appointment. It also means you shouldn't offer a load a driver can't legally complete on their remaining hours.

Do logistics companies need 10DLC registration for driver texts?

Yes, if you send SMS to US numbers from a standard 10-digit long code. Since February 1, 2025, US carriers block unregistered A2P traffic outright. Register your brand and campaigns, collect opt-in, honor opt-out keywords, and register operational and offer-style traffic as separate campaigns.

How do you stop alert fatigue in a dispatch team?

Tier events by severity so only the most urgent trigger an immediate notification, run everything through an actionability test, and let each user set their own thresholds. Anything that fails the test goes to a digest or dashboard instead of a live alert.

What happens to notifications when a driver has no signal?

Without the right design, they can be lost. Use retry policies, channel fallback, and an in-app inbox that syncs on reconnect so time-sensitive messages are waiting for the driver when they're back in coverage.