Have you ever responded to an RFP? A tedious process to put it mildly. A customer, through a very structured buying process, is attempting to gather as much information as possible about the various vendors they are evaluating. They want to know whether the vendor can meet their requirements.
Vendors are required to share extensive amounts of data about their capabilities, resources, and costs. Vendors frequently question the necessity of all of the information. Responding to an RFP is a lot of work; you would hope that the work is essential and relevant.
When you think about it, an RFP is an exciting tool for examining buying processes and what factors are essential to the customer. An RFP is a bit like an insurance policy. It exists to:
• Ease anxiety – extensive RFPs cover all the bases
• Assist in making the right decision – compare apples to apples
• Most importantly, the RFP helps avoid the wrong decision.
Customers begin with project definitions. They often prepare scope documents that detail all aspects of their needs. Facts, figures, configurations, requirements, costs, they’re all in there.
What is not spelled out in a scope document or RFP is anxiety level. Customers are not inclined to share the degree of perceived risk associated with a project.
From the vendor’s point of view, the perceived risk factor is an essential element to understand. The risk is not defined solely by the data. The risk is a series of interconnected circumstances and the vulnerability of those circumstances depending on the previously made decisions.
For example, a customer is contemplating buying an ERP system. The risk factor and anxiety associated with this project is probably high. An ERP system is the data foundation for an organization. It holds great promise for efficiency, coordination, collaboration, cost control, etc. It also has a risk of shutdowns, lost data, incompatibilities, lost customers, and lost jobs. An ERP installation is a big bet.
The scope document and RFP for an ERP purchase would be extensive. It’s many months if not many year processes. Customers dedicate considerable resources and money to the process to get to the point of sending out an RFP.
In this situation, a successful vendor realizes they need to understand more than the system requirements. The best vendors seek to understand the anxiety and risks of the project. This is not an engineering or design function. This is a people and relationship function.
Customers are not inclined to share their emotional anxieties with someone they do not know. Sharing goals and desired solutions is easy. That’s a matter of data. Sharing fears is another matter. That’s a matter of opening up and trusting someone.
Build a relationship that whose foundation is built on trust, and the customer will be more inclined to share the ramifications of a bad decision. In other words, what they are really worried about.
To build strong relationships, you need two things:
1. Strong communication skills — Strong communication skills foster clarity and understanding. Clarity and understanding build trust.
2. Demonstrable expertise — Show the customer you understand the personal, personnel, operational, and financial ramifications of their project. Demonstrate how your solution fits. Proving your expertise builds trust.
Building trust builds a stronger relationship. A stronger relationship frees the customer to share their anxieties and their perception of risk. Knowing this separates you from the masses.
Bottom Line – Ask yourself, on a scale of 1-5, how well you understand the customer’s anxieties and perceptions of risk. If you score a 1 or 2, work on the relationship. If you don’t, your RFP response will be a commodity offering, and the only thing the customer will look at is the price.