How to Write an RFP: A Section-by-Section Guide
Published on October 8, 2026 in RFP Guides
This guide shows how to write a request for proposal (RFP) for software or IT services, section by section: what goes in each part, an example line for each, and how to write requirements that vendors can’t brush off with a one-word “yes”. For the buying process around the document, see the RFP process guide. If RFPs are new to you, What is an RFP? explains the basics first.
Before you write: the inputs you need
Gather these first. Each gap comes back later as a vendor question, an addendum or a price you can’t compare.
- An agreed problem and scope, signed off by your sponsor.
- The figures vendors price against: users by type, sites, volumes, data to migrate and systems to connect.
- A budget range for one-time and recurring costs over the contract term.
- Requirements from every team the purchase affects, each marked must-have or nice-to-have.
- A shortlist. If you can’t name one yet, send an RFI first.
- Your standard terms and security questionnaire, from legal and security.
- A template for your category, such as the CRM software RFP template, the ERP RFP template or the cybersecurity RFP templates, or any template in the RFP examples library.
The sections of an RFP, in order
This order suits most software and IT services RFPs: context first, then what you need, then how vendors should answer. [Brackets] mark your own details.
1. Introduction and background
Say who you are, why you’re buying now and what’s wrong with the current system. Vendors use this to decide whether to bid, so keep it short.
Example: “[Company] sells industrial parts through distributors in [regions]. Sales and customer service work in separate systems, so neither team can see a customer’s full history.”
2. Objectives
List the outcomes you want, in priority order. Describe results rather than features, and let vendors propose how to get there.
Example: “Give sales and service one shared record for each customer account, and retire [current system] before its contract ends on [date].”
3. Scope
State what’s in and out of scope, with your figures. For services such as implementation or data migration, describe the work clearly enough to price, or attach a draft statement of work; the SOW template gives you a structure.
Example: “In scope: [number] sales users, [number] service agents, migration of account and case history from [current system], and integrations with [ERP] and [email]. Out of scope: marketing automation.”
4. Requirements
Group requirements by type (functional, integration, security, implementation and support), give each one an ID, and lay them out in a table with columns for priority, response code and vendor comment. Mark each one must-have (a vendor that can’t meet it is out, so keep this list short) or nice-to-have (it earns extra points). Then require a response code on every line, so a “yes” says how:
| Response code | What the vendor is saying |
|---|---|
| Standard | Works out of the box in the edition priced |
| Configuration | Met through settings, without code |
| Custom | Needs code or a custom integration; say who maintains it |
| Third party | Needs a partner product or add-on; name it |
| Roadmap | Not available yet; give a release date |
| Not available | Can’t be met |
Example: “FR-14. A sales manager can reassign all of a departing rep’s accounts and open opportunities in one step, with a record of who made the change. Priority: Must-have.”
5. Vendor questions
Requirements show what a product can do. Questions show how the vendor works. Ask about your hardest scenarios and the team and plan behind the implementation, and set a length limit for each answer.
Example: “Describe a customer of similar size that moved from [current system] to your product. What took longer than planned, and what did you change as a result?”
6. Pricing table
Give every vendor the same pricing sheet, so proposals priced per user, per module or per transaction still line up. Separate one-time from recurring costs, ask for list price, discount and net price, and cover the whole contract term, including renewal increases.
| Cost item | One-time | Per year |
|---|---|---|
| Subscription: [user type], per user | ||
| Implementation and data migration | ||
| Training and premium support | ||
| Any other cost, listed by the vendor |
Example: “Price a [three]-year term on this sheet, list any other cost in the last row, and state the maximum annual increase at renewal.”
7. Evaluation criteria and weights
Say what you’ll score, how much each part counts, how must-haves are checked and what scale you’ll use, for example 1 to 5 with each score defined. Set the weights before any proposal arrives. Public-sector buyers may have to publish the criteria and their relative importance, so check your rules. The RFP process guide covers how to run the scoring.
Example (the weights are an example only): “Proposals that meet every must-have will be scored out of 100 points: functional fit 35, technical and security 20, implementation and support 15, vendor strength and references 10, cost 20.”
8. Submission instructions
Say what to send, in what format and where. Name one contact, explain how questions are asked and answered, and require vendors to keep your numbering.
Example: “Submit your narrative response as one PDF, plus the completed requirements and pricing sheets in their original format, through [portal or email address] by the proposal deadline in Section 9.”
9. Timeline
List every date from issue to contract, with a time and time zone for each deadline, and have other sections refer here so dates can’t drift out of step. The RFP process guide’s example response window for a mid-sized software RFP is three to four weeks.
Example: “RFP issued [date]. Questions due [date and time]. Answers to all vendors [date]. Proposals due [date, time and time zone]. Target signature [date].”
10. Terms and conditions
Include your key contract terms or a draft contract, confidentiality rules, how long proposals must stay valid, and statements that you aren’t obliged to award a contract and that vendors bear their own costs of responding. Have legal review it before issue.
Example: “List every exception to the attached terms in the exceptions table, with the wording you propose instead.”
How to write requirements vendors can’t answer with “yes”
A vague requirement gets a “yes” from every vendor, which tells you nothing. A strong one names who needs to do what and how you’ll check it, so a vendor that only partly meets it has to say so. Keep to one need per line, because a bundled requirement lets a vendor answer “yes” when it meets half. Describe the task rather than a product feature, and say what proof you want: a demo with your data, a document or a reference.
| Weak | Strong | Why it’s better |
|---|---|---|
| “The system should have good reporting.” | “Sales managers can build a pipeline report filtered by region, product and expected close date, and schedule it to be emailed weekly, without IT’s help. Show this in the demo.” | Names the user, the task and the proof. “Good” can’t be scored. |
| “Must integrate with our ERP.” | “Sync customer accounts and open orders with [ERP] in both directions every [interval]. State whether this uses a standard connector, middleware or custom code, and who maintains it through upgrades.” | Defines the data, direction and frequency, and exposes custom work a bare “yes” would hide. |
| “Must support single sign-on.” | “Support single sign-on with [identity provider] using SAML 2.0 or OpenID Connect, in the edition you have priced. Show a user signing in during the demo.” | Names the standard, and catches a feature sold only in a more expensive edition. |
RFP best practices and writing tips
- Number everything. When vendors answer against your IDs, evaluators can read every answer to FR-14 side by side.
- Send response forms. Requirements and pricing sheets that vendors fill in come back in a layout you can compare.
- Tie every question to a score. If an answer won’t change a score or a decision, cut the question.
- Define your terms once. Say what “user” or “site” means and use it the same way throughout. Reserve “must” for must-haves.
- Ask for assumptions. Vendors should list what their price and plan assume, so you can see what a low number leaves out.
- Get a cold read. Ask someone outside the project to read the RFP as a vendor would. If they can’t tell what to price, vendors won’t be able to either. Then have IT, security, finance and legal sign off the sections they own.
Common RFP writing mistakes
These are mistakes in the document’s wording and structure. For broader ones, such as making everything a must-have, see What is an RFP?
- Adjectives you can’t measure. “User-friendly”, “fast” and “scalable” can’t be scored. Name the task, volume or standard you mean.
- The same requirement twice. It can be scored twice and answered differently in each place.
- Rules buried in the requirements. Submission rules and contract terms hidden in a requirements table are easy to miss.
- Leftover template text. Before you send, search for unfilled [brackets] and another project’s name.
- A pricing sheet that doesn’t match the scope. If data migration is in scope but has no pricing row, some vendors will price it and some won’t.
Frequently asked questions
How long should an RFP be?
Long enough for vendors to price and answer accurately, and no longer. Most of the length comes from the requirements, so cut any requirement every vendor will meet or that won’t change your decision.
How long does it take to write an RFP?
It depends on the groundwork. In the 17-week example timeline in RFPhub’s RFP process guide, writing the RFP and scoring rubric, plus legal review, takes weeks 5 and 6, after the requirements and budget are agreed.
Should you include your budget in an RFP?
It’s a trade-off. A budget range stops vendors proposing something you can’t afford, while holding it back keeps prices from clustering just under your number. Public-sector buyers should check whether their rules cover disclosing an estimate.
Can I use a template to write an RFP?
Yes. Pick one for your category, then tailor it: delete requirements that don’t apply, add your own figures and integrations, and set your own priorities and weights.
What’s the difference between an RFP and an RFP response?
The RFP is the buyer’s document: it describes the need and asks for proposals. The RFP response, or proposal, is the vendor’s answer, and it should follow the buyer’s structure, numbering and pricing sheet. Vendors can start from RFPhub’s RFP response template.