RFI vs. RFP vs. RFQ: How they differ and which is best for you

Why are RFIs, RFPs and RFQs important?

Making a large enterprise software purchase comes with major considerations, such as whether the vendor is reputable and whether the software meets requirements and aligns with budgetary considerations. To reduce risk and manage costs, companies often streamline and standardize the procurement and sourcing processes.

Depending on the company's size and business type, a dedicated procurement team might be charged with following detailed guidelines about the situation in which each type of document is required and the processes that they must follow to make sure purchases are unbiased and defensible.

What is an RFI?

Software buying teams use an RFI when they want additional data from vendors before completing the RFP or RFQ. The buying team might lack clarity on requirements, want more information on available options in the market or need details validated, which the vendors' industry experts can do. The RFI provides insight into the project's scope and requirements. Gathering RFI responses from multiple vendors is critical to gain an understanding of the marketplace.

Because of the level of effort required for completing an RFI, some vendors might not reply to a request for information unless an understanding exists that the company intends to move forward with the project.

What is an RFP?

A buying team might issue an RFP once they possess a good understanding of their project's requirements.

The RFP will list the requirements in detail, provide a recommended timeline and request pricing from the vendors. The buying team might ask specific questions about the vendor, such as the length of time they've been in business, completion proportion of similar projects, annual sales and number of staff. The RFP might include mandatory terms that the vendor must follow, such as a submission due date. Buying teams might disqualify a vendor from submitting a response if the response fails to meet the RFP's mandatory requirements.

In their RFP response, vendors explain how their tools or services will meet the requesting organization's requirements. An RFP is an opportunity for the vendor to differentiate themselves from competitors. The vendor's response to an RFP might include additional items that could be a value add, and they might also partner with one or more additional vendors to meet the RFP's obligations if they can't meet all the requirements on their own. In that case, the RFP response would include information about each vendor and detail how the combined effort would work.

The vendor's RFP response should indicate any associated fees, such as implementation costs, ongoing maintenance and support costs, pricing details for change requests and hourly rates for different roles on the project. For example, a project manager might charge a certain hourly rate, while a technical architect might charge a different rate. Fee negotiations can begin after selecting a vendor, but the RFP is an opportunity to identify each vendor's different financial requirements.

What is an RFQ?

Buying teams use an RFQ when they know exactly what they want and are only looking for vendor quotes. In an RFQ, the software buying team gives external vendors all the needed information so the vendors can offer a quote.

The vendor response will focus on the software price and any ongoing costs, such as annual licensing fees. Vendor responses should also include the proposed timeline.

Understanding the differences between RFI, RFP and RFQ

The following are three of the main ways in which an RFI, RFP and RFQ are different.

1. Timing of the document

The software buying team issues the RFI early in the buying process as the team learns about the available options. An RFI can be particularly helpful when a company has unique needs, and the buying team is looking for less well-known products.

The RFP and RFQ are issued after the RFI, once the software buying team has gathered any needed information to progress in the software buying process.

2. Knowledge about company requirements

The software buying team might still be figuring out what their company needs from a new product. An RFI can help the team decide what they are looking for from a vendor, particularly if they are trying something new and need to learn more about available options.

The RFP and RFQ are issued once the buying team has gained more knowledge. The buying team might move ahead to sending out an RFP or RFQ if the group knows what their organization needs from the start of the process and doesn't need to send out an RFI.

3. Differences in products

A software buying team might decide to send out an RFP or an RFQ based on perceived differences between the products they are considering.

For example, a software buying team might send out an RFQ because they don't think they need any further information beyond price. The team might believe that few differences exist between the products that they are considering. For example, a software vendor might sell their product through resellers and the same product is available from each reseller.

However, the software buying team sends out an RFP if the group believes that potential products are different enough that they need more information. An RFP asks for details about each vendor's product.

Which is best for your company?

Choosing the right document depends on where the software buying team is in the vendor selection process and their organization's needs.

Using all three documents might not be advisable, as doing so would be time-consuming and likely add little value to the outcome. In addition, vendors might not be interested in participating in a lengthy procurement process, given the level of effort required to respond to each request.

Eric St-Jean is an independent consultant with a particular focus on HR technology, project management and Microsoft Excel training and automation. He writes about numerous business and technology areas.