Are you are looking for a replacement for your existing phone system? Do you want to see what solutions are available, and explore their capabilities?
If you are interested in receiving proposals from multiple sources, you may consider issuing a Request For Proposal (RFP). This document will explain your requirements and allow bidders to create a proposal to meet your needs.
Not sure you need an RFP? Read this.
Creating an RFP document can be difficult. Vendor’s often offer to provide you with their RFP document as a starting point. That sounds great, doesn’t it?
Before you use a vendor’s document, consider this:
Responding to an RFP takes effort and often there are expenses as well. Most companies evaluate the risk and reward before deciding whether to respond.
What is their chance of winning the business? How long will the process take? What level of effort is required?
Of course, they will look to the RFP document for many of these answers. If the document appears to be slanted toward one specific solution, and it’s not theirs, they won’t respond to the RFP. They don’t think they have a chance to win the business.
Here’s an example:
When VOIP first became available, the Cisco phones ran on a proprietary protocol named Skinny (SCCP). Since the technology was new, many people didn’t realize that this protocol was specific to Cisco only. We had a client who told us that he wanted a requirement for “VOIP phones and Skinny protocol”. He didn’t realize that this requirement would eliminate every other system from consideration.
I have read many RFP documents prepared by vendors. They don’t invest effort in creating these documents for the good of humanity. The vendor’s RFP is designed to make their solution look better than the competition, by emphasizing their strong points and minimizing (or leaving out) their weaknesses.
Throughout the document, there are many clues:
- Proprietary names for features
- An emphasis on a perceived competitive strength (all-in-one solution, automated implementation process, international reach, etc.)
- Few (if any) requirements for delivery and support
However, most potential customers don’t write RFPs very often. They don’t see these clues when they read the document.
But potential bidders DO recognize these signs. And they make the decision to respond, or not, based on their evaluation of their chances of winning the opportunity.
Do you want your RFP to limit your options?
If you want help in creating an RFP,
Not sure that you have enough time to take on a major project? Click here!
If artificial intelligence is part of your future, then the cloud must be, too.
Make sure that everything you wanted in the contract actually makes it in, and that acceptance and payment terms are reasonable.
In part 2 of this series, we cover issues that can occur with configuration and failover of SIP trunking.
Determining answers to a series of questions around your motivations and requirements for cloud migration will help you sort through the wilderness of options.