Now The Platforms Are Coming Fully Cooked
That's Not Necessarily Good News.


Something has changed since I wrote about Frankenstein contact centres last week.
A few people came back with the same question: "But the CCaaS vendors have solved this now, haven't they? They're all shipping AI natively. Isn't that exactly what you were describing?"
It's a fair challenge. And the answer is: partly yes โ and that's precisely where the new risk lies.
The Platforms Did Listen
Let's be honest about what's happened. The major CCaaS vendors have moved fast.
Native intent understanding, predictive engagement, agent assist, autonomous resolution โ it's all arriving baked in, not bolted on. The integration problem I described last week โ months of custom API work to make your stack talk to itself โ is being actively addressed. For many organisations, that's genuinely good news.
So why am I still cautious?
You're Not Buying AI. You're Buying Someone Else's Vision of AI.
Here's what "fully cooked" actually means when you read the fine print.
The AI your CCaaS vendor ships is trained on their data, optimised for their use cases, and constrained by their architecture decisions. When they decide what the AI can and can't do โ which interactions it handles, which channels it understands, what it can execute, when it escalates โ those decisions are made at a platform level. Not for your business specifically. That's fine when your needs align with their vision. It becomes expensive when they don't.
The model is shifting from "buy the platform, bring your integrations" to "buy the platform, accept our AI." The integration burden moves โ but the dependency doesn't go away. It just migrates upstream.
And here's the part that doesn't show up in the vendor briefing: when the platform's AI makes a decision you disagree with โ an escalation threshold that's too aggressive, an intent model that misreads your customer base, a capability that's on their roadmap and not yours โ your options are limited. You can configure within their parameters. You can raise a product request. You can wait.
You cannot go around them.
CPaaS Is a Different Conversation Entirely
This is where the architecture debate gets genuinely interesting โ because CCaaS and CPaaS aren't really competing products. There are different philosophies about who controls the logic.
CPaaS platforms don't come fully cooked. They come as programmable infrastructure โ voice primitives, messaging APIs, media processing, and an empty canvas for your application logic.
That's not an easier path. In fact, for most organisations, it's significantly harder. You're trading vendor dependency for engineering dependency. Instead of accepting someone else's AI model, you're building your own โ which means you need the team, the time, and the discipline to do it well.
But what you get in return is architectural sovereignty.
Your AI isn't the platform's model. It's your model, running against your data and making decisions based on your business logic. When you want to change how escalation works, you change it. When a better AI model becomes available, you swap it in. When you need to connect a new data source, you give your AI access to an API endpoint โ configuration, not a development project.
Model Context Protocol is making this increasingly practical. Your AI agent connects to your CRM, billing system, and knowledge base through standardised connectors. Change the underlying model without rebuilding the integrations. The platform is yours because you built it.
This is the architecture that gives you genuine optionality. The question is whether that optionality is worth the cost of creating and maintaining it.
So Which One Is Right?
The honest answer โ and this is where "Problem first. Platform last." actually means something โ is that it depends on what you're trying to protect.
Fully-cooked CCaaS makes sense if:
Your AI requirements are largely standard โ intent understanding, routing, agent assist, self-service automation
You don't have the internal capability to build and maintain custom AI orchestration
Speed to value matters more than long-term architectural flexibility
Your competitive differentiation isn't the contact centre itself
CPaaS makes sense if:
Your contact centre is a genuine differentiator โ the experience is the product
You have complex, proprietary workflows that no platform vendor will ever prioritise building for you
You need to move faster than a vendor roadmap allows
You're building at a scale where per-interaction economics matter significantly
A hybrid approach โ which is where many serious deployments land โ makes sense when:
You want the stability and compliance coverage of an established CCaaS core
But you need programmable infrastructure for specific channels, edge cases, or AI workloads the platform doesn't handle
You're prepared to own the integration layer that comes with it
The Questions Nobody Asks in the Vendor Briefing
When you're evaluating a fully-cooked AI platform, the demo is always compelling. The AI works. The integrations look seamless. The roadmap sounds ambitious.
Ask these instead:
What can't the AI do โ architecturally? Not what it doesn't do yet. What is it structurally incapable of doing? Every platform has constraints baked into its model. Find them before you sign.
Who owns the AI's behaviour? If a model update changes your deflection rate, what's your recourse? If a new release shifts how escalation works, how much control do you actually retain?
What's the exit cost in three years? If a fundamentally better architecture emerges, how much of what you've built inside their ecosystem transfers? How much doesn't?
What happens at the edge of their roadmap? Your most differentiating workflows are probably the ones no platform vendor prioritises. What do you do when you hit that wall?
The Real Risk Has Changed
For years, the risk was what I described last week โ accumulating complexity, integration debt, and vendor sprawl that cost more than the capabilities were worth.
That risk is real, and it hasn't disappeared for organisations still managing legacy stacks.
But for organisations making platform decisions right now, the emerging risk is different.
It's choosing a platform whose AI vision aligns with the demo, signing a three-year term, and discovering that in 18 months, the platform's direction and your business needs have divergedโand you have nowhere to go.
The platforms are coming fully cooked. The question isn't whether the food is good.
It's whether you're comfortable with someone else controlling the menu.
Paul Wilson Co-founder, Canzuki | Vendor-agnostic CX consulting across NZ & AU | Problem first. Platform last.
