The contact centre industry has a long history of buying best-of-breed. It’s not unusual to buy a voice IVR system from one vendor, a webchat bot from another, workforce management from a third, analytics from a fourth. Each system gets evaluated on its own merits, each one solving a specific problem well.

I’ve spent years building on top of these kinds of architectures. And to be fair there are legitimate reasons the point solution approach has worked for a lot of organisations.

But I’ve noticed something recently. Firstly, the technical tradeoffs shift as you scale. But, the bigger impact recently has been AI, and to a lesser extent, regulation catching up with AI. I think that has changed how we should think about those tradeoffs in today’s ecosystem, and that’s what this post is about.

The case for point solutions

Let’s start with the advantages with point solutions – in part because I think that this can get dismissed by platform sellers.

A specialist vendor that does one thing well can can outperform a platform’s built-in equivalent. If you need a best-in-class WFM tool, a vendor who has spent ten years on nothing but workforce optimisation is probably going to have more sophisticated forecasting models than whatever a platform ships as a bundled feature. That’s can be a real advantage, if that’s what you need.

Point solutions are also faster to deploy for a single use case. You don’t need a platform migration to get a voice bot live. You sign a contract, integrate with your telephony, and you’re running in weeks. That speed matters when you’re under pressure to show results.

They’re also easier to get budget approval for, as it’s one subset of the overall cost. “We need £40k for a chatbot” is a simpler conversation than “we need to migrate our entire contact centre to a new platform.” Procurement teams understand discrete purchases.

Finally, I don’t want to dismiss the innovation that happens in niche vendors. A startup building nothing but conversational AI can iterate on their product faster than a platform team that’s also shipping telephony features, analytics, and WFM in parallel.

These are good advantages, they really are.

Where the tradeoff starts to shift

The problem is that these advantages are strongest at the point of purchase and weaken over time. Let me try and illustrate what I mean, using a scenario I’ve seen play out in different forms across multiple customers. The scenario is made up, but every element of it has shown up in real customers.

Picture a healthcare contact centre. Let’s call them Morgan Health. Private provider, around 200 seats, handling appointment bookings, prescription queries, and post-discharge follow-ups.

Over five years, Morgan has assembled what looks like a modern contact centre. Voice bot from Vendor A. Webchat bot from Vendor B. WFM from Vendor C. Analytics from Vendor D. Legacy PBX with SIP trunks underneath.

The dashboards are green. Leadership thinks the contact centre is modern because it has bots. On paper, everything works.

But the technical reality is different, and that bleeds into the experience. A patient calls about a prescription, the voice bot triages them, then transfers to an agent who has zero context about what the bot already asked. The patient repeats everything. This happens dozens of times a day.

The webchat bot resolves an FAQ, but that interaction never shows up in the analytics platform because the two systems don’t share data. Management underestimates chat volume. When things change, there’s a lag between the contact center getting the changes and the FAQ being updated. Agents spend additional time having to explain these discrepanices.

When something breaks across the voice bot and telephony boundary, Vendor A blames the SIP config. The telephony vendor blames the bot. The ticket takes three weeks to resolve because nobody owns the gap.

The WFM tool can’t see AI deflection rates because it only gets telephony-layer data. Staffing models are always slightly wrong. Not by loads, but just enough that the contact center is over or under-staffed every week.

Every quarter, IT spends two weeks pulling data from four vendor dashboards into a board report that nobody fully trusts.

This is what best-of-breed can look like when you actually live with it over time. Each tool still does its specific job well. But the spaces between them are where the problems live. And those problems compound.

Tradeoff 1: total cost of ownership over three years

Individually each point solution has a defensible price tag. The voice bot is £X per month, WFM is £Y per seat, analytics is £Z per dashboard.

What doesn’t appear in those business cases is the integration cost. I don’t mean the setup or configuration cost, or adding an API key from one solution to another. I mean building middleware so the WFM tool can consume events from the voice bot. Mapping data schemas between systems that were never designed to share data. Writing custom ETL jobs to get Vendor A’s call records into Vendor D’s reporting format. Then maintaining all of it every time a vendor ships an update that changes their data model or deprecates an endpoint.

In healthcare, every integration point is also a data governance question. Patient data flowing between systems means more data processing agreements, more DPIA assessments, more surface area where something can go wrong. Morgan Health’s IT team spends more time maintaining glue code between vendors than building anything that improves the actual service. This isn’t a problem unique to healthcare, it’s just that it’s taken more seriously there – arguably it gets the attention there that it ought to get in every industry (but that’s another blog post!)

Then the voice bot contract comes up for renewal and there’s a 30% price increase. Suddenly you’re calculating three years of integration costs, middleware maintenance, and vendor management overhead on top of the licence fees. The total cost looks nothing like the original business case.

A platform approach usually has a higher upfront cost, it’s true. Migration is more work than buying a single tool. But, once you’ve done it, you’re then not paying the integration tax every quarter, and you’re not at the mercy of four separate vendor pricing strategies.

There’s an obvious counter here – which is what stops the platform raising prices too? My experience is around Amazon Connect and how that’s built, and the answer is architectural. Your call recordings, transcripts, and contact trace records live in S3 buckets in your own AWS account, in standard formats. If Connect ever stopped making sense commercially, you could migrate your data out. That’s harder to do when a point solution vendor stores everything in their cloud, in their format, behind their API.

Tradeoff 2: regulatory readiness

I’ve written separately about the EU AI Act and what it means for contact centres. The short version: if you’re using AI to interact with customers, you need to demonstrate transparency, maintain audit trails, and prove human oversight. That means logging what the AI decided, why it decided it, and what happened next.

Point solution vendors will solve this for their own product. A good voice bot vendor will add compliance logging to their platform. That’s fine in isolation.

The problem is at the boundaries. Morgan Health’s voice bot logs decisions as JSON payloads pushed to the vendor’s analytics dashboard. Their webchat bot logs decisions as event streams into a separate data store. Neither system records what happened during the handoff between them.

When the compliance team needs a unified audit trail of every AI-driven patient interaction, someone has to write code to join two completely different log formats, reconcile timestamps across systems that may not even be in the same time zone, and fill in the gaps where one system handed off to another and nobody recorded the transition. In a healthcare setting, those gaps aren’t just a nuisance; they’re a liability.

A platform that shares a single data layer doesn’t have those boundaries. On Connect, contact trace records, call recordings, chat transcripts, and AI agent decision logs all live in the same AWS account, in consistent formats, queryable through the same tools. A compliance report comes from one data source. That’s an architectural difference that matters when a regulator asks you to explain what your AI did and why.

This is a grown-up, at scale problem, to be clear. If you’re only running AI on one channel then a point solution with good compliance tooling might be perfectly adequate. The tradeoff shifts when you’re running AI across multiple channels and the audit trail has to cross system boundaries.

Tradeoff 3: what a shared data layer makes possible

This is the one I find most interesting technically. I’ll use Amazon Connect as the example, because it’s what we build on at CloudInteract. But the principle applies to any platform with a genuine shared data layer.

In Connect, a contact trace record captures the entire lifecycle of an interaction: the queue it entered, the AI agent’s decisions, the human agent it was routed to, the outcome, the follow-up task. That record exists in one place. The AI agent, the analytics engine, and the WFM scheduler all read from the same data. Nobody had to build an integration to make that happen.

That changes what you can do. Your WFM tool can see real AI deflection rates, not a number you manually pulled from a bot dashboard and keyed into a spreadsheet. Your AI agents can be evaluated against actual outcomes, not just “did the caller hang up or get transferred.” When something goes wrong, you can trace the full journey in one system instead of correlating timestamps across four vendor dashboards.

None of this is impossible with point solutions. You can build integrations to pipe data between systems. People do it all the time. But you’re recreating something the platform gives you by default, and you’re maintaining that recreation forever. And, you have to do it.

Go back to Morgan Health and reimagine them on Connect. A patient calls. The AI agent triages using Bedrock, and it can see the patient’s recent chat transcript because chat and voice share the same contact history. It escalates to a human with full context attached. The human creates a follow-up task that shows up in the same system. WFM adjusts next week’s staffing based on actual deflection data. The compliance team queries one data source for the audit trail.

None of that required middleware or custom glue code. It works because the data was never split apart in the first place.

On the commercial side, Connect’s Unlimited AI pricing reinforces this. You’re not paying per AI feature or negotiating a new contract every time you want to use another capability. With point solutions, adding AI to another channel means another vendor, another contract, another integration project. On Connect, it’s just a configuration change.

So what should you do?

I don’t think point solutions are always wrong. If you need one specific capability, you’re not running AI across multiple channels, and you don’t have a compliance requirement that crosses system boundaries, a specialist tool might be exactly what you need. It’ll be faster to deploy and probably cheaper in year one.

But if you’re running a contact centre at any kind of scale, with AI on more than one channel, with regulation on the horizon, and with an IT team that’s already spending too much time on integration work, the tradeoffs tilt toward a platform. Not because platforms are perfect, but because the problems they avoid are the ones that get more expensive every year.