Planned vs actual routes: why the gap is valuable data

What does the gap between planned and actual routes show?#

The gap between planned and actual routes shows where reality overruled the optimizer. Route planning software builds a sequence of stops with time windows and estimated drive times; the driver app and telematics record what happened. Every difference between the two is either noise or a decision.

Fleet managers usually look at the gap as a single KPI, route adherence, and stop there. That number hides the interesting part. Behind each deviation is a reason, such as a customer who was not ready, a dock that was full, a rush order added at noon or a driver who knew a faster sequence.

Those reasons are what AI developers want. A model that plans routes well on paper still has to learn how plans fail and how experienced dispatchers repair them.

Gap types and the reasons behind them#

Gap types fall into a short list, and each leaves a different trace in the records. The table pairs each type with the evidence and the reasons that usually explain it.

Keeping the gap type and the reason as separate fields matters. The same resequenced stop can come from traffic, a customer call or a driver's local knowledge, and a model needs to tell them apart.

Why plan plus actual plus reason is a decision record#

Plan plus actual plus reason is a decision record because it captures an intention, an outcome and the explanation for the difference. That is the same shape as a support ticket with a resolution or a purchase request with an approval, and it is the shape AI developers look for in operational data.

Each layer alone is weak. A plan with no actuals is a forecast. Actuals with no plan are a trail. Both without a reason show that something changed but not why. Linked, they let a model learn to predict which plans will break and to propose repairs a dispatcher would accept.

AI developers use these records to test re-planning agents, to train arrival-time models that explain their predictions, and to evaluate whether a proposed route change matches what a seasoned dispatcher actually did. Each use depends on the reason layer being present for a meaningful share of changes.

• 1Plan layer: route ID, date, vehicle, driver role, planned stop sequence, time windows, planned arrival times, load summary.
• 2Actual layer: stop arrival and departure events, delivery status, proof of delivery, odometer or distance, telematics stop events.
• 3Reason layer: driver app exception codes, dispatcher notes, customer service tickets, reattempt and return records.

Where each layer lives, and the plan snapshot problem#

Each layer usually lives in a different system. Plans sit in a route planning tool such as Roadnet or Descartes, or in a TMS planning module. Actuals come from the driver app and from telematics platforms such as Samsara. Reasons are scattered across driver app codes, dispatch notes in the TMS and customer service tickets.

The most common problem is that the plan is not preserved. When dispatch edits a route during the day, some planning setups overwrite the original sequence, so the record shows only the final plan, which already matches the actuals. Saving a frozen snapshot of each morning plan is a cheap change that makes future history far more useful.

Telematics retention is the other risk. Many platforms keep detailed location history only for a period set by plan or configuration, so check the vendor documentation and export history before a contract change or a fleet system migration.

Driver privacy and customer details#

Driver privacy is the main preparation issue for route data. Location trails, stop timestamps and harsh-driving events describe identifiable people at work, and some state privacy laws treat precise geolocation as sensitive personal information. Which laws may apply, and what notice employees received, is assessed deal by deal with counsel. Collective bargaining agreements sometimes address telematics use as well.

Customer locations need care too. Commercial delivery addresses are usually less sensitive than residential ones, but both can identify customers. A common approach is to replace drivers and customers with stable pseudonyms, coarsen locations to a zone or grid cell, and keep times relative to the route start rather than exact clock times where the use allows.

Routes that mix commercial and home deliveries may be split, with residential stops excluded or reduced to stop events without addresses.

Illustrative: a janitorial supplies distributor reviews its route history#

Illustrative: a fictional janitorial and paper supplies distributor runs its own box trucks from two warehouses to schools, offices and property managers. Routes are planned each evening in a route planning tool, drivers use a handheld app for stop events and proof of delivery, and dispatchers log changes in a notes field.

The COO learns that the planning tool overwrites routes during the day, so only final plans survive. The team keeps the history it has for stop events and reasons, starts saving nightly plan snapshots, and scopes a future package around the period with frozen plans. Stops at residential addresses are excluded.

The decision costs little and changes the archive from a record of where trucks went into a record of how dispatch handled every disruption.

How SourceX approaches route records#

Route records go through the SourceX five-step transaction of Supply, Rights, Preparation, Approval and Delivery, and for this record type Preparation carries most of the weight, because locations must be coarsened and drivers pseudonymized. No files are shared during the initial fit check.

Under the SourceX Enterprise Data Value Framework, plan-versus-actual records tend to rate well on human-generated signal, recency, scale and AI utility when reasons are captured, while privacy burden from driver location data and the preparation cost of joining systems reduce net value. The SourceX Evidence Packet documents what was removed and who authorized release.