The fleet data nobody looks at until they need it
The live map is the feature everyone opens daily and the least valuable data the system produces. The history is the other way round.
In short
- The live map sells the system and gets used daily; the trip, stop, and usage history is what you need on a bad day.
- History cannot be collected retroactively — the recording has to have been running before the thing you need it for happened.
- Four days it matters: a disputed delivery, an incident, a vehicle that keeps failing, and the annual argument about fuel.
- Driver behaviour data is also surveillance of your staff, and how you introduce it decides whether it works.
Fleet software is bought for the live map. That is not a criticism — the map is genuinely useful, it answers the question dispatchers get asked forty times a day, and it is the reason the system gets opened every morning. It is also, on its own, the least valuable data the system produces, because it is information with a shelf life of about four minutes. Where the van is right now stops mattering the moment it arrives.
The data that earns the subscription is the exhaust: trip and stop history with timestamps, engine hours, idle time, geofence crossings, and fuel consumption per vehicle and per driver. Nobody opens any of it on an ordinary Tuesday. It sits there being recorded, worth approximately nothing, until one of four days arrives — at which point it is worth a great deal and cannot be obtained any other way.
The four days it matters
The delivery somebody says never happened
A customer states the driver never came. The driver states they did. Both are usually being honest — this is far more often a misremembered address, or a delivery signed for by somebody who has since gone home, than anyone lying — and the conversation has no way to end on its own. Stop history with timestamps ends it in about thirty seconds, and it ends it in the direction of whoever is actually right, which is not always the direction you were expecting.
The incident
A collision, a complaint about driving, an insurance claim. What is needed is a specific hour of a specific day: route, speed, stops, in a form somebody outside the company will accept. This is the case where the retroactive problem is starkest, because the request always arrives after the fact and often months after it. If the system was not recording, or the retention window has already rolled past, the answer is that the data does not exist — and there is no version of that conversation that recovers it.
The vehicle that keeps going wrong
One van is always in the workshop and nobody can say why. The temptation is to blame the vehicle or the driver, and the cause is usually neither: it is a service schedule keyed to a calendar being applied to a vehicle whose actual usage does not match the calendar. Maintenance scheduled against mileage and engine hours — both of which the system is already counting — is the difference between a service that happens because it is March and a service that happens because the vehicle has done the work.
That is a genuinely different way of buying maintenance, and it only works if the counters have been recorded continuously. A usage-based schedule with a three-month gap in its data is a calendar schedule wearing a costume.
The annual argument about fuel
Fuel spend rises, the question gets asked, and nobody can answer it because the only number anybody has is the total. Consumption and idle time reported per vehicle and per driver turn that into a conversation with specifics — at which point it stops being a data problem and becomes a management one, because the numbers now have names attached to them.
You cannot collect it afterwards
Everything above shares one property: the recording had to already be running. That sounds obvious and is routinely got wrong, in two specific ways.
The first is coverage. A vehicle without a tracker is invisible to the map, to trip history, and to geofence alerts — completely invisible, not partially. Hire vehicles, the owner's van, the one that was off the road the week the fitting happened: each of those is a hole in the record that only becomes apparent on the day the record is needed. Anything you might one day have to answer a question about needs a device in it.
The second is retention. Every system keeps history for some period and then stops, and almost nobody asks what that period is at purchase, because retention is not a feature anyone markets. It is nonetheless the property that decides whether the system can help with an insurance claim that surfaces four months later. Ask for the number, ask whether it differs by data type — position and speed data is far bulkier than service records and is often kept for less time — and ask what getting it out looks like.
Three questions to settle before you need any of it
- How long is history kept, per data type, and what does keeping it longer cost? The answer that matters most is the one for position and speed, because that is both the bulkiest and the one an incident enquiry will ask for.
- What does an export actually look like? Not a report on a screen — a file you can hand to an insurer or a solicitor, in a format they can open, produced without raising a support ticket.
- Who can replay a driver's day, and is that access itself logged? This is the access control question, and it is much easier to answer before somebody asks it about one named driver.
None of those are exciting, and all three are cheaper to answer during procurement than in the week the data is needed. The pattern is the same one that runs through every operational system worth having: the information you need under pressure has to have been collected calmly, months earlier, by something nobody was thinking about at the time.
