How to Write an RFP: A Step-by-Step Guide for Procurement Teams

Bad RFPs produce bad proposals. When your document is vague, structurally inconsistent, or missing key evaluation criteria, vendors fill the gaps with marketing copy — and you end up comparing apples to press releases. The problem isn't vendor quality. It's the signal you sent.

This guide is for procurement teams who want to run a process that generates responses they can actually use: comparable, specific, and grounded in your real requirements.

A good RFP does three things:

1. Communicates your requirements precisely — vendors know exactly what you need, not what you might need.
2. Structures responses so they're comparable — every vendor answers the same questions in the same format.
3. Signals that you're a serious buyer — vendors allocate their best people to well-run processes.

A bad RFP does the opposite. It uses vague language ("scalable," "enterprise-grade," "best-in-class"), asks open-ended questions with no word limits, and buries evaluation criteria in an appendix — or omits them entirely. The result: a stack of 60-page PDFs that each tell a different story, none of which maps to your actual decision criteria.

The fix isn't a better template. It's a better process.

The most common RFP mistake is writing the document before the internal alignment work is done. If your stakeholders disagree on what you're buying, vendors will sense the ambiguity and respond to it.

Before you open a document, answer these questions internally:

• What problem are we solving? Be specific. "We need a contract management system" is not a problem statement. "Our legal team is tracking 400+ active contracts in spreadsheets, leading to missed renewal windows and inconsistent clause language" is.
• What are our hard requirements vs. preferences? Separate must-haves from nice-to-haves. Must-haves are pass/fail. Preferences are scored.
• What does success look like in 12 months? Define measurable outcomes, not feature lists.
• Who are the internal stakeholders? Identify everyone who will use, integrate with, or be affected by the solution. Get their input before issuing the RFP, not during vendor Q&A.
• What are our constraints? Budget range (even a rough one), timeline, integration requirements, data residency, compliance obligations.

Document this in an internal requirements brief. The RFP is a translation of that brief into a vendor-facing document — not a substitute for it.

An RFP sent to 20 vendors is a waste of everyone's time, including yours. Serious vendors deprioritize wide-net RFPs because the win probability is low. You also create an evaluation burden you can't realistically handle.

A well-run process typically involves 4–8 vendors. To get there:

• Start with a long list. Use analyst reports, peer recommendations, your existing vendor relationships, and tools like VendorXray to identify candidates.
• Issue an RFI if the market is unfamiliar. A Request for Information is a lightweight document — 5–10 questions — designed to help you understand the vendor landscape before committing to a full RFP process. See our guide on RFP vs. RFI vs. RFQ for when to use each.
• Shortlist based on basic fit. Before issuing the RFP, do a quick pass: Does the vendor serve companies your size? Do they have relevant industry experience? Can they meet your hard technical requirements? Eliminate vendors who clearly don't fit before you ask them to invest in a response.

Document your shortlist rationale. If a vendor later asks why they weren't included, you need a defensible answer.

A well-structured RFP has eight required sections. Don't add sections for the sake of thoroughness — every section you add is a section vendors have to respond to and you have to evaluate.

Two to three paragraphs. Who you are, what you do, and why you're running this process now. Give vendors enough context to understand your business without writing a company history.

What you're buying and what you expect it to accomplish. Be specific about scope boundaries — what's included and, importantly, what's not. If you're not buying implementation services in this engagement, say so.

This is the core of the document. Break requirements into categories (functional, technical, security, compliance, support) and use a structured format:

"Must-have" requirements are pass/fail. A vendor who can't meet them is disqualified. "Preferred" requirements are scored. This structure forces internal clarity and makes vendor responses directly comparable.

What you need to know about the vendor as a company: years in operation, customer references in your industry, financial stability, team size, support model. Ask for specific evidence, not assertions. "Please describe your customer support model" produces better responses than "Do you have good customer support?"

Specify the format you want. If you need a per-seat SaaS price, ask for it in a table. If you need professional services scoped separately, say so. Unstructured pricing responses are nearly impossible to compare. Include your expected contract term and volume so vendors can price accurately.

Timeline expectations, resource requirements on your side, training approach, and go-live criteria. If you have a hard deadline, state it here.

Tell vendors how you'll score their responses. This is not optional. Vendors who know your criteria write better responses. You also create accountability for your own evaluation process. A typical weighting might look like:

Submission deadline, format requirements (PDF, online portal, etc.), Q&A window dates, expected decision date, and primary contact. Be realistic about your timeline. If you tell vendors you'll decide in three weeks and it takes three months, you damage your credibility for the next process.

This step is listed separately because teams routinely skip it. They finalize the RFP, send it out, and then figure out how to score responses after they arrive. That's backwards.

Before the RFP goes out:

• Finalize your scoring rubric. For each criterion, define what a 1, 3, and 5 looks like. Don't leave it to evaluator interpretation.
• Assign evaluators to sections. Your security team scores security. Finance scores pricing. Don't ask one person to evaluate everything.
• Agree on how you'll handle disqualifying responses. If a vendor can't meet a must-have requirement, is that automatic elimination or does it depend on context?

Doing this work upfront means your evaluation process is consistent and defensible. See How to Score RFP Responses for a detailed scoring framework.

Every RFP should include a structured Q&A window — typically 5–10 business days after issuance. Vendors will have questions. How you handle them matters.

Centralize all questions. Require vendors to submit questions in writing to a single email address or portal. No phone calls, no sidebar conversations with stakeholders.

Publish all Q&A to all vendors. Every question and answer goes to the full shortlist, anonymized. This keeps the process fair and prevents any vendor from gaining an information advantage.

Answer questions completely. Vague answers to specific questions signal that you don't know your own requirements. If a vendor asks a question you can't answer, that's a sign you need to do more internal alignment before responses come in.

Hold the line on the deadline. Extensions undermine the process and signal disorganization. Build enough time into your timeline that you don't need them.

When responses arrive, resist the urge to read them narratively. A well-written response is not the same as a good response. Evaluate against your rubric, not against your impression.

Practical guidelines:

• Score independently before discussing. Have each evaluator score their sections before the group convenes. Group discussion before independent scoring produces anchoring bias — everyone converges on the first strong opinion.
• Flag non-responses. If a vendor didn't answer a question, that's a data point. Don't fill in the gaps with assumptions.
• Document your scores with rationale. "Strong" is not a score. "Vendor demonstrated native SAML 2.0 integration with evidence from two reference customers in financial services" is a score.
• Conduct reference checks before finalist selection, not after. References take time. Build them into your process before you're in final negotiations.

After scoring, convene your evaluation team to review aggregate scores, discuss outliers, and agree on a shortlist for demos or best-and-final offers.

Writing the RFP in isolation. Procurement owns the process, but the requirements belong to the business. If IT, legal, finance, and end users aren't in the room during requirements definition, you'll get change requests after vendor selection — the most expensive time to make them.

Asking for too much. A 100-question RFP signals that you haven't prioritized. Vendors either answer superficially or invest disproportionate time on a low-probability opportunity. Aim for depth on fewer, higher-signal questions.

Omitting budget guidance. "We can't share budget" is a common instinct, but it produces proposals that are either wildly over or under your range. Sharing a budget band — even a wide one — helps vendors propose solutions that are actually viable.

Treating the RFP as a legal document. RFPs are procurement tools, not contracts. Overly legalistic language slows the process and signals adversarial intent before the relationship has started.

Ignoring vendor fit signals. A vendor who submits a generic, clearly templated response to your specific requirements is telling you something. A vendor who asks sharp, specific questions during Q&A is also telling you something. Pay attention to both.

Moving goalposts after issuance. If your requirements change materially after the RFP goes out, issue an amendment and extend the deadline. Don't evaluate responses against criteria that weren't in the original document.

Procurement teams consistently underestimate how long a well-run RFP process takes. A realistic timeline for a mid-complexity procurement:

If your stakeholders are expecting a vendor selected in four weeks, have that conversation now. Compressing the timeline produces shortcuts that show up as regret after contract signature.

A well-written RFP is one part of a larger sourcing process. For related guidance:

• Not sure whether you need an RFP, RFI, or RFQ? Start with RFP vs. RFI vs. RFQ to choose the right instrument for your situation.
• Once responses are in, use a structured scoring approach. How to Score RFP Responses walks through a rubric you can adapt for most procurement categories.
• To see how VendorXray structures vendor intelligence for procurement teams, review the VendorXray sample report.