How These Deployments Fail

Fleet telematics fails in recognisable ways, and almost none of them is the hardware.

Bought for the map

Symptom: a live view nobody opens after the first month, and no other value demonstrated.

Cause: the demonstration showed position and the procurement specified position.

Correction: the field list per model, and the three cost figures before purchase.

Dongles where a CAN connection was needed

Symptom: no consumption data, generic codes only, an odometer that drifts.

Correction: accept the installation cost for the vehicles where maintenance and fuel data matter, which is most of them.

Alerts enabled on day one

Symptom: hundreds of notifications, then none read.

Correction: a month of silent logging, thresholds from your own data, three categories with named recipients.

No link to the workshop

Symptom: codes arriving as emails, someone retyping odometer readings weekly.

Correction: odometer and hours into the maintenance system, codes creating jobs.

Device register not maintained

Symptom: per-vehicle history that belongs to a different vehicle.

Correction: device identity recorded at fitting against registration and VIN, checked quarterly, updated at every swap and disposal.

Position retained by default

Symptom: six months of location history nobody decided to keep, with the obligations that attach.

Correction: retention set separately for asset and position data, and every personal field justified or switched off.

Servicing still by calendar

Symptom: the system is live and the maintenance schedule has not changed.

Correction: triggers on actual usage with lead time, and a workshop conversation about rolling demand.

Nobody owns it

Symptom: data quality degrading, alerts unread, the register stale.

Correction: a named owner with allocated time, which is a fraction of a role and less than the cost of not having one.

Driver monitoring bolted on

Symptom: a workforce dispute, and a deployment that now needs consultation and an assessment.

Correction: decide that separately, deliberately, with its own justification — or not at all.

The common thread

Every one is a configuration or an ownership decision rather than a technology problem, which is why replacing the provider fixes none of them.

Diagnose before replacing the provider

The check that prevents an expensive mistake.

Run the four data quality checks and see which fails.

Ask what the field list actually delivers on your models.

Look at whether the workshop ever receives the data.

A fortnight, and it frequently shows that the platform is fine and nothing was configured or connected.

Reproduce the workflow

For another way to make this requirement testable, consult review this workflow page. Reproduce the case with real roles, codes, failures and recovery steps.