route & fleet
Buying guides

Twelve Questions to Ask Fleet Software Vendors

The questions that reveal how a vendor will behave after you sign — support, upgrades, data ownership, roadmap and what happens when things go wrong.

Illustration: Twelve Questions to Ask Fleet Software Vendors
Advertisement
Ad space · activate by adding your AdSense publisher ID to lib/manifest.js

Feature questions get rehearsed answers. These twelve are about how the relationship will work over five years, and the quality of the answers is more predictive than any feature comparison.

1. "Who exactly will be on our implementation team, and are they contractually committed?"

Pre-sales teams are excellent. Delivery teams vary. Ask for names, roles, allocation percentages and whether they are named in the statement of work. Ask what happens if a named person leaves mid-project.

2. "Describe an implementation that went badly and what you changed as a result."

A vendor who cannot name one is either new or not being candid. The answer reveals whether they learn, and how they behave when a project is in trouble — which is when you actually need them.

Advertisement
Ad space · activate by adding your AdSense publisher ID to lib/manifest.js

3. "What is your annual price increase mechanism, and will you cap it?"

Uncapped uplifts compound over a five-year term. This is one of the most commonly conceded points in negotiation and one of the least often raised.

4. "What happens to our data if we leave?"

Specifically: what format, how quickly, at what cost, including historical records and attachments such as proof-of-delivery photographs. Get it in the contract, not in an email. A vendor unwilling to commit to this in writing is telling you about their retention strategy.

5. "Show me your public API documentation."

Right now, in the session. Public, complete documentation indicates engineering maturity and gives you practical assurance that your data is reachable. Documentation behind a sales gate is a warning.

Advertisement
Ad space · activate by adding your AdSense publisher ID to lib/manifest.js

6. "How do upgrades work, and what notice do we get?"

For SaaS: notice period, sandbox availability, whether upgrades are mandatory, deprecation policy for APIs, and how breaking changes are communicated. A vendor who pushes changes without notice will eventually break your integration at your busiest hour.

7. "What are your support hours, and what is the actual response time?"

Not the SLA target — the measured median. Ask for last quarter's figures. If your operation starts at 04:00, business-hours support in a different timezone is inadequate regardless of what the target says.

8. "Which of our requirements are on the roadmap rather than available today?"

Then treat every roadmap item as absent for scoring. Ask for the commitment in writing with a date and a remedy if missed. Roadmaps slip; contracts do not.

9. "Can we speak to a customer who has been live for three or more years?"

Not a recent reference — those are still in the honeymoon period. A three-year customer knows about price increases, upgrade disruption, support quality and whether the roadmap materialised. Ask them what they would do differently.

10. "What does it cost to change configuration after go-live?"

New depot, new pricing rule, new vehicle class, new report. If every change is a professional services engagement, that is a recurring cost and an agility constraint. Establish what your own administrators can change.

11. "What is your financial position and ownership structure?"

Private equity ownership frequently precedes price increases and support changes. A vendor with funding runway concerns may not be there in year three. For a system this embedded, vendor viability is a genuine risk, and asking is entirely reasonable.

12. "What are you not good at?"

The single most informative question in the list. Vendors who answer honestly — "our maintenance module is newer and less deep than our routing", "we're weaker in field service than in delivery" — are describing a product you can plan around. Vendors who claim excellence at everything are describing a product you will discover the truth about in month four.

Questions to ask their reference customers

Reference calls are usually wasted on confirming the product works. Ask instead:

  • What surprised you during implementation?
  • What did the vendor underestimate?
  • How much internal effort did it actually take, compared with the estimate?
  • What do you use that you did not expect to, and what did you never use?
  • How has support quality changed since you went live?
  • What has happened to your price?
  • Knowing what you know now, would you choose them again, and what would you do differently?

Frequently asked questions

Will vendors answer these honestly?

The good ones will, and the quality of the answers is itself the assessment. Evasion on data ownership, price uplifts or support metrics is meaningful information regardless of what is being evaded.

Should we ask all twelve in one session?

Spread them: some in the RFP, some in the demonstration, and the commercial ones during negotiation. Asking all twelve at once turns a working session into an interrogation.

What if we cannot get a three-year reference?

Ask why. It may be a genuinely new product, in which case price the risk accordingly, or it may mean long-term customers are unwilling to speak. Both are worth knowing before you commit to a five-year term.

How much weight should vendor viability carry?

Meaningful weight for any system that becomes embedded in daily operations. Migrating away from a fleet platform is expensive and disruptive, so a vendor that may not exist in three years is a real operational risk, not just a commercial one.

Is it rude to ask what they are bad at?

No — and the reaction tells you a great deal. Experienced enterprise vendors expect it and answer well. Defensive reactions to a reasonable question predict defensive reactions to problems later.

Nil Masferrer Jiménez · Editor

Nil writes and edits Route & Fleet. It is an informational reference compiled from public sources — vendor documentation, regulator publications and published industry research — not consultancy, and not based on first-hand experience of running a fleet. Corrections are welcome and get published.

How we research and review our articles

This article is editorially independent. Route & Fleet is funded by advertising displayed on the page; advertisers have no influence over our research, recommendations or conclusions. See our advertising disclosure.

Keep reading

Related articles

Buying guides

The Demo Script That Exposes Weak Products

How to run vendor demonstrations on your terms — a scripted scenario approach that reveals what a standard demo is designed to hide.

26 July 2026 · 5 min read

Advertisement
Ad space · activate by adding your AdSense publisher ID to lib/manifest.js