The CX Industry Has a Tool Problem, Not a Technology Problem

Every CX vendor has AI now. Every pitch deck says "omnichannel." Every demo shows a chatbot answering a question. Customer experience in most companies is worse than it was five years ago. The technology got better. The results didn't. That's not a technology problem. It's an architecture problem.

CX infrastructure is the unified data, routing, and governance foundation that sits beneath every customer interaction: one data model, one routing engine, one governance framework, so that multiple capabilities share context instead of duplicating it. Without it, every tool you add makes the problem worse.

I've spent eight years watching this industry invest billions in tools while ignoring the foundation those tools sit on. The pattern repeats so reliably it almost feels scripted. A company buys a chatbot, connects it to their ticketing system with an API integration that took three months to build, launches it, then wonders why their CSAT scores barely moved. Six months later, they buy an analytics platform to figure out what went wrong. That platform needs its own integration. Another three months. Another six-figure contract.

Tool fatigue is real

Companies have accumulated CX tools the way some people accumulate gym memberships. Having the tool doesn't produce the outcome.

The average enterprise CX stack now includes five to eight tools with partially overlapping capabilities. A chatbot here, a ticketing system there, a knowledge base, a CRM, an analytics dashboard, a workforce management tool, a quality monitoring platform. Each one was purchased to solve a specific problem. Each one came with its own onboarding, its own data model, its own reporting dashboard, its own definition of what a "resolved interaction" even means.

I've walked into organisations where the CX team has access to seven dashboards and can't answer a basic question: what percentage of customer issues are actually resolved on first contact? Not because the data doesn't exist. It exists in seven different places, measured seven different ways, with seven different definitions of "resolved."

Every one of those tools works fine in isolation. The tools were never designed to work together, and no amount of middleware will fix a problem that's structural.

The integration tax

What nobody puts in the pitch deck: the real cost of a CX tool isn't the subscription. It's the integration.

Every new tool needs to be connected to every other tool. Data needs to be mapped. Workflows need to be bridged. Edge cases need to be handled, and in CX, edge cases are about 40% of the total volume. The integration work takes longer than the implementation. It costs more than the licence. And it's fragile. One API change on either side and the whole chain breaks.

At the large enterprise level, it is not unusual for a company to spend $200,000 on a CX platform and three times that on the integrations to make it work with everything else, plus six figures a year maintaining those integrations. Mid-market budgets are roughly half that, but they expect more pre-configured capabilities out of the box. SMBs spend a fraction of mid-market and have almost zero appetite for paying for customisation. The pattern is the same at every tier: the tool was the cheap part. The architecture tax was the real price.

Gartner reported that roughly 52% of enterprise digital initiatives don't meet their business outcome targets. I don't think that's because the technology is bad. I think it's because most of those initiatives add another tool to a stack that's already architecturally broken. You can't integrate your way out of a foundation problem.

Infrastructure vs. tools

A tool does one thing. It chats, or it tickets, or it routes, or it analyses. Infrastructure provides a foundation that multiple capabilities sit on top of.

The distinction matters because it changes what you build, what you buy, and what you measure. When you think in tools, you ask: "Which chatbot should we buy?" When you think in infrastructure, you ask: "What foundation do we need so that any AI capability can plug in and share the same data, the same governance, the same measurement framework?"

This is the same evolution that reshaped computing. In the early 2000s, companies bought servers. Individual machines, each configured for a specific workload. Then AWS and its successors said: stop buying servers, start building on infrastructure. The servers didn't disappear. They became a layer within something larger.

The CX industry is still buying servers.

The language tells you everything

Look at the pricing pages. They charge per seat. Not per resolution, not per outcome. Per seat. That's a tool metric. It tells you how many people are using the software. It tells you nothing about whether the software is producing results.

Success metrics tell the same story. Tickets closed. Average handle time. First response time. These are activity metrics, not outcome metrics. They measure whether the tool is being used, not whether customers are being served.

The category shift that's coming will rewrite all of this. Tickets become resolutions — the unit of work changes from "something was opened and closed" to "a customer problem was actually solved." Seats become outcomes: pricing moves from counting agents to counting issues resolved. And tools become infrastructure, which is the biggest shift of all, because the buying decision stops being "which point solution do we need" and starts being "what foundation enables every CX capability we already have, plus the ones we haven't bought yet."

When you stop counting seats and start counting outcomes, you build differently. You have to.

What infrastructure actually looks like

I'm not using "infrastructure" as a buzzword. I mean something specific. I call it The Five-Layer CX Infrastructure Stack, and it has a shape that I've refined over eight years of building and deploying this in production.

It starts with one data layer. Every interaction, every resolution, every customer signal written to and read from the same place. Not seven dashboards with seven data models. One. On top of that sits a single routing engine that decides, the moment a customer reaches out: can AI handle this? Does it need a human? Which human? What context do they need? That decision shouldn't be scattered across three different tools with three different rule sets.

The third layer is where most companies have nothing at all: governance. What is the AI allowed to do? What requires human approval? What's the escalation path? What gets audited? These rules need to live in one place and apply consistently. When they're configured separately in each tool, which is the default state of every enterprise I've audited, you get inconsistent enforcement and invisible gaps.

I'm not sure the industry is ready for this conversation. Most CX leaders I talk to are still fighting to get their chatbot to stop hallucinating product specs. Asking them to think about governance frameworks feels like asking someone to plan a kitchen renovation while their house is on fire. But the fire is caused by the missing kitchen. That's the part that's hard to see from inside.

Then analytics, real measurement that spans the entire customer journey from first contact through resolution through follow-up. Not fragmented reports from each tool that you stitch together in a spreadsheet. And finally, the capabilities themselves: chat, voice, email, AI agents, automation, human routing. All of these plug into the foundation. They share the same data, follow the same rules, and get measured the same way.

Most companies have fragments of the first two layers. Almost nobody has built layers three through five. That's the gap. And you can't close it by buying another tool. The operating model shift I wrote about is a direct consequence of this architectural deficit: you can't run an outcomes-based CX operation on a tools-based architecture.

Where this goes

If the problem is architecture, not technology, then most of the money being spent on CX tools right now is going to the wrong place. The tools do things. But they do things on top of a broken foundation, which means the outcomes will always be limited by the architecture beneath them.

The companies that win the next decade of CX will not be the ones with the best AI model. Models are converging, becoming commodity faster than anyone predicted. The winners will be the ones who built the infrastructure beneath the AI. The ones where every resolution is recorded, every action is governed, every outcome is measurable, and every capability shares the same foundation.

I spent a career in semiconductor design before I built a CX company. Chip architecture taught me something that transfers directly: you cannot optimise a system you haven't characterised, and you cannot characterise a system whose data lives in seven places. The CX industry has AI. It does not have infrastructure. That's the gap, and it's the reason I came back to build this. Whether the industry figures this out in two years or ten, I genuinely don't know.

Frequently asked questions

What is CX infrastructure vs CX tools?+

A CX tool does one thing — it chats, or tickets, or routes, or analyses. CX infrastructure is the unified data, routing, and governance foundation that sits beneath every customer interaction. One data model, one routing engine, one governance framework, so that multiple capabilities share context instead of duplicating it. The distinction changes what you build, what you buy, and what you measure.

What is the Five-Layer CX Infrastructure Stack?+

The Five-Layer CX Infrastructure Stack is a framework for building CX as infrastructure rather than assembling tools. Layer one: a single data layer where every interaction reads from and writes to the same place. Layer two: a routing engine that decides whether AI or a human handles each interaction. Layer three: governance — what AI is allowed to do, escalation paths, audit rules. Layer four: analytics spanning the entire customer journey. Layer five: capabilities (chat, voice, email, AI agents) plugging into the shared foundation. Most companies have fragments of layers one and two. Almost nobody has built layers three through five.

Why do CX tool integrations cost more than the tools themselves?+

Every new tool needs to connect to every other tool. Data must be mapped, workflows bridged, and edge cases handled — and in CX, edge cases are roughly 40% of total volume. At the enterprise level, a company might spend on a CX platform and then several times that on integrations to make it work with everything else, plus ongoing maintenance costs. Mid-market budgets are roughly half, but they expect more pre-configured capabilities. SMBs spend a fraction and have almost zero appetite for customisation. The pattern is the same at every tier: the tool is the cheap part, the architecture tax is the real price.

What percentage of enterprise digital initiatives meet their business targets?+

According to Gartner, roughly 52% of enterprise digital initiatives do not meet their business outcome targets. The problem is not that the technology is bad. It is that most initiatives add another tool to a stack that is already architecturally broken. You cannot integrate your way out of a foundation problem.