How to Write
an RFP
A good RFP is not the one that asks the most questions. It is the one that produces responses you can lay side by side and actually compare — and that is a much harder document to write.
The failure most procurement teams recognise is the pile of six proposals, each 90 pages, each structured differently, each pricing a slightly different scope. Nobody can tell which vendor is genuinely stronger, so the decision drifts toward whoever demoed best or whoever the loudest stakeholder already preferred. That outcome is almost always determined by the RFP, not by the evaluation.
Here is how to write one that does its job — written from the buyer's side, having read a great many of them from the other.
Before you write anything
Three decisions have to be made before drafting starts, and making them during drafting is what produces incoherent documents.
Decide whether you actually need an RFP. They are expensive for everyone — typically six to twelve weeks of your team's time and a large amount of vendor effort. If you already know the market, the requirement is straightforward, and the value is modest, an RFQ or a structured three-vendor comparison will get you there faster. Reserve the full RFP for genuine complexity or where procurement rules require it.
Agree the decision-making group and the weightings first. If IT, finance, and the operational users have not agreed what matters most before the RFP is published, they will fight about it during evaluation — when the criteria are fixed and the disagreement has nowhere to go. Settling this early is uncomfortable and saves weeks.
Do market discovery before the RFP, not through it. An RFI or a few vendor conversations will tell you what is technologically realistic and roughly what things cost. Teams that skip this write requirements that no vendor can meet, or specify an approach the market abandoned two years ago, and only discover it through the clarification questions.
The structure
Eight sections. The proportions matter as much as the presence — the requirements section should dominate, and the parts that read like legal boilerplate should be short.
Context and objectives
1–2 pagesWho you are, what problem you are solving, and what success looks like eighteen months after go-live. This is the section vendors use to decide whether to bid seriously, and the one most often written as boilerplate. Say what is actually driving the purchase — a contract expiring, a system failing, a regulatory deadline, a growth constraint. Vendors who understand the driver write better proposals.
Scope of work
2–5 pagesWhat is in scope, what is explicitly out, and where the boundaries sit with your other systems and providers. Name the out-of-scope items. Every boundary you leave implicit becomes a pricing assumption that differs between vendors, and differing assumptions are what make bids incomparable.
Current state
2–4 pagesYour existing systems, data volumes, user counts, integration points, and known constraints. Withholding this to avoid "biasing" vendors backfires: they price in uncertainty as risk margin, and the bid you get is both higher and vaguer. Give real numbers.
Requirements
The bulkGrouped by theme, individually numbered, and each marked mandatory or desirable. Numbering is not bureaucracy — it is what lets you build a comparison matrix and what lets vendors prove coverage. This section deserves the most drafting attention and usually gets the least.
Evaluation criteria and weightings
1 pageThe criteria, their weights, and the scoring scale. Publishing weights is not giving away your position — it is how you get proposals that address what you care about instead of what vendors like discussing. Withhold the weights and you will receive fifty pages about the wrong things.
Commercial requirements
1–2 pagesA pricing template every vendor must complete identically, contract term, payment structure, and any budget range you are willing to disclose. Free-format pricing is the single largest cause of incomparable bids.
Process and timeline
1 pageDates for clarification questions, answers published to all bidders, submission, shortlisting, demonstrations, decision, and start. Vendors resource their bid teams against these dates; changing them late costs you goodwill and quality.
Submission instructions
1 pageFormat, page limits, file naming, portal or email address, required forms and signatures, and what causes disqualification. Be precise: ambiguity here generates clarification questions that consume your team’s time.
The evaluation criteria are the most important page
If you change one thing about how your organisation writes RFPs, change this. Publishing weighted evaluation criteria transforms the responses you receive, and most buyers either omit them or state them so vaguely that they carry no information.
The reasoning is simple. Vendor proposal teams allocate their effort against the weightings. Publish that technical approach is 40% and price is 20%, and you get detailed technical content. Publish nothing, and every vendor guesses — usually guessing that you care about whatever they are strongest at.
Uninformative
“Proposals will be evaluated on quality, capability, experience, and value for money.”
Every vendor writes about everything, at length, hoping to hit whatever you meant.
Usable
- Technical solution and integration approach — 35%
- Implementation plan and risk management — 20%
- Total cost of ownership over five years — 20%
- Relevant experience and references — 15%
- Support model and service levels — 10%
Vendors now write proportionally, and your comparison matrix is already built.
State the scoring scale too — a 0–5 scale with described levels, so vendors know what distinguishes a 3 from a 5 and your evaluators score consistently. And say plainly how price is treated: lowest-price-wins, a formula, or scored qualitatively. Vendors price differently depending on the answer, and leaving it unsaid produces bids you cannot compare on cost either.
The five mistakes
These come up repeatedly, and each one quietly reduces the quality of what you get back.
Copying requirements from a vendor’s website
It happens more than anyone admits — a stakeholder liked a product, and its feature list became the requirements. Every other vendor reads it immediately, and the good ones no-bid rather than serve as your price check. You end up with fewer, weaker bids and an award that looks pre-decided.
Marking everything mandatory
When 200 of 220 requirements are mandatory, you have not expressed priority — you have built a disqualification minefield. Capable vendors with one small gap withdraw. Aim for a genuine minority of mandatories: the things that would actually end the conversation.
Asking for information you will not evaluate
Every question costs vendors hours and costs your panel reading time. If no criterion scores it, cut it. A tight RFP that asks forty things you will genuinely assess produces better decisions than one asking three hundred you will skim.
An unrealistic response window
Two weeks over a holiday period does not filter for the most committed vendors. It filters for the ones with the most recycled content. Four weeks is a reasonable minimum for anything substantial; six for complex or multi-party bids.
Publishing clarification answers selectively
Answers must go to every bidder, unattributed, by a published date. Anything else is a fairness problem, and in regulated procurement, a challenge risk. It also degrades your responses: vendors who suspect an uneven playing field invest less.
The hard case: writing an RFP when you have an incumbent
This is the situation everyone faces and few handle well. There is a current provider. They may be doing fine. But policy, contract expiry, or governance requires a competitive process.
The dishonest version is an RFP written around the incumbent's capabilities so the outcome is safe. Experienced vendors recognise it within ten minutes, and you get two token bids and no genuine market test — which means you also learn nothing about whether your current arrangement is good value.
The honest version accepts that the incumbent has real advantages and levels only what can be levelled fairly:
- Publish the current-state detail the incumbent already has. Data volumes, integration inventory, ticket counts, known problem areas. Information asymmetry is the incumbent's largest structural advantage, and it is the one you can actually remove.
- Describe outcomes rather than the current implementation. Requiring the process you have today guarantees the provider who built it wins. Ask what the business needs to happen, not how it currently happens.
- Score transition risk explicitly and proportionately. The incumbent's zero-transition-risk advantage is legitimate — give it a weighting rather than letting it operate as an unstated preference in the room.
- Be honest in the market briefing. Saying "there is an incumbent, we are genuinely open, here is the current-state pack" attracts better bidders than pretending otherwise. Vendors talk to each other; a reputation for genuine processes gets you stronger fields over time.
And if the honest answer is that you are not genuinely open — that the process is a compliance formality — the fair thing is to run a shorter, clearly-scoped process rather than consuming six weeks of several companies' time for a foregone conclusion.
Before you publish
Pre-publication checklist
- 1Every requirement is individually numbered and marked mandatory or desirable.
- 2Every mandatory requirement is one you would genuinely disqualify a vendor over.
- 3Evaluation criteria are published with numeric weightings and a described scoring scale.
- 4Every question maps to a criterion. Anything unmapped is cut.
- 5A single pricing template is provided that all vendors must complete identically.
- 6Scope boundaries state what is out, not only what is in.
- 7The timeline gives at least four weeks to respond and does not span a major holiday.
- 8Someone outside the drafting group has read it and listed every ambiguity they found.
- 9You have confirmed the requirements are achievable by more than one vendor in the market.
The eighth item is the one that pays for itself. Give the draft to a colleague with no involvement and ask them to mark every sentence they could interpret two ways. Each one they find is a clarification question you will not have to answer under time pressure, or a pricing assumption that will not diverge between vendors.
What a good RFP earns you
A well-built RFP does not just produce a better decision. It produces a better field. Strong vendors are selective — they qualify hard, and a document that shows a clear requirement, published weightings, a realistic timeline, and a fair process reads as a deal worth pursuing properly. A vague one with 200 mandatories and a two-week window reads as a lottery, and the vendors you most wanted will quietly decline.
The effort compounds too. The structure, requirement library, and evaluation framework you build for one RFP are reusable, and the second one takes a fraction of the time.
On the other side of the table?
If you respond to RFPs as well as issue them, BidGenie handles the mechanical work—extraction, reuse, and compliance tracking—so your team can focus on the answer.
Get Started for Free