Is your company getting ready to dump ye olde analog or digital telephone system? Many organizations turn to internal champions or outside consultants to then draft that monster most feared by vendors: the dreaded Request for Quote (RFQ) or Request for Proposal (RFP).
I thought I would add my two cents from a vendor perspective about what is and is not helpful for companies.
- Do figure out if you actually need an RFP or if you can get by calling a handful of reputable local companies and having some fact-finding conversations. Creating, collecting and evaluating RFPs is very time consuming for you and your vendors. If you have not established precisely what features are important to you and what your solution ought to look like (in broad strokes), then you are making an expensive mistake with an RFP. I say expensive not only because of the time it takes but because of the chance you end up with the lowest bidder of the wrong solution, which can be extremely expensive to correct and expensive in terms of missed opportunities for your business to improve.
- Do make sure you define what services you want from your vendors. Nowadays, there are a lot of moving, interrelated parts with communications systems. I see RFP after RFP that is vague about the company network and who is doing what – so, because this is a bidding war first and foremost, I as a vendor have to exclude anything from my scope of work (SoW, a.k.a what exactly my engineers will be doing) in order to keep my price low. In a non-RFP situation, I would have a casual talk with your IT staff or service company and wrap up that issue in a 20 minute phone call and get you what you need. Similarly, be very clear about your training expectations. Giving vendors freedom to make their best judgment, in a bidding war, which is what RFP’s are designed to create, means you get the cheapest, shortest training I can provide.
- Do make sure you distinguish requirements from preferences. Some things are very important – you need enough phones for everyone, and you probably need voicemail and a unified communications client. And others, such as wanting the telephone display to be a certain size or to have exactly so many buttons on the phone, are probably not deal-breakers. Vendors will read and re-read your RFP ten times like a Talmudic scholar and take things very literally, so please be specific about what is critical and where you are flexible.
- Do describe desired outcomes over technical jargon where possible. “We want to be able to Instant Message each other and see on our computer who is available” makes sense to your vendors, and each of them will show you their manufacturer’s solution. “We need a TAPI-compliant unified communications client that supports HTML5 and a NoSQL database” is dangerous to write. Know that vendors will not put 20 hours into your proposal if it is a lost cause, so be confident about the jargon you are using. In this example, TAPI is an older standard specific to Windows applications, there is confusion with “client” and “HTML5” (is this a browser-based solution?), and name-dropping the hip name of your database without explaining what it means in the context of the project just means I might walk away from the opportunity.
- Do provide a network diagram and describe your planned carrier services. I have received RFPs with no mention of where the phone system is going or how it will make phone calls. This gives me a hint as to whether I am walking into a field of dandelions or land mines for pricing up my labor. Hiding the fact your network is a black hole or a disaster only sets the stage for a fight down the road, and if your network is in good shape, say it! You’ll save money if I can just budget for a situation where your staff will plug all the phones in.
- Do ask about future costs. Have vendors describe maintenance agreement and software assurance costs, future upgrade costs, costs of past but still recent upgrades for similar systems, and get a copy of the maintenance contract.
- Do get a network analysis before you quote the RFP. The number one killer of VoIP project budgets: an unprepared network forcing last minute upgrades and rushed implementations. No one wants to be overnighting switches and running cable at time and a half over the weekend because the connectivity in that part of the building is terrible. Reputable companies can run packet captures and speed tests to tell you whether you are ready for VoIP or not, before you start shopping for systems.
And some don’ts
- Don’t short yourself on the timeline. Give yourself a couple of weeks to evaluate solutions once the RFPs come back, and give your vendors at least a month to put their RFPs together with an opportunity to ask questions somewhere in the middle of that month.
- Don’t promise to buy something in the RFP. You might decide to shelve the whole thing, the price tags might cause your boss to keel over, who knows. Avoid making promises in the language of the RFP that might be construed as a commitment to buy something.
- Don’t let your vendor write your RFP (unless the RFP is just some red tape you have to get through in order to buy that system you already decided on buying). Hey, we weren’t born yesterday, we know that a lot of the time, the RFP is just a formality and you already picked your phone system. But believe it or not, I have seen companies bring their IT company in to help with the RFP, only to find that the RFP described <drum roll> the phone system that said IT outfit just happens to sell. If your RFP seems awfully nitpicky about things you don’t actually care about, you might want to be careful about sending the RFP out to bid, unless you planned this masterstroke all along.
- Don’t forget your scoring rubric! Let us vendors know what you care about and how you are going to make a decision. If you only care about price, say it! Then I know what to quote. If money is not as important as having a few critical call center features you need for regulatory compliance, say that. I want to know that my solution requires a Sarbannes-Oxley, HIPAA or PCI compliance stamp of approval.
- Don’t forget to make the demo part of the process. Don’t take our word for it – bring the finalists in to demonstrate the features you described. If you have an awful gut feeling about one system but, on paper, it looks ok, a demo will give you the chance to both evaluate the system first hand and toss out a solution that you just don’t feel good about.
- Don’t forget documentation and final walk through. Require manuals, network diagrams and the like to be handed over before you cut that last check.
Lastly, good luck!
Share and Enjoy