Communicating Delay Upward
A three-hour wait costs the detention rate. A three-hour wait that nobody downstream learns about until the delivery is missed costs the delivery, the next load, and the customer's confidence. For a workforce-operations comparison point, this overview.
Most of the damage from dwell is not the dwell. It is the delay in the information about it, and that is fixable without anyone changing how the dock runs. For additional freight-operations context, see Association of American Railroads.
The three messages
Each has a different recipient and a different purpose. Sending one and not the others is the common failure.
At free-time expiry, to the facility. We are at two hours; detention begins now. Purpose: give them a chance to fix it, and create the record the claim will need. Sometimes it produces a door.
At the point of no return, to dispatch or planning. At this rate the driver cannot make the 16:00 delivery. Purpose: let somebody reroute, reschedule or repower while options still exist. This is the message with the highest value and the one most often skipped, because it feels like admitting failure while there is still hope.
And at the moment it becomes certain, to the customer. We will not make today; here is the revised plan. Purpose: their downstream decisions.
Why the middle one is skipped
Worth naming, because it is a human problem rather than a process one.
Hope. The driver expects to be loaded in twenty minutes, every twenty minutes, for three hours. Each individual estimate is reasonable.
And the cost of the message feels immediate while the cost of silence is deferred. Telling dispatch at hour two produces a conversation now. Telling them at hour four produces a bigger conversation later, and the later one is always someone else's problem in the moment.
The fix is to make it a trigger, not a judgement. At free-time expiry, message dispatch. Always. A rule survives; a decision under pressure does not.
Making the messages useful
Include the arithmetic. Gate in 14:02, still not at a door, 3h 40m remaining on the window. Somebody planning needs the remaining hours more than they need your estimate of when loading will start.
State what you need, not just what happened. Can we move the 16:00, or should I look for a repower?
And send it through something that timestamps. The same message serves as the record for a claim, so a channel that logs send time does two jobs.
The escalation rule worth writing down
Most operations have none, and improvise per incident.
At free-time expiry: message the facility and dispatch.
At free time plus one hour: dispatch decides whether the day's plan still holds, and tells the customer if it does not.
At the point where the 14-hour window will not permit the delivery: the load is rescheduled. Not hoped about.
Three lines, and they convert a recurring judgement call into something anyone on the desk can execute.
What to tell the customer, and when
Early and approximate beats late and precise.
A customer told at 15:00 that today is at risk can act. One told at 18:00 that it failed cannot. The first conversation is about options and the second is about blame, and the information content is nearly identical.
And say what is controllable. If the constraint is the receiving facility's hours or appointment availability, that is worth naming — not to deflect, but because the customer may hold the lever you do not.
The measurement worth adding
Time from delay onset to first notification. One field in your log.
If that number is two hours, most of your dwell cost is avoidable without touching a dock. If it is fifteen minutes, your losses really are the waiting, and the fix is upstream at the facility.
Very few operations know this number, and it distinguishes two entirely different problems.
The short version
- Most of the damage from dwell is the delay in information about it, not the waiting
- Three messages: facility at free-time expiry, dispatch at the point of no return, customer when it is certain
- The middle one is most valuable and most often skipped, because hope renews every twenty minutes
- Make it a trigger rather than a judgement — a rule survives pressure and a decision does not
- Include remaining hours rather than an estimate of when loading will start, and send it through something that timestamps
- Measure time from delay onset to first notification; it separates an information problem from a facility problem