The dashboard said 86 open jobs. The driver had three

You open the driver app to check one driver’s month. Trips completed reads nine, and the pick-ups and drop-offs add up to nine, so that looks right. The tile underneath says 86 jobs assigned this month and still open.

Eighty-six is not a number of jobs a person does in a month. And a number on a dashboard that nobody believes is worse than no number, because everyone stops reading the dashboard.

This was a car rental business, and the owner had spotted it himself on the live app after an earlier fix. When we looked, that one driver had 1,385 jobs in the “still open” state across the whole history of the system. Of the 86 in the current month, seventy were expired or completed, eight were waiting on a refund, one was cancelled. Three were genuinely open — and eighty-three already had a drop-off date in the past.

What was actually going on

A job is marked “assigned” to a driver when the office allocates it. In this system, the only thing that could ever change that label was the driver completing the handover inside the app. Nothing else could. If the office finished the booking another way, if the customer cancelled, if the booking simply lapsed, or if the platform the bookings come from closed it — the label stayed “assigned” for ever.

So the label was not lying. It was accurately recording that nobody had ever told it otherwise. The mistake was reading a label that only one thing can change as if it described the real world.

The booking itself knew exactly what had happened. It carried its own status — expired, completed, refund pending — and so did the rental platform it came from. Two reliable answers sat right next to a tile that was reading a third, weaker one.

What we changed

The count now asks the booking, not the label. A job counts as open only if the booking still has driving left in it. Cancelled, expired, returned, refund pending and refund done are all excluded, and so are the platform’s own “cancelled” and “completed”, because the platform can close a booking before the app’s label catches up.

Before changing anything, three different definitions of “open” were written down and each was run against the real data. All three gave the same answer, and the three surviving jobs for that driver were exactly the ones his app was already showing on its home screen. That last check is what made it safe: the home screen list and the dashboard tile are two separate questions asked of the same data, and they had been disagreeing by a factor of nearly thirty. When they agree, the number can be trusted.

The change touched no data and needed no app update. The caption on the tile became true rather than needing to change.

What it did not fix, deliberately

The office still sees a returned booking as open, because the settlement has not been done. The driver does not, because the driving is finished. The same booking is open on one screen and closed on another, and that is correct — “finished” is a question about whose work, not about the record. Forcing both screens to share one definition would have made one of them wrong.

The pattern, for anyone with a dashboard they have stopped believing

Go through the statuses in your system and, for each one, ask what can change it. Where the answer is “one thing, and only when it succeeds”, you have a label that describes whether that one thing ran — not whether the work is still outstanding.

The tell is a count that only ever grows. Real work has other endings: cancelled, lapsed, done by somebody else, done by hand, forgotten. If none of those endings can reach the label, the label holds half the story, and the half it holds gets less true every month.

Where this ends up

Sazinga Rentals counts bookings and the fleet standing behind them. A count like that is only worth reading if every way a job can end — cancelled, lapsed, finished in the office — can reach the field the count is taken from.