Melissa Swartz | No Jitter | November 10, 2013
If you want the job, you need to look knowledgeable and professional with your proposal.
Many organizations use a Request for Proposal (RFP) process for procuring goods and services. As an independent consultant, I have written many RFPs and evaluated even more responses (see “Do You Really Need an RFP? Because It’s Really a Pain…” ). The process offers a mechanism for providing large amounts of information that, when done properly, helps the buyers to evaluate and compare options. It is, in effect, a job interview. If you want the job, you need to look knowledgeable and professional with your proposal.
Responding to an RFP can require a significant amount of effort from a vendor; sadly, we see proposals in response to RFPs that guarantee immediate elimination from consideration. Here are some of the biggest mistakes to avoid when responding to an RFP:
1. Disclaimers stating that the information and/or pricing contained in the response is not binding. Organizations issue RFPs, in part, so that they can separate the hype from the reality in terms of capabilities and pricing. If your proposal does not contain accurate information that your company is willing to stand behind (without disclaimers), then it’s of no use to the purchasing organization.
2. Ignoring the Terms and Conditions in the RFP. Most organizations have standard terms and conditions that are included in the RFP so that responders know what the customer expects contractually. Bidders are expected to examine the terms and conditions and take exceptions, if any, in the response (except for some government entities which do not allow exceptions). If no exceptions are taken, evaluators assume that the vendor’s proposal accepts the terms and conditions. When responders ignore the terms and conditions initially, and then want to negotiate changes later, they look sloppy and unprofessional, and it can damage their credibility at a key point in the selection process.
3. Death by Boilerplate. While it is important to provide informative answers to questions in the RFP, many proposals we have reviewed use excessive boilerplate material to answer relatively simple yes/no questions. Often I have read 4-5 pages of material in response to a question and at the end of it I still do not know if the answer was “yes” or “no”. We recommend that responders answer questions with simple direct answers, and perhaps one to two sentences of explanation if needed. Additional detail can be provided in an appendix where appropriate.
4. Ignoring instructions (“Forget your format; I’ll use mine”). One of the fastest ways to be eliminated from consideration is to respond with a proposal that does not follow the instructions in the RFP in terms of format and/or information required. If your company cannot do what the customer requires before the sale is made, how can you be trusted to provide the goods or services the customer needs?
5. Answering questions with “To be provided upon award.” We see this response a lot, and it is another good way to be eliminated from consideration. When the RFP asks for references, or for a plan for implementing the goods or services, or sample documentation, you should provide that information. The customer is using your answers to evaluate your capabilities in these areas. If you don’t provide the information, then the evaluators have to assume that you either can’t demonstrate that capability or you don’t care enough to provide it. Either way, you are likely to be eliminated.
6. Not addressing the selection criteria. Most RFPs provide the criteria that the customer plans to use to evaluate the proposals. Your response should demonstrate how your proposed solution meets those criteria. Don’t expect the evaluators to know this; you must connect the dots for them, succinctly, if you want to move forward in the process.
7. Confusing capabilities that are included and priced with those that are additional-cost options. This typically is a result of boilerplate responses that tout every capability the solution offers and do not take into account what is actually being proposed. Unless optional features are clearly distinguished, customers feel like they are victims of a bait-and-switch maneuver, and this lessens your credibility. Most people won’t buy anything from someone they don’t trust.
8. Making assumptions rather than asking questions. Every RFP I have ever seen has a mechanism for submitting questions. If you are not sure about something, ask for clarification. You are putting a lot of effort into the proposal, so you should be sure that you understand what the customer is looking for. Many times, the work on the proposal is begun so late that the deadline for questions (if there is one) has passed before the respondents have given the proposal their full attention. This can easily result in an inferior response.
9. Submitting the proposal late. Some organizations do not accept proposals after the deadline; late proposals are automatically eliminated. Even if a proposal is accepted, it has given the impression that the respondent is unorganized and may not be able to handle the project. Don’t kill your proposal’s chances before it is even opened.
10. Using the wrong customer name. This seems so obvious that it should not even be mentioned, but we see it all the time. Of course this makes a negative impression and can be easily avoided. Too many sales teams submit proposals that they have not read and end up looking sloppy or uncaring. While putting together an RFP response is almost always a team effort, someone needs to review the final response and eliminate obvious errors and contradictory information.
Cloud experts offer guidance for differentiating between cloud offerings and the questions you need to ask.
Phone systems are now considered part of IT, but these 5 factors often surprise IT staff when changing to a new voice technology.
The mad scramble to remote work is over. Now the “return to work” process is beginning, and that brings many questions. Before moving forward, take a moment to assess your situation.
In Part 1 of this series, I discuss pitfalls involved in compatibility, pricing and facilities as SIP trunks are implemented.