RFPs: When to Respond and when to Walk Away
There has been some recent discussion on LinkedIn about when it's worth responding to a request for proposal and when it's better to walk away. Of course, the best case scenario is that you are developing the RFP on behalf of the client. Odds are you will get the contract based on your existing relationship. So what happens if you suspect a competitor has developed the RFP? Usually it's obvious based on the content and level of detail. I recently saw one that had several questions relating to very specific hardware functionality, and these questions were phrased as though only one type of hardware would be placed—it screamed copier dealer.
There may be cases where the end-user actually does develop their own RFP, but if they are inexperienced in managed print services, it would be difficult for them to ask appropriate questions. I have seen a couple of these as well, where most of the questions don't make sense, likely due to the fact that they don't know what they want and have a limited understanding of what MPS is. Although let's face it: most RFPs have a slew of questions that are irrelevant or overly complicated.
Regardless of the types of RFP opportunities that come across your desk, there are a few things you can do to be prepared and minimize the amount of time spent responding:
- Have a fully developed RFP on hand. If you end up with a client that needs to send out an RFP, you want to make sure you can be the one to help them out with it. Although each customer may need some customization, you should have a basic RFP put together. The questions you develop should be specific enough to highlight your competitive differentiators. Don't make a question asking if the vendor provides quarterly reviews; instead, use one or two unique aspects of your own quarterly reviews and ask if the vendor can provide that (I'll admit that this suggestion contributes to the reason why some questions seem irrelevant).
- Keep all of your previous RFP responses organized and available. It's too much work to complete an RFP response to not make use of it after it's submitted. Don't lose track of your old responses, because there will always be similar questions in another RFP. Ideally, compile all of your old RFP responses into a single file that you can reference.
- If you think a competitor developed the RFP, evaluate risk vs. reward. If you're comfortable asking the end-user, confirm that they've had help. If they have, odds are it will be an uphill battle to win the contract. From my perspective, the only time it ever makes sense to submit a response to an RFP that you are unlikely to win is if the profit potential is extremely high. Even then, since you already know you have to beat out their first choice, you will likely have to reduce your prices and profits will shrink. The only other reason to try in this scenario is if the RFP is relatively straight forward and you can develop a response in a few hours—if you are presented with an RFP developed by a competitor that consists of multiple 10-page documents, forget it.
- If you think the customer developed the RFP, offer some input. This can also apply if you think a competitor developed the RFP, but your success in that case may be more limited. However, if it's obvious that the customer developed the RFP themselves, approach them with some suggestions of what they should be including—specifically, questions from the RFP you already have developed.
In an ideal world, every RFP would be an outline of the company's current scenario followed by a single question: what can you do for us? No, wait—in an ideal world, there would never be RFPs. As much as you can, get in front of the situation and let potential customers know what value you can bring them before their existing contract ends and they release an RFP. For those situations where an RFP is inevitable, make sure you are using your time and effort wisely. Don't go chasing something that someone else already caught.
Posted by Emily Offshack on 04/25/2011