Request for Information (or RFIs) are designed to allow organisations to compare products. RFIs are essentially primers for making an informed decision when buying new products or services. The truth is, a majority of RFIs/questionnaires are poorly designed and do everything but help organisations make an informed decision.
What is wrong with the way most RFIs are answered?
A typical RFI has a quick introduction to the company, the project timeline and details on the project the organisation needs a product for. Most RFIs dwell extensively on features that the company is looking for in a new product. Here in, lies the first problem with RFIs: Features. Features are useless without a business context or a “what do you want to achieve?” question to go with them.
To illustrate, let's assume company X is looking for a paid web browser to install on their machines across the organisation. Imagine a typical meeting that would take place around RFI preparation. The heads of customer service, IT, development and all departments get together, they spend time and come up with a list of relevant features. Someone compiles the list, makes an excel sheet and then sends it out to browser companies A, B and C as an RFI.
What happens? Companies A, B and C come back with check marks against the features mentioned in the RFI. On the surface, all 3 browsers meet the feature requirements. This is a reality of products that are on offer in the market today. On a feature level most products are similar or they appear similar.
So now that browser companies A, B and C have sent back RFIs with the same set of answers, how does X choose which product to go with?
At this point one of two things usually happen which kill off a fair contest.
Either organisation X goes with the cheapest browser on offer (because clearly A, B and C are all the same!) or the organisation chooses a product based on the team’s past experience and preferences because they rather not change what they know.
So what actually happened? Did organisation X find the right solution for their organisation? The answer is maybe.
On the bright side, if the organisation is willing to commit to a product evaluation post the RFI then the right product still has a fighting chance of making it to the final stages (assuming the sales team can show value).
What to do when you get sent a RFI
Get the business context
A common mistake made by sales individuals is allowing customers to drag you down to a feature level. If you get an RFI that is talking about features, jump on a call and get business context around the features in question. If the feature list is too long, figure out which are the must haves. Then find the business context around the must haves. Remember, your responses should give out value not a yes or no.
To continue on the browser example from earlier:
Because everything was dragged down to a feature level, no one actually stopped to consider why they needed feature 10.1 in the first place. To elaborate. Let’s assume feature 10.1 was real time web page debugging and all three browsers answered yes to this.
If a sales individual in Company A asked a question like “Why do you need feature 10.1?” and the answer from organization X was “We need this to be able to assist our development team when they are making web pages for prospective customers.”
Then the answer to feature 10.1 from Company A would be “We offer an in built development tool that allows developers to debug but also execute any modifications in real time. This replaces the need for any additional development tool.”
Now imagine similar responses all across the RFI!
Pricing will probably be the last consideration on everyone’s mind in organization X. The first thing they will try to find is the right fit for their needs.
If your customer is not playing ball and refuses to give you the context. Then the next best thing to do is to research and reply with value responses that you think will be relevant given the current organisation.
For example, an organization looking for a browser for their customer service team does not need to know how good your debugging tools are.
Get the organization to do a product evaluation
Get the organisation to commit to a product evaluation post the RFI. This will only work if you know who the competition is and confident you will get the prospect to do a product evaluation.
If this happens, it will allow you enough time to understand requirements and offer value. I have known sales individuals to quickly fill out RFIs with just yeses and nos.
Knowing that the real opportunity to influence the decision is when the prospect signs up for a trial or a demonstration of the product.
Understand the true purpose of the RFI
Another reason why companies send out RFIs is as part of due diligence. Sometimes companies have already made up their mind on what product they need and are simply looking to get more quotes or RFIs to complete due diligence. You can escape wasting time on these ‘opportunities’ by being up front with the prospect and clearing any doubts you have on the purpose of the RFI.
Remember there is no one way to skin a cat. You should be willing to try different approaches and learn from your mistakes.