Writing a fleet management software RFP

Most fleet software RFPs are a spreadsheet of features with a Yes/No/Partial column. Every vendor returns it with Yes in every row. You hold demos, pick the one whose salesperson you liked, and discover the interesting differences eighteen months into the contract.

The problem is not that vendors lie. A feature question with a binary answer has no losing response. “Does your system support preventive maintenance scheduling?” is answerable Yes by every product in the category, including the one that schedules only by date when you need engine hours, and the one where it works but takes eleven clicks.

Write the current state first

Before any requirement, describe what you have: unit count by class, how many are DOT-regulated, annual work order volume, who enters data today, the system it lives in now, your fuel card, telematics hardware already installed, and the financial system costs must land in.

Vendors price against this. Without it every proposal is a guess and the costs are not comparable. Powder Springs, Georgia got part way there in a four-page solicitation for its 71-vehicle fleet — composition down to the 33 police cars and 4 garbage trucks — but never said what system it ran, which fuel card, or what telematics were already fitted. So every proposer had to guess at the integration and conversion work, which is exactly the part you need priced.

Then state outcomes rather than features: produce a defensible cost per mile by unit and class, show PM compliance for a DOT audit, tell a department head what their vehicles cost last quarter, flag units past a replacement threshold. Ask each vendor to produce those four from their own demo data. If federal money is involved, the Uniform Guidance points the same way — solicitations need a clear description of technical requirements, and “detailed product specifications should be avoided if at all possible.”

The four requirements that separate vendors

Data migration. Usually under-specified to one line saying the vendor “will assist.” Be specific about what moves: asset master records with custodial and warranty fields, open and closed work orders, historical parts and labour cost by unit (what your cost per mile and replacement scoring depend on), meter history, PM schedules with last-completed dates, fuel transactions. Ask for it as a priced line item with a stated file format, a validation step, a named owner for cleanup, and an answer on what happens to records the vendor cannot map.

Florida’s state fleet is the documented cautionary case: the Auditor General could not match 2,279 of 34,861 vehicle records, with acquisition costs totalling about $57 million, against state property records. Management’s own explanation was that property data was never imported, records were typically keyed by hand, and two employees were running the implementation.

Integrations. Name your actual systems, then ask three things a Yes cannot answer: native, middleware, or file drop? What refresh interval? Who pays, in build cost and ongoing fees? A native fuel card link posting nightly to the unit is a materially different product from a monthly CSV import, and both answer Yes to “do you integrate with fuel cards.” Ask for a reference customer running your combination.

Work order structure. Almost all day-to-day usability lives here and almost no RFP asks. Can one work order carry multiple jobs with separate labour and parts? How is technician time captured? Are outside vendor repairs first-class work orders or attachments? Is there a core charge and warranty recovery flow? Ask for a screen recording of one multi-line work order from open to close, with labour, parts, an outside invoice and a warranty claim. It tells you more than forty checkboxes.

Reporting. The failure mode is a hundred canned reports, none of which is the one your council asks for. Can a non-technical user build and save a new report? Is there direct access to your own data, and in what form? And own your exit before you sign: what happens to your data if you leave, in what format, at what cost.

Publish the weights

NIGP’s practice standard is explicit that criteria and weights must be stated with enough detail for a proposer to know what to put in the proposal, and that changes go to all interested parties before the deadline.

The federal floor is lower. The Uniform Guidance requires only that a solicitation identify all evaluation factors and their relative importance, with award to the most advantageous proposal considering price and other factors. Ranking criteria in order without numbers clears that bar and is common practice. It is also weaker: unpublished weights get argued about in the evaluation room after proposals are in, and they give a disappointed proposer somewhere to stand in a protest.

Score independently before the committee meets. Consensus discussion after individual scores are recorded surfaces disagreement; scoring as a group produces whatever the loudest evaluator thinks.

Weight implementation like it is half the purchase

Software you never fully implement returns nothing, and scope, staffing and milestones settled after award are settled at the point you have no leverage left.

Florida retired its two predecessor systems in June and July 2021; the replacement went live in September, and the state ran its fleet on manual templates in between. As of July 2024, nearly three years after go-live, management still reported the system was not fully implemented. The lesson is sequencing: put retirement of the old system in the RFP as a milestone that follows acceptance of the new one, not a date on the finance department’s calendar.

Require specifics — named project manager and their other current engagements, hours by role for both sides, a milestone schedule, what your staff must supply and when, training hours by role, the definition of go-live and who signs it. Ask for the estimated hours of your staff time. A vendor who says “minimal” has not done this before, or is not telling you.

Whether you need an RFP at all

For a small fleet, a full RFP can cost more staff time than the software. A cooperative contract already competitively awarded may satisfy your bid requirement and let you go straight to a scripted demo and a negotiation — with the trade-off that you inherit someone else’s scope and terms. See buying through cooperative contracts.

The reverse also holds: if your integration list is long or your requirements are genuinely unusual, an RFP is the cheaper path even at a small unit count, because it forces the answers out before you sign rather than after. Either way the underlying work is identical. The scripted demo, the named integrations, the migration mapping and the implementation plan are what you need in order to choose. The RFP is one container for them, not a substitute.