The software selection process involves gathering extensive information from vendors to determine the best solution for your needs. Two common methods for soliciting vendor information are requests for proposals (RFPs) and requests for information (RFIs). While related, these serve different purposes in the procurement process. This article explains what an RFP and RFI are, when to use each, and provides tips for creating effective requests that deliver the data you need to make informed software decisions.
What is a Software RFP?
A request for proposal (RFP) is a detailed document issued when you have clearly defined software requirements and are ready to collect proposals from vendors. RFPs outline your functional and technical needs, allow vendors to propose solutions, and provide pricing quotes.
An RFP signals that you are ready to thoroughly evaluate options and expect vendors to respond with their best offers. It comes later in the buying journey when you have established selection criteria and are approaching final decisions.
RFPs should comprehensively capture requirements across features, technology stack, service and support expectations, implementation needs, and security and compliance factors.
Vendors respond with formal proposals that answer each requirement, provide product specifications, project plans, pricing and contract terms. Proposals demonstrate how the vendor would deliver the right solution customized to your needs.
What is a Software RFI?
A request for information (RFI) is used earlier in the procurement process when you are still researching options and determining what capabilities solutions must have.
RFIs help shape high-level solution requirements by gathering general information, capabilities, and rough cost estimates from software vendors. Think of it as a discovery phase.
The goal of an RFI is to understand what technology or features are available, get an overview of different products, and clarify what selection criteria are most important.
RFIs ask broad questions about company background, product direction and roadmap, implementation methodology, support services, and licensing models. This helps you frame the requirements for a future RFP once you are ready to evaluate specific solutions in detail.
Vendors provide responses with sales materials, feature overviews, and high-level pricing ranges rather than formal quotes. The focus is education rather than responding with a custom proposal.
When to Use RFPs vs RFIs
As a structured information gathering tool, an RFI comes before an RFP in the typical software selection journey:
- RFIs are used when you are in the early stages of research and need high-level information to develop selection criteria and requirements.
- RFPs are used once criteria are defined to collect detailed responses from shortlisted vendors you may purchase from.
An RFI helps determine what to buy while an RFP helps determine who to buy from.
Good candidates for issuing RFIs include:
- Evaluating new technology or solutions you have limited experience with
- Gathering inputs across departments to shape consensus requirements
- Developing an initial shortlist of leading vendors in a software category
RFPs are appropriate when you are ready to closely scrutinize a few final options, needing specifics to finalize the decision.
You can draw insights from RFIs to refine RFP requirements. Streamline the RFP process by only inviting RFI respondents who proved most aligned to provide full proposals.
How to Write Effective RFPs and RFIs
Follow these best practices when drafting RFPs and RFIs:
For RFPs:
- Outline clear, comprehensive functional and technical requirements. Avoid vague requests like “best of breed solution”.
- Classify must-haves vs. nice-to-haves so vendors focus proposals on what matters most.
- Ask specific questions about capabilities, integrations, training, implementation, customization options, and ongoing support.
- Request clear pricing breakdowns by module, user types, optional services, maintenance and SLA costs.
- Standardize responses by providing templates or tables for vendors to complete.
- Share detailed criteria and scoring methodology you will evaluate proposals against.
For RFIs:
- Keep questions high-level around vendor background, product information, markets served, implementation approach, support model and rough order-of-magnitude pricing.
- Focus on gathering features and technology overview to shape your future requirements. Don’t dive into specifics prematurely.
- Use open-ended questions to allow vendors to demonstrate knowledge and guide you rather than respond to detailed feature checklists.
- Avoid questions about contractual terms, commitments, pricing structures at the RFI phase or you may see lower response rates.
- Develop a large potential vendor list for RFIs to discover all players rather than shortlisting too early. Cast a wider net initially.
For both RFPs and RFIs:
- Concisely explain your key business drivers, pain points, and objectives. Gives helpful context.
- Set clear timelines for response with at least 3-4 weeks for quality submissions.
- Evaluate non-disclosure agreement needs to protect sensitive information.
- Use secure portals rather than email for transmission and collection of responses.
RFPs and RFIs require substantial effort but deliver outsized rewards through detailed vendor information to support smart software decisions. RFIs expand perspective in the early research phase while RFPs provide winner-take-all proposals from finalists.
Take care to match the request type to where you are in the buying journey. Rushing to RFPs without clear requirements wastes resources. Overdoing RFIs can delay decisions.
Leverage these structured processes as tools that evolve understanding rather than creating rigid constraints. The inputs can validate needs while revealing new considerations.
With strategic, focused requests for information and proposals, you gain invaluable insights while signaling an organized, methodical selection approach. This builds credibility with vendors as a knowledgeable buyer and drives higher quality responses. The ultimate result is better software decisions backed by real-world data.
