Fleet Software Buying Checklist
Every vendor demo works. It works because it was built to work, on their data, driven by someone who has given it four hundred times. This checklist is for finding out what happens on your data, on your worst vehicle, in month seven.
Fleet software is bought in a hurry and lived with for years. The trigger is usually an event — a lost vehicle, a failed audit, a fuel bill nobody can explain — and the event creates urgency, and the urgency is what the buying process never recovers from. Three vendors are seen in a fortnight, all three demos are impressive, and the decision comes down to price and whoever was most likeable.
Then the real system arrives. The vehicle list turns out to have eleven duplicates and four vehicles that were sold. The integration with the finance system needs a developer nobody budgeted for. The report the depot actually needs is on the roadmap. None of this was hidden; it simply was not asked about, because the demo was answering questions about features and the problems were all about data, process and people.
Work this list in order and it will slow you down, which is the point. The sections before the demo matter more than the demo. Do not let a vendor present until you can state the problem you are buying a solution to, in a sentence, with a number attached to it that you found yourself.
46 checks across 6 sections
Before you let anyone demo anything
- Write down the three problems you are buying this to fix, in one sentence each, and get the person who owns each problem to agree with the sentence.
- Quantify today's position for each problem, however roughly, so you can tell in a year whether anything changed.
- Separate must-have from nice-to-have before the first demo, because after the demo everything you were shown becomes a requirement.
- Identify who will actually use this daily, and ask them what would make their Tuesday better. It is usually not what the board thinks.
- Count the vehicles honestly, including the ones on hire, the trailers, the plant and the things nobody thinks of as fleet until they need tracking.
- Audit your vehicle list against the yard before anyone imports it. Every migration problem you will have is already sitting in that spreadsheet.
- Decide who owns this project internally and whether they have the hours. A system with no internal owner fails regardless of which one you buy.
Running the demo so it tells you something
- Send your own data ahead and ask them to demo on it. A vendor who declines has told you something useful and free.
- Ask to be driven rather than watching. Someone from your depot should hold the mouse, because a system that is easy to demonstrate is not necessarily easy to use.
- Give them your worst case, not your typical one: the mixed fleet, the multi-depot vehicle transfer, the trailer with no ignition feed.
- Ask to see the screen the supervisor will look at every morning, and count the clicks from login to the answer.
- Ask what the system does when data is missing or wrong, and be suspicious of any answer that involves a smooth line.
- Watch how an alert is configured, live, in front of you. Alert configuration is where these systems are won and lost and it is never in the demo script.
- Ask them to show a feature they know is weak. The answer tells you what kind of relationship you are about to have.
- Test it on a phone with one bar of signal, because that is the actual working environment for half your users.
Hardware and installation, where projects actually stall
- Establish who fits the devices, who pays for the fitting, and how many vehicle-hours the fleet loses to installation.
- Ask what happens on vehicles with no OBD port, no permanent power, or a warranty that prohibits certain wiring.
- Check trailer and plant coverage separately. Untethered assets are a different hardware problem and vendors present them as a footnote.
- Confirm what the device does when the vehicle is out of coverage, and whether it stores and forwards or simply loses the trip.
- Ask who owns the hardware at the end of the contract and what a device costs to replace outside warranty.
- Check whether the platform will accept devices you already own, and get that answer in writing rather than in a meeting.
- Establish the failure process: how you find out a device is dead, how long a replacement takes, and who fits it.
Data, integration and the exit
- Ask who owns the data. Then ask to see the clause, because the answer in the room and the answer in the contract are not always the same.
- Establish how you get your data out, in what format, at what cost, and whether that includes history or only the current period.
- Test the export before you sign, not at renewal. An export that arrives as a PDF is not an export.
- Check whether there is a real API, whether it is documented publicly, and whether using it costs extra.
- Identify every system this must talk to — finance, payroll, ERP, fuel cards, the workshop system — and confirm each integration exists rather than being possible.
- Ask what happens to your history if you leave, how long they retain it, and how it is deleted.
- Confirm where the data is hosted and whether that satisfies the rules that apply to you, particularly for driver personal data.
- Ask who at the vendor can see your data and under what circumstances.
Commercials, read properly
- Get the price per vehicle per month and then get the total for three years including hardware, fitting, setup and every module you were shown.
- Ask which of the features in the demo are in the quoted tier. Some of them will not be.
- Check what happens to the price when the fleet shrinks. Growth is priced generously in these contracts; contraction usually is not.
- Establish the term, the notice period and the auto-renewal, and find the date by which you must decide.
- Ask what the price does at renewal and whether there is a cap. An uncapped renewal on a system you now depend on is a position you have chosen.
- Find out what support costs, what response times are contractual rather than aspirational, and what happens at three in the morning.
- Ask what a change request costs once you are live, because you will need one within the first quarter.
- Check whether training is included, how much, and whether it is for the users or for the administrator.
Rollout, support and the reference call
- Agree a pilot on one depot or one vehicle group with a defined success test and a defined exit, before the whole fleet is committed.
- Ask for the implementation plan with named people and dates, and check whether the people named are the people who did the demo.
- Establish what you must supply and when — vehicle data, driver data, geofences, cost codes — and be realistic about how long that takes you.
- Ask for a reference from a fleet like yours in size and mix, then ask that reference what went wrong rather than whether they are happy.
- Ask the reference how long it took before anyone trusted the data. That number is the honest project timeline.
- Ask a reference who left the vendor, if you can find one. It is the most useful conversation available and nobody has it.
- Confirm who your support contact is after the salesperson moves on, which they will.
- Plan for the driver reaction. The rollout risk in a fleet is not technical and every project that failed will tell you the same thing.
How to use this checklist
- Score the vendors against your own must-haves, written before the first demo, and refuse to add rows afterwards. Requirements that appear during an evaluation are not requirements; they are things you were shown.
- Take the data and exit section to your legal review rather than your IT review. Those clauses are commercial, they decide what leverage you hold at renewal, and they are the ones nobody reads until they need them.
- Give the same worst case to every vendor. Comparing three demos of three different scenarios compares presentation quality and nothing else.
- Keep the answers in writing. The gap between what a salesperson says and what the contract says is not usually dishonesty, but it is always yours to carry.
- Run the pilot properly or do not run one. A pilot that everybody works around because it is temporary proves nothing except that people can work around things.
Frequently asked questions
Buying features instead of buying an outcome. A demo is a list of things a system can do, and every item on that list looks worth having when it costs nothing to want it. Six months later the fleet is using four screens out of forty and paying for a tier it chose because of a module nobody opened. Start from the three problems, insist that every requirement traces to one of them, and treat anything else as a pleasant surprise rather than a reason to pay more.
We will not put a per-vehicle figure here, because the honest answer depends on what is included and the published ranges compare things that are not comparable. What is worth doing instead is building the three-year total yourself: licences, hardware, fitting, setup, integration work, training, and the internal time. Then compare that total against the problems you wrote down at the start. If a system costs more than the problems are worth, the price is wrong regardless of what the market says.
It depends on whether your problems share data. Fuel, maintenance and utilisation all hang off the same vehicle and the same trip, and splitting them across three systems means somebody spends every month reconciling three vehicle lists that have drifted apart. Genuinely separate problems can live in separate systems. The test is simple: if answering a question requires joining two systems by hand, they should have been one system, and the integration cost you avoided at purchase is now an annual salary.
The arithmetic is usually fine and the inputs are usually somebody else's. Those models are typically built from the vendor's best outcomes on fleets that had no controls at all before, which is a legitimate result and not a prediction about you. The useful move is to invert it: take their model, replace every improvement percentage with a number you would defend in front of your finance director, and see whether it still works. If it only works at their number, you have a brochure.
Long enough to do the first section properly, which is usually the part that gets compressed. Scoping the problems, cleaning the vehicle list and finding out who will own the project internally is a few weeks of unglamorous work, and it is the work that determines whether the project succeeds. The demos themselves are quick. If an evaluation is running to months, the delay is almost never the vendors; it is an organisation that has not decided what it wants.
Run this checklist automatically
Platform turns these checks into scheduled, assignable work with a full audit trail.