Planned vs Actual: The Weekly Route Review That Changes Next Week

A route plan only becomes useful when somebody checks it against what actually happened. Without that loop, an understated service time stays understated, an awkward delivery window stays in the wrong place, and the same route keeps finishing later than the office expects.

A planned vs actual review is not a post-mortem on the driver. It is a way to improve the inputs that create the next plan. The practical question is simple: where did execution differ from the assumptions, and which assumptions should change before the route is planned again?

If the review ends with a fleet or service-frequency decision, add the full cost-per-drop view before changing capacity. Planned-vs-actual tells you where the route differs; cost-per-drop tells you what that difference costs.

Bring four comparisons to the weekly review

Do not begin with every metric in the system. Start with the parts of the plan that can actually be corrected. Four comparisons give an operations manager a practical starting point for deciding what to investigate.

A single unusual day can be just that. The review becomes valuable when the same type of gap repeats or when the explanation points to a record that is plainly wrong. The output is not a score. The output is a set of edits.

Explain the gap before editing the route

Route performance can quickly become personal because the driver is a highly visible part of the day. That is a poor starting point for a planning review. Before drawing conclusions about individual performance, check whether the plan gave the driver a credible day in the first place.

Ask the operational questions first. Was the correct delivery window recorded? Was the service-time assumption realistic? Did the route change after the plan was built? Was a stop added late? Was the vehicle suitable for the work? Was the route carrying a recurring access issue that belongs in the delivery-point record?

Drivers still have an important role in the review. They often know why a gap exists. The useful contribution is evidence: the customer changed its receiving point; the market blocks the road on a particular morning; unloading now requires a sign-in process. Once that information becomes a shared record, it stops being an explanation that has to be rediscovered every week.

It is tempting to respond to a late finish by moving several stops at once. That can hide the original problem. A better method is to find the small number of stops that create the largest repeated differences.

The same applies to delivery windows. If the plan repeatedly reaches one customer before they can receive, moving that stop may remove waiting. If five stops all miss because the day is overloaded, the route-level problem is different. Planned vs actual comparison helps separate the local correction from the wider capacity decision.

Record one change and give it a re-test

A review loses value if the team cannot tell whether last week’s correction was actually made. Keep a short change log beside the route review. It needs only the route or stop, the evidence, the change, the owner and the date it should appear in planning.

This prevents a familiar failure: the meeting correctly identifies that a delivery window is wrong, everybody agrees, and the old window is still in the system the following week.

A planning change is not complete when somebody edits the record. Decide what you expect to see on the next comparable run. If a service time is increased because the customer consistently needs a longer unload, the next plan should reflect that time and the route finish should move accordingly. If a stop is moved later because of its receiving window, check whether the next arrival lands inside the window without creating a new problem elsewhere.

Keep the test modest. You are not trying to prove that one edit caused every improvement on the route. You are checking whether the corrected input behaved more credibly than the old one. Over time, that creates a planning discipline in which changes have evidence behind them and can be reversed when they do not help.

Know whether the problem is data or route capacity

Not every late route can be repaired by changing one stop. Sometimes the plan is broadly accurate at stop level and the route is simply carrying more work than the available day can absorb. The review needs to distinguish those two situations because the remedies are different.

Start by asking whether the variance is concentrated. If two or three stops account for a large share of the difference, investigate their windows, service times, access notes and sequence. If the delay is spread across the whole day, look at route-level assumptions: total stop count, order volume, vehicle suitability, breaks, late additions and any capacity constraints the planner is expected to respect. A depot can waste weeks adjusting individual stops when the real decision is whether the round itself needs to be split, rebalanced or scheduled differently.

The opposite mistake is just as common: treating one awkward stop as evidence that the whole route is overloaded. Keep the review granular enough to see where the time is actually being lost. Route-level changes should be supported by route-level evidence; stop-level changes should be supported by repeated stop-level evidence.

The RouteMagic records to bring into the room

RouteMagic separates the planning view from the execution evidence you need to review it. The Route Planner assigns confirmed orders to vehicles and drivers, sequences stops and checks ETAs against delivery windows. Route Monitor provides the live picture during the day, while Route History provides the after-the-fact view for performance review.

Delivery points can hold their own delivery windows and settings, and geofencing can record arrival and departure events where configured. Skipped and failed visits can be recorded with reasons. Those records give the operations team something concrete to compare with the plan rather than relying on the end-of-day explanation alone.

Route optimisation can also respect time windows, vehicle skills and configured weight/volume capacity constraints. The important point for a planned-vs-actual review is not that optimisation removes the need for judgement. It is that better underlying records give the next planning cycle better constraints to work with.

Conclusion

A planned route is a hypothesis about how the day will run. The weekly review is where that hypothesis meets evidence. Compare arrival with delivery windows, actual stop time with planned service time, route duration with plan, and the exceptions that changed the day. Then follow the meaningful gaps back to the record that should change. Some weeks the right answer will be “no change”; other weeks one corrected delivery window or service-time assumption will materially change the shape of the next plan. Keep the review focused on inputs before people, write down the changes, and look for evidence on the next run. The goal is not a perfect historical report. It is a planning system that learns from its own operation instead of carrying last month’s assumptions indefinitely.