Short answer: A request for proposal (RFP) is a document a buyer issues to invite vendors to propose a solution to a defined problem and quote a price for it. It is used when the buyer knows the outcome they need but not the best way to get there, which is what separates it from a request for quote. A typical RFP process runs six to twelve weeks: define requirements, shortlist vendors, issue the RFP, answer questions, score responses against a published rubric, run demos, and award, then paper the deal with a master agreement and a statement of work.
Last updated: July 2026.
An RFP is a good tool used badly more often than almost anything else in back-office operations. Done well, it forces a buying team to agree on what they actually need before vendors start selling to them. Done badly, it is a 40 page questionnaire that punishes the vendors who answer honestly and rewards the ones with a dedicated proposal team.
What is a request for proposal (RFP)?
An RFP describes a business problem, the constraints around it, and the criteria on which proposed solutions will be judged. Vendors respond with their approach, their evidence, their team, and their price. The buyer compares responses against a rubric and selects.
The defining feature is that the solution is open. You are asking vendors how they would solve it, which means you get to compare approaches, not just prices. If you already know precisely what you want and only need a number, you are running the wrong process.
RFP vs RFQ vs RFI
| RFI (information) | RFP (proposal) | RFQ (quote) | |
|---|---|---|---|
| You know | The problem, not the market | The outcome, not the solution | Exactly what you want to buy |
| You are asking | Who exists and what is possible | How would you solve this, and for how much | What is your price for this exact thing |
| Vendors submit | Capability summaries | Approach, evidence, team, price | A price, and delivery terms |
| Decided mainly on | Nothing, it is research | Weighted criteria, price is one of several | Price, against fixed specifications |
| Typical duration | 2 to 3 weeks | 6 to 12 weeks | 1 to 3 weeks |
The common mistake is running an RFP when an RFQ would do. If your requirements are fully specified and interchangeable across vendors, asking six companies to write bespoke proposals wastes their week and yours. The reverse mistake is worse: running an RFQ on a complex problem, getting six prices for six different interpretations of the work, and comparing them as if they were the same.
The RFP process, step by step
| # | Step | Owner | Typical time |
|---|---|---|---|
| 1 | Define the problem, requirements, and budget range internally | Business owner of the process | 1 to 2 weeks |
| 2 | Agree the scoring rubric and weights, before you see any vendor | Buying team | 2 to 3 days |
| 3 | Build a shortlist of 4 to 6 credible vendors | Procurement or the process owner | 1 week |
| 4 | Issue the RFP with a clear timeline and a single point of contact | Procurement | 1 day |
| 5 | Run a question window, answer in writing, share answers with all bidders | Procurement | 1 to 2 weeks |
| 6 | Receive responses, check compliance, score independently before discussing | Each scorer | 1 week |
| 7 | Shortlist 2 to 3, run structured demos against your own scenarios | Buying team | 1 to 2 weeks |
| 8 | Reference calls, security and insurance review, pricing clarification | Process owner, security, finance | 1 week |
| 9 | Award, debrief the losers, negotiate, sign | Procurement and legal | 2 to 4 weeks |
Step 2 is the one teams skip and the one that decides the outcome. Weights agreed after you have met the vendors are not weights, they are a rationalization of the vendor someone already liked.
What to include in an RFP
Keep it as short as the decision allows. Every question you ask, you have to read six times.
- Company and context. Who you are, what you do, and the scale that matters (users, transactions, locations, volumes).
- The problem. The current process, what breaks, and what a good outcome looks like in measurable terms.
- Scope. What is in, and explicitly what is out.
- Requirements. Split into must have and nice to have. If everything is a must have, you will get one compliant bid and it will be expensive.
- Technical and integration needs. Systems the solution must connect to, data formats, and any migration involved.
- Security, compliance, and insurance. The standards you require and the evidence you will accept.
- Commercial model. How you want to be priced (per seat, per transaction, fixed fee) and the pricing template all bidders must complete.
- Evaluation criteria and weights. Published, in the document. This is not a courtesy, it is what gets you comparable answers.
- Timeline. Question deadline, response deadline, demo window, award date.
- Submission rules. Format, page limits, contact, and what disqualifies a bid.
Publishing the weights feels like giving away the exam, and that is exactly the point. You want vendors optimizing for what you actually care about, not guessing.
How to score RFP responses
Score independently, in writing, before the scorers speak to each other. Group discussion first is how one confident voice becomes a consensus. A simple weighted rubric, with each vendor scored 1 to 5 per criterion:
| Criterion | Weight | Vendor A | Vendor B | Vendor C |
|---|---|---|---|---|
| Fit against must have requirements | 30% | 5 | 4 | 5 |
| Approach and implementation plan | 20% | 3 | 5 | 4 |
| Evidence of comparable delivery | 15% | 4 | 5 | 2 |
| Total cost over three years | 20% | 5 | 2 | 3 |
| Security and compliance posture | 10% | 4 | 5 | 3 |
| Support model and named team | 5% | 3 | 4 | 4 |
| Weighted score | 100% | 4.25 | 4.05 | 3.80 |
Two rules keep this honest. Score total cost of ownership over three years, including implementation, migration, training, and the price increase at renewal, not the year one license. And treat any criterion a vendor cannot evidence as unscored rather than assumed, because the confident answer and the true answer are not correlated in a proposal document.
Ask for evidence, not claims
The security and compliance section is where RFPs get gamed most. Everyone claims to be secure. Ask for the artifact instead of the assertion: the SOC 2 Type 2 report rather than "we are SOC 2 compliant," the current certificate of insurance with your required limits rather than "we are fully insured," the data processing terms rather than "we take privacy seriously." Serious vendors have these ready, since they already track their controls and obligations in one place, and the ones who do not will take three weeks to produce a document they claimed to have.
The same applies to references. Ask for a customer of your size, in your industry, who went live in the last 18 months. Any vendor can produce a happy reference from their best account.
How long does the RFP process take?
Six to twelve weeks from issuing the document to awarding, for most mid-market purchases. Add two to four weeks for contract negotiation before anyone starts work. Complex enterprise deals with security review and legal redlines routinely run four to six months. If someone tells you an RFP will take three weeks, they have either pre-selected the vendor or they have not scheduled the demos yet.
Who writes the RFP?
The person who owns the process being fixed writes the problem, the requirements, and the evaluation criteria. Procurement owns the format, the timeline, the fairness of the process, and the commercial template. Legal owns the terms that will follow. When procurement writes the requirements alone, you get a document that is procedurally perfect and describes a problem nobody has.
What happens after the award?
The RFP does not become the contract, although it usually gets attached to one. The winning proposal and the RFP are typically incorporated by reference into a master service agreement, with the actual work defined in a statement of work that turns the vendor's promises into deliverables, dates, and acceptance criteria. This is the step where enthusiasm from the demo has to survive contact with specifics.
Watch for the gap between what was promised in the proposal and what appears in the SOW. It is not usually dishonesty, it is that the proposal was written by a salesperson and the SOW by a delivery lead. If a capability mattered enough to score, it belongs in the SOW as a deliverable with an acceptance test, not in a slide.
Common RFP mistakes
- Running a process with a predetermined winner. Vendors can tell, they stop bidding, and you lose the only leverage the process was supposed to create.
- Asking 200 questions. Response quality falls, small vendors drop out, and you end up selecting on proposal-writing skill.
- Requirements copied from a vendor's website. If your must haves are one vendor's feature list, you have written a specification, not a competition.
- No published weights. You get incomparable responses and an argument at scoring time.
- Ignoring the switching cost. Migration, retraining, and integration rebuilds are frequently larger than the license difference you are optimizing.
- Forgetting the exit. Ask, in the RFP, how you would get your data out and in what format. The answer tells you a great deal about the vendor.
Do small companies need an RFP?
Rarely, for purchases under a few tens of thousands of dollars a year. The cost of running a formal process, on both sides, exceeds what it saves. A structured two week evaluation, with the same discipline (write down your requirements first, score against them, ask for evidence, run your own scenario in the demo), gets most of the benefit without the ceremony. The parts of the RFP worth keeping at any size are the written requirements and the rubric agreed before you meet anyone. The rest is process for organizations that need to defend the decision later.
Whatever size you are, the vendor you select becomes part of your operation, which means the selection is really a decision about the process you are going to run for the next three years. Score it accordingly, and hold the shortlisted vendors to the same standard of paperwork you would expect from anyone joining your vendor onboarding process.