Phone system selection affects call quality, operational efficiency, and technology cost for years after the decision gets made. Most organizations still approach it reactively, comparing whichever vendors happen to pitch them rather than evaluating systems against requirements defined in advance, an approach that tends to produce systems fitting the sales conversation better than the business.
This guide covers what actually differentiates business phone systems: the technical mechanics behind call quality and bandwidth, the federal compliance rules governing emergency calling, realistic pricing across the major platform categories, and a scorecard that produces an actual usable comparison instead of a list of unscored adjectives.
Define Requirements Before Talking to Vendors
Start with a current-state assessment: existing infrastructure, call volumes, specific pain points, and capabilities worth preserving. What already works should shape requirements as much as what does not. Project growth over the system’s expected life, typically five to seven years for a real platform decision, not just current headcount; a system adequate today but capped at 50 users is the wrong choice for an organization planning to double in three years.
Set budget parameters before vendor conversations start: capital versus operating expense preference, acceptable monthly per-user cost, and how much total investment the decision actually warrants. Separate must-have requirements from nice-to-have features early, since vendors are very good at making nice-to-have features sound mandatory once a conversation is underway.
Call Quality: Codecs and Bandwidth
Call quality questions reduce to a small number of technical facts that most vendor pitches gloss over.
Codec bandwidth. The codec a system uses for a call determines how much network bandwidth that call actually consumes:
| Codec | Type | Audio Bandwidth | Approx. Network Bandwidth (per direction, with overhead) | Approx. Total per Two-Way Call |
|---|---|---|---|---|
| G.711 | Narrowband, uncompressed | 64 kbps | 80-90 kbps | 160-175 kbps |
| G.722 | Wideband (HD voice) | 64 kbps | 80-90 kbps | 160-175 kbps |
| G.729 | Narrowband, compressed | 8 kbps | 30-40 kbps | 60-80 kbps |
G.711 is the default codec on most systems and gives the highest fidelity within narrowband range (300-3,400 Hz), the same frequency range a traditional phone call has always used. G.722 runs at the same wire bandwidth as G.711 but captures a much wider frequency range, roughly 50-7,000 Hz, which is why HD voice sounds noticeably clearer without costing more bandwidth. G.729 cuts bandwidth by more than half compared to G.711 through compression, useful on bandwidth-constrained WAN or cellular links, at some cost to audio quality.
The practical math: a 20-person office running concurrent G.711 calls needs roughly 3.2-3.5 Mbps of dedicated bandwidth (175 kbps x 20) for voice alone, before any other network traffic. A call center running 50 concurrent calls on G.729 instead would need only about 3-4 Mbps for the same call volume, the kind of tradeoff that matters when comparing a branch office on a modest connection against a headquarters location with bandwidth to spare.
Quality of Service. Voice traffic needs to be prioritized over file transfers, backups, and other data on the same network, or call quality degrades under load regardless of codec choice. Confirm that QoS marking (typically DSCP tagging) is supported end to end, not just at the phone system, and that it actually works with your existing switches and routers, not just the vendor’s reference hardware.
Redundancy. Hosted/cloud systems should run across geographically distributed data centers so a regional outage does not take down phone service. On-premise systems need redundant components or clustering to avoid a single point of failure taking the whole system down.
Network Requirements and Firewall Behavior
Beyond raw bandwidth, two practical network issues cause most real-world VoIP deployment problems. SIP ALG (Application Layer Gateway), a feature built into many consumer and small-business routers, is intended to help VoIP traffic traverse firewalls but frequently breaks it instead, causing one-way audio, dropped calls, or registration failures; confirm with your network team or MSP whether SIP ALG needs to be disabled on your specific router/firewall model before deployment, since this single setting causes a disproportionate share of VoIP support tickets. Separately, confirm how the system handles NAT traversal and what firewall ports it needs opened; a system requiring a long list of open inbound ports is a larger attack surface than one using a session border controller or cloud-mediated connection that needs minimal inbound exposure.
Security
Encryption for both call signaling (TLS) and the media stream itself (SRTP) should be enabled by default, not an optional add-on or a manual configuration step; verify this directly rather than accepting “we support encryption” as an answer, since support and default-on are different things. Administrative access should require multi-factor authentication without exception, since admin-level access to a phone system can redirect calls, access voicemail and recordings, and in some cases manipulate billing.
Toll fraud protection (call pattern analysis, geographic call restrictions, spending alerts) matters more for cloud and SIP trunk systems than buyers often realize. A compromised system or stolen credentials can generate thousands of dollars in international call charges within hours before anyone notices; spending alerts and geographic restrictions catch this before the bill arrives.
Federal E911 Compliance: Kari’s Law and RAY BAUM’S Act
Any business deploying a multi-line telephone system (MLTS), meaning any system serving more than one line or extension, is subject to two specific federal rules that govern 911 calling. Both took effect February 16, 2020, and apply regardless of which vendor or platform you choose.
Kari’s Law requires that any extension on an MLTS be able to dial 911 directly, with no prefix, trunk-access code, or other digit required first. A system that still requires dialing 9 before 911 is non-compliant. Kari’s Law also requires the system to send a notification, to a front desk, security office, or other on-site location, whenever a 911 call is placed from any extension, so someone on premises knows a call went out and can direct first responders to the right location within the building.
RAY BAUM’S Act, Section 506, requires that 911 calls from an MLTS deliver a “dispatchable location” to the public safety answering point handling the call: a validated street address plus enough additional detail (floor, suite, room) to actually locate the caller within a multi-room or multi-floor facility. A system that only reports the building’s main address, with no floor or suite detail, does not meet this requirement for a multi-floor or multi-tenant building.
These are not generic “nice to have” features; they are FCC rules with real compliance exposure, particularly for any business with multiple floors, multiple buildings, or remote/softphone extensions where dispatchable location is harder to maintain automatically as people move between locations. Confirm directly with any vendor: does every extension dial 911 with no prefix, does the system send an on-site notification when a 911 call is made, and does it maintain accurate per-location dispatchable location data as extensions move or remote workers connect from different sites. A vendor selling into the business market should answer all three without hesitation.
Architecture: Hosted, On-Premise, or Hybrid
Hosted/cloud (UCaaS). The phone system runs in the provider’s data centers and connects over the internet, with no on-site PBX hardware to maintain. Major platforms include RingCentral, 8×8, Zoom Phone, Nextiva, GoTo Connect, Vonage Business, and Microsoft Teams Phone (sold as an add-on to a qualifying Microsoft 365 license). Pricing commonly runs $15-45 per user per month depending on platform and tier: Zoom Phone’s metered tier starts around $15/user/month, full UCaaS suites with contact-center features from RingCentral, 8×8, and Nextiva often run $25-45/user/month, and Microsoft Teams Phone tends to land lower, roughly $8-16/user/month, but only works as intended alongside a qualifying Microsoft 365 license. Hosted systems shift most maintenance burden to the provider and scale with headcount changes without new hardware purchases.
On-premise PBX. Hardware (the PBX server, handsets, gateways) lives on site and is owned by the business, carrying higher upfront capital cost and an internal or contracted IT maintenance burden, offset by lower or no recurring per-user licensing fees beyond SIP trunking and support contracts. This still fits organizations with strict data-residency requirements, unreliable internet connectivity that makes a cloud dependency risky, or existing PBX hardware with useful life left.
Hybrid. Combines on-premise hardware for some locations or functions with cloud-hosted services for others, commonly used during a phased migration from an aging on-premise system, or where one location needs local survivability and others do not.
Integration, Mobility, and Scalability
Integration. CRM integration (screen pops with caller information, automatic call logging) is standard on most mid-tier and above platforms for the common CRM platforms (Salesforce, HubSpot, Microsoft Dynamics), but confirm a pre-built connector exists for your specific CRM rather than assuming generic support covers it. REST API and webhook support matter for any organization planning custom integrations beyond what pre-built connectors offer.
Mobile. Native apps should deliver calling, messaging, and presence with real feature parity to the desk phone, not a stripped-down companion app, and seamless call transfer between mobile and desk phone is now a reasonable baseline expectation rather than a premium feature.
Scalability. Understand whether stated user limits are hard caps requiring a system replacement or soft limits requiring only a license purchase, and ask for performance references from deployments at or above your anticipated scale, not just total customer count. Multi-site organizations should specifically evaluate inter-site calling and whether administration is centralized or managed separately per site.
Vendor Evaluation: Contracts, Pricing, and Support
Contract term length (monthly, annual, multi-year) trades commitment for pricing; multi-year terms typically buy a meaningfully lower per-user rate in exchange for reduced flexibility, so confirm cancellation provisions and early-termination costs before signing, not after a problem arises.
Pricing transparency matters more than the headline number. Confirm whether quoted pricing is all-inclusive or à la carte, what triggers overage charges, and what add-on fees commonly show up on invoices that were not part of the initial quote; a vendor unwilling to say what price increase existing customers saw at their last renewal is telling you something. Support quality is difficult to judge from a sales conversation, so request references specifically about support experience, not general satisfaction, and confirm support hours and response-time commitments actually match your operational needs (a 24/7 operation needs 24/7 support, not 9-to-5 with an answering service after hours).
A Functional Evaluation Scorecard
Score each vendor 1-5 on each factor (1 = does not meet requirement, 3 = meets minimum requirement, 5 = exceeds requirement with clear advantage), multiply by weight, and total. Adjust weights to reflect actual priorities rather than treating every factor as equally important.
| Factor | Weight | Scoring Guidance |
|---|---|---|
| Call quality and codec support | 5 | 1 = G.711 only, no QoS; 5 = HD codec support plus verified QoS interoperability |
| E911 compliance (Kari's Law/RAY BAUM'S Act) | 5 | 1 = cannot confirm compliance; 5 = direct dial, on-site notification, and per-location dispatchable location all verified |
| Security (encryption, MFA, fraud controls) | 4 | 1 = encryption optional/extra cost; 5 = encrypted and MFA by default |
| Architecture fit (hosted/on-prem/hybrid) | 4 | Score against your actual connectivity and data-residency requirements, not a generic preference |
| Scalability and multi-site handling | 4 | 1 = hard user cap below your 3-year projection; 5 = verified headroom plus multi-site references |
| Integration (CRM, API, mobile) | 3 | 1 = no pre-built connector for your CRM; 5 = native connector plus open API |
| Total cost of ownership (pricing transparency) | 4 | 1 = vague/à la carte with unclear overage fees; 5 = fully inclusive, transparent pricing |
| Contract flexibility | 3 | 1 = long term, costly early exit; 5 = reasonable term with clear, bounded exit cost |
| Support quality | 4 | Score against verified reference checks, not vendor claims |
| Implementation and training support | 3 | 1 = self-service only; 5 = dedicated project management and admin training included |
Questions to Ask, and Red Flags to Watch For
Cover four areas directly with every vendor: technical (which codecs are supported, is HD voice/G.722 standard or an add-on, is encryption on by default), compliance (walk through exactly how a 911 call is handled, including on-site notification and per-floor dispatchable location), pricing (what is included versus billed separately, and what price increase existing customers saw at their last renewal), and support (hours, response-time commitments, and references from organizations comparable in size and industry, contactable directly).
A vendor relationship rarely improves after signing if early warning signs show up in the sales process: pricing that takes an unusually long conversation to actually understand, vague or evasive answers to the Kari’s Law/RAY BAUM’S Act questions above, reluctance to provide real references, pressure toward a fast decision, or a demo that feels unprepared.
Key Takeaways
Call quality comes down to verifiable specifics: which codecs are supported, what they actually cost in bandwidth, and whether QoS genuinely works on your network. E911 compliance under Kari’s Law and RAY BAUM’S Act is a federal requirement, not a feature differentiator, and any vendor selling into the business market should answer direct-dial, on-site notification, and dispatchable location questions without hesitation.
Architecture choice (hosted, on-premise, hybrid) should follow from connectivity reliability and data-residency needs, not vendor preference. Hosted platforms commonly run $15-45 per user per month depending on tier; weigh that recurring cost against an on-premise system’s higher upfront capital cost and lower recurring fees over the system’s expected life.
A weighted scorecard with real scoring anchors, not blank columns, turns vendor comparison into an actual decision tool. Reference checks focused specifically on support experience and compliance verification reveal more than any sales conversation will.