A PBX (Private Branch Exchange) is a telephone switchboard that a business owns and operates for itself. Inside it are extensions: short numbers reaching desks. Outside it are trunks: shared lines to the public network. The receptionist’s console, the transfer button, dialing 9 for an outside line, three-digit extensions, all of it is PBX behavior, and every product category in the modern phone-system market descends from that box. The market’s vocabulary makes sense only as a series of answers to two questions: who operates the switchboard, and what else comes with it.
The lineage: from key systems to the cloud
- Key telephone system
- The pre-PBX small-office answer: every phone has a button (key) per outside line, and a user picks a free line by pressing its lit button. No real switching intelligence. Common in small offices through the 1980s and 1990s.
- Analog / TDM PBX
- The classic switchboard: a cabinet in a closet, proprietary digital or analog handsets, trunks delivered as analog lines or ISDN PRI circuits. Features (transfer, hunt groups, voicemail cards) live in the cabinet. Maintained by a certified technician.
- IP PBX
- The same box, re-plumbed: SIP signaling and IP handsets inside the office instead of proprietary wiring. The business still owns and patches the server (Asterisk and its descendants made this a software product). Trunks become SIP trunks, though many IP PBXs ran on PRI for years.
- Hosted / cloud PBX
- The PBX stops being a box and becomes the provider’s software, multi-tenant, in their data centers. The business keeps only endpoints: desk phones, What is a softphone?, mobile apps. Numbers, trunks, upgrades, and redundancy are the provider’s problem. “Hosted PBX,” “cloud phone system,” and “virtual PBX” all name this.
- UCaaS
- Unified Communications as a Service: cloud PBX plus the rest of workplace communication in one suite: team messaging, video meetings, presence, sometimes fax and SMS. Sold per user per month. The category most mid-market “phone system” purchases land in.
Neighbors: CCaaS and CPaaS
Two adjacent categories share the infrastructure but serve different buyers. CCaaS (Contact Center as a Service) is the descendant of the call-center ACD: queues with skills-based routing, IVR trees, wallboards, workforce management, and quality monitoring, sold per agent. A business buys CCaaS when it staffs a team whose job is answering volume, not when it wants ten employees to have phone numbers. CPaaS (Communications Platform as a Service) is not a phone system at all: it is APIs (numbers, calls, messages) for software developers to build communication into their own applications. The three overlap at the edges (UCaaS vendors sell contact-center add-ons; CPaaS vendors ship prebuilt widgets), but the buyer, the unit of pricing, and the thing being operated differ.
The extension model vs the user model
The deepest change between the PBX era and the cloud era is the unit of design. A PBX modeled wired extensions: extension 204 was a port, a cable, and a desk, and a person happened to sit there. Modern platforms model users: a person who has an identity, one or more numbers, and several simultaneous endpoints (a desk phone, a desktop app, a mobile app) that all ring as one. Extensions survive as optional short codes for internal dialing, but nothing is wired to them. The user model is why remote and hybrid work did not require re-architecting cloud systems: the person, not the desk, was already the endpoint.
“Virtual phone system” is the SMB-market term for a lightweight cloud PBX built entirely on this model: numbers, routing rules, voicemail, and apps, with no desk-phone assumption at all. It is not a distinct technology, just cloud PBX packaged for businesses that will never rack a server or provision a SIP handset.
What a small business actually needs from the list
Enterprise RFP checklists (paging zones, SIP handset provisioning profiles, dial-plan classes of service, E1 failover) obscure how short the real SMB list is. Most small businesses need: one or more numbers (local or toll-free), routing (business hours, a greeting or menu, ring order across people), Voicemail, transcription, and visual voicemail with transcription to email, texting on the business number (SMS, with 10DLC registration handled), and mobile apps so the number works away from a desk. Call recording, queues, analytics, and CRM integration matter for some and are noise for others. Comparing platforms starts with striking every line the business will not use, because unused enterprise features are what the per-user price is buying.
On-premises vs cloud, honestly
The on-premises PBX is not indefensible; it is a trade. Owning the switch means control (no subscription, data stays on site, deep customization on open-source platforms) and single-site survivability: an office with an on-prem PBX and analog trunks can keep internal calling and trunk access during an internet outage, which a cloud system cannot match at that site. The costs are equally real: someone must patch, back up, and eventually replace the server; remote and multi-site work requires VPNs or edge devices the cloud model gets for free; features arrive by forklift upgrade rather than continuously; and disaster recovery for the box in the closet is the owner’s project. See VoIP reliability and failover for the failure-layer view. The market has moved decisively toward cloud for businesses without dedicated telecom staff, and the honest reasons are maintenance and remote work rather than any single killer feature.
The categories side by side
| On-prem PBX (incl. IP PBX) | Cloud PBX / virtual phone system | UCaaS | CPaaS | |
|---|---|---|---|---|
| Who operates the switch | The business (or its integrator) | The provider | The provider | The provider operates the platform; the customer operates the application built on it |
| Endpoints | Desk phones on the LAN, often proprietary or provisioned SIP | Desk phones optional; desktop and mobile apps standard | Apps first (calling, meetings, chat in one client); desk phones supported | Whatever the customer’s software presents (WebRTC in a browser, an embedded dialer) |
| Typical buyer | IT staff at a business with telecom skills, or one with hard on-site requirements | Small businesses that want numbers, routing, and apps without infrastructure | Mid-market and up, standardizing communication in one suite | Product and engineering teams building communication into their own product |
| How trunks and numbers arrive | Bought separately: SIP trunks (or legacy PRI) from a carrier, numbers with the trunk | Bundled: the provider is or resells the carrier; numbers provisioned in the portal | Bundled, with BYOC optional on larger platforms | Numbers and minutes are the product, bought per unit via API |
| Pricing shape | Capital cost plus maintenance plus trunk charges | Per user or per number, monthly | Per user per month, tiered by feature bundle | Usage: per number, per minute, per message |