Whether It Paid For Itself
Vendor savings figures assume things that are rarely true. What to measure before and after, and the costs that appear later.
Telematics is sold on fuel savings and productivity gains. Both are measurable, and almost nobody measures them.
The claims that need checking
"Reduces fuel by fifteen percent." Sometimes true where driving was genuinely poor, and the figure usually comes from the worst deployments the vendor has seen.
"Adds a job per day per vehicle." This assumes the extra job exists and that the round had slack, neither of which is automatic.
"Reduces overtime." Depends on whether the overtime was caused by round design, which the tracker does not fix on its own.
None of these is dishonest. They are best cases presented as typical.
Measure the baseline first
Before deployment, for at least a quarter:
Fuel per vehicle per distance.
Jobs completed per vehicle per day.
Overtime hours.
Disputed visits and the value written off.
Insurance premium and claims count.
Without a baseline no improvement can be demonstrated, and the second phase becomes hard to fund.
Compare honestly
Like periods, because seasonality dominates in field operations.
Adjust for job mix, which changes with the market.
Separate what the data enabled from what a decision did. A round resized after looking at the data improved because of the resizing, and attributing it entirely to the software overstates the case.
Report the failures too. A measure that did not move is information, and hiding it makes the ones that did move less credible.
The costs that appear later
Hardware and installation, including vehicle downtime.
Subscription per vehicle per month.
Administration: someone maintaining geofences, investigating gaps, handling access requests.
The time spent on data quality, which is ongoing.
Compliance work: assessment, consultation, notices, reviews.
And the turnover cost if the deployment lands badly, which is the largest of them and appears in no business case.
What to commit to
Not a percentage from a brochure.
A specific change in a specific measure, with a date and the same method afterwards.
"Disputed visits from twelve a month to three within two quarters."
"Fuel per hundred kilometres down five percent, measured against the same quarter last year."
Checkable, which is what makes it fundable a second time and what stops the system being renewed on faith.
The review worth running annually
Did the measures move?
Is the collection still limited to what the purposes need?
Has the purpose limitation held?
Would you deploy it the same way again?
That last question produces the useful decisions, and nobody asks it unless a process does.
Report the failures too
What makes the successes believable.
A measure that did not move is information.
Hiding it makes the ones that did move look selected, which is how a renewal conversation goes badly.
Say which claims were tested and which were not.
And separate what the data enabled from what a decision did: a round resized after looking at the data improved because of the resizing.
Turn the principle into a test
For an example that can make this requirement testable, consult the boundary-testing example. Treat the page as a starting point rather than proof: reproduce the workflow with real roles, failures and permissions.