Several exceptions are predictive, not reactive. Pre-Pickup Update Needed fires when there has been no update since a fixed number of hours before the appointment, even if the truck is moving. ETA After Delivery fires the moment the projected arrival is past the appointment. The load has not failed yet; the exception is the early warning that it will unless someone acts.
Why did this exception fire, or why hasn't it cleared?
Updated today
An exception appears when a threshold on the load's service level is crossed and clears when the condition behind it is no longer true. Most "why is this red" questions come down to which tier the load matched, which threshold it crossed, and whether the load was managed rather than resolved. Match your question below; the Exception reference defines each exception in full.
Why is this load flagged when nothing is wrong yet?
Why is a managed load still showing as managed days later?
Managing an issue sets a follow-up time, and the load returns to the board when that time is due. An issue that was managed with a far-off time, or one that has been escalated, stays managed until it is solved or the time arrives. If a load has read Managed for three days, open its Issue History tab to see who set the follow-up and for when. Managed is not resolved; the underlying condition still exists.
Why is a truck that arrived late not showing Detention Risk?
By design. Detention Risk counts only dwell the carrier can bill for, so a driver who arrived after the appointment window is excluded from it. The Dwell Risk tab includes late arrivals; use it when the question is "who has been sitting", and Detention Risk when the question is "what can we bill". At Pickup Too Long and At Delivery Too Long flag long dwell regardless of arrival time.
When does Detention Risk start?
At the detention threshold on the load's service level, measured from the recorded arrival. The default is two hours; your admin can set it per tier in Configure Tracking Service Levels. A load with no arrival recorded cannot accrue detention, which is why recording stop arrivals matters for billing.
Why did this load get a different threshold from that one?
Each load matches one service level, decided by a rule on the load's fields, such as customer name or equipment, evaluated in priority order. A Reefer tier and a Drop Trailer tier can have different late and dwell thresholds on purpose. If a load landed in the wrong tier, the fix is the tier's match rule, not the exception. Tracking Service Levels explains matching.
Why didn't the exception fire at all?
Three usual causes, in order. The exception is switched off on the load's service level tier; every exception starts off on a new tier. The load's appointment data is missing, since time-based exceptions measure from the appointment. Or the load matched a different tier than you expected, one where that exception is off.
I fixed the problem, so why is the load still red?
Exceptions clear on the next board refresh after the condition changes, and boards refresh on a schedule rather than instantly. Select Refresh Table & Big Number Data above the board. If it is still red, the condition is still true: check that your update reached the TMS on the load's Update History tab, since TrackFlo only records the update after the TMS confirms it.
Related
Was this helpful?
Was this helpful?