Cross-cutting decisions cannot be outsourced.

Three vendors, three perimeters, three optimisation logics. The integrator carries the CCaaS platform. The agency carries the AI layer. The internal data team carries the repositories. Each delivers their scope. Each reports on their own indicators. And when a decision touches all three perimeters at once, nobody makes it.

That is where CX programmes drift. Not in the components. In the spaces between components that nobody owns.

Parallel outsourcing produces local optimisations

When each domain is entrusted to a different actor, each actor optimises by their own criteria. The CCaaS integrator optimises platform availability and functional delivery timelines. The AI agency optimises model performance metrics — automation rate, response accuracy, processing time. The data team optimises pipeline quality and repository coverage.

These optimisations are all legitimate. They are also locally coherent. The problem comes when they contradict each other. The AI agency wants to enrich customer context with real-time data. The data team says the repository cannot support that level of querying without degrading performance for other uses. The CCaaS integrator says the requested integration is not in the original contract scope.

Each is right in their own lane. Nobody arbitrates for the whole. The decision remains in suspense, or it is made by default — by the most insistent vendor, or by nobody, which amounts to the same thing.

How cross-cutting conflicts resolve without an arbiter

Without a decision owner for cross-cutting conflicts, they resolve via two mechanisms. The first is committee. Representatives from all three perimeters are gathered, the disagreement is presented, consensus is sought. Consensus takes time. It usually produces a compromise solution that fully satisfies nobody and creates new undocumented dependencies.

The second mechanism is escalation. The conflict goes to the steering committee, or to the programme director, or to the CIO. The decision is made at a level where technical context is insufficient to arbitrate correctly. It is made quickly, under pressure, with the information the three vendors chose to surface — each with their own interests.

A programme without a cross-cutting arbiter accumulates compromise decisions until the whole becomes unmanageable.

In both cases, decision time is long. Teams adapt while waiting. They work around, patch, create local exceptions. These workarounds persist. They become undocumented norms. They create hidden dependencies that nobody maps and that everyone discovers at the next change.

What a single arbiter changes concretely

A single arbiter — whether internal or an externally positioned Design Authority — changes speed first. When a cross-cutting conflict arrives, there is one person who decides. Not a committee. Not an escalation process. One person, with the authority and context to resolve the issue.

That person does not need to be the technical expert of each domain. They need to understand the trade-offs that matter: what protects the customer service in case of degradation? What creates a new dependency that cannot be easily undone? What is outside the contractual perimeter and requires an amendment? What can be decided now and what needs broader validation?

A single arbiter also changes traceability. When the decision belongs to one person, it can be documented, dated, and owned. We know why this choice was made, in what context, under what constraints. If context changes, we can revisit the decision on a factual basis. Without a named arbiter, decisions get lost in meeting notes or individual memories.

Design Authority vs coordination: the difference that counts

The most frequent confusion is between coordination and Design Authority. Coordination ensures that actors talk to each other, that information flows, that timelines are aligned. It is necessary. It is not sufficient.

Coordination does not resolve. It facilitates. It organises exchanges. But when two vendors arrive at a coordination meeting with incompatible positions, coordination has no authority to impose a decision. It can only acknowledge the disagreement and arrange another meeting.

The Design Authority resolves. It has explicit authority over cross-cutting architectural and functional decisions. It can tell the CCaaS integrator that their integration approach must change to comply with the data layer's standards. It can tell the AI agency that its next model update must go through a validation process before production deployment. It can tell the whole programme that a given exception is accepted for six months with an explicit exit condition.

This authority is not naturally accepted. It must be contractually defined, communicated to all vendors at programme start, and exercised consistently from the first decisions. A Design Authority that hesitates on its first calls quickly loses effective authority, even if it remains formally defined.

Coordination is not a deliverable — it is a role

The most common symptom of a programme without a cross-cutting arbiter is the confusion between deliverable and role. A coordination plan is created. A RACI matrix is written. Cross-vendor coordination meetings are defined. These documents exist. The arbiter role, however, is not filled.

A coordination plan does not decide. A RACI matrix does not arbitrate. They describe an intention of organisation. Without someone who actually exercises the role — who attends meetings with the authority to resolve, who documents decisions, who follows their implementation — these documents become comfort deliverables that give the appearance of governance without the substance.

The practical question to ask at the start of any multi-vendor programme is simple: who, by name, has the final say when the CCaaS integrator and the AI agency disagree on a decision that touches both perimeters? If the answer is "that gets handled in committee" or "it goes to the steering committee," the programme has no arbiter. It has disagreement management mechanisms that will produce slow compromises and undocumented exceptions.

The answer must be a name. One person. With a written mandate and authority acknowledged by all vendors. That person carries the cross-cutting trade-offs. Not the coordination plan. Not the steering committee. One head.