Dashboards are not visibility

A control tower screen showing ninety-eight per cent on-time delivery tells a dispatcher nothing useful. They already know ninety-eight per cent is normal, and they already know which two per cent is theirs.

Visibility is not a display of the fleet. It is a short, current list of the exceptions that need a decision in the next hour.

On-time performance is a lagging aggregate

It is calculated after the fact, it is a percentage, and by the time it appears the delivery is either fine or not recoverable.

The screen is showing you what already happened. What a dispatcher needs is which vehicle is about to become an exception, and what to do about it.

Build the exception list, not the fleet map

The useful artefact is ranked and time-boxed: things that will become problems, ordered by how soon and how expensive.

• a vehicle stationary beyond a threshold for its stage
• a delivery window at risk given current position and traffic
• a failed delivery needing re-attempt decision before the depot closes
• a temperature excursion on a constrained load
• a route where the planned stop order no longer makes sense

Each entry should say what is wrong, when it started, what it costs if ignored, and the options available. The dispatcher's job is then genuinely a decision rather than a search.

Make the list short enough to be read. Ten open items with owners is manageable. Four hundred is a queue nobody works.

Predict the exception rather than reporting it

The transition that changes a control tower is from reactive to predictive.

You do not need a sophisticated model for this. Scheduled delivery windows, position updates and route plans are sufficient to compute: given where this vehicle is now and how long the remaining stops take, which ones will miss.

That calculation is arithmetic with a map API and some caching, and it can be made thirty minutes ahead of the delay rather than thirty minutes after.

Reserve machine learning for the cases that genuinely need it — estimating real remaining travel time under conditions the schedule does not account for.

Exception quality determines everything

A control tower with a poor exception rate is worse than none, because the team learns to ignore the list. That happens when thresholds are generic rather than per-lane, per-customer or per-constraint.

Measure three things continuously:

• Precision. What proportion of raised exceptions were real? Below roughly sixty per cent the list loses credibility.
• Lead time. How early is the exception raised relative to when it would have been visible otherwise?
• Action rate. What proportion get acted on? This is the honest measure of whether the list is useful.

Track action rate especially. An exception nobody acts on is either wrong or unactionable, and both are worth investigating.

Design for the person who has to act

Two roles use this, with different needs:

A planner works in exception windows and needs ranked items with options and a way to assign. A manager works in trends and needs where the losses concentrate — which lanes, which customers, which failure modes.

Forcing both onto one screen produces a screen that suits neither. A single real-time exception list plus a periodic exception-analysis view covers both properly.

Close the loop on action

Whatever the dispatcher does — reroute, reassign, call the customer, accept the delay — capture it against the exception.

That is what turns a dashboard into a system. Within a quarter the data answers: which exception types recur, which interventions actually recovered the delivery, and which alerts should be suppressed because nothing ever comes of them.

Without it you have built a screen. With it you have a control tower that gets better each month.