The claim, and the problem with it
Every telematics proposal contains a fuel saving percentage. The number is usually somewhere between five and fifteen per cent, and it is usually not wrong — but it is presented as though the hardware produces the saving. It does not. The hardware produces data. The saving comes from three changes in behaviour that the data makes possible, and if you do not make those changes, you have bought a very precise map of your existing costs.
Having deployed ITMOS across operators from twelve vehicles to several hundred, here is where the money is actually found.
1. Idling, which nobody believes until they see it
Idling is the most reliable saving and the one operators consistently underestimate. Engines left running during loading, at customer sites, through breaks, and in yards before departure. In fleets we have instrumented, idle time commonly sits between eight and eighteen per cent of engine hours before intervention.
The saving is straightforward because the intervention is straightforward: measure it per vehicle, show drivers their own figure, and set a target. No route change, no schedule change, no capital expenditure. This is normally where the first few per cent comes from, within about two months.
The failure mode is measuring idle time and reporting it upward without ever showing it to the driver. Idle percentage on a management dashboard changes nothing.
2. Driver behaviour, with a caveat about how you use it
Harsh braking, aggressive acceleration and speeding all cost fuel, and they correlate strongly with accident risk, which is often the larger financial exposure. Scoring works.
The caveat is significant. Scoring used punitively produces gaming, resentment and in some fleets a genuine safety problem as drivers optimise for the metric rather than the road. Scoring used as coaching — drivers see their own score, understand which specific events drove it, and get a conversation rather than a warning letter — produces sustained improvement.
We have watched the same software produce both outcomes in different organisations. The determining factor was never the software.
Worth measuring separately: insurance and accident cost reduction frequently exceeds the fuel saving, particularly in fleets carrying passengers or operating in dense urban environments. It is harder to attribute and slower to appear, so it rarely features in the proposal — but it is often the larger number.
3. Maintenance moving from reactive to scheduled
The third saving is the least visible and the most valuable in older fleets. Servicing on actual engine hours and fault codes rather than calendar intervals means fewer roadside failures, fewer emergency parts at emergency prices, and less unplanned downtime — which in a tightly scheduled operation is the expensive part, not the repair.
This one takes longer to show up, typically two to three service cycles, and it requires the workshop to actually change how it schedules. Fleets that install telematics but leave the workshop on a calendar do not get this saving.
Two places the saving usually is not
Route optimisation, in dense urban operations
Route optimisation is genuinely valuable in long-haul and rural distribution. In dense urban delivery — much of Singapore — the routes are already close to optimal because the drivers know the roads better than the algorithm knows the traffic. Expect scheduling and sequencing gains rather than distance reduction, and be sceptical of proposals quoting large kilometre savings in a city operation.
Headcount
Telematics rarely reduces driver headcount, and proposals that imply it usually mean better utilisation of existing drivers. That is a real benefit — more jobs per shift — but it appears as revenue capacity, not as a cost line you can point at.
How to evaluate a proposal
- Ask which of the three mechanisms the saving comes from, and what behaviour change each requires from your team. If the answer is vague, the number is a benchmark, not a forecast.
- Insist on a baseline period before any intervention. Without one, you cannot attribute anything, and every subsequent conversation becomes an argument.
- Check whether drivers will see their own data. This single design decision determines most of the outcome.
- Confirm the workshop is in scope. Maintenance savings need the workshop to change how it schedules, which is an organisational commitment rather than a software feature.
- Ignore kilometre-reduction claims in urban operations unless the vendor can show you a comparable local deployment.
Done properly, the payback period on a fleet of any reasonable size is short and the savings persist. Done as a hardware installation, you get a very good record of what you are already spending.
