A VoIP RFP exists to pin vendors down on outcomes, technical obligations, and regulatory duties before money changes hands, not to collect glossy brochures. The immediate move is to copy the outline and requirements fulfillment matrix below into your document and make bidders map every claim against it, line by line. Build in the CRTC's E9-1-1 rules, name your jitter tolerance, and treat installers like BusinessVoip as a useful reference point for what a fully accountable, on-site delivery model looks like in practice.
TL;DR:
- Vendors must demonstrate compliance with E9-1-1 regulations and provide proof of support for basic or enhanced 9-1-1 services as part of the evaluation.
- The technical specifications should include jitter under 30 milliseconds, clear bandwidth estimates based on call volume, and evidence of interoperability with existing systems.
- Use a weighted scoring rubric, assign mandatory and desirable requirements, and include a formal rectification period to ensure fair and efficient bid evaluation.
- A requirements fulfillment matrix should be used to force vendors to specify whether features are native, add-on, or unsupported, exposing weaknesses early.
- On-site providers should handle system design, installation, testing, and support within a fixed-price framework, with verification of network readiness and E9-1-1 compliance before award.
Table of Contents
- What goes into a practical VoIP RFP outline
- Which technical specs to demand and how to verify them
- Scoring bids fairly without slowing down the process
- Submission logistics and the paperwork you'll actually need
- Copy-ready clauses and a compact fulfillment matrix
- What field experience says about avoiding a failed cutover
- The three things I'd never skip in a VoIP RFP
- What to expect from a fully installed, on-site VoIP provider
- Sources
- FAQ
What goes into a practical VoIP RFP outline
A usable RFP has a predictable skeleton. Skipping a section is usually what causes vendors to submit incomparable, unenforceable proposals.
Start with the procurement basics:
- Header block: issuing organization, RFP number, key dates, and a single point of contact for questions.
- Timeline: issue date, question deadline, proposal due date, demo window, and target award date.
- Submission rules: format, number of copies or portal upload instructions, and what disqualifies a late or incomplete bid.
The body of the document does the real work:
- Scope of work: number of seats, sites, extensions, and any special requirements like overhead paging or fax lines.
- Deliverables: what "done" looks like, phone counts, porting of existing numbers, training sessions, and documentation.
- Acceptance criteria: the tests a system must pass before final sign-off, including call quality checks and failover tests.
- Warranty and maintenance terms: what's covered, for how long, and the vendor's response time for outages.
- Commercial terms: pricing model (per seat, per site, or flat fee), whether phones are purchased or rented, and whether pricing is fixed for the contract term.
Ask bidders to return a requirements fulfillment matrix rather than free-text answers. Modern procurement documents, including the Tanana Chiefs Conference unified communications RFP, use this format to force vendors to mark each requirement as native, add-on, integration, or not supported. That single table does more to expose weak proposals than pages of narrative, because a vendor who writes "integration" next to E9-1-1 compliance has just told you to ask harder questions.
Which technical specs to demand and how to verify them
Vague technical language is where RFPs fall apart during evaluation. Ask for numbers, not adjectives.
Bandwidth is the easiest place to start. Plan for roughly 80 to 90 kbps per concurrent call using standard codecs, then multiply by your expected simultaneous call volume to size your uplink.
Jitter tolerance under 30 milliseconds is a common procurement threshold, cited in documents like the OECM RFSQ, and it's a reasonable line to hold vendors to for voice quality.
Require these in the technical section:
- Voice quality targets: jitter under 30 ms, a defined packet loss ceiling, and a latency goal, plus how the vendor monitors and reports against them.
- E9-1-1 compliance evidence: proof of Basic or Enhanced 9-1-1 service and a documented process for notifying customers of any limitations, as required by the CRTC.
- Interoperability: confirmed support for existing paging systems, analog devices, and any APIs your other business systems need. Our overhead paging integration guide covers the common failure points.
- Security evidence: SOC 2 Type II reports, recent penetration test summaries, and a Threat Risk Assessment, all increasingly standard asks in competitive procurements.
For nomadic or remote-office lines, the vendor's notification obligations get more specific. Our E9-1-1 breakdown walks through what evidence to actually collect.
Scoring bids fairly without slowing down the process
A weighted rubric keeps evaluation defensible and stops the lowest bidder from winning on price alone when their implementation plan is thin.
A workable starting model looks like this:
- Technical fit: 35 points
- Commercial terms: 25 points
- Implementation plan: 20 points
- Security and compliance: 10 points
- References: 10 points
That's one example weighting, adjust it to your organization's risk tolerance, but implementation and support should carry real weight for any multi-site project, not just price.
Split requirements into mandatory and desirable before scoring starts:
- Mandatory (pass/fail): E9-1-1 compliance, proof of insurance, and a documented contract or attestation with the vendor's 9-1-1 answering bureau.
- Desirable: extra integrations, mobile app polish, or advanced reporting dashboards.
Score the fulfillment matrix directly: native support earns full points, add-on or integration earns partial credit depending on added cost and complexity, and "not supported" against a mandatory item disqualifies the bid outright.
Build in a rectification period, a short window where a bidder can supply missing documentation or clarify an ambiguous answer, rather than disqualifying over a paperwork gap. Reserve outright disqualification for missed mandatory technical or regulatory items. Shortlist finalists for live demos, check at least two references on comparable deployments, and use a final clarification round to negotiate any remaining commercial terms before award.
Submission logistics and the paperwork you'll actually need
Publish a clear timeline: RFP issue date, question deadline, notice of intent to bid, proposal due date, demo and interview window, and target award date. Public listings like the Merx VoIP telephone system solicitation show how these stages typically get laid out.
Require a complete proposal package:
- Signed RFP response and cost schedule.
- Implementation plan with named milestones.
- Proof of insurance and E9-1-1 compliance evidence.
- SOC 2 or equivalent security documentation.
State your submission format (portal or email), your late-submission policy, and a requirement that bidders acknowledge every addendum in writing. Include confidentiality language and a defined contract negotiation window after award, and consider bid security for large, multi-site procurements.
Copy-ready clauses and a compact fulfillment matrix
A few clauses cause most of the disputes later, so write them precisely now.
E9-1-1 clause: "Vendor shall provide Basic or Enhanced 9-1-1 service in accordance with CRTC requirements and shall notify the customer in writing of any limitations to 9-1-1 functionality prior to service activation."
Service level clause: "Vendor guarantees 99.9% uptime measured monthly, a response time of two hours for critical outages, and service credits equal to one day of service fees per hour of unplanned downtime beyond the guaranteed threshold."
Implementation milestone clause: "Vendor shall deliver a written implementation plan identifying design, cabling, programming, testing, and go-live dates, with each milestone subject to written acceptance by the customer."
Security attestation clause: "Vendor shall provide current SOC 2 Type II reports and evidence of penetration testing performed at least annually."
A compact checklist and sample fulfillment matrix entry:
What field experience says about avoiding a failed cutover
Hidden costs show up during cutover, not before it: extra cabling runs, analog line conversions, and paging systems that need a separate integration path. Staged VLAN rollouts and on-site design cut that risk sharply because problems surface during testing, not on go-live day.
Pro Tip: Ask every bidder to walk through their staged cutover plan for your highest-risk location before you score anything else.
Demand a network readiness check and E9-1-1 verification before award, not after. BusinessVoip's on-site model, fixed pricing, and lifetime warranty on rented phones reflect the same principle: install failures usually trace back to skipped verification, not bad equipment.
The three things I'd never skip in a VoIP RFP
If I had to cut every requirement in this guide down to three, they'd be E9-1-1 compliance evidence, a completed fulfillment matrix, and a named implementation plan with acceptance criteria. Everything else is negotiable; these aren't.
Before you publish, confirm you have: the outline above, a weighted scoring rubric, mandatory pass/fail items defined, a fulfillment matrix template attached, and a rectification period written into the evaluation rules.
— James
What to expect from a fully installed, on-site VoIP provider
Not every organization wants to manage cabling, programming, and staged testing themselves. On-site providers typically handle system design, cabling, phone programming, staff training, and warranty support as one package instead of leaving setup to your IT team.
When comparing an on-site provider against a remote-only vendor, check who actually shows up for install day, who owns the network checks, and whether pricing stays fixed for the contract term. Some on-site providers install and support systems locally within a regional area, with larger projects handled more broadly, and may offer warranty on rented phones. If your RFP process points toward a fully managed, on-site build, visit Businessvoip to request a site visit or quote, or see how the model applies to multi-site and remote-office setups.
Sources
Ground your document in real procurement language rather than starting from a blank page.
- 9-1-1 obligations of local VoIP service providers in Canada | CRTC
- REQUEST FOR SUPPLIER QUALIFICATIONS (OECM RFSQ)
- Unified Communications (Phone System) Replacement RFP (Tanana Chiefs Conference)
- RFP #2190006 - VoIP Telephone System & Services FINAL (Merx)
FAQ
Is VoIP legal to use for business phone service?
Yes. VoIP is a legal, regulated telecommunications service, and providers offering local service must meet CRTC 9-1-1 requirements and notify customers of any limitations. Businesses should confirm their provider carries this documentation before signing.
What is an RFP in networking procurement?
An RFP, or request for proposal, is a formal document that lays out an organization's requirements, evaluation criteria, and submission rules so vendors can bid on a networking or communications project. In VoIP procurement, it typically includes scope of work, technical specifications, and a requirements fulfillment matrix.
What does VoIP stand for?
VoIP stands for Voice over Internet Protocol, a technology that carries voice calls over an internet connection instead of traditional phone lines. It's the underlying technology behind most modern business phone systems.
What is the difference between an RFP and an RFQ?
An RFP asks vendors to propose a solution and approach, useful when the buyer needs help designing the system, while an RFQ (request for quotation) asks for pricing against a specification the buyer has already defined. VoIP procurement often starts with an RFP when requirements are still being scoped.