An RFP exists to produce comparable responses from vendors who understand your operation. Most fail at both: they ask closed feature questions that every vendor answers yes to, and they describe the requirement so vaguely that pricing is meaningless.
When an RFP is worth it
- Purchase value justifies the effort — typically six figures over the term
- Three or more credible vendors exist
- Your organisation requires competitive procurement
- Requirements are stable enough to document
For smaller purchases, a structured evaluation with two or three vendors and a scripted demo achieves more in a fraction of the time. Do not run a formal RFP for a twelve-vehicle fleet; vendors will not respond proportionately and you will spend more managing it than you save.
Structure
1. Introduction and context. Who you are, what you do, why you are buying. Vendors write better proposals when they understand the problem.
2. Current state. Vehicle count by type, depots, stops per day, customers, order channels, existing systems, integration landscape, geography. Specific numbers, not adjectives.
3. Scope. What is in and, explicitly, what is out. The out-of-scope list prevents inflated proposals and is the most useful paragraph in the document.
4. Functional requirements. From your requirements checklist, with weights shown. Showing the weights produces better-targeted proposals and costs you nothing.
5. Scenario questions. The most valuable section — see below.
6. Technical requirements. Architecture, hosting, data residency, security certifications, API, integration approach, performance at your volume.
7. Implementation. Approach, timeline, resourcing on both sides, data migration, training, acceptance criteria.
8. Commercial. Pricing structured in your format, not theirs. A five-year total cost table with defined line items, so responses are comparable.
9. Support. Hours, channels, response and resolution targets, escalation, named contacts.
10. Vendor information. Company details, financial position, customer count in your sector and size band, references, roadmap, release process.
11. Evaluation criteria and weighting. Publish them. It produces better proposals and demonstrably fair process.
12. Timetable and process. Question deadline, submission date, demo dates, decision date.
Scenario questions worth asking
Adapt to your business:
- A driver completes 30 stops with no mobile signal all day. Describe exactly what happens, including proof of delivery and sync.
- A customer is placed on credit hold at 10:00 while the driver has already loaded their order. Trace the flow.
- Peak season doubles our volume for six weeks. What changes technically and commercially?
- Our ERP feed fails at 03:00. Who is alerted, what does the planner see at 06:00, and how is it recovered?
- A planner needs to lock two stops to a specific driver and re-optimise everything else. Show the steps.
- Show a plan for these 200 stops with these constraints. (Attach real, anonymised data.)
- A vehicle breaks down at 11:00 with 18 stops remaining. Describe the reassignment process.
- We need a report you do not provide as standard. Show us how we build it.
- We terminate the contract in year four. Describe exactly what we receive, in what format, how quickly and at what cost.
- Describe a recent implementation that went badly and what you changed as a result.
The last question is the most revealing. Vendors who answer it candidly are generally better partners than those who claim never to have had a difficult project.
Sections vendors game
Feature matrices. Everything gets a yes, sometimes qualified with a roadmap footnote. Require evidence for anything scored as available, and treat roadmap items as absent.
Reference customers. You are given the three happiest. Ask for a customer who has been live for three or more years, and one in your sector at your size — and ask them about the implementation, not the product.
Pricing. Structured to look cheapest. Insist on your template, with your volumes, over five years, including implementation, uplift and exit.
Implementation timelines. Optimistic, and often assume more of your internal resource than you can supply. Ask what happens when a milestone slips and who bears the cost.
Named team. The people in the pitch may not be the people delivering. Ask who is contractually committed.
Evaluation
Publish weightings, and use something like:
| Criterion | Typical weight |
|---|---|
| Functional fit | 30–35% |
| Driver app and usability | 15–20% |
| Integration and technical fit | 10–15% |
| Implementation approach and risk | 10–15% |
| Total cost of ownership | 15–20% |
| Vendor viability and support | 10% |
Score against evidence, not assertion. Written responses inform the shortlist; demonstrations and proof of concept decide the outcome.
Frequently asked questions
How long should an RFP take?
Six to twelve weeks from issue to decision for a mid-sized purchase: two to three weeks for responses, two for evaluation, two to three for demonstrations, then reference checks and negotiation. Compressing it produces worse decisions rather than faster ones.
How many vendors should we invite?
Four to six for written response, shortlisting to two or three for demonstrations. More than six produces evaluation fatigue and worse scrutiny of each.
Should we include our budget?
Stating a realistic range saves everyone time and prevents proposals that are wildly out of scope. Stating an inflated figure guarantees you will be quoted it.
What if vendors refuse to answer in our format?
Treat it as information about how they will behave as a supplier. A vendor unwilling to price in a comparable format during a competitive process will not become more accommodating afterwards.
Do we have to run an RFP at all?
Only if your organisation requires it or the value justifies it. For most mid-market purchases, a structured evaluation of two or three vendors with scripted demonstrations and a proof of concept produces a better decision faster.
