Why a CX programme fails when every component works.

The standard diagnostic looks for the failing component. The CCaaS platform? Maybe. Poorly configured AI? Possibly. Incomplete data? Likely. Yet in the CX programmes I have seen fail, every component worked. Processing times were correct. Technical availability was there. Individual indicators were green. The programme itself did not hold.

The failure was not in any component. It was in the interfaces between them.

What we miss by looking for the failing component

A CX programme is not a sum of components. It is a series of handoffs: customer context from one channel to the next, data from one system to another, decisions from one actor to another. Each handoff is a potential fragility point. And these handoffs belong to nobody.

The integrator delivers the CCaaS. The agency delivers the AI layer. The internal team owns the data. Each delivers their scope, on time, within the contractual perimeter. Every governance milestone is validated. Nobody owns the interface between the three. Nobody defines what happens when context fails to transfer, when two systems disagree, when an escalation has no recipient.

This is not a competence problem. It is a design problem. A programme that does not draw its interfaces before launching its components will discover those interfaces in production — at the worst moment.

First interface: who carries customer context between channels

A customer moves from chat to phone. From self-service to human. From bot to advisor. At each transition, a concrete question: who transmits what, in what form, with what acceptable latency?

I have seen programmes where the advisor received an empty ticket at the moment of handoff. The bot had collected the reason for contact, validated identity, and suggested a first response. None of that information was transmitted to the advisor's screen. The break was total. The customer repeated, the advisor scrambled to catch up, the delay lengthened. The CCaaS was operational. The AI channel was operational. The interface was empty.

The context transmission rule must be written before the first sprint. Not just the technical format — who is responsible for coherence, what is the tolerated delay between collection and availability, and what happens if data is absent or invalid. Without this rule, every team optimises its side of the boundary and leaves the join to improvisation.

Second interface: who arbitrates between roadmaps

In a multi-vendor programme, roadmaps diverge. It is mechanical. The CCaaS integrator plans its releases. The AI agency pushes model updates. The internal data team ships new pipelines. These calendars are not aligned, because each actor answers to its own constraints.

The problem arrives when an upstream change breaks something downstream. A new data export format that changes the structure expected by the AI engine. A CCaaS update that modifies events transmitted to reporting tools. An enrichment API change that breaks the routing journey.

Without a single arbiter, these breaks get resolved through bilateral negotiation between teams. This is slow, partial, and opaque. Each vendor defends its roadmap. Nobody owns the full programme. The usual result: compromises that do not hold, fixes that create new dependencies, and crisis meetings that manage symptoms without addressing the cause.

When nobody owns the interface, everyone repairs their own edges and leaves the middle to nobody.

Third interface: governance when disciplines contradict

CX disciplines regularly contradict each other. Compliance imposes a recording retention period that data wants to expunge sooner. Personalisation pushes recommendations that security must restrict for certain segments. Real-time performance requires synchronisation the architecture cannot absorb without degradation.

These contradictions are not design flaws. They are inherent to any programme that simultaneously touches the customer, data, and regulation. What distinguishes a programme that holds from one that drifts is the presence of an explicit arbitration rule — and an actor who applies it.

What the Design Authority changes concretely

A Design Authority is not another committee. It is the role that owns interfaces. It defines exchange standards between components, priority rules in case of conflict, and the process for validating exceptions. It makes visible what nobody else is watching.

In a programme that holds, the Design Authority intervenes before conflicts — not after. It publishes interface rules at project start. It validates every change that touches a component boundary. It keeps the exception register with scope, duration, and exit condition for each entry.

Recognising a fragile programme before it falls

The symptoms are often subtle. Fixes applied without documentation. Meetings between teams held outside the governance structure. Operational workarounds that have persisted for months without formal validation. Escalations that reach leadership not because indicators fired, but because an important client picked up the phone.

The simplest test I use: ask each team what they do when another component produces incorrect data. If the answer describes a bilateral, informal process — "we contact the relevant team", "we flag it in our system", "we noted it for the next meeting" — the programme has no interface governance. It has workarounds that hold by habit.

A solid CX programme can name its arbiter. It can describe the rule that applies when two disciplines contradict each other. It can produce the list of active exceptions with their exit conditions. If none of these three things exist, the components work. The programme is on borrowed time.