RFP Template for Software Vendor Selection

I once sat through an RFP evaluation where all four vendors scored within two points of each other, because the RFP had asked 240 yes/no questions and every vendor had answered "yes" to nearly all of them. We had a spreadsheet full of green cells and no idea who to pick. The document had done the opposite of its job: it manufactured the appearance of comparison while erasing every real difference between the candidates.

A Request for Proposal is your one chance to make vendors do the comparison work for you — but only if you ask questions that force them to differentiate. Ask 240 checkbox questions and you get 240 checkmarks. Ask "quote us the three-year cost at 400 users and 2M API calls a month, itemized" and the vendors who were hiding their year-two ramp suddenly can't. The whole skill is asking the questions a vendor can't answer identically to their competitor, and refusing to ask the ones they can.

When to Use an RFP

RFPs are worth the time for:

• Significant spend (enough to warrant the formality)

• Multiple genuine candidates

• A purchase you'll commit to for years

• A category where vendors compete on more than price

Skip the RFP for:

• Small purchases or trials

• Categories with one obvious leader

• Tools the team can pilot quickly without procurement

• Cases where the requirements are too fluid to specify

The point is structured comparison. If you can compare informally, do that.

The Template

# RFP: [Solution Category]

## 1. About Us
[Brief context — who we are, what we do, why we're buying]

## 2. The Problem
[What we're trying to solve, in our words]

## 3. Scope
[What this RFP covers and explicitly doesn't]

## 4. Requirements
[Numbered functional and non-functional requirements]

## 5. Evaluation Criteria
[How we'll judge responses, with weights]

## 6. Response Format
[Structure of the response we expect]

## 7. Timeline
[Submission, evaluation, decision dates]

## 8. Contact and Process
[How to ask questions, where to submit]

A working RFP is 5-15 pages. Longer than that and vendors stop reading carefully; shorter and you miss things.

About Us and The Problem

Vendors respond better to RFPs that explain context. A vague RFP gets a generic response. A specific problem statement gets a specific proposed solution.

Bad: "We're looking for a CRM."

Good: "We're a 200-person B2B SaaS with a 12-person sales team. We need to replace our current CRM because it doesn't integrate with our product analytics, which means reps work without account context. Top priority is the analytics integration; secondary priorities are reporting and pipeline visibility."

Even the second example is short. It tells the vendor what to emphasize.

Requirements That Get Useful Answers

The requirements section is where most RFPs go wrong. Two failure modes:

Too long. 400 requirements that no one can answer carefully. Vendors check yes/yes/yes without thinking.

Too vague. "Easy to use" or "scalable" — meaningless. Every vendor claims both.

Better: 30-60 specific requirements, grouped by category, with clear yes/no/partial answers expected.

Example structure:

## 4. Requirements

### 4.1 Integration
- 4.1.1 Native integration with [specific tool we use]
- 4.1.2 Webhook support for [specific events we need]
- 4.1.3 SSO via [our IdP]

### 4.2 Data
- 4.2.1 Export raw data in CSV and JSON
- 4.2.2 API access to all data the UI shows
- 4.2.3 Retention configurable up to X years

### 4.3 Security
- 4.3.1 SOC 2 Type II certified
- 4.3.2 Encryption at rest
- 4.3.3 Audit logs for admin actions

Each requirement should be answerable with yes/no/partial. If the vendor needs to write a paragraph to explain, the requirement is unclear.

Distinguishing Must-Have from Nice-to-Have

Mark each requirement with M (Must) or N (Nice). Be honest. If you mark 90% as Must, the discrimination is meaningless.

A working ratio: 30-50% Must, the rest Nice. Vendors triage their effort accordingly.

Evaluation Criteria

Tell vendors how you'll evaluate. They'll write the response to match.

Example:

## 5. Evaluation Criteria

| Criterion | Weight |
|---|---|
| Meets must-have requirements | 30% |
| Integration with our stack | 20% |
| Total 3-year cost | 20% |
| Implementation timeline | 10% |
| Reference customers similar to us | 10% |
| Support and SLAs | 10% |

If you publish this, vendors will tilt their responses. That's fine — it gets them to address what you actually care about.

If you don't want to publish, at least know it yourself. Without an explicit weighting, the team's evaluation drifts to whoever's most enthusiastic in the meeting.

Response Format

Specify the format so responses are comparable.

• For requirements: a table with the requirement, yes/no/partial, and a brief explanation

• For pricing: itemized, including any usage-based components, with a 3-year total under stated assumptions

• For implementation: a phased plan with timelines

• For references: at least three customers similar in size and industry

The single most useful constraint: a page limit. "Responses should not exceed 25 pages." Forces vendors to focus.

Pricing Done Right

The most gameable part of an RFP. Vendors structure pricing to look favorable in the comparison while being painful in practice. The classic move: a low per-seat license with the connectors, the sandbox environment, and premium support broken out as line items you didn't think to ask about, so the "cheapest" bid on the scorecard is the one you end up writing the biggest checks to. I've seen a winning bid that was 20% under the field on license fees turn into the most expensive option once the implementation "services" — quoted separately, at a day rate — landed.

Defensive moves:

• Specify all assumptions. Number of users, data volume, API calls, etc. If a vendor's price depends on those, they need to use yours.

• Ask for the 3-year total cost, not just first-year.

• Itemize all variables. Hidden fees become visible.

• Specify what's included and what's not. Implementation, training, support — make vendors explicit.

• Ask for the cost of common changes. Adding 50 users, upgrading SLA tier, etc.

Compare TCO (total cost of ownership), not list price.

Timeline

Specify:

• Submission deadline: when responses are due

• Q&A window: when vendors can ask clarifying questions

• Shortlist notification: when finalists hear back

• Demo period: when shortlisted vendors will demo

• Decision: when you'll choose

• Implementation start: when work begins

A typical RFP cycle for a mid-sized purchase: 6-10 weeks from issue to decision. Longer for enterprise; shorter for SMB tools.

The Q&A Process

Every vendor will have questions. Decide upfront how to handle them.

Option 1 (clean): Vendors submit questions by a deadline. You answer all questions in one document shared with all vendors. Equal information.

Option 2 (informal): Vendors call or email questions ad hoc. Faster but harder to keep fair.

Option 1 is the right default for significant purchases. It ensures vendors aren't competing on access.

Demos and References

Shortlisted vendors get a demo session. Structure it so it's actually informative.

• Scripted scenarios. Give each vendor the same scenarios. Watch them handle yours, not their canned demo.

• Time-boxed. 90 minutes max. Long demos are uninformative.

• Q&A from the actual users. Not just the procurement team.

• Same evaluators across vendors. Otherwise you're not comparing.

For references, talk to two or three customers per shortlisted vendor. Ask:

• What was the implementation like?

• What's worked well?

• What's been frustrating?

• Would you choose them again, knowing what you know now?

• Where do they fall short?

The "where do they fall short" question is the most valuable — most reference customers won't volunteer it but will answer honestly when asked.

After the Decision

The RFP doesn't end with the decision.

• Capture the lessons in a procurement playbook for future RFPs

• Maintain a relationship with the runner-up (markets shift)

• Note explicitly what trade-offs you accepted by picking the winner — useful in 6 months when those trade-offs become real

Anti-Patterns

The 200-requirement RFP. Vendors check boxes without consideration. Useless data.

The reverse-engineered RFP. Written to match one specific vendor. The "selection" is theater.

The price-only evaluation. Cheapest wins, regardless of fit. Common in procurement-driven processes.

The endless Q&A. No deadline; vendors ask questions forever. Slows decision.

The single evaluator. One person reviews all responses. No diversity of perspective. Bias dominates.

Key Takeaway

A working RFP is 5-15 pages with 30-60 specific requirements, an explicit evaluation framework, and a structured response format. Specify must-have versus nice-to-have honestly. Ask for 3-year TCO with stated assumptions. Run a clean Q&A process where all vendors get the same information. Demo against your scenarios, not theirs. The point is to do the comparison work upfront so the evaluation is meaningful. A vague RFP produces vague responses and a decision driven by whoever sells best, which is not the same as who fits best.