Fleet Software Requirements Builder
Every vendor demo goes well. That is what demos are for. This tool takes the requirement list you wrote before anyone showed you a dashboard, scores one vendor against it with must-haves weighted properly, and puts the unmet must-haves in their own box where they cannot be averaged away.
Your numbers
Requirements where a gap ends the evaluation. If your list runs past about thirty, some of them are wishes.
Real value, but you would sign without them and plan to get them later.
Things you would enjoy. Keep them on the list — they break ties honestly.
Shipped, configurable, and demonstrated on your data rather than on the vendor's sample fleet.
Met via export, custom field, roadmap promise or a manual step. Counts for half.
Result
Vendor fit score
75.0 %
112.5 of 150 weighted points, at 3 for a must, 2 for a should, 1 for a nice.
- Unmet must-haves
- 2 requirements
- Must-have coverage
- 79.2 %
- Must-haves met by workaround
- 3 requirements
- Weighted points scored
- 112.5
- Weighted points available
- 150
The formula
- Requirements are weighted: must-have 3, should-have 2, nice-to-have 1
- Weighted points available = (Must-haves × 3) + (Should-haves × 2) + (Nice-to-haves × 1)
- Must-haves met natively is clamped to at most the must-have count
- Must-haves met by workaround is clamped to at most the must-haves not already met natively
- Unmet must-haves = Must-haves − met natively − met by workaround
- Weighted points scored = (met natively × 3) + (met by workaround × 1.5) + (should-haves met, clamped to the should-have count, × 2) + (nice-to-haves met, clamped to the nice-to-have count, × 1)
- Vendor fit score = (Weighted points scored ÷ Weighted points available) × 100
- Must-have coverage = (met natively ÷ Must-haves) × 100
Assumptions and limits
- The 3-2-1 weighting is a convention, not a measurement. Its only job is to stop forty nice-to-haves outvoting a missing must-have, which is what an unweighted tick-count does.
- A workaround scores half. That is generous on the day and expensive over five years, because the manual step becomes a person's job and the roadmap item stays on the roadmap.
- The fit score cannot veto. One unmet must-have should end an evaluation regardless of a 91 percent headline, which is why that count is reported on its own.
- Nothing here prices anything. A vendor scoring 95 at four times the cost is not the winner, and this tool will not tell you that.
- Implementation effort, data migration and support quality are invisible to this model, and they are where the difference between two similar-scoring vendors usually turns out to live.
- The output is only as good as the list you wrote. Requirements gathered after the first demo tend to describe that demo.
Write the list before you watch the demo
Requirements written after a vendor presentation are not requirements. They are a description of what you were shown, reordered slightly. Everyone knows this and almost every evaluation does it anyway, because the demo is the moment possibilities become concrete and the list suddenly feels thin.
The defence is dull and it works. Write the list from your own operational problems, date it, circulate it, and refuse to add to it during the evaluation window. Anything a vendor reveals that you did not know you wanted goes into a separate parking area for the next cycle.
What a must-have really is
The test for a must-have is not importance. It is whether a gap ends the conversation. If you would still sign the contract, it is a should-have, and calling it critical only corrupts the score.
Applied honestly this collapses most lists. Fleets arrive with sixty must-haves and finish with about a dozen: the regulatory ones they cannot legally skip, the interface to the system that pays people, and the two or three things their operation is structurally built around. Everything else turns out to be negotiable, which is useful to learn before the negotiation rather than during it.
The workaround column is the one to watch
Vendors rarely say no. They say the word yes with a shape around it: you can export that to a spreadsheet, you can use a custom field, that is on the roadmap for the next release. Each is a real answer and none of them is the same as the feature existing.
Score those at half and then look at the count rather than the score. Three workarounds is a configuration exercise. Nine is a second system that you will build, staff and maintain yourself, inside a product you are also paying for. That is the shape of an implementation that runs a year late, and it is visible on day one if you write it in the right column.
Frequently asked questions
Fewer than you think, sorted more harshly than feels comfortable. The total barely matters — sixty or a hundred is fine — but the must-have count does. Once it climbs above roughly thirty, the category has stopped meaning anything and the score starts rewarding a vendor for breadth rather than for fitting your operation.
Yes, by running it once per vendor against the same requirement list and the same definitions of met and workaround. The comparison is only valid if the list does not change between runs, which is harder to hold to than it sounds, because the second demo always suggests an improvement to the list.
As a workaround at most, and only with a date in the contract. A roadmap is a statement of intent by a company whose priorities will change. If the requirement genuinely ends the deal without it, treat the roadmap answer as unmet and see what the vendor does with that.
Because a combined fit-and-price number lets a cheap vendor buy its way past a capability gap, and the arithmetic hides that it happened. Score fit here, price separately, then set the two figures side by side and make the trade-off in the open where the people signing can see it.
Not universally, and the tool would be dishonest if it were built so we did. We are modular, which scores well for fleets whose must-haves cluster in fuel, maintenance and tracking, and badly for fleets whose must-have list is dominated by deep freight-forwarding or warehouse functionality. Running this properly should tell you that before a demo does.
Stop estimating. Measure it.
Fleet Software Requirements Builder gives you the arithmetic. Platform gives you the live numbers from your own fleet.