Chapter 2 walkthrough from The AI Contact Center Handbook by Sho Shimoda. Available on Amazon.
Three pitches, one architecture
On a Thursday in October, Daniel Ostrowski, the Chief Technology Officer of a specialty insurance carrier in Hartford, sits in a windowless conference room and endures three vendor pitches back to back to back. Each one lasts an hour. Each one is delivered by a well-dressed sales team that flies in from a different city. Each one shows him a slick demo of what looks like — from where Daniel is sitting — essentially the same product.
At the end of the third pitch, Daniel walks his head of applications back to their office and asks a question that has been forming in his mind for three hours:
"Are those three companies actually selling different things?"
His head of applications, a fifteen-year veteran named Katrina, thinks for a moment. "They started out selling different things," she says. "Right now they are all sprinting toward the middle. In two years they will all be selling the same thing under different names. The only question is which of them will still be independent."
The three acronyms describe three historical starting points; the reality on the ground is that all three are converging into a single, cloud-native platform that runs the whole communications surface of the enterprise.
The three acronyms, decoded
| Acronym | What it is | Whose problem it solved | Vendors you know |
|---|---|---|---|
| UCaaS Unified Communications as a Service |
Your internal phone-and-collaboration system in the cloud — voice, video, chat, presence, screen share. Inward-facing. Its customer is your employee. | Replacing the on-prem PBX (the basement-humming phone system from Ch 1). | Microsoft Teams Phone, Zoom Phone, RingCentral, 8x8, Webex Calling |
| CCaaS Contact Center as a Service |
Your customer-service platform in the cloud — the ACD, routing, agent desktop, WFM, QA, and increasingly the AI. Outward-facing. Its customer is your customer. | Replacing on-prem Avaya, Cisco, and Genesys contact-center suites. | Genesys Cloud, Five9, NICE CXone, Amazon Connect, Talkdesk, Salesforce Service Cloud Voice |
| CPaaS Communications Platform as a Service |
Developer building blocks — send an SMS, place a call, verify a phone number — through APIs. You don't log in; your code does. | Giving developers a way to embed communications into any app without negotiating with a carrier. | Twilio, Vonage, Bandwidth, Sinch, MessageBird, Amazon SNS |
In plain English: A quick way to keep the three straight is to look at who the vendor's marketing photos show. UCaaS shows employees on a video call. CCaaS shows an agent with a headset serving a customer. CPaaS shows a developer with a laptop and a hoodie. The categories were built around three different mental images of "the user."
The convergence — three arrows meeting in the middle
All three categories, over the last five years, have grown into each other's territory. Zoom launched a contact center product in 2022. Microsoft Teams added contact-center capabilities and developer APIs. Genesys added internal collaboration on top of Genesys Cloud. Five9 partnered with Zoom. Twilio built Flex — an actual contact center — on top of its APIs. Draw those arrows on a whiteboard and you get a single point in the middle. Analysts now call it a Unified CX Platform, or, more prosaically, a Communications Cloud.
The M&A activity backs the pattern up. Cisco acquired IMImobile (CPaaS) in 2021 to bolt communications APIs onto Webex. Salesforce paid $27.7 billion for Slack, which was in part a UCaaS play strapped onto a CRM. Amazon quietly folded a series of AI-communications startups into Amazon Connect. Every deal reads the same way when you squint at it: a vendor strong in one of the three categories buying its way into the other two.
Why is this happening now, when the three categories coexisted comfortably for a decade? Three reasons.
| Driver | What changed |
|---|---|
| 1. Architectural | Once all three moved to the cloud, they all became the same kind of thing underneath — containerized microservices, public cloud infra, APIs, managed databases. Vendors could plausibly expand into each other's territory without rebuilding. |
| 2. Customer demand | Enterprise buyers got tired of integrating three separate platforms. The maintenance cost of the seams — identity mismatches, sync bugs, reporting inconsistencies — became specific enough that a single-vendor pitch started to look attractive even to best-of-breed buyers. |
| 3. AI | Modern AI — transcription, sentiment, agent-assist, voice bots — needs to see across all three domains. It needs to know the customer just called an agent, sent a support chat, and spoke to sales in a video meeting last week. That cross-domain visibility is nearly impossible across three separate vendors. It's straightforward when they live in one. |
The one-line takeaway: The three acronyms describe where the vendors came from; the platform they are all becoming is the same platform.
Where the 20–30% TCO savings actually come from
The industry benchmark most often cited is a 20% to 30% total-cost-of-ownership reduction over three years from moving to a unified cloud platform vs. running separate systems. That number appears in Nemertes, Metrigy, and Forrester TEI reports. The savings come from five places.
| Savings category | Where the money comes from |
|---|---|
| 1. Hardware & telco | PBX maintenance contract (12–18% of purchase price / year), desk-phone replacement cycles, per-channel PRI line costs — all replaced by SIP over the data network at half the cost. |
| 2. IT labor | The team of 2–5 specialists who came in at 3 a.m. when the switch went down shrinks to a small cloud-ops function focused on config, not infrastructure. Vendors do the patching, failover, DR. |
| 3. Real estate | Cloud platform → agents work anywhere. Call-center real estate footprints have shrunk 20–40% at the median since 2022 (Site Selection Group). |
| 4. License consolidation | Bundled seat pricing regularly comes in 15–25% below best-of-breed procurement across UCaaS + CCaaS + video. |
| 5. Middleware & integration | The custom integration work required to make separate stacks talk to each other lives on the professional-services line every year forever. Convergence eliminates most of it. |
The time-to-market story is arguably even more compelling. A new call routing rule that would have taken six weeks on an on-prem Avaya (change ticket, change window, specialist consultant, rollback plan) takes an afternoon on a modern cloud platform. When the pandemic hit in March 2020, a regional airline running Twilio Flex moved its entire 800-agent contact center from on-prem to cloud in eight days. That is now the case study everyone tells.
Monolith vs. Composable — the technical shift
If there is a single technical concept that separates the modern platform from the legacy one, it is composability. The legacy contact center was a monolith: you bought the whole thing from one vendor, and if it didn't do exactly what you needed, you filed a feature request, waited eighteen months, and paid a systems integrator to work around it in the meantime.
The modern platform is composed of primitives — voice, messaging, video, transcription, routing, natural language understanding — that you can assemble however you want, via APIs.
Twilio Flex is the clearest example. It's technically a contact center — you can buy it and get a working agent desktop out of the box — but under the hood it's composed of Twilio's primitives (Voice API, Messaging API, TaskRouter, Sync, Studio). Each primitive is separately documented, separately priced, separately accessible. You can use Flex as the whole product, use the pieces to build something custom, or start with Flex and progressively replace pieces as your requirements grow.
In plain English: A monolith is a car you can't open the hood of — you get what the manufacturer shipped. A composable platform is a car whose engine, transmission, and dashboard are all separate components you can swap. The second one is harder to buy (you need someone who can work on cars). It's the only one where you can, later, put in an engine that hadn't been invented yet.
The upside is that composability is the only way to build the kind of agentic AI experiences the rest of the book describes. An AI agent that has to place a call, read from a CRM, send an SMS, and hand off to a human is doing composed work — voice API → CRM API → messaging API → routing API, in a sequence with data flowing between the steps. That is a job for a composable platform, not a monolith.
What the buyer should actually evaluate
If you're Daniel Ostrowski sitting in that conference room after the three pitches, what should you actually be evaluating? Not which of the three categories to buy — that framing is already dated. You should be evaluating the platform on the criteria that will matter three years from now, when your operation looks nothing like it does today.
| Criterion | The question to actually ask |
|---|---|
| 1. API surface & openness | Can your engineering team, with reasonable effort, build custom workflows on top of the platform? Are APIs documented, versioned, and stable? Or is the platform effectively closed past vendor-supplied config? |
| 2. AI architecture & openness | Does the platform let you bring your own AI — plug in OpenAI, Anthropic, a fine-tuned model, or an internal LLM — through a defined integration point? Vendors who lock you into their AI are going to look worse as the model market keeps moving. |
| 3. Data model coherence | Does the platform have a single canonical customer identity across voice, chat, email? Or does each channel have its own record you stitch together downstream? Stitching cost is enormous — both operationally and for what AI you can layer on top. |
| 4. Cross-domain visibility | Can a supervisor — or an AI copilot — see, in one interface, what a customer just did across voice, messaging, and video? Without this, all the AI in the world runs into the same limitation the legacy stack had. |
| 5. Compliance posture | HIPAA, PCI DSS, GDPR, emerging state-level AI regulations. Are those capabilities baked in as configuration options, or are they roadmap items? |
| 6. Contract flexibility | Per-seat, per-usage, or outcome-based? Can you scale down as easily as up? Contact center demand is spiky — a 12-month floor is going to hurt in quarters when AI cuts headcount need 30%. |
| 7. Vendor viability | The market has consolidated fast. You do not want to buy into a platform whose vendor is going to be absorbed into a competitor's roadmap in eighteen months. |
Notice what is not on this list. Feature checklists — the endless spreadsheet columns of "does the platform have skills-based routing?" — matter less than they used to. Every modern platform has skills-based routing. The interesting differentiation is architectural, not featural.
Daniel Ostrowski, after his three pitches, ended up choosing the vendor whose answer to "what does your AI integration look like?" was: "we let you plug in whatever model you want, we don't charge you extra for it, and here is the SDK." That was not the vendor with the flashiest demo. It was the vendor with the most honest architecture. Two years later, when Daniel's team wanted to swap the underlying LLM for a newer, cheaper one, they did it in a sprint. The colleagues who had chosen a competing vendor with a proprietary AI were still stuck.
The moral is not that Daniel got lucky. It's that the vendor answered a specific question honestly and in language that revealed something about their architecture. Design your evaluation around questions of that shape. What can I extend? What can I replace? What data do I control? What can I take with me if I leave? Those are the questions whose answers survive contact with the real deployment.
What to take with you from Chapter 2
The three acronyms — UCaaS, CCaaS, CPaaS — are historical artifacts. They describe three different starting points for what is now converging into a single cloud-native platform. UCaaS came inside-out (replacing the internal phone system). CCaaS came outside-in (replacing the customer-facing contact center). CPaaS came bottom-up (developer building blocks). All three are now expanding into each other's territory, and the winning vendors are the ones who can credibly deliver all three from one platform.
The economic case is real: 20–30% TCO reduction, order-of-magnitude faster time-to-market, and — most importantly — the architectural foundation you need to layer AI on top. That last point is not incidental. AI in the contact center needs cross-domain visibility, real-time data, and composable primitives. It cannot get any of those from three separately procured systems held together with middleware.
If you're evaluating vendors right now, the criteria that matter are architectural: API surface, AI openness, data-model coherence, cross-domain visibility, compliance posture, contract flexibility, vendor viability. Feature checklists are a distraction. Every modern platform has skills-based routing. The interesting question is what happens when you want to do something the vendor didn't ship.
One last note. Convergence in the vendor market is not automatically convergence in your operating model. Organizations whose internal buying structures still split the three categories across three different budgets and three different vice presidents will get less out of the convergence than organizations that reorganize their procurement to match. That has to be designed on purpose.