Vehicle downtime is a data problem before it is a workshop problem

A truck comes off the road on a Tuesday morning and the conversation starts in the workshop. It should usually have started six weeks earlier, at the moment nobody could answer a plain question: is this vehicle due for anything?

In fleets of five to fifty vehicles that question is rarely answered from data. It is answered from memory — the workshop manager knows the old tractor unit is about due, a driver mentions the brakes feel long, somebody checks the folder. That works until it doesn’t, and the reason is not negligence: the two inputs you need in order to answer live in two different places and are never brought together.

Two clocks, kept in two places

Almost every service cycle is either a calendar cycle or a distance cycle, and most fleets run both at once.

A calendar cycle counts days — an oil change every twelve months regardless of use, preparation ahead of a statutory test. Its only input is the date of the last service, and that date gets written down without anyone trying, because the invoice carries it.

A distance cycle counts kilometres, and it is the one that tracks actual wear. It needs two numbers nobody records by default: what the odometer reads today, and what it read at the last service of that type. The first lives in the cab. The second lives on a job card that may or may not have a reading on it.

So the calendar half of your maintenance plan is judgeable and the distance half is not — and the plan as a whole is only as good as its worse half. That is why “we service on instinct” is such a common answer from otherwise well-run operations. It is not a discipline problem. Half of the arithmetic simply has no numbers in it.

The kilometre baseline is the highest reading, not the latest

Suppose you fix this and compute distance cycles properly. Due point equals baseline plus interval; baseline is the odometer at the last service of that type. That is the obvious definition, and it is wrong in a quiet way.

Consider three completed services of the same cycle on one vehicle:

• March, 412 000 km recorded
• September, 458 000 km recorded
• February, no reading — the field was left blank

Take the latest record and your baseline is nothing. Depending on how the blank is stored you either compute from zero, in which case the vehicle reads as 458 000 km overdue, or you compute from an empty value and the cycle drops off the board altogether. One is loud and wrong; the other is quiet and wrong, and the quiet one is worse — a truck that has vanished from the due list looks exactly like a truck that is fine.

Take the maximum reading across the completed services of that cycle and the baseline is 458 000, which is the truth. Odometers only go up. A service somebody forgot to write a reading on has not undone the 458 000 km the vehicle has covered; it only failed to add information, and failing to add information should never subtract any. The fold you want is max, not last — worth stating plainly, because “the most recent record” is the answer most spreadsheets encode.

The rule protects you from the other direction too. A reading that arrives lower than the highest you hold is a typo, a transposed digit, or an old job card entered late. Keep the higher figure, or a mistyped 45 800 drags the baseline down by 400 000 km and manufactures a service that is not due.

What to do with a cycle you cannot judge

Do this properly and you will meet cycles you cannot compute at all: a distance cycle on a vehicle that has never been serviced, so there is no baseline; one whose every past service was written without a reading; a vehicle with no current reading, so there is nothing to compare the due point against.

The tempting move is to fill the gap — assume a baseline of zero, assume the fleet-average monthly distance, put something on the board so the row looks complete. Don’t. A guessed due date is indistinguishable on screen from a computed one, and once one row is a guess, no row is evidence.

The honest output is a fourth state alongside overdue, due soon and fine: cannot be judged — reading missing. It names the vehicle and the cycle, and deliberately carries no due date, no due kilometre and no overdue flag, because none of those are known. It reads as what it is: a missing measurement, which a person can go and fix in about ninety seconds.

This matters most for the empty state. A board that says nothing needs attention today is making a claim. If unjudgeable cycles are dropped rather than listed, that all-clear is false precisely for the vehicles you know least about.

Report it on a board; do not book it into a bay

There is a limit to this, and it is worth drawing carefully. A board should show unjudgeable cycles. Its job is to tell a human what is known and what isn’t, and an unmeasurable cycle is a fact about the vehicle.

A scheduler — anything that automatically raises work orders from due items — should skip them. It creates real jobs in a real bay, and a cycle whose due point nobody can compute cannot produce an honest one: you would send a workshop after a job with no defensible date, and re-send it the moment the last one closed. “We cannot judge this” is honest on a board and manufactured work in a workshop. Both surfaces ask the same question and get the same answer; they differ only in what they do with it.

The daily check is the meter

All of which comes back to one number, typed by one person.

The odometer reading a driver enters at the daily walk-around is what makes distance cycles judgeable at all. Nothing else in a small fleet produces that figure with any regularity. Telematics can, if you have it and if the unit reports vehicle odometer rather than accumulated GPS distance — many report the latter, which drifts. Job cards produce it a few times a year at best. The driver produces it every morning, already standing at the vehicle with a form open.

That makes the daily check the highest-leverage data entry in the whole maintenance chain, and it reframes what the check is for. Most fleets treat it as a compliance ritual and a defect-reporting channel. It is both. It is also the meter reading that turns your distance intervals from a plan into a measurement — a useful second argument if you are fighting the perennial battle to get walk-around checks completed, which we have written about separately.

Make it a required field rather than an optional one, and sanity-check it against the last known figure as it is entered. A required field that is occasionally wrong beats an optional one that is usually blank: a wrong figure gets caught by the maximum rule above, a blank one by nothing.

Statutory dates are worth keeping in the same view but handling differently. Roadworthiness testing and tachograph inspection run on the calendar at intervals set nationally, they are not yours to defer, and their consequence is binary: a service that is due is a planning input, while a lapsed statutory date is a refusal to dispatch.

Where navichain fits

navichain schedules maintenance on distance or on the calendar, per maintenance type, so a vehicle whose components run on different intervals is judged against each of them rather than one blanket cycle — the platform page puts it as knowing which truck is due a service, on distance or on the calendar. Daily walk-around checks sit in the driver app and open a defect when something fails; a failed inspection grounds the vehicle and a critical defect keeps it grounded, while roadworthiness and tachograph expiry stop a run outright. All of it is on every plan — you pay for scale, not capabilities — from 995 kr a month, billed monthly with no lock-in. The platform page has the detail, and pricing is public.