The RFP Process, Step by Step

The RFP process is the path from “we need a new system” to a signed contract with the supplier best placed to deliver it. This guide walks through each step for a software or services purchase, plus who should be on the buying team, an example timeline and the mistakes to avoid. If the terms are new to you, start with What is an RFP?

The RFP process steps at a glance

For a software or services purchase, the RFP process has twelve steps in four phases. A small purchase can fold some together.

1. Define the need and bring in stakeholders.
2. Confirm the budget and who approves it.
3. Research the market, with an RFI first if it’s new to you.
4. Write the RFP, including scoring criteria set in advance.
5. Issue the RFP with a realistic deadline.
6. Answer questions and issue addenda to every bidder.
7. Evaluate and score the proposals independently.
8. Run demos and, if needed, a proof of concept.
9. Check references.
10. Negotiate price, terms and the statement of work.
11. Award and debrief.
12. Sign the contract and kick off.

Who should be on the buying team

Name the buying team before you write the RFP. Each person brings requirements, and a requirement that turns up after the RFP is out means an addendum, a delay or a re-issue.

Keep the scoring group small enough to meet in one room. Ask everyone to declare conflicts of interest, such as a family member at a bidding vendor, before the RFP goes out.

Phase 1: RFP preparation

Preparation is the easiest phase to rush, and it decides whether vendors’ answers will be comparable.

1. Define the need and bring in stakeholders

Write down the problem in business terms: what’s broken, what should change, and what’s in and out of scope. Interview each team the purchase touches and mark each requirement must-have or nice-to-have.

Collect the figures vendors will price against: users by type, sites, transaction volumes, data to migrate and systems to connect. Vendors size their proposals from these numbers, so gaps here produce prices you can’t compare.

2. Confirm the budget and approval path

Agree a budget range for the whole contract term, covering one-time costs such as implementation, migration and training as well as recurring fees. Find out who approves spending at this level and what they’ll want to see, such as a business case or security review. Get the sponsor to sign off scope and budget before the RFP goes out.

Sharing a budget range stops vendors proposing something you can’t afford; holding it back keeps prices from clustering just under your number. Public-sector buyers should check whether their rules cover disclosing an estimate.

3. Research the market, and decide whether you need an RFI

Build a long list from peers, industry groups, review sites and existing suppliers. Send a request for information (RFI) first if you aren’t sure which products fit your size and industry or how they’re priced, or if the list is too long to evaluate properly. Use the answers to build a shortlist and sharpen your requirements. What is an RFI? explains when one helps, and the free RFI template gives you questions to start from.

Skip the RFI if you already have a credible shortlist. If research shows every supplier would deliver the same thing, a request for quotation (RFQ) may suit you better than an RFP. RFP vs RFQ vs RFI compares the three.

Phase 2: Write and issue the RFP

4. Write the RFP

Start from a template for your category, such as the CRM software RFP template, the ERP RFP template or the cybersecurity RFP templates, or browse the full RFP template library. Tailor it, then check that it includes:

• Requirements marked must-have or nice-to-have, with a response code for each: standard functionality, configuration, custom work or roadmap item.
• Specific questions about your hardest scenarios.
• A pricing table every vendor fills in the same way, covering one-time, recurring and renewal costs.
• Evaluation criteria and their weights.
• Response instructions: format, deadline, how to ask questions and who to contact.
• Your key contract terms, plus a draft statement of work if services are involved. The free SOW template gives you a structure.

Set the scoring weights before any proposal arrives. As an example only, a software RFP might split 100 points as functional fit 35, technical and security 20, implementation and support 15, vendor strength and references 10, and cost 20. Have legal review the terms before anything goes out.

5. Issue the RFP

Send the RFP to your shortlist, or publish it if your rules require an open process. Ask vendors to confirm by a set date whether they’ll bid, so you know early if the field is thin.

For a mid-sized software RFP, a response window of three to four weeks is a workable example; allow more if you want detailed implementation plans. Name one point of contact for all vendor communication, and ask the rest of the team not to discuss the RFP with bidders while it’s open.

6. Answer vendor questions and issue addenda

Set a deadline for written questions early in the response window. Answer every question in one document and send it to all bidders without saying who asked what. If you hold a bidders’ call, confirm anything said on it in writing.

If an answer changes the requirements, dates or terms, issue it as a numbered addendum and ask vendors to confirm receipt. When the change is large, extend the deadline.

Phase 3: Evaluate the proposals

7. Evaluate and score the proposals

Start with a compliance check. Confirm each proposal arrived on time, is complete and meets every must-have, and set aside any that fail under the rules you published.

Each evaluator then scores their own sections independently, using a rubric with defined 1-to-5 scores. Only then meet to compare. Talk through large gaps between scorers instead of averaging them away. Consider reviewing cost separately so price doesn’t color the functional scores, and compare total cost over the contract term. Send written clarification questions where answers are unclear, record the reasoning behind each score, and pick two or three finalists.

8. Run scripted demos and, if needed, a proof of concept

Write the demo script yourself, based on your hardest real processes. Send every finalist the same script and sample data in advance, score each demo with the same rubric, and ask for the people who would implement the product to attend.

Run a proof of concept when a demo can’t prove a requirement that matters, such as an integration with your systems or performance at your volumes. Agree the scope, duration, success criteria, data handling and who pays before it starts.

9. Check references

Ask for references that match your size, industry and scope, ideally implemented by the team that would work with you. Ask specific questions: what took longer than planned, how support handles escalations, whether the implementation team stayed, and what they would negotiate differently.

Phase 4: Negotiate, award and contract

10. Negotiate

Negotiate with your preferred vendor while a runner-up is still in the process, if your rules allow it. Once the others are released, you have less room to walk away.

Cover more than price: renewal caps, payments tied to accepted milestones, service levels, data ownership, exit assistance, and a statement of work with deliverables, named staff and acceptance criteria. For software, negotiate the subscription and the implementation SOW together, because each affects the other. Make sure the commitments in the proposal end up in the contract.

11. Award and debrief

Get final approval from whoever holds the budget, notify the winner in writing, and tell the other bidders the outcome promptly. Offer each unsuccessful vendor a debrief: explain how its proposal scored against your criteria and where it fell short, without revealing other vendors’ pricing or confidential information. Keep the full record, from the RFP and addenda to the scores and a short decision memo.

12. Sign the contract and kick off

For software, the contract package usually includes the subscription or license agreement, the order form, the SOW, service levels and, where personal data is involved, a data processing agreement. Check that the signed documents match what you negotiated.

Then give the delivery team the RFP, the winning proposal and the negotiated terms, so commitments made during the sale are tracked through implementation, and hold a kickoff with both project leads.

Example RFP timeline

This example schedule is for a mid-sized software or services purchase that starts with a short RFI, and runs about 17 weeks from kickoff to signed contract. A purchase with a known shortlist can move faster. An ERP selection can take longer: the example schedule in RFPhub’s ERP RFP template runs about 22 weeks.

Add time for board approvals, holidays, and any proof of concept that needs test integrations built.

Common RFP process mistakes

These are mistakes in running the process. For mistakes in the document itself, such as copying one vendor’s feature list, see What is an RFP?

• Starting without a sponsor or approved budget. The RFP can stall at award, after every vendor has done the work.
• Running the RFP after you’ve already chosen. The other vendors are bidding for nothing. Compete the purchase properly, or use the route your policy allows for buying direct.
• Answering one vendor’s question privately. It gives that vendor information the others don’t have.
• Squeezing the response window. Vendors that need time to price implementation will decline or send generic answers.
• Letting vendors run their standard demo. It’s built around the product’s strongest features. Give every finalist your script.
• Signing before the SOW is finished. Gaps left in the SOW can come back as paid change requests.

How public-sector RFPs differ

Government agencies, and organizations spending public or grant money, run RFPs under rules set by law, regulation and policy. Those rules vary by country, state and agency, and sometimes by the value of the purchase, so check with your procurement office or legal counsel before relying on any point below.

• Public advertising. You may have to advertise openly rather than invite a shortlist. Each US state posts solicitations on its own portal; see RFPhub’s state procurement portals directory.
• Fixed evaluation rules. Agencies generally must evaluate against the criteria they published. For US federal negotiated acquisitions, FAR 15.305(a) requires agencies to assess competitive proposals solely on the factors and subfactors specified in the solicitation.
• Formal communication. Contact usually runs through one named contracting officer or buyer, and some jurisdictions restrict bidders from contacting anyone else while a solicitation is open. Changes are issued as formal amendments (for federal negotiated acquisitions, see FAR 15.206).
• Limits on negotiation. Whether you can negotiate, and with whom, depends on the procurement method.
• Debriefs and protests. Unsuccessful bidders may be entitled to a debrief and able to challenge an award, sometimes under short deadlines. Under FAR 15.506(a), a federal offeror whose written request reaches the agency within 3 days after it is notified of the award is to be debriefed.
• Public records. Proposals may be subject to public records laws, so vendors should mark confidential material as the solicitation allows.

FAR references are to the text on acquisition.gov as of October 2026. The FAR is being rewritten under the Revolutionary FAR Overhaul, and many agencies, including DoD, GSA and HHS, have adopted a deviation based on the overhauled Part 15, which renumbers the three rules cited above. Under it, evaluation on the stated factors is at FAR 15.202(a), amendments are at 15.106, and debriefings are at 15.206-2 (before award) and 15.301-1 (after award), with the same 3-day window to request one. Check which version your solicitation applies before relying on a section number. This isn’t legal advice.

Frequently asked questions

How does the RFP process work?

A buyer defines what it needs, writes those needs into a request for proposal and sends it to suppliers that could meet them. The buying team scores the proposals against criteria set in advance, tests the finalists with demos and reference calls, then negotiates with its preferred supplier and signs a contract.

What are the steps in the RFP process?

Define the need, confirm the budget, research the market (with an RFI if needed), write the RFP, issue it, answer questions and issue addenda, score the proposals, run demos, check references, negotiate, award and debrief, then sign and kick off. Smaller purchases can combine some of these steps.

How long does the RFP process take?

It depends on the purchase and its approvals. The example timeline in this guide runs about 17 weeks from kickoff to signed contract for a mid-sized software purchase with an RFI first. A simple purchase with a known shortlist can move faster, and an ERP selection can take longer.

How do you prepare for an RFP?

Agree the problem and scope with every team the purchase affects, and collect the figures vendors need, such as users, volumes and systems to integrate. Confirm the budget and who approves it, and name the buying team. Then decide whether to go straight to an RFP or send an RFI first.

How many vendors should you send an RFP to?

Enough for real competition, and few enough that your team can score every response properly. For a software purchase, a shortlist of three to five is a workable size. Public-sector buyers may have to advertise openly, in which case any eligible supplier can respond.