What to Include in a VoIP Phone System RFP

Writing a request for proposal (RFP) for a new telephone system is a big job, requiring a lot of information and no costly omissions. Completing this task with confidence requires patience, thoroughness, and attention to detail.

When is a PBX Phone System RFP Necessary?

Before drafting an RFP, consider if it is necessary. Is your goal to define your needs and receive pricing quotes? If so, then you may be better served by making an informal list of requirements and sending it to vendors in the course of the normal sales process. Some governments, schools/universities and large organizations have policies that require formal RFP’s for significant purchases, in which case an RFP is necessary. In those situations, it is a good idea to speak to vendors before drafting a RFP to develop a basic understanding of the products, options, and capabilities of different systems.

Creating An RFP Outline

When beginning a large, detailed document, the first step is an outline. The outline should contain a list of absolute necessities for the telephone system, as well as desired but nonessential features. Knowing which is which is key: needs will vary based on the business entity creating the RFP.

At the beginning of the document, include a summary of the overall document and instructions for proper completion of a proposal. Despite appearing first, these items are usually written last—until the rest of the RFP has been drafted, it is not possible to create a summary or instructions for completing it.

Next, the inclusion and exclusion clauses: the “must have” and “must not have” requirements. A requirement that a provider have a geographic redundancy strategy for business continuity is an example. Stating these requirements up-front will reduce the number of ineligible proposals received.

Follow that with the major details of the project, including:

• A high-level, general view of project scope
• Expected completion date
• Price caps or protection clauses

Describe RFP Details

Next, the RFP should examine project specifications, like the types of users the phone service will need to support, numbers of stations, hardware requirements, system software needs, and calling features. Include all possible detail right down to minor items like auto-attendant messages. There may be “want” items here in addition to “need” items, but remember to include them. The vendor will be present to install the system, so it is easier and more cost-effective to have them handle small configuration details during that time than to pay them to come back later.

Include a section with business details.

How much experience should a provider have? What parts of system management are the responsibilities of the vendor, and which fall to the buyer? What level of insurance should a vendor to have? What special considerations must the proposal address? These are some considerations when evaluating the VoIP providers’ RFP responses.

Special considerations can be tricky.

For-profit enterprises have one set of needs, while government agencies have a different set. Educational institutions will have different needs than medical facilities. Some providers offer special pricing for public schools and libraries via the E-Rate program. Each city or town in which the buyer has a physical plant may have different local building codes. Specialized information should be spelled out in detail, along with a mandate that a vendor address how each need will be met.

Maintenance agreements should be specified as well.

Telephone systems can be complex. Programming a premise-based PBX may require expert knowledge even for tasks like adding, changing, or deleting a station. Include details here regarding training to be provided to on-site IT staff and end users of the system. Make sure it is clear which services are covered by a maintenance agreement and which are not. A lack of clarity will cost money later. One of the advantages of a cloud based phone system like MiCloud Connect is the elimination of many of the complexities and risks of buying traditional premise-based systems.