The RFP request is the buyer's opening move. Before any supplier writes a proposal, someone on the buying side has to decide what they need, turn that into a clear document, and send it to the right vendors in a way that produces responses they can actually compare. Get the request right and evaluation is straightforward; get it wrong and you spend weeks trying to score answers to questions you never really asked. This guide is written for the buyer. It covers what an RFP request is, how to prepare one, a step-by-step for writing and issuing it, a request structure you can copy, how to send it and run the questions window, and how to evaluate what comes back.
Key takeaways
- An RFP request is the buyer's document; its quality decides how comparable the responses will be.
- Preparation matters more than wording: define the need and the evaluation criteria before you write.
- Publish scoring weightings in the request so suppliers answer what you will actually reward.
- Run one clear questions window and share every answer with every vendor to keep the process fair.
What an RFP request is
A request for proposal is a formal document a buyer issues to invite suppliers to propose how they would meet a defined need. The RFP request is that document and the act of sending it. It is not a purchase order and not a bare price enquiry; it is a structured brief that says here is what we are trying to achieve, here is what we want you to tell us, here is when we need it, and here is how we will judge your answer. The supplier's reply is the proposal, which we cover from their side in the RFP proposal guide. This article stays on the buyer's side of the table and focuses on getting the request itself right.
The reason the request deserves this much attention is simple: everything downstream depends on it. If your questions are vague, the responses will be vague. If you forget to publish your evaluation criteria, suppliers guess at what matters and you receive answers you cannot line up against one another. A good RFP request is really a scoring instrument in disguise. Every question you include should map to something you intend to measure, and every requirement should exist because a decision depends on it.
When to send an RFP request
Not every purchase needs a proposal. The test is how well you can specify what you want. When you already know the exact item, quantity and standard, and the only real variable is price, an RFQ is faster and fairer. When you know the outcome you need but not the precise solution, and you want suppliers to bring their expertise to the how, an RFP request is the right tool. Choosing services, software or anything where approach and capability differ between vendors is classic RFP territory, because you are buying a method as much as a price.
This choice sits inside the wider discipline of procurement, and getting it right early saves rework. Sending an RFP request for something you could have specified with an RFQ wastes everyone's time; sending an RFQ for something genuinely complex forces suppliers to quote against a specification that does not fit, and you lose the chance to see how they would actually solve your problem.
How to prepare before you write
The strongest RFP requests are written last, after the thinking is done. Before you open a document, settle four things. First, the need: what business outcome are you actually buying, and how will you know it has been met? Second, the scope: what is in and, just as important, what is out, so suppliers price the same thing. Third, the budget and timeline, at least internally, so you can judge whether responses are realistic. Fourth, and most often skipped, the evaluation criteria and their weightings. Decide how you will score before you ask a single question, because those criteria tell you which questions are worth asking.
Write your evaluation criteria before your questions. If you cannot say how a question will be scored, it probably does not belong in the request. Working backwards from the scorecard keeps the document tight and makes the responses genuinely comparable.
It also pays to agree who is involved. A request written by one person in isolation tends to miss what other stakeholders care about. Pull in the people who will use the product or service, the person who holds the budget, and anyone with a compliance or technical veto. Capturing their requirements now is far cheaper than discovering a deal-breaker after the responses arrive.
Writing and issuing the request, step by step
With the preparation done, writing the request becomes assembly rather than invention. A dependable sequence looks like this:
- State the objective. Open with the business outcome in plain language, so suppliers understand the problem before the detail.
- Define the scope. Set out what is included and excluded, with any volumes, standards or constraints that shape the work.
- List the questions. Ask specific, answerable questions that map to your evaluation criteria, and number them so responses stay aligned.
- Publish the criteria. Show how you will score, with weightings, so suppliers invest effort where it counts.
- Set the timeline. Give the issue date, the questions deadline, the response deadline and the expected decision date.
- Explain submission. State the required format, the response length limits and exactly how and where suppliers must submit.
- Confirm the terms. Note any mandatory requirements, contractual conditions and the fact that the request is not a commitment to buy.
Once the draft is complete, have someone who was not involved read it as if they were a supplier. If they cannot tell what you want, what you will score, or when it is due, the vendors will not either. Fix those gaps before you issue, because you cannot quietly patch a request that is already in suppliers' hands without treating everyone equally.
A request structure you can copy
You do not need to design the layout from scratch. Most effective RFP requests follow the same skeleton, and reusing it makes your requests easier for regular suppliers to answer. The core sections are an introduction and background, the objective, the scope of work, the questions or requirements, the evaluation criteria, the timeline, the submission instructions and the terms. Keep the introduction short, put the scope and questions at the heart of the document, and never let the evaluation criteria be an afterthought at the end.
Objective and scope
The outcome you want and the boundaries of the work, so every vendor prices the same thing.
Questions
Specific, numbered questions that each map to something you intend to score.
Evaluation criteria
How you will score and the weight of each factor, published so suppliers can prioritise.
Timeline and terms
Key dates, submission format and the conditions that govern the process.
A template is a starting point, not a straitjacket. Tailor the questions to each purchase, but keep the structure stable so your evaluation team and your regular vendors both know where to look. Consistency of format across your requests is one of the quiet marks of a mature buying function.
Sending it out and running the questions window
Deciding who receives the request is a strategic choice, not an afterthought. Send it to too few suppliers and you narrow your options; send it to too many and you create work for everyone with little gain. A shortlist of qualified vendors who can genuinely deliver, drawn from your own research and any prior relationships, usually beats a mass mailing. This is where the request feeds directly into strategic sourcing: you are not just buying, you are shaping a competitive field.
Once the request is out, the questions window is the most important phase to manage well. Suppliers will spot gaps and ambiguities you missed, and their questions are a gift. Set a clear deadline for questions, answer them properly, and share every question and answer with every supplier, not just the one who asked. Answering privately hands one vendor an unfair edge and undermines the integrity of the whole exercise. Professional bodies such as the Chartered Institute of Procurement and Supply treat this even-handed transparency as a basic principle of fair sourcing, and it protects you as much as the suppliers.
Evaluating the responses
When the responses land, the work you did on criteria pays off. Score against what you published, using the weightings you set, and record why each score was given. Evaluating one factor at a time across all responses, rather than reading each proposal end to end and forming an overall impression, keeps the process fair and defensible. A simple scoring frame keeps everyone honest:
| Criterion | What you are testing | Typical weight |
|---|---|---|
| Capability | Can the supplier actually deliver the outcome? | High |
| Approach | Is the proposed method sound and low-risk? | High |
| Price | Is this good value, not simply the cheapest? | Medium |
| Support | What happens after go-live, and how well? | Medium |
| Compliance | Are all mandatory requirements met? | Pass or fail |
Treat mandatory requirements as a gate, not a score: a response that misses one is usually out before the weighted scoring begins. For everything else, let the numbers do the heavy lifting, then use a moderation discussion to sense-check the outcome rather than to override it. If the winner surprises the room, revisit the scores and the evidence, not the criteria. Changing the rules after you have seen the answers is how sourcing exercises lose their credibility and, sometimes, end up challenged.
Common RFP request mistakes to avoid
- Vague objectives. If suppliers cannot tell what outcome you want, their responses will be equally unfocused.
- No published criteria. Hiding how you will score forces suppliers to guess and leaves you with answers you cannot compare.
- An unrealistic timeline. Too short a window produces thin, hedged, and often pricier responses.
- Answering questions privately. Sharing an answer with only one vendor breaks the fairness of the whole process.
- Sending to the wrong list. A poorly chosen supplier list wastes effort and narrows or floods your options.
- Changing the rules late. Moving the goalposts after responses arrive undermines the result and invites challenge.
Most of these come down to the same discipline: decide what you want and how you will judge it before the request goes out, then run the process exactly as you promised. A little rigour at the front removes most of the pain at the back.
Running the request with ProcureWave
Everything above is possible over email and spreadsheets, and for a single small request it is fine. As soon as you are managing several vendors, a questions window and a scored evaluation, though, the admin starts to swamp the thinking. A sourcing platform keeps the request, every supplier question and answer, and all the responses in one place, enforces a single deadline for everyone, and makes scoring structured and auditable. That is exactly what ProcureWave's sourcing module is built to do. It lets you issue a request from a reusable template, run the questions window fairly with answers shared to all, and score responses against your published criteria without wrestling a dozen attachments.
The result is less version chaos, a cleaner audit trail, and more of your time spent on the decision rather than the paperwork. If you would like to see how it handles your own request and evaluation process, you can book a demo and walk through it with us.
Getting the request right
A good RFP request does most of the work of a good sourcing decision before a single response arrives. Define the need, agree the evaluation criteria, write specific questions that map to them, choose the right suppliers, and run an open, well-timed questions window. Score against what you published, gate on the mandatory requirements, and resist the urge to rewrite the rules once you have seen the answers. Do that and evaluation becomes a formality rather than a fight, because you asked exactly the questions you needed answered. For the process end to end, see our RFP guide, and for the view from the other side of the table, our RFP proposal guide shows how suppliers turn your request into a winning bid.
Frequently asked questions
What is an RFP request?
An RFP request is the document a buyer prepares and sends to invite suppliers to propose a solution to a defined need. It sets out the objective, the scope of work, the questions each supplier must answer, the timeline and, crucially, how the responses will be scored. It is the buyer side of the process our RFP guide covers end to end.
How is an RFP request different from an RFQ?
An RFQ asks for a price against a fixed, well-understood specification. An RFP request is used when you know the outcome you want but not the exact solution, so it asks suppliers to propose an approach as well as a price. Send an RFQ when you can already specify everything; send an RFP request when you need suppliers to help shape the how.
How long should suppliers get to respond?
It depends on complexity, but two to four weeks is common for a substantial request. Give suppliers enough time to ask questions, involve their own experts and price properly. A rushed window produces thin, hedged responses that are harder to compare and often more expensive.
What makes a good RFP request?
Clear objectives, a defined scope, specific questions, a realistic timeline and, above all, published evaluation criteria with their weightings. A request that tells suppliers exactly what you will reward draws out responses you can actually score side by side.
Do I need software to run an RFP request?
No, but it helps once the process grows beyond a handful of suppliers. A sourcing platform keeps every question, answer and response in one place, enforces a single deadline and makes scoring auditable, which is hard to manage over email once several vendors are involved.
Want to see this in your own numbers?
Book a tailored demo and we will show ProcureWave running on scenarios that match your business.
Get in touch