Automation Insider: Why You Should Ditch RFPs for RFIs

Tracey Knight, Co-founder of Real Treasury

Requests for Proposals (RFPs) for software rarely accomplish anything. They are useless. Let me tell you why.

I was a sales engineer for many years. I’ve had multiple titles (treasury consultant, solutions consultant, demo woman, etc.), but they all meant the same thing.  I was part of the sales team paired up with a salesperson. Together, the salesperson and I were responsible for winning new business.

Talking to new prospects, understanding their current state, helping them understand a possible future state, responding to RFPs, giving demos, and more - that’s what I did for many years.

What you don’t know is this: I know a hundred different ways to say “yes”.  Or better yet, I know a thousand ways to avoid saying “no.” It was not technically in my job description, but it absolutely was a part of my job. I had to find ways to avoid responding “no” honestly so that we would score high on all RFPs.  When most of the questions are a simple yes, no, or some version of “partially,” “No” doesn’t get any points. And my job was to maximize the points received so that we could continue in the selection process.

Think about this. If you issue an RFP and get responses back from 5 vendors and all of them have 99% of the questions answered “Yes”, have you learned anything useful?  And how many hours were put into writing or modifying the RFP?  How many dollars did you pay a consultant to put one together for you?  How many hours did you spend reading and scoring the responses?  All those hours could have been better spent understanding and prioritizing your requirements and conveying them to vendors.

The idea of RFP’s being outdated isn’t new.  I found articles as far back as 2016 saying the same thing. And frankly, the case for eliminating them is even stronger now as cloud based software to which you just subscribe and use (and not install like in olden times where you had to be concerned with hardware requirements) is ubiquitous. Software as a Service (SaaS) tools aren’t new anymore.

SaaS are literally like leasing a car; just set it up (from simple onboarding to more complex implementations depending upon the sophistication of the tool) and use it. If your needs grow and change, call the vendor and ask them to add more modules or more users, whatever you need (for a price, of course).  Like calling (or doing it self-service online) your television streaming provider and adding another channel or turning off the ones you don’t watch much.

A Better Approach

Create a short Request for Information (RFI) asking for the background info you need to know about the vendor (things that management and/or procurement will expect you to be able to answer like:

·         Location

·         Date incorporated

·         Ownership structure

·         Number of current customers

·         Support hours

·         Indicative pricing

And a few very detailed questions requiring detailed answers (not yes, no, or partially) about your top requirements (not hundreds of questions from which you learn nothing.)

That's it. That's all.

This should be after you have your initial discovery calls and demos from relevant vendors (new ones and established ones). A quality RFI should help you narrow down the field of vendors to five or less. And it should make it easy to eliminate vendors whose indicative prices are far outside of your budget. From there, a short, pointed demo script can get you to your top choice.

The main idea is that the RFI should add value to the process and not waste time, neither yours nor the vendors. RFPs do just that -- waste the time of everyone involved.

A well-crafted, short, pointed RFI, however, can add great value. So push back on RFP requirements. Or create the short, specific RFI I have talked about here and just call it an “RFP.” The content is what matters, not the title.