Start with the sampling rate, not the model.
Every fleet operator has been pitched AI in the last two years, and the pitches sound alike because they share a blind spot: they describe what a model could do without asking whether the vehicle data behind it can support the claim. The first question about any fleet AI use case is not which model, but at what resolution the signal is recorded and how long it is kept. A typical telematics unit reports on an interval — often every 30 to 60 seconds when moving, far less when parked — plus event-triggered bursts around harsh braking or impact. Trip and shift-level questions are well supported by that shape: utilisation, idle time, dwell at sites, fuel or energy per job. Event-level questions are supported only where a trigger already exists; you can analyse harsh braking because the device was configured to capture it, but you cannot retroactively analyse a near-miss that never fired one. Sub-second questions are not supported at all without additional hardware. We have seen more AI projects die on this point than on any modelling problem. The model was fine. The data was recorded at a resolution that could never answer the question being asked.
Utilisation and right-sizing.
The least discussed and most reliably valuable use case. Position and ignition data over a few months tells you which assets are working, which are idle, and which are being kept for a seasonal peak that no longer exists. This is largely arithmetic rather than machine learning, and it routinely funds the rest of the programme. If you do nothing else with your telematics data, do this first: it requires no new hardware, no model training, and no behavioural change from drivers.
Driver coaching from context, not thresholds.
Traditional driver scoring counts harsh events and produces a league table. Drivers dispute it, correctly, because a hard brake in dense city traffic is not the same as one on an empty motorway. Context-aware scoring is now practical: combine the event with road type, time of day, weather, load and route familiarity, and score against comparable conditions rather than a fixed threshold. This is a modest modelling problem and a significant change-management one. Fleets that introduce it as coaching see engagement; fleets that introduce it as discipline see gaming and disconnected devices.
Video telematics with automated triage.
Camera-equipped fleets have the opposite problem to data-poor ones: far more footage than anyone can review. Vision models are now good enough to triage it, flagging the small fraction of clips containing a genuine safety event and discarding the pothole jolts and door slams that dominate trigger volume. Two design points matter more than model choice. Run the first pass at the edge, because uploading every triggered clip over cellular is the cost that kills these programmes. And keep a human in the loop for anything that reaches a driver's record — an automated system that penalises a driver on a misclassification loses the fleet's trust permanently, and it only has to happen once. This is where our camera and hardware background has been most directly useful: the constraint is rarely the model, it is power budget, thermal envelope, storage, and how much inference you can run before the unit browns out on a cold start.
Predictive maintenance, with honest scope.
The most oversold use case, and still a real one provided the scope is stated precisely. What works: fault-code patterns, battery health trends, and component-specific models where you have both enough failures to learn from and a maintenance record clean enough to label them. Batteries, brakes on high-mileage duty cycles, and cooling systems are common wins. What does not work is a general predict-any-failure model. Failures are rare, heterogeneous and often recorded inconsistently — three properties that defeat a single model. If a vendor offers whole-vehicle failure prediction without asking to see your maintenance history first, they are selling a demo.
What still needs more than telematics.
Be sceptical of three claims unless you are prepared to add data infrastructure. Collision fault determination from telemetry alone: accelerometer and GPS traces narrow the picture but do not settle liability; video changes this, telemetry alone does not. Fuel theft detection from tank sensors alone: sensor noise and terrain produce false positives at a rate that erodes trust faster than the recovered fuel justifies, and it works only when fuel-card and transaction data are correlated with position, which is an integration problem rather than a model one. And ETA prediction that beats a good routing provider: your historical data helps at the last mile and at your own sites, but for everything in between a commercial traffic feed will outperform a model trained on your fleet alone.
The architecture question underneath all of it.
Most fleet AI programmes stall on plumbing rather than models. The recurring pattern is a telematics provider's dashboard that cannot be queried, an export that arrives daily as CSV, and no single place where vehicle, driver, job and maintenance data are joined. Fixing that is unglamorous and decisive. Land raw telemetry in your own store in addition to whatever the provider shows, so decisions about model resolution stop being irreversible. Join it to operational context — jobs, shifts, maintenance, fuel — because nearly every valuable question crosses those boundaries. Decide edge versus cloud per use case, driven by bandwidth cost and latency rather than preference. And instrument the outputs: if a driver alert fires, record whether it was acted on, because without that you cannot improve the system and cannot defend it.
Where to start.
If you are early, run the utilisation analysis: it pays for the next step and requires no new hardware. If you already have video, automated triage will return the most operator time per pound spent. If you have a clean maintenance history, a component-scoped predictive model is worth a pilot. And if you are being pitched a platform, ask three questions: at what resolution is the data recorded, what happens when the model is wrong, and can you see the raw stream or only the vendor's dashboard. The answers separate the systems that reach production from the ones that stay in a demo environment.