Ask anyone who's run a serious vendor RFP how long it took, and the honest answer is usually longer than they'd like to admit. Not because the vendors were slow — because the internal process sprawled: a shortlist that grew from five vendors to eleven because nobody wanted to say no to a referral, a scoring rubric that got rewritten twice mid-process, and a final decision that took three more weeks because the person who needed to sign off hadn't been in the room for any of it.
None of that is inherent to RFPs. A tightly run process, with the scope locked before a single vendor is contacted, can go from kickoff to signed contract in six weeks. Here's the version of that process we've seen work consistently, across CRM, marketing automation, and agency selections alike.
The framework below isn't ours alone — it's a synthesis of how procurement teams at several mid-market companies described their process to us, stripped down to the steps that showed up at every company regardless of what they were buying. What varies by category is mostly the weighting of the scorecard and the depth of the security review, not the underlying sequence of steps.
Key takeaways
- Cap the shortlist at five to seven vendors before you write a single RFP question — a longer list doesn't produce a better decision, it produces a slower one.
- Send every vendor the same questions on the same deadline; staggered RFPs make honest comparison nearly impossible.
- A weighted scorecard, agreed on before responses come in, prevents the most common failure mode: picking the vendor the loudest stakeholder already liked.
- Reference calls should go to the finalist's current customers, not the customers the vendor hand-picks — ask for someone who churned, too, if you can get it.
Why RFPs usually take three months longer than they should
The single biggest time sink isn't vendor response time — it's internal indecision before the RFP is even sent. Scope creep during the requirements-gathering phase, a shortlist that keeps growing as stakeholders add "just one more vendor to consider," and a scoring framework that gets negotiated after responses have already arrived (so it ends up reverse-engineered to favor whoever's already the frontrunner) are the three patterns that reliably turn a six-week process into a six-month one.
Building the shortlist before you write a word of the RFP
Lock the shortlist first, separately from writing the RFP itself. Pull five to seven vendors from a mix of category research, analyst comparisons, and peer referrals, and get sign-off from every stakeholder on that list before any requirements document exists. This sounds backwards — shouldn't the requirements come first? — but in practice, letting stakeholders see the shortlist first surfaces objections ("we already tried that vendor and it failed") far earlier than if those objections show up after three weeks of RFP-writing.
What to actually ask for
A usable RFP has six sections, no more: company background and relevant client references, functional requirements mapped to your must-haves, pricing broken out by tier and any required add-ons, implementation timeline and team, security and compliance documentation, and a section for the vendor to tell you what they think you're missing. That last section is underused and often the most revealing — it tells you whether a vendor actually read your requirements or just mail-merged a template response.
Keep the functional requirements section itself short and specific rather than exhaustive. A 200-line feature checklist invites vendors to check "yes" on everything, because nobody wants to be the one response with visible gaps, and a wall of checkmarks gives you nothing to differentiate on. We've had better luck asking vendors to walk through three or four realistic scenarios drawn from our actual workflow — "describe exactly how a rep would reassign fifty accounts after a territory change" — because a scenario response reveals how a product actually behaves in a way a feature checklist never does.
Setting a realistic timeline
A six-week process breaks down roughly like this: one week to finalize the shortlist and requirements, one week for vendors to receive and begin responding, two weeks for vendors to complete written responses (less than that and you'll get rushed, generic answers), one week for scoring and reference calls, and one week for negotiation and contracting. Compressing any of these stages below what's listed tends to produce worse decisions, not faster ones — vendors asked for a one-week turnaround on written responses will often reuse a template response wholesale rather than answering your specific scenarios, which defeats the purpose of asking for them.
Scoring without playing favorites
Build the weighted scorecard before any response arrives, and get every stakeholder to agree to the weights in writing. Weight categories by what actually matters to your business — if implementation speed matters more than feature depth this year, say so explicitly, rather than discovering it after scoring is already underway. When scores come back close, resist the urge to add a new weighting category just to break the tie in a preferred direction; that's usually a sign the real decision is happening on a factor nobody put in the rubric, and it's worth naming that factor honestly instead.
The reference-call questions that matter
Don't waste a reference call asking "are you happy with the product" — everyone the vendor offers you will say yes. Ask instead about the implementation timeline versus what was promised, what surprised them about the pricing after the first year, and what they'd do differently if they signed again today. If you can get a reference from a customer who churned — some vendors will give you one if you push — that single call is often more useful than the three happy-customer calls combined.
Download the RFP scorecard template
A weighted scoring spreadsheet with the six RFP sections above pre-built as scoring categories, ready to send to your stakeholders before responses come in.
Negotiating from a position with options
The entire point of running a disciplined multi-vendor process, rather than falling in love with one vendor early, is that it gives you real negotiating leverage at the end. If your finalist knows they're the only option left, they know it in the pricing call too. Keep your second-place vendor warm through the negotiation — not as a bluff, but because a genuine fallback changes what you're willing to accept, and vendors can usually tell the difference between a real alternative and an empty threat.
Before you sign, push on three contract terms that rarely show up in the RFP itself but matter enormously later: what happens to your data and configuration if you leave at the end of the term, whether price increases at renewal are capped, and what the actual exit timeline looks like if the relationship doesn't work out. None of these cost the vendor anything to put in writing if they're confident in the relationship, and a vendor who resists writing them down is telling you something about how they expect the relationship to go.