Most fleet software business cases fail in the finance review, not because the investment is bad but because the case is built on vendor percentages instead of measured baselines.
Start with the baseline
Before anything else, measure the current state over at least four representative weeks:
| Measure | Why |
|---|---|
| Total route hours and overtime hours | Largest cost line |
| Distance driven | Fuel and maintenance driver |
| Vehicle count in use | Fixed cost |
| Stops completed per hour | Productivity |
| Failed deliveries and redeliveries | Direct waste |
| Planner hours per week | Displaced labour |
| Customer service contacts per 1,000 deliveries | Downstream cost |
| Maintenance cost per vehicle | Fleet efficiency |
| Fuel consumption per vehicle | Efficiency and behaviour |
| Downtime days | Availability |
Freeze the definitions in writing. A benefit claimed against a definition that changed halfway through is the fastest way to lose a finance director's confidence permanently.
Benefit categories
Group benefits by how confidently they can be claimed.
Hard, measurable, cash-releasing
- Reduced overtime hours
- Reduced vehicle count (or avoided vehicle purchases as volume grows)
- Reduced fuel consumption from shorter routes and less idling
- Reduced failed deliveries and redelivery cost
- Reduced maintenance cost from better scheduling
- Recovered warranty
- Reduced insurance premium from a safety programme
Hard, measurable, capacity-releasing (real but only cash-releasing if you act)
- Planner hours saved
- Administrative hours saved
- Customer service contacts avoided
- Workshop productivity improvement
Soft, real, difficult to quantify
- Customer satisfaction and retention
- Driver satisfaction and reduced turnover
- Compliance risk reduction
- Better decision-making from better data
Present all three, but base the payback calculation on the first group only. A case that survives on hard benefits alone and lists the rest as upside is far more credible than one that needs soft benefits to work.
A worked structure
``` Annual benefit Overtime reduction: hours saved × loaded hourly rate Fuel: km saved × consumption × price Vehicle avoidance: vehicles × annual fully loaded cost Failed deliveries: failures avoided × cost per failure Planner time: hours × rate (capacity, note separately) = Total annual benefit
Annual cost Subscription Amortised implementation Hardware and connectivity Internal support effort = Total annual cost
Payback = implementation + first-year cost ÷ annual net benefit ```
Then run three scenarios: conservative, expected and optimistic. Present the conservative one as the case. If it does not work at conservative assumptions, the investment probably should not proceed on financial grounds alone — say so, and make the argument on risk or capability instead.
Assumptions that need justification
Every number in the case should have a source. The ones finance will challenge:
- Percentage improvements. Where does the figure come from? "The vendor says 25%" is not a source. Your own pilot data is.
- Cost per hour. Fully loaded, including on-costs, or it understates the benefit and looks naive.
- Vehicle avoidance. Only claim it if you will genuinely dispose of a vehicle or avoid a purchase. A vehicle that stays in the yard saves nothing.
- Capacity benefits. A planner saving ten hours a week is only a cash benefit if the role changes. Present it as capacity unless you will act.
- Ramp-up. Benefits do not start at go-live. Phase them in over two or three quarters.
- Ongoing internal cost. Someone will administer this system. Include their time.
The five mistakes
- Vendor percentages instead of measured baselines. The most common and the most fatal.
- Claiming both labour savings and volume growth from the same capacity. Pick one.
- Omitting implementation and internal effort, so the case looks better and the project overruns.
- No ramp-up, producing a first-year forecast that will visibly miss.
- No post-implementation review, so nobody knows whether it worked — which makes the next case harder to get approved.
Post-implementation review
Commit to it in the business case, and schedule it for six and twelve months after go-live. Report honestly: what was achieved, what was not, and why.
Two reasons. First, it is the only way to learn. Second, the credibility of your next business case depends entirely on whether the last one turned out to be true. Fleet managers who report honest partial results are trusted; those whose cases are never revisited are treated as optimists.
Frequently asked questions
What payback period is acceptable?
Organisations differ, but many expect operational software to pay back within 12–24 months. Longer paybacks can be justified where the driver is compliance, risk or capability rather than cost — make that argument explicitly rather than stretching the financial case.
Should we include soft benefits?
List them, quantify them where you honestly can, and exclude them from the payback calculation. A case that depends on soft benefits invites scepticism about the hard ones.
How do we prove savings after implementation?
By comparing against the frozen baseline with unchanged definitions, adjusting for volume changes. This is why the baseline and its sign-off matter so much — without them, every claimed saving is arguable.
What if the vendor offers a guarantee?
Read what triggers it and what it pays. Most are limited to a partial refund of fees rather than compensation for the business impact, and most require conditions on your side that are easy to breach. Useful as a signal of vendor confidence, weak as financial protection.
Should we pilot before committing?
Where practical, yes. A pilot on one depot produces your own improvement percentages, which converts the entire business case from vendor claims to measured evidence — and it also reveals the implementation effort more accurately than any proposal.
