AI for fleet management: where the money is and where the hype is

AI for fleet management is almost always sold with the same pitch: a map with dots moving in real time and the promise of a round percentage saved on fuel. The map is usually fine; what rarely gets explained is that the saving doesn't come from the map. It comes from changing how people drive, when a vehicle goes into the workshop and how routes are built. And that takes data, not a screen.

This guide covers what genuinely moves the P&L in a fleet of 10 to 300 vehicles — haulage, urban distribution, field service, construction, refrigerated delivery: fuel, maintenance, driving and rest time compliance, and planning. It also covers which telemetry each case needs, because that is where 80% of stalled projects stall: the data exists, but it is split between the vehicle manufacturer, the telematics platform, the tachograph software and a spreadsheet the transport manager keeps.

A warning up front, because it saves money: if GPS already tells you where every vehicle is and still nobody can answer in two minutes what each route costs per kilometre, the problem is not artificial intelligence. It is scattered data. That gets fixed sooner and costs less.

What does AI actually add to fleet management?

There are four areas with a defensible return. The rest, today, is either classic telematics with an "AI" label stuck on top, or a pretty dashboard nobody opens in month two.

Fuel and driving style. Working out how much of the spend is explained by the route, the load, the vehicle and the driver. It is not about pinning a league table on the wall: it is about isolating the variables so you know where the real margin sits.

Predictive maintenance. Anticipating breakdowns from vehicle signals and workshop history, instead of replacing parts by calendar or waiting for a roadside failure. A vehicle off the road mid-route costs far more than the part.

Compliance and the tachograph. Automatically reviewing driving and rest times, flagging infringements before they happen and assembling the paperwork for an inspection without losing a day to it.

Route and load planning. Assigning jobs to vehicles while respecting delivery windows, capacity, legal driving hours and driver profile. Mathematical optimisation has worked here for decades; what machine learning adds is sharpening the estimates that feed the optimiser — how long that unloading really takes, not how long the standard times table says.

If the vendor starts with the live map rather than with which decision you will change on Monday, you are buying a screen. The map is the cheap part.

Which telemetry do you need, and where does the data come from?

No use case works in a vacuum. Before signing anything, be clear about which signal you have, at what frequency, and who owns the data.

| Source | What it gives you | Check before you commit | |---|---|---| | Manufacturer telematics (FMS/CAN) | Real fuel use, revs, torque, retarder use, AdBlue, fault codes | Whether there is an open API or only a web portal; whether the contract lets you export history | | Aftermarket device (OBD/CAN) | Position, speed, harsh events, idling, geofences | Sampling frequency; many report every 30-60 s, which erases short events | | Digital tachograph | Driving, rest, activity per driver, kilometres | Whether remote download is active and how often; file formats | | Fuel cards | Litres, amount, station, date and time | Whether refuelling is tied to a vehicle and a driver, or only to a card | | Workshop / CMMS | Work orders, parts, labour hours, kilometres at intervention | Whether the failure reason is coded or written in free text | | ERP / TMS | Jobs, customer, origin-destination, weight, units, delivery times | Whether actual arrival and unloading times are stored, not just planned ones | | Driver terminal | Incidents, proof of delivery, photos, waiting time | Whether waiting at the customer is recorded as such |

The question that decides the project is simple: do you have real fuel consumption per vehicle and per trip, or only the monthly card total? With a monthly total you can control spend, but you cannot attribute consumption to a route, a load or a driving style. Better to know that before paying for a year of licences.

One detail comes up again and again: sampling frequency. A device reporting once a minute sees neither a harsh brake nor a 40-second idling spike. If the use case is driving style, you need second-by-second data, at least around events. If it is position tracking to notify customers, a minute is plenty. Paying for high frequency across the board wastes money; paying for low frequency and expecting fine-grained analysis buys frustration.

If you have been through integrations that went sideways, the source-of-truth and master-data pattern we describe in integrating ERP and CRM without breaking things applies here too — with the added twist that the registration plate is written four different ways in four systems.

Can you cut fuel spend with data without blaming the driver?

Fuel is the biggest line item and the worst analysed. The usual approach is to compare litres per 100 km across drivers and draw conclusions. It is unfair and it doesn't work: whoever runs the mountain pass fully loaded will always lose against whoever runs flat and empty.

What does work is normalising before comparing. A decent model estimates the expected consumption of each trip from the vehicle, the weight, the elevation profile, traffic, weather and job type. The interesting part is not the prediction: it is the residual, the gap between expected and actual. That is where actionable things appear:

• Avoidable idling. Engine running while parked at a customer, during loading or during a rest. It is the fastest saving and the least contentious, because almost nobody defends it.
• Service brake versus retarder use, gear changes outside the efficient band, cruise speed above the efficient range on long stretches.
• Tyre pressure and vehicle configuration, which explain stable deviations over time and are not fixed by training.
• Routes that systematically burn more, regardless of who drives them. That is a planning problem, not a driving one.

Whether this saves money or ends up in a drawer depends on how it is presented. A monthly report with a public ranking breeds gaming — and drivers switching the engine off where they shouldn't. A weekly, private, per-driver summary with two or three concrete points, compared against that driver's own history, gets used. It is the same principle we set out in change management in AI projects: a tool perceived as surveillance gets sabotaged; one that helps earn a clear bonus gets adopted.

How does predictive maintenance work in a fleet?

It is the case with the most potential and also the most oversold. It helps to separate three levels, because the price and the requirements are very different.

Level 1 — maintenance by actual usage. Replace the calendar with kilometres, engine hours and working conditions. No AI required, just the odometer feed connected to the maintenance system. It is cheap and usually delivers the first saving.

Level 2 — alerts on fault codes and trends. Read vehicle fault codes and parameter trends (temperatures, AdBlue consumption, pressures) to spot degradation before failure. This is where the model starts to earn its keep, and it works well on components with a clear signal.

Level 3 — component-level failure prediction. Estimating failure probability within a kilometre window. This needs coded breakdown history and enough cases of the same component. A 30-vehicle fleet rarely has the volume; a 300-vehicle fleet with homogeneous units does.

The requirement almost nobody meets at the start is clean workshop history. If the reason for the intervention is free text — "odd noise", "service" — there is nothing to learn from. Those work orders have to be coded before modelling, and automated document extraction helps a lot here: the mechanics are in document data extraction. The general logic — which sensors and history each case needs, and when it beats preventive maintenance — is in predictive maintenance.

How to measure it without fooling yourself: the metric that matters is not "breakdowns predicted". It is unplanned off-road events per 100,000 km, maintenance cost per kilometre, and the share of workshop visits that are scheduled. If those three don't move in six months, the project isn't working, however many alerts it fires.

What can AI do with the tachograph and compliance?

The value here is less glamorous and very concrete: avoiding fines and removing admin work. The European driving and rest time framework is rigid, and inspections look backwards, not forwards.

What can be automated today with confidence:

• Automatic download and validation of tachograph and driver card files within the mandatory deadlines, with an alert when a download fails. It sounds trivial; it is one of the most common causes of penalties.
• Infringement review across history, classified by severity, with the specific day and driver. A review that takes hours by hand.
• Early warnings. If a driver is on track to exhaust their weekly driving time, the system tells the transport desk with enough margin to reassign, not the next day.
• Inspection preparation: gathering files, reports and supporting documents for the requested period without digging through folders.

Two cautions. First: tachograph data identifies a person and describes their working day. It is personal data in the fullest sense, with limits on what it can be used for and how long it is kept; define that before connecting anything, using the criteria we explain in GDPR and AI. Second: the tool flags risk, it doesn't decide. Reassigning a job still belongs to the transport manager.

How do you plan routes and loads with your own data?

Planning is where the difference shows most clearly between an optimiser fed with real data and one fed with standard times invented five years ago.

The workable design has two layers. First, estimate well: how long each leg really takes at that hour, how long unloading takes at that specific customer — a loading dock and a city-centre shop are not the same thing — and how likely a wait is. Those estimates are learned from your own history and improve on their own. Second, optimise: assign and sequence while respecting capacity, time windows, legal hours, vehicle requirements (chilled, ADR, crane) and reasonable preferences.

Where it usually fails:

• Nobody records actual arrival and departure times at the customer, so waiting time doesn't exist in the data and the plan ignores it. It is the most expensive failure and the easiest to fix.
• Optimising the kilometre and forgetting the service. A route 4% shorter that misses two delivery windows is a worse route.
• The plan leaves at six in the morning and reality starts at ten past six. Without intraday replanning, the optimiser is a theoretical exercise.

If the problem is more warehouse than road, we cover stock and picking in AI in logistics, and the forecasting that drives the workload in demand forecasting.

Where should you start, and in what order?

An order that works in mid-sized fleets, designed so each phase pays for the next:

| Phase | What happens | Typical timeline | What you have at the end | |---|---|---|---| | 0. Data | Join telematics, fuel cards, workshop and jobs; normalise plate and driver | 3-5 weeks | A cost per kilometre you can trust | | 1. Visibility | Dashboard of fuel use, idling, cost per km and availability per vehicle | 2-4 weeks | The argument about which number is right ends | | 2. Compliance | Automatic tachograph download, infringement review and alerts | 3-5 weeks | Fewer fines and fewer admin hours | | 3. Fuel | Expected-consumption model and per-driver feedback | 4-8 weeks | Saving potential identified and attributed | | 4. Maintenance | Usage-based maintenance and alerts on vehicle signals | 6-10 weeks | Fewer roadside breakdowns | | 5. Planning | Times learned from history and route optimisation | 8-12 weeks | Routes that actually hold |

Two rules about this timeline. Phase 0 doesn't get skipped, however much the vendor says their platform "connects itself": it connects, and it learns from whatever dirty data you have. And phase 1, which looks unambitious, is the one that changes meetings most, because it is the first time transport, workshop and admin look at the same figure calculated the same way. The minimum hygiene to keep that standing is in data quality.

On budget: the range depends mostly on how many systems have to be read and whether the telematics platform has an API. Ranges by project type and what inflates them are in what an AI project costs, and the honest way to measure return is in measuring AI ROI.

What shouldn't be automated in a fleet?

A short list, because getting this wrong is paid for in driver turnover:

• Automatic internal sanctions. The system supplies evidence; the conversation belongs to a person who knows the context of that route.
• The decision to take a vehicle off the road. The alert proposes, the workshop manager decides. A false positive that stops a lorry on a Friday costs more than the inspection.
• Live job reassignment without supervision, at least for the first quarter. The optimiser doesn't know that this particular customer won't accept deliveries after two.
• Customer-facing incident communication when money or a claim is involved. The delay notification, yes; the negotiation, no.
• Continuous driver monitoring outside working hours. Beyond being unlawful in almost every scenario, it destroys the trust you need for everything else to work.

Frequently asked questions

How many vehicles do you need before AI in fleet management pays off?

For fuel visibility and cost per kilometre, it pays from 10-15 vehicles, because the work is data work and the investment is small. For component-level failure prediction you need many more units of the same model plus coded workshop history; below a few dozen homogeneous vehicles there is not enough volume to learn from.

Do you have to change telematics provider?

Almost never at the start. What you do have to check is whether your current contract allows exporting history via API, and at what sampling frequency. If the platform only lets you view reports in its own portal, you are paying to look at your own data without being able to use it — and that is a reason to renegotiate.

Can tachograph data be used to assess drivers?

With real care and written rules. It is personal data tied to working hours, with a defined purpose and retention period, and it requires prior information to staff and their representatives. Using it for compliance and planning is defensible; using it as continuous surveillance is neither lawful nor effective.

How much fuel saving is realistic to expect?

Anyone quoting a figure without seeing your fleet is selling. The sensible route is to measure your own baseline per route and vehicle for a few weeks, quantify avoidable idling and the spread between drivers on comparable trips, and estimate the margin from there. If your normalised spread is already small, the saving will come from routing and maintenance, not from driving style.

---

If you are weighing where to start and don't want to buy a platform before the use case is clear, an audit gives you a map of what telemetry you have, what is missing and which project pays first. And if you would rather pressure-test it in half an hour, looking at your last fuel invoice and your workshop history, let's talk.