RFI, RFQ, & RFP: What’s the Difference?

If you’ve worked for any length of time on the vendor side of a B2B business, you’re likely accustomed to receiving RFPs from clients interested in your products and services. Short for “request for proposal,” an RFP is a document that a company searching for enterprise-level services can use to get an overview of offerings and costs from several vendors at once. If a vendor participates in an RFP, it answers a series of questions about the products, services, methodology, and costs that will go into fulfilling the company’s needs.

Given how large a role the RFP plays in enterprise software, it shouldn’t be surprising that many of us have strong feelings on how they should be structured. My colleague Chris wrote an article arguing that many companies are “getting the RFP process wrong.” By not performing enough due diligence prior to sending out the RFP, he wrote, a company is alienating the very vendors that could best serve its needs.

Another problem plaguing the modern RFP is that, in many cases, it isn’t an RFP at all. It’s become an umbrella term that’s applied to RFPs, RFIs, and RFQs. All three have certain features in common, but each has clear distinctions, and understanding those distinctions will vastly improve your selection process as you search for a vendor. Here’s a rundown of each document’s distinctions and guidance on when you should use it:

RFI

Short for “request for information,” the RFI is really a preliminary document used by companies that don’t understand the marketplace they’re about to enter. In the case of a company searching for a customer relationship management (CRM) solution, for instance, it would use an RFI if it had no prior experience with CRM and wanted to gain an understanding on the range of options in the CRM space.

Because the RFI is more of a fact-finding document, you’ll want to ask open-ended questions, ones that allow the vendor to talk about its full range of offerings. Typically, the RFI will state the broad business challenges you’re having, and then the vendor can tailor its response within the context of those challenges. Oftentimes, the vendor will explain its position in the marketplace (for instance, what industries it specializes in), how it licenses its product, and what other fees you can expect.

RFP

An RFP, “Request for Proposal,” is a document that asks vendors to propose solutions to a customer’s problems or business requirements. An RFP is usually what follows an RFI; in fact, it’s rare that a company will go from an RFI to an RFQ (for reasons that will become clear below). An RFP should contain much more specificity in terms of what a company’s needs are by outlining the business goals for the project and identifying specific requirements that are necessary for the work being requested. The key to this document is that there is sufficient detail to give vendors the context they need in order to propose a valid solution, yet it still needs to allow enough leeway for the vendors to apply creativity and best practices to fulfill those needs.

RFQ

Short for “request for quotation,” the RFQ is an even more detailed document that drills down to the exact specifications required by the company. In a situation where an RFQ is used for a B2B software project, the company knows enough about its current system and exactly how it wants to change or improve it in the future.

Unlike the RFP, which allows for the flexibility of the vendor to suggest creative solutions to the problem, a company deploying an RFQ isn’t looking for creativity, but rather for the vendor to deploy the software using predetermined specifications. Typically, the RFQ contains a table that lists each requirement and then asks the vendor to assess its ability to meet that requirement. The vendor then will specify whether it can meet the requirement out of the box, whether it will require some configuration, whether it will require some custom code, or whether it will require leveraging a third-party vendor.

Which one is best?

As a vendor, I come to this issue with certain biases, but I prefer the RFI-RFP route as opposed to an RFQ. Why? Typically, clients that come to us with an RFQ tend to be closed-minded in their approach. Because you’re not opening yourself to the creativity and the accumulated institutional knowledge of the vendor, you’re basically signaling that you don’t want to learn anything new, nor do you want to open yourself up to new approaches.

In my experience, many customers mistakenly name their RFQs as RFPs, but when you go to respond you are not allowed to “propose” a variety of solutions and have subsequent conversations about your proposed options, which is the purpose of an RFP. In these cases, you are simply asked to fill out a list of requirements and give detailed costs for each line item, which by its definition is simply an RFQ.

An RFQ is appropriate for a project in which you are adding on to or augmenting an existing system. For instance, Cobalt offers cloud migration services for organizations already using Microsoft Dynamics 365 products and services. If you’re moving from Dynamics CRM on-premises to Dynamics 365 online, an RFQ would be the right thing to send our team in the assessment phase. 

However, I believe the RFQ approach is inappropriate for a project in which you are planning on implementing an entirely new system. We also offer CRM implementation packages and Microsoft Dynamics 365 for small business success for companies that want a new, enterprise-level CRM at a price small businesses can afford. In those cases, we would much rather see an RFP, and here’s why.

You can easily fall into the trap of requesting that vendors provide you a system that does exactly what your current system does. If that is the case, then you need to take a hard look at why you are implementing a new system in the first place and make sure your business goals are in line with your project goals.

Typically, you are looking to implement a new system because what you are using today doesn’t meet your needs. If that is truly the case, how can you know what systems out there will meet your needs unless you give the vendors the flexibility to discuss your current business processes in a collaborative manner?

If you simply put out a list of detailed needs based on what you do today, you will get responses in which vendors try to shoehorn their solutions to meet that list and miss the opportunity to truly change your business for the better. The RFQ mentality, in short, undercuts some of the positive changes you can see in your business processes as a whole. And turning a blind eye to change is the quickest path to a company’s obsolescence.

Get More from Your CRM Investment 

Small businesses (with 1-500 employees) rely on Cobalt’s deep Microsoft Dynamics 365 expertise to get more from their CRM investment. Explore the ways Dynamics 365, the Power Platform, and Cobalt’s Engagement Dynamics software help small businesses, associations, certification organizations, and accreditation bodies. You will find refined, affordable solutions for sales, marketing, e-commerce, and all the ways you need to connect with whoever you serve.

I hope you will be able to put these distinctions and best practices about the differences between an RFI, RFP & RFQ to use right away. Explore other articles like this on our blog, and get a better sense for when you should send out an RFP in our Definitive Guide to Choosing a New AMS/CRM for Your Association.