How to Run a SaaS RFP That Doesn't Waste 6 Weeks

The need was identified in January. By February, the director had sent an RFP to seven vendors. By mid-March, six responses were in. A scoring committee of five people met three times over four weeks to evaluate the responses. Two vendors were shortlisted. Both gave demos. Neither demo was structured identically, so comparison was difficult. Internal debate continued. A decision was made in late April. Contract negotiation started in May. The tool went live in August.

Fourteen months from need identification to go-live. Forrester's research on B2B software purchasing cycles shows that drawn-out procurement processes are one of the leading causes of stalled or abandoned software projects — the cost isn't just time, it's the compounding cost of an unsolved problem.

The process wasn't incompetent. It was just designed for a different kind of organization. Enterprise procurement cycles are built for risk management at scale: multiple stakeholders, large contracts, long vendor relationships, regulatory oversight. For a 150-person company buying a $40K/year tool, this process doesn't manage risk. It creates it: the risk of slow decisions, team frustration, and the cost of a problem that went unsolved for a year.

A good SaaS RFP for a mid-market company takes three weeks, not six. Here's how to run one.

What a Lean RFP Actually Accomplishes

Let's be clear about what a SaaS RFP is and isn't for.

An RFP is for: making a defensible decision among multiple credible options, ensuring requirements are clearly defined, and creating a paper trail that justifies the selection.

An RFP is not for: discovering what you need (that's a requirements brief), running a procurement beauty contest, or creating a process so thorough that no one can second-guess the outcome. Before you write the first line of an RFP, make sure you've run the SaaS buying decision tree to confirm you should be buying at all — not building or extending an existing tool.

Most RFPs fail because they're trying to do all of the above simultaneously, and the weight of the process collapses the speed of the decision. The lean RFP separates these steps, keeps each one focused, and maintains momentum.

Phase 1: Requirements Brief (Day 1-2)

Before any vendor hears from you, write a one-page requirements brief. Not a thirty-page RFP document: a one-page brief.

The brief answers five questions:

1. What problem are we solving? One paragraph, no jargon, specific enough that someone unfamiliar with the team would understand the need.

2. What are the must-have capabilities? Maximum five. These are the capabilities without which the tool doesn't work for you. Be specific: "bidirectional CRM sync" not "integrations."

3. What are the nice-to-have capabilities? Maximum five. These inform scoring but don't disqualify vendors.

4. What does success look like at 90 days? One or two measurable outcomes. "Response time below 2 hours for 90% of tickets" is a success metric. "Better customer service" is not.

5. What are the constraints? Budget range (be direct), integration requirements, compliance requirements, timeline.

Template: 1-Page Requirements Brief

Project: [Tool Category] Selection — [Date]
Owner: [Name + Role]

Problem statement:
[2-3 sentences describing the current state and the cost of the problem]

Must-have capabilities (rank-ordered):
1.
2.
3.
4.
5.

Nice-to-have capabilities:
1.
2.
3.

Success metrics at 90 days:
1.
2.

Constraints:
- Budget: $[X] to $[Y] per year
- Integration requirements: [list]
- Compliance: [list]
- Timeline: live by [date]
- Decision authority: [name]

Circulate this brief to the decision-maker and one technical stakeholder for sign-off before any vendor outreach. This step prevents the most common RFP failure: requirements that shift mid-process because they were never clearly defined.

Phase 2: Vendor Shortlist (Day 3-5)

Invite three to five vendors. Not seven. Not ten.

The instinct to cast a wide net comes from fear of missing the best option. But inviting too many vendors creates four problems. For CRM specifically, a CRM buyers checklist can help you pre-screen vendors before they reach the formal shortlist stage, reducing the field without slowing down your process.

1. Vendors give generic responses when they're competing against a large field
2. Evaluation becomes unwieldy and comparisons become unfair
3. The process takes longer, eroding momentum
4. You signal low seriousness, which affects vendor engagement quality

How to build the shortlist in 48 hours:

• Start with Gartner Peer Insights, G2, or Capterra filtered by company size (your size) and industry
• Check which tools your peer network uses (ask in Slack communities, LinkedIn, direct outreach to two or three peer operators)
• Look at what the vendors you've already seen in demos actually compete against (ask the rep directly)
• Confirm the shortlist against your must-have capabilities and remove any vendor that visibly can't meet must-have #1 or #2

Send each shortlisted vendor a copy of the requirements brief plus two specific asks:

1. A 30-minute initial call to confirm whether they're a fit before going to formal demo stage
2. Written answers to your five must-have questions before the call

The 30-minute screening call eliminates vendors who aren't a fit without burning time on a full demo. Any vendor who can't answer your must-have questions in writing before a call is probably not operationally ready for your requirements.

Phase 3: Structured Demo Script (Week 2)

This is the step most mid-market RFPs skip, and it's the one that most affects decision quality. Running the vendor diligence checklist in parallel with Phase 3 lets you verify security, financial health, and support SLAs while your team is evaluating features in demos.

Without a structured demo script, each vendor shows you what they're proud of. You see different features in different contexts and comparing them becomes a subjective exercise that favors whoever gave the most polished presentation.

With a structured demo script, every vendor shows you the same scenarios in the same sequence. You're comparing how different tools handle the same problem, which is actually useful.

Building the demo script:

Take your five must-have capabilities and write one scenario per capability. The scenario should describe a real workflow from your business, not a generic use case.

Bad scenario: "Show us how your reporting works." Good scenario: "A sales manager needs to see, by rep, which accounts moved from Qualified to Proposal in the last 30 days, with the associated ARR. Walk us through how to build and share that view."

Include two or three scenarios from your nice-to-have list as bonus items if time permits.

15-Question Demo Script Template:

Send this to vendors the day before the demo. Tell them to walk through your scenarios, not their standard demo flow.

1. Walk through [Must-Have Scenario 1] from setup to output.
2. Walk through [Must-Have Scenario 2] end-to-end.
3. Walk through [Must-Have Scenario 3] including how an error or edge case is handled.
4. Walk through [Must-Have Scenario 4] including permissions and access control.
5. Walk through [Must-Have Scenario 5].
6. Show us the integration with [CRM/HRIS], specifically how [specific data object] syncs bidirectionally.
7. Show us what happens when the integration breaks: how is the error surfaced and resolved?
8. Show us the admin dashboard, specifically how a new user is provisioned and removed.
9. Show us the reporting view that [specific role] would use daily: how is it accessed and customized?
10. Show us a scenario where something goes wrong (a failed import, a permission error, a sync conflict) and how the system handles it.
11. Walk us through the implementation process for a company our size. What does week one look like?
12. What's on your roadmap for the next 90 days that's relevant to our use case?
13. What do customers your size typically struggle with in the first 60 days?
14. What's your SLA for a P1 outage and can you show us where that's documented?
15. If we signed today and went live in 30 days, what would you need from us and what would you deliver?

Allocate 60-75 minutes per vendor. Keep your own notes on a scoring sheet (see below) while the demo runs.

Phase 4: Scorecard Evaluation and Decision (Week 3)

After demos are complete, score each vendor on a weighted criteria matrix before any group discussion. This prevents anchoring bias, where group discussion converges on the most-discussed or most-recently-seen option rather than the best one. Research from Harvard Business Review on group decision-making shows that individual scoring before group discussion consistently produces more accurate assessments than open deliberation without a structured framework.

Weighted Vendor Scoring Matrix:

Each evaluator scores independently before a group meeting. The group meeting reviews the scores, discusses significant variances (where evaluators scored the same vendor differently), and makes the decision.

Assign a single tiebreaker (the decision-maker) before the group meeting starts. If scores are close and discussion doesn't resolve it, the decision-maker decides.

Common Pitfalls

Inviting too many vendors. Three to five is optimal. Beyond five, the process becomes a sorting problem, not an evaluation.

Writing requirements that favor the incumbent. This happens when the person writing the requirements brief has already seen one vendor's demo and unconsciously mirrors its features as "requirements." Circulate the brief to someone who hasn't seen any demos yet.

Skipping the structured demo script. Free-form demos are presentations, not evaluations. The structured script is what makes comparison possible.

Evaluation by committee without a tiebreaker. Committees without designated decision authority produce consensus-toward-the-middle outcomes, not best outcomes. Name the tiebreaker upfront.

Starting negotiation before the decision is final. Negotiating with multiple vendors simultaneously is appropriate only if you're genuinely undecided. If the decision is made and you're negotiating for better terms before signing, say so. That's a different conversation.

Decision Memo Template

Before signing, document the decision. Not a lengthy report: a one-page memo that captures the key facts for the record. McKinsey's analysis of high-performing procurement organizations identifies decision documentation as one of the most consistent practices separating teams that successfully rationalize software spend from those that don't.

Decision: [Tool name] selected for [use case]
Date: [Date]
Decision maker: [Name]
Evaluators: [Names]

Vendors evaluated: [List]
Selection rationale: [2-3 sentences on why this vendor]
Key terms: $[X]/year, [Y] seats, [Z]-year term
Implementation timeline: [start] to [go-live date]
Success metrics at 90 days: [from requirements brief]
Review date: [90 days from go-live]

Alternatives considered:
- [Vendor B]: [1 sentence on why not selected]
- [Vendor C]: [1 sentence on why not selected]

This memo takes fifteen minutes to write. It creates a record that's useful at the 90-day review, at renewal time, and if the decision needs to be defended internally.

Learn More

• The SaaS Buying Decision Tree: When to Buy, Build, or Bolt On — the framework to run before the RFP starts
• The Pre-Purchase Vendor Diligence Checklist for Mid-Market Buyers — the diligence layer to run in parallel with shortlisting
• Negotiating a SaaS Contract: Where the Leverage Actually Sits — what comes after the RFP selection
• Procurement vs Operations Ownership: Who Decides on SaaS and When — how to set up governance so the RFP process runs smoothly next time
• TCO Modeling for SaaS: Beyond the Sticker Price — the financial model to build alongside your RFP scoring matrix
• SaaS alternatives compared — vendor comparison context to inform shortlist decisions