RF-What? The Difference Between an RFI, RFP and RFQ

January 8, 2020

by Royce Grayson Morse, IOFM Managing Editor

Whether you’re asked to participate in information gathering prior to your organization purchasing a vendor solution for process improvement, or you’re the person spearheading that effort, you’ll be confronted with the “RF” puzzle. Which of the RF documents do you need to prepare to write and what goes into each of them?

Let’s break them down and explain how they differ.

RF simply means “request for.” In each case, you’ll be requesting material from prospective vendors that will help you with your decision. Each of these documents—the RFI, RFP and RFQ—involve a formal written request intended to yield information you’ll need to make important choices along the way.

While you may not need to write all three of them for any given project (and probably won't), each serves a specific purpose.

RFI = Request for Information

This is typically the first step in the RF process. You’re basically looking for general information about vendor solutions. It’s the getting acquainted stage—“tell me about yourself.” Later on, you’ll be able to leverage what you’ve learned at this step to decide which vendors are best suited to meet your needs.

Some of the information you can expect to get at this stage includes:

Vendor experience in your market
Company information, mission and vision
Specialty areas
Product offerings

You may discover at this point that a vendor’s solutions are more than your organization needs or can afford. Alternatively, you may find that certain vendors are specifically targeted to a single process while you need a broader spectrum of services. Basically, this is a general fact-finding stage that helps you learn more about what’s available, while ruling out vendors that aren’t a good fit.

RFP = Request for Proposal

Here, you’re asking selected vendors to offer their solutions to your specific problems. Typically, an RFP is used when your challenge is complex and you aren’t sure of precisely how it needs to be addressed.

In order to get solid responses, you’ll need to be very specific about what you need done. The RFP document you’ll write should be very detailed about what your desired results are, but you’ll want the vendors to describe how they will achieve them. Each vendor may approach this differently.

Because an RFP lays out your requirements and expectations in detail, this is usually the most time-consuming of the three RF documents to write. Reviewing and tabulating the responses is also quite a detailed process. More about that later.

Typically, you’ll want to discuss:

Purpose and scope of your project
Your existing process and desired outcome
Compliance considerations
Desired reporting and metrics
Any industry-specific concerns
Security and technology requirements

RFQ = Request for Quotation

If you already know the method by which you want the vendors to address your needs, you ask them to bid competitively on that specific solution. Often, an RFQ is only used when the organization already knows exactly what it needs and is simply looking for a price. RFQs aren’t really useful for a complex software implementation. They are more appropriate for repeated purchases of products or bulk services—say, per-page pricing for document scanning.

If you’ve prepared a detailed RFP, you will probably want to request pricing as part of that, making a separate RFQ unnecessary. The only real pitfall to requesting pricing in the RFP stage is when the vendor’s recommended solution later requires clarification or refinement, which may necessitate an amended quote.

Sorting It Out

At each RF stage, but most notably after an RFP, you’ll need to tabulate your results. Many organizations put together a matrix in a spreadsheet or similar tool, and record each vendor’s response to the questions posed so that everything is clearly organized and can be compared apples-to-apples. This matrix can be copied directly from the list of questions created for the RFP.

Each vendor’s scorecard can include a numerical value for each desired feature. For example, does the software do it well (3), somewhat well (2), sort of (1), or not at all (0)? Many organizations also like to weight some features more heavily than others by using a multiplier, and a spreadsheet can then calculate by using these weighting factors to give an aggregate score for each vendor.

For any significant investment in automation, you’ll also want to meet the vendors face-to-face. You may want to set up a series of meetings where the vendors come to make their formal presentations. Your sponsor can arrange to have top decision-makers present at this stage.

A caveat: Many vendors, especially large ones, have slick product literature and boilerplate language that they will pull from to create an attractive and impressive presentation. Don’t be dazzled by that to the degree that you don’t get your questions answered thoroughly. In fact, it may be a vendor with a less-fancy but more carefully considered presentation that’s the best fit. If you don’t get specific answers to specific questions, press the issue. And don’t forget to request referrals to the vendors’ other clients and talk to them.

You don’t need to look far to find horror stories of expensive software implementations that have failed to perform as expected, costing the company lots of money, eating up time, and potentially souring upper management on further investment in AP.

The RF process is your best opportunity to gather the information essential to improving your operation. While all three RF documents may not be necessary for an individual project (and probably won’t be), any significant investment will almost certainly require an RFP. While this can be a time-consuming and rigorous process, it’s definitely worth doing—and doing right.

Resources: