HOS Trip Planning
Dispatcher HOS Planning Guide
How dispatchers can build load plans around realistic HOS limits rather than theoretical maximums, and why fragile schedules create downstream driver problems.
By Dale Connors, Founding Editor · Content reviewed quarterly against FMCSA guidance and official state resources. A fragile load plan — one that only works when every stop is fast, every dock is open, and every road is clear — is not a plan. It is a list of things that need to go right.
The dispatcher's job is to build the margin into the plan before the driver accepts the load, not to ask the driver to find the margin after the trip has started.
The dispatcher's planning decisions have a direct and measurable effect on driver outcomes. A plan built around theoretical maximum hours creates a driver who is forced into safety decisions — improvised parking, skipped breaks, rushed dock procedures — that the dispatcher never had to experience but entirely caused.
The most useful shift in dispatcher planning is treating driver available hours as a starting budget that decreases with every planned event, rather than a ceiling that the load should fill completely. The 14-hour clock runs continuously from the moment on-duty time begins — including loading, fueling, and waiting — which is why plans built only around driving miles regularly fail late in the day.
A dispatcher who has built a load plan around realistic hours — not theoretical maximums — can tell a driver exactly what to do when something goes wrong: update the customer, confirm the new stop, and rebuild the remaining plan. A dispatcher who built around theoretical maximums has nothing to offer the driver at that moment except pressure. For a printable reference, see the dispatcher trip planning checklist.
Fragile dispatch plan vs. realistic dispatch plan
| Factor | Fragile plan | Realistic plan |
|---|---|---|
| Hours basis | Theoretical 11-hour driving maximum used as the mileage target | Confirmed available hours minus realistic time for every known on-duty event |
| On-duty events accounted for | Driving miles only — loading, fueling, scales, breaks treated as zero-time events | Loading, fueling, break, scale stop, parking search each assigned a realistic time estimate |
| Detention treatment | Not included — assumed everything will be fast | Built-in buffer for expected wait time; communication trigger defined for when detention exceeds buffer |
| Parking plan | Driver expected to find parking at the end of the trip | Named primary and backup stop identified before dispatch, with trigger time for switching to backup |
| When something goes wrong | Dispatcher has no recovery option — driver is already at the limit | Dispatcher has a pre-built response: updated customer ETA, confirmed alternative stop, rebuilt plan for the next segment |
| Driver experience | Pressure, improvised decisions, fatigue-driven choices late in the day | Known plan, clear communication points, protected margin for unexpected events |
Where dispatcher decisions create driver problems
When a dispatcher builds a plan using the theoretical 11-hour driving limit as the mileage target, the driver has no buffer for loading time, traffic, fuel, a scale stop, or finding a parking space at the end of the day. Those activities do not stop the 14-hour clock. They just reduce the margin until the driver is forced to make a safety decision that should have been a planning decision.
The downstream effects of fragile planning are not always visible to dispatch: the driver who parks on a ramp because the lot was full, the driver who skips the scale stop hoping the bypass works, the driver who pushes through fatigue to make an appointment that was never realistic. These outcomes look like driver errors. They are often dispatcher planning failures.
What the plan should include before dispatch
- Check current available hours — confirmed with the driver and the ELD, not estimated from a reset time.
- Add realistic time for loading, unloading, detention, fuel, scales, breaks, and parking search.
- Name a safe parking decision point in the plan before dispatch.
- Confirm the driver can reach a legal stop after delivery given the planned on-duty activity.
- Identify the point where the plan diverges from realistic hours — and set that as the communication trigger.
- Confirm customer staging and receiver parking rules before the driver enters the delivery market.
- Set the detention trigger — the amount of time beyond planned dock time that triggers an immediate plan update and customer notification.
- Confirm the driver has the dispatcher's contact information and a clear protocol for reporting plan deviations, not just delivery confirmations.
Common planning mistake
The common mistake is confirming available hours with the driver at dispatch and then building appointments that use every hour on paper. Available hours are not driving hours — they include every minute the driver is on duty.
A second common mistake is not updating the customer when the plan is already unrealistic at dispatch. A load that fits on paper but not in practice creates a problem at delivery that could have been managed at dispatch.
Driver / dispatcher / owner-operator angle
- Driver: report real available hours, not the theoretical maximum, before accepting a load with a tight appointment.
- Dispatcher: add realistic time for loading, check-in, fuel, scales, breaks, and parking to the available hours before confirming an ETA.
- Owner-operator: a load that fits on paper but not in practice will create a problem. The dispatcher and driver need to agree before the truck moves.
What to check before relying on this
- Driver's actual available hours at the start of the trip — confirmed, not estimated.
- Estimated on-duty time for every known stop, including loading, check-in, fuel, scales, and parking search.
- Whether the delivery appointment is achievable with a practical buffer, or only achievable if nothing delays the trip.
- The parking option after delivery if the delivery runs late.
- Whether the customer has been informed if the appointment is already tight at dispatch.
Backup plan
Identify the point in the trip where the dispatch plan and the driver's actual clock diverge. That is the communication trigger — the dispatcher updates the customer, the driver confirms the new stop, and the plan is rebuilt before options run out.
How should a dispatcher calculate whether a load fits a driver's available hours?
Start with the driver's actual confirmed available hours — not the theoretical maximum from a full reset. Subtract realistic time for every known on-duty event: loading or pickup process, transit at a realistic average speed, break, fuel, any expected scale stop, delivery check-in and unloading, and a parking search at the end. If the sum exceeds available hours, the load does not fit. A load that only works under best-case conditions for every event is a load that will regularly fail.
What is the dispatcher's responsibility when a driver runs out of hours before completing a delivery?
When a driver's hours are exhausted before delivery, the driver must stop at the nearest safe, legal parking location and go off duty. The dispatcher's responsibility at that point is to update the customer with a realistic new ETA, ensure the driver has a confirmed overnight stop, and rebuild the plan for the next day. The dispatcher who contributed to the hours shortage by building an unrealistic plan also carries responsibility for the outcome — the correct time to address this is at dispatch, not after the driver is stranded.
How should a dispatcher handle detention time in an HOS plan?
Detention time should be treated as a plan-changing event the moment it exceeds the buffer built into the schedule. When detention consumes more than 60–90 minutes beyond the planned dock time, the dispatcher should immediately recalculate the driver's remaining available hours, identify a revised parking stop, and update the next-day appointment if needed. Waiting until the driver reports a problem at end of day converts a manageable scheduling issue into a safety and compliance problem.