The traditional RFP exists for a good reason: it forces a structured, comparable evaluation instead of an ad hoc one. In practice, for most mid-sized decisions, it has become a process that consumes weeks of internal time to produce a comparison that could have been made in days with the right shortlist to begin with.
The document isn't the problem. The distribution is.
Writing a good RFP is genuinely useful work: it forces clarity about requirements. The part that breaks down is who receives it. Sent broadly, an RFP attracts vendors optimised for winning RFPs, a specific and different skill from being the right operational fit. Sent narrowly, based on whoever the team already knew, it defeats the purpose of running a competitive process at all.
Responses are not apples to apples
Every vendor answers an RFP in the format that flatters them most. Comparing five responses that each frame pricing, implementation timelines, and support commitments differently is genuinely difficult work, and it's work that has to happen before any real evaluation can start, not as part of it.
What actually needs to happen
The useful parts of an RFP process, defined requirements, a structured comparison, documented reasoning for the final decision, do not require the twelve-week timeline that usually comes attached. They require the requirements to be captured clearly once, and the vendor options to already be qualified before the comparison starts, so the comparison itself is fast because it is between vendors who have already cleared a real bar.
That is a sourcing problem more than a documentation problem. The RFP template was never the bottleneck. The unfiltered vendor pool it gets sent to is.