Daniel's been thinking about the PBX — the old phone switch that used to live in a closet — and what actually happened when it stopped being a box you owned and became a service you subscribed to. He's not asking whether the cloud won. He's asking what the honest ledger looks like: what did we trade away, and what did we get in return that was genuinely impossible before? And he sharpens the question with two things. First, that the PBX's real successor isn't Twilio at all — Twilio is CPaaS, raw programmable building blocks. The product that replaced the PBX is UCaaS: RingCentral, 3CX, the whole turnkey cloud phone system category. And second, that this might not be a straight line from hardware to cloud — because a century ago the phone company already sold Centrex, which was basically a PBX you rented running in their exchange. So maybe we've looped.
The Centrex point is the one that should keep more people up at night. You spend twenty years and billions of dollars in venture capital to reinvent... the thing Bell System was selling in nineteen sixty-five.
The PBX as a service, except now it's got a React frontend and someone's charging you per seat per month instead of per line on the bill.
Right. And the reason that parallel matters is exactly what Daniel's getting at — if you don't know you've looped, you can't read the ledger properly. You think everything's new, so you don't notice what the old version had that this one doesn't.
So let's do the arc. What was the box, actually?
A PBX — private branch exchange — was a specialized computer that sat in your building and switched calls. Physically, it was a metal chassis in a rack or on a wall, with cards slotted in for different functions. A trunk card connected to the phone company's lines. A line card connected to each desk phone. A processor card ran the show. Copper pairs ran from the PBX to every handset in the building — usually twenty-two or twenty-four gauge, punched down on sixty-six blocks in the wiring closet.
And the thing was yours. You bought it, you owned it, it sat on your balance sheet as a capital asset. When it broke, you called the guy in the van.
The interconnect vendor. That's the part people forget — AT&T's breakup in nineteen eighty-four created this whole ecosystem of third-party companies that sold and serviced PBXs. Before that, you leased your gear from the phone company. After divestiture, suddenly you could buy a Nortel or a Mitel or a Rolm box from an independent dealer, and that dealer employed the technicians who came out and programmed it.
And programming meant... what, exactly?
In the eighties and early nineties, it meant a technician sitting at a dedicated terminal — often a dumb terminal or a proprietary phone set with admin buttons — navigating a menu system that was essentially a configuration database. Extension numbers, trunk groups, class of service restrictions, hunt groups, call routing tables. Every change was a deliberate act by a trained person who physically came to the site. Later, you got remote administration over a modem, but the model was the same: a specialist with deep knowledge of that specific system made changes one at a time.
And that slowness was a feature in some ways, right? Nobody could accidentally reconfigure your whole phone system from a coffee shop.
Nobody could reconfigure it at all without credentials, physical access or a dial-in, and knowledge of a proprietary system that took years to learn. The attack surface was the size of a postage stamp. Compare that to a cloud PBX where the admin portal is on the public internet and every intern's got a login.
So the box disappears, and what replaces it? Walk me through the fork Daniel's pointing at, because I think this is where most coverage gets it wrong.
Two things replaced it, and they're completely different animals. UCaaS — Unified Communications as a Service — is the direct descendant of the PBX. RingCentral, 3CX, Microsoft Teams Phone, Zoom Phone, 8x8. You pay per user per month, you get a softphone or a desk phone that registers to their cloud, you get an admin portal, and it works. Extension dialing, auto attendants, hunt groups, voicemail-to-email — the whole PBX feature set, but someone else runs the switch.
And then there's the thing Daniel actually wants to talk about, which is CPaaS.
Communications Platform as a Service. Twilio is the canonical example, though there's also Vonage, MessageBird, Plivo. This is not a phone system. It's a set of programmable building blocks — a voice API, a messaging API, a video API — that let developers build communications into their own applications. You don't get a dial tone. You get an API endpoint that can place a call, receive a call, play an audio file, gather DTMF input, route a session.
So the difference is: UCaaS is a product you buy, CPaaS is a component you build with.
And that distinction is where the whole "what was lost" question gets interesting, because the two models lost very different things.
Let's do UCaaS first. What did we trade?
The biggest one is independence from the internet. The old PBX didn't care if your WAN link was down. It had copper to every desk and copper trunks to the PSTN. Power outage? The phone company's central office had generators and batteries, and the PBX could run on a modest UPS. Your phones kept working. In a UCaaS world, if your internet connection goes down, your phone system is gone. Every handset is a paperweight. Every call drops. You can't even dial internally between desks.
Which is fine until the building's on fire and nobody can call anyone.
And the workarounds are all kludges. Some providers let you set up a cellular failover on a per-user basis. Some sell you an on-premises survivability gateway — which is, and I want to underline this, a small box you put in your closet that handles calls when the cloud is unreachable. You have reinvented the PBX but worse, and you're paying extra for the privilege.
There's something almost beautiful about that. The solution to cloud dependency is a tiny on-premises server you buy from the same vendor.
The industry calls it "local survivability." I call it admitting the architecture has a hole in it.
What else?
Call quality became someone else's problem, which sounds good but cuts both ways. On the old PBX, a bad-sounding call was almost always a problem with the trunk or the handset, and you could troubleshoot it. On UCaaS, your voice packets are traversing your LAN, your firewall, your ISP, possibly several transit networks, and then the provider's infrastructure before they hit the PSTN. Every hop adds jitter and latency, and none of them are under your control. The provider's support team can see their side, but the path between your desk and their data center is a blind spot.
So you traded a problem you could fix for a problem you can only complain about.
And the complaint goes into a ticket queue. The old interconnect vendor had a relationship with your business. He knew your building, knew your system, probably had a key to the phone closet. When something broke, you called his cell phone. The cloud replaces that with a service-level agreement and a portal you log into.
I want to sit with the skill thing for a second, because Daniel mentioned it and I think it's deeper than just "jobs went away."
It's a whole body of knowledge that's evaporating. The PBX technician understood TDM — time-division multiplexing. He understood how a T1 was twenty-four channels of sixty-four kilobits each, how CAS and PRI signaling worked, how to read a bit error rate from a CSU/DSU. He could put a butt set on a pair and hear whether the line was seized. That knowledge is valuable for understanding how networks work at a physical level, and the industry's losing it.
And what replaced it is... what, exactly? A different body of knowledge, or just a thinner one?
Different, but in some ways narrower. The modern VoIP engineer understands SIP signaling, codec negotiation, WebRTC, maybe some REST API design. But the physical layer is completely abstracted away. There's no equivalent of putting a test set on a line and hearing the problem. The diagnostic tools are all software — packet captures, SIP traces, log files. Powerful, but they don't give you the same intuition about what's actually happening.
I remember when a friend's office moved to a cloud phone system and the installer — who was maybe twenty-three — spent an hour trying to figure out why the fax machine wouldn't work. He'd never touched a fax machine in his life. Didn't know what T.38 was. The old guy who'd maintained their Nortel would have had it working in five minutes.
Fax over VoIP is its own special circle of hell, but you've hit on something real. The old skill set was broad in a way the new one isn't. A PBX tech touched everything from the physical cable plant to the carrier trunks to the station programming. The modern stack is stratified — the network team handles the switches and firewalls, the UCaaS admin handles the portal, the ISP handles the circuit, and nobody has end-to-end visibility.
Now let's flip to CPaaS, because I think this is where Daniel's actually more interested. Twilio isn't a phone system. What did we trade when we traded the PBX for an API?
We traded a product for a capability. And the ledger there is almost completely different.
Start with what we got.
The thing that was impossible before: provisioning a phone number in any of dozens of countries in under two minutes from a web browser. The old way, if you wanted a number in, say, Japan, you needed a local entity, a contract with a carrier, probably a physical presence. It took weeks or months. Twilio collapsed that to an API call.
And that's not just convenience. That's a whole category of business that couldn't exist before.
Right. The entire modern communications workflow — two-factor authentication via SMS, appointment reminders by voice call, call tracking for marketing attribution, virtual call centers that spin up and down with demand — none of that works if you have to buy a PBX and sign a trunk contract every time you need capacity. CPaaS made communications programmable in the way that AWS made servers programmable. You don't provision hardware; you call a function.
And the building blocks are lower-level than a PBX feature set. You're not configuring an auto attendant. You're writing code that answers an HTTP request, reads some input, queries a database, and decides what to do next. The phone call is just one input among many.
That's the shift. The PBX was a closed system that did phone calls. CPaaS is an open system where phone calls are a data type. And that openness means you can build things the PBX designers never imagined — a phone tree that checks your CRM before it routes the call, a conference line that transcribes the conversation in real time, a support line that looks up the caller's order history and routes them to the agent who handled their last ticket.
So what's the debit side?
The first thing is that you now depend on a single vendor for a capability that used to be distributed across your own infrastructure and the public switched telephone network. If Twilio has an outage — and they've had some significant ones — every application that depends on their API stops working. Every verification SMS, every call center, every appointment reminder. You've concentrated risk.
And you have no physical fallback. The PBX could fail in isolation — your building loses phone service, but the rest of the world still works. The CPaaS model means a single provider's failure can cascade across thousands of businesses simultaneously.
The second thing is cost predictability, which is weirdly inverted from what you'd expect. The old PBX was capital expenditure — you paid a big chunk up front, then relatively predictable monthly costs for trunks and maintenance. CPaaS is pure operational expenditure — you pay per minute, per message, per phone number. That's great for scaling up, but it means your costs are directly tied to usage in a way that can surprise you.
I've seen a Twilio bill after a bug in someone's retry logic. It was not a fun morning.
A loop that calls itself and places an outbound call each time... yeah, that can get expensive fast. The old PBX couldn't accidentally spend ten thousand dollars in an hour because of a logic error. The worst it could do was tie up all your trunks.
There's a deeper loss too, I think, around ownership of the logic. On a PBX, the call routing lived in the box. It was your configuration, on your hardware, and nobody could change it out from under you. With CPaaS, your call logic lives in your code, but it depends on an API that the vendor can deprecate, change pricing on, or rate-limit.
Vendor API risk is the cloud's dirty secret. Twilio's been pretty good about deprecation policies, but you're still writing against an interface you don't control. If they change the voice API — and they have, multiple times — you're rewriting your application. The old PBX didn't have API versions. The interface was a dial tone and a set of features that worked the same way for a decade.
And the skill loss is different here too. The PBX tech understood telephony. The CPaaS developer understands HTTP and JSON. Telephony becomes just another web service.
Which is powerful but also means the developer often doesn't understand the telephony part at all. They don't know what a SIP invite is, they don't understand early media versus post-dial delay, they've never heard of RFC three-two-six-one. And then they build something that works fine in testing but falls apart when a carrier in Brazil does something unexpected with the signaling.
So the CPaaS trade is basically: you get infinite flexibility and global reach, but you give up physical independence, cost predictability, and a certain depth of domain knowledge.
And you give up the idea that your phone system is a thing you can point to. The PBX was in a closet. You could see the lights blinking. If something was wrong, you could look at it and know. CPaaS is... a dashboard. Logs. Metrics. It's real, but it's not tangible in the same way.
Let's bring Centrex into this, because I think that's where Daniel's loop observation gets really sharp. What was Centrex, exactly?
Centrex — Central Exchange — was a service the phone company offered starting in the nineteen sixties where the PBX functionality lived in the telco's central office instead of on your premises. You got PBX features — extension dialing, transfer, conference — but the switching equipment was owned and operated by the phone company. You paid a monthly fee per line.
So it was cloud PBX before cloud was a word.
It was literally the same thing. The switching fabric was the phone company's Class Five switch — typically a Nortel DMS-one hundred or a Lucent 5ESS — partitioned to give each business its own virtual PBX. The phones in your office were connected directly to the central office over copper pairs. No box in your closet at all.
And what happened to Centrex?
It faded in the nineties and two thousands as businesses moved to on-premises PBXs. Businesses left Centrex because they wanted more control, more features, and lower costs. The on-premises PBX gave them that. Then twenty years later, they left the on-premises PBX for the cloud, which is... Centrex with a web portal.
So the loop is: rented from the telco, then bought and owned, then rented from a startup. And at each step, people believed they were moving forward.
They were moving forward in some ways. The PBX era gave you features Centrex couldn't match — unified messaging, computer-telephony integration, eventually VoIP. The cloud era gives you things the PBX couldn't match — global scale, API programmability, zero capital outlay. But the fundamental architecture of "someone else runs the switch" is exactly where we started.
Which makes you wonder what the next loop looks like. Are we due for another swing back to on-premises?
I don't think we're going back to boxes in closets, but I do think we're seeing the pendulum swing toward hybrid models. The local survivability gateways I mentioned. Edge computing that runs communications software on-site. The realization that "everything in the cloud" has failure modes that "everything on-premises" didn't, and the smart money is on architectures that can survive either.
There's something else in Daniel's question that I want to pull out — the idea that conflating CPaaS and UCaaS hides something important. What's hidden?
What's hidden is that they represent completely different philosophies about who controls the logic. UCaaS is the PBX model — the vendor designs the feature set, you configure it within their constraints. CPaaS is the anti-PBX model — the vendor gives you primitives, you build whatever you want. The first is product. The second is platform.
The platform model is the one that actually changed what's possible.
Yes. UCaaS is a better PBX. CPaaS is a different category entirely. It's the difference between buying a car and getting access to an engine, wheels, and a chassis with the instruction "build whatever moves you."
That's a good image. But it also points to the hidden cost of CPaaS that nobody talks about — you have to build it. The PBX came with an auto attendant already working. Twilio gives you an API that can be an auto attendant if you write the code.
Maintain it, and monitor it, and fix it when it breaks at three in the morning. The operational burden shifts from the vendor to your engineering team. For a startup that was going to build custom communications anyway, that's fine. For a dentist's office that just wants the phones to work, it's absurd.
The market sorted itself accordingly. UCaaS for the dentist's office, CPaaS for the engineering team. Two different answers to "what replaces the PBX," for two different kinds of buyer.
The interesting tension is in the middle. The mid-market company that's outgrowing UCaaS but can't justify building on CPaaS from scratch. That's where you get these hybrid plays — companies building vertical-specific communications products on top of Twilio, selling to that middle market.
Let's talk about reliability for a minute, because I think the old PBX had a property that neither UCaaS nor CPaaS has fully replicated.
The PBX was a single point of failure in a good way. If it failed, your phones went down, but only your phones, and only in one building. The failure domain was contained. In the cloud model, the failure domain is the provider's entire region or service. When Twilio's voice API has an issue, it affects every customer in that region simultaneously.
The old PSTN had this almost absurd level of reliability engineering built in. Five nines — ninety-nine point nine nine nine percent uptime — was the standard. The central office had days of battery backup and diesel generators. The network was designed by people who thought about nuclear war.
The PSTN was built to survive things that would take down any cloud provider. It was circuit-switched, so once a call was established, it had a dedicated path through the network. No packet loss, no jitter, no congestion collapse. The cloud is packet-switched, best-effort, and shared with every Netflix stream and Zoom call on the same infrastructure.
We traded survivability for flexibility. That's the trade in a sentence.
We mostly don't notice until something big breaks. A hurricane takes out the internet and suddenly nobody can call anyone, even though the old copper network might still be standing.
Alright, let's do the full ledger. I want to hear you tally it.
On the debit side — what we lost. One: physical independence. The old system didn't need the internet. Two: contained failure domains. Your PBX failing didn't take down anyone else's. Three: cost predictability. Capital expenditure with known maintenance costs versus operational expenditure that scales with usage. Four: a deep body of craft knowledge — the PBX technician who understood the system end to end. Five: ownership of the logic. Your configuration, your hardware, your rules. Six: call quality that didn't depend on seventeen different networks behaving themselves.
On the credit side?
One: global reach at zero setup cost. A phone number in any country in minutes. Two: programmability. Communications as a software primitive, not a closed appliance. Three: elastic scale. Spin up a thousand-line call center in an afternoon, tear it down that evening. Four: integration depth. Your phone system can query your database, update your CRM, trigger your workflows. Five: zero capital outlay. No fifty-thousand-dollar box to buy before you can make a call. Six: continuous improvement. The cloud provider adds features every week; your PBX ran the same software for five years.
That's a pretty honest ledger. Neither column is empty.
I think Daniel's right that "great" and "strictly better" aren't the same claim. The cloud model is great for a lot of things. It is not strictly better. There are failure pattern the old PBX simply didn't have, and there are businesses — hospitals, emergency services, critical infrastructure — where those failure pattern are dangerous.
The hospital example is a good one. A hospital with a cloud phone system loses internet and suddenly nurses can't call between floors. That's not an inconvenience. That's a patient safety issue.
Hospitals know this, which is why many of them still run on-premises PBXs or hybrid systems with local survivability. The people who deal with life and death have been slower to trust the cloud, and they're not wrong.
Where does this leave us? We've looped from Centrex to PBX to cloud, and the cloud is mostly Centrex with better marketing. What's the next thing?
I think the next thing is the collapse of the distinction between UCaaS and CPaaS. The UCaaS vendors are adding APIs. The CPaaS vendors are building higher-level products. Eventually you won't choose between "phone system as a product" and "phone system as a platform" — you'll get a platform that can be a product when you want it to be, and primitives when you need to build something custom.
The ownership question doesn't go away. It just gets more complicated. When your phone system is a set of API calls to a platform that's also your CRM and your contact center and your chatbot, who do you call when it breaks?
You call the one vendor. Which is convenient right up until it's terrifying.
I want to go to Hilbert. He's been unusually quiet, and I'm worried that means he's got a story.
Hilbert: I installed a Nortel Meridian One in nineteen ninety-four. Option eleven C. Forty-eight extensions, four trunk cards, a voicemail module the size of a microwave. Took me three days.
You installed a PBX.
Hilbert: For a law firm in Hartford. They'd bought it used from a bank that was upgrading. Cost them twelve thousand dollars. I charged two thousand for the install, which included programming all the extensions and setting up the auto attendant.
Wait — you did the programming? You were the guy in the van?
Hilbert: I was twenty-three. Worked for a company called Tel-Plus. We did Nortel and Mitel. I had a butt set, a punch-down tool, and a binder full of programming codes. The codes for the Meridian were all four-digit sequences you entered on the admin phone. Star-nine-three-seven-two to enter programming mode. Star-eight-four-one-one to assign an extension to a port. You memorized them after a while.
When you say you installed it, you mean you physically mounted the chassis, punched down all the cross-connects, and programmed the whole system.
Hilbert: Tested every handset. And labeled the blocks. And trained the receptionist on how to use the console. Three days, one person, done.
What happened to that system?
Hilbert: As far as I know it's still running. They had it when I left Tel-Plus in ninety-seven. I drove past the building a few years ago, law firm's still there. Wouldn't surprise me.
Twenty years on a used PBX. That's the reliability we're talking about.
Hilbert: The thing about the Meridian was, once it was set up, it didn't change. The law firm wasn't adding new features every week. They had extensions, they had transfers, they had voicemail. That's what they needed. The system did those three things and it did them forever.
The cloud model assumes you want continuous change. The PBX model assumed you wanted continuous stability. Those are just different values.
Hilbert: I've got four of the option eleven cards in a box in my apartment. Trunk cards, line cards, a processor. Can't bring myself to throw them out. They still work. You can't say that about a SaaS subscription.
You have PBX cards in your apartment.
Hilbert: They're not hurting anyone.
I'm not sure that's true, but go on.
Hilbert: The part you didn't mention is the sound. A call on that Meridian, copper to the central office, sounded like the other person was in the room. No compression, no packet loss concealment, no jitter buffer making everything sound slightly underwater. Just sixty-four kilobits of clear channel end to end. People don't remember what a phone call used to sound like.
The PSTN used G.711 uncompressed. Most VoIP calls are compressed — G.729 or worse — and even when they use G.711, it's riding on top of a packet network that can drop or delay. Hilbert's right that the baseline quality has objectively declined.
Hilbert: The lawyers complained about the hold music. That was the only audio quality issue in ten years.
Hold music complaints are timeless.
Hilbert: They wanted something classical. The system only supported eight-bit mono WAV files, total of four minutes. I gave them Pachelbel's Canon. By year three they would have killed a man to hear something else.
You couldn't change it?
Hilbert: You could. They never asked. They just complained to each other. I found out years later from one of the partners.
There's something about that story that captures the whole thing. The system could be changed, but the friction of change meant they just lived with it. And honestly, Pachelbel's Canon for ten years is fine. Nobody died.
Hilbert: The cloud would have let them change the hold music from an app. They'd have changed it every week. Spent more time choosing hold music than making phone calls.
That's the paradox of removing friction. You optimize things that don't matter.
Hilbert: I'm not saying the old way was better. I'm saying it was different, and the differences were real, and most of the people writing about this never punched down a sixty-six block.
The cutting-room floor detail I can't get out of my head: the PSTN's five-nines reliability standard means less than six minutes of downtime per year. Most cloud providers target three or four nines. The difference sounds small — ninety-nine point nine nine nine percent versus ninety-nine point nine nine percent — but it's the difference between five minutes of downtime a year and almost nine hours.
The PSTN achieved that with technology from the nineteen seventies. Circuit switching, physical cross-connects, and generators in the basement. Sometimes the old thing was better at the thing it was designed for.
You can't unbake the cloud. The programmability and global reach are real, and they enable things that were literally impossible before. But I think Daniel's right that the honest ledger matters. Knowing what you traded means you can design around the gaps instead of being surprised by them.
Maybe the smartest thing the industry could do is take the Centrex loop seriously. We've been here before. The pendulum swings. The question isn't which architecture wins — it's how to build systems that don't assume the pendulum won't swing back.
Thanks to Hilbert Flumingtop for producing, and for the PBX cards in his apartment that we're all going to pretend are normal.
This has been My Weird Prompts. Find us at my weird prompts dot com, or email the show at show at my weird prompts dot com.
We'll be back soon. Don't change your hold music.
