Technology leaders are usually the ones asked whether something can be automated. It is a fair question to put to us, and most of us are very good at answering it. We can scope it, cost it, size the model, find the data, and say with reasonable confidence whether the thing is buildable.
That competence has quietly become the trap.
The question arrives already framed, and answering it well feels like doing the job. Can we automate this? Yes, we can. So it gets built, and it works in the technical sense, the question implied, and then somebody in the business is surprised that customers do not feel better served.
The technology leaders who partner well with CX have learned to ask the question back. Not can this be automated, but should this particular decision be made by a machine, and within what bounds?
The first question is about capability. The second is about authority. They are not the same question, and only one of them is ours to answer alone.
CONFUSING THE TWO IS A DELIVERY RISK, NOT A GOVERNANCE NICETY
It is tempting to treat that distinction as something the CX team or the risk function worries about after we have shipped. It is not. It prices in, and it prices into our budget.
When a decision is automated ahead of clarity about whether it should be, the cost does not disappear. It relocates. It arrives as exception volume nobody forecast, review queues that need staffing, remediation when an automated action has to be unwound, monitoring built retrospectively because nobody specified what good looked like, and retraining for a frontline that inherited a harder job than the business case assumed.
The public reversals are instructive here, and none of them are stories about model quality. Klarna promoted an AI assistant as handling the workload of seven hundred agents, then walked the position back and reintroduced human support for the moments that needed judgement and trust repair. Commonwealth Bank linked an AI voice bot to a reduction in forty-five customer service roles, then reversed weeks later, having concluded the roles were not redundant and that the original assessment had missed relevant factors. In both cases, the technology did what it was built to do. What was mispriced was the authority it had been given.
Fluent output is not the same thing as governed service. An organisation that scales autonomy faster than it resolves the question of who should be deciding is not scaling AI. It is scaling the cost of unwinding it later.
NOT ALL AI IS THE SAME LAYER
There is a second confusion worth clearing up, and this one sits on our side of the table rather than theirs. “AI” is not one thing. It is a stack of at least four quite different capabilities, and treating them as interchangeable is among the most reliable sources of disappointment in this work. Each layer has its own failure mode, and each belongs in a different kind of decision.
Automation executes fixed, rules-based tasks. It is efficient, cheap to run and entirely predictable, which is precisely why it is brittle at the edges. It does what it was told, including when the situation has changed, and the instruction is now wrong. It belongs where the rules are stable, and the exceptions are rare enough to be handled by hand.
Conversational AI understands and responds in natural language. It is strong for search, guidance and support, and genuinely good at meeting customers where they are. Its weakness is precision. It is at its least reliable exactly when an answer has to be complete and exact, which is often the same moment the customer most needs it to be. It belongs where being helpful matters more than being definitive.
Copilots support human judgement with prompts, recommendations and next-best actions. They are the most immediately valuable layer in most service environments, and the risk they carry is a subtle one. Over-reliance is a design problem, not a user problem. If the copilot is right ninety-five per cent of the time, the human stops checking, and the remaining five per cent stops being caught. Copilots belong where a person is accountable and needs to be faster – not where a person is nominally accountable and has quietly stopped deciding.
Bounded agents initiate and complete multi-step work within defined rules, thresholds and controls. This is where orchestration and genuine scale come from, and it is the layer where trust, control and auditability stop being desirable and become load-bearing. An agent that can act across systems on a customer’s behalf needs explicit scope, explicit permissions, a defined stopping condition, and a way to be reversed.
Set those four against the three modes of delegation the business will recognise – autonomous machine, human-supervised, and human-led with AI assisting – and the mapping is not one-to-one. That is the useful part. A bounded agent sits perfectly well inside an autonomous decision where the stakes are low and the outcome is reversible. The same agent, pointed at a hardship case, is in the wrong tier, no matter how well it performs.
Which layer belongs where in the experience system is a design decision. It is not a procurement one.
CLASSIFY BEFORE YOU BUILD
Which brings us to the discipline that makes the rest of it hold. The tiers apply to the steps and decisions inside a customer mission rather than to the mission as a whole, and a well-designed mission almost always contains all three.
Tier one is autonomous. Low stakes, reversible, rules-based, low emotion – reminders, status checks, low-risk retrieval. AI acts within clear guardrails, and nobody misses the human.
Tier two is human-supervised. Moderate complexity, bounded risk, multiple systems, some judgement – claims triage, churn intervention, account query resolution. AI orchestrates while a human supervisor monitors, intervenes and can override.
Tier three is human-led and AI-assisted. High stakes, emotionally sensitive, regulated or reputationally exposed – hardship, vulnerability, major complaints, complex disputes. AI supplies insight, context and prompts. The human owns the decision.
There is a predictable pressure here, and it is worth naming plainly, because it tends to land on our desk rather than the CX team’s. Stakeholders will push tier two and tier three towards full automation, partly because the cost case looks attractive and partly because we are the people who can technically make it happen. Holding that line is a technical leadership responsibility, not only a customer one. Decide tiers on decision complexity, risk, emotion and regulatory exposure. Never on cost preference.
And classify before you build. No step is wired to a customer until it has a tier written against it, and both the customer side and the technology side have signed the same map.
CLASSIFICATION ONLY HOLDS IF SOMEBODY OWNS THE THING BEING CLASSIFIED
At the point AI enters a journey, most ownership maps have a hole in them that nobody notices until something goes wrong.
Five roles need to be explicit and visible:
- The mission owner holds end-to-end accountability for the customer outcome and the decision principles that govern it.
- The agent owner is accountable for the scope, permissions, guardrails, monitoring, escalation and rollback of any copilot or agent operating inside that mission.
- The knowledge steward looks after source quality, policy currency, and the audit evidence that proves the knowledge can still be trusted.
- The risk partner sits in the design conversation rather than at the approval gate on the way out.
- The quality-assurance lead holds a view of whether the system is producing the outcome, not merely whether it is running.
Most of these roles already exist somewhere in the organisation, implicitly, held by whoever cared enough to pick them up. Making them explicit is most of the work.
There is a blunt test for whether mission ownership is real, and it is worth applying before you accept a name on a slide. Can that owner move money and change a process in a function they do not manage? If they cannot, you have not appointed an owner. You have appointed a coordinator, and the accountability gap is exactly where it was.
THE ECONOMICS YOUR BUSINESS CASE IS PROBABLY MISSING
The last piece is the business case, and it is usually the weakest document in the programme.
Value gets read off handling time, because handling time is easy to measure and moves quickly. It is a poor proxy for whether the experience system as a whole is better off. Four levers need to sit in the same view.
Cost-to-serve is the obvious one, and often the only one the business case contains. Revenue and margin is the one most likely to be left out, because attribution is harder – yet a mission completed rather than abandoned is a commercial outcome. Productivity through augmentation is the copilot dividend, which is real and rarely counted honestly, because it shows up as better decisions rather than fewer minutes. And then there is the risk pricing of controls, monitoring and remediation: the standing cost of being able to explain, supervise and unwind automated decisions when they are challenged or wrong.
Hybrid delivery carries hidden costs as readily as hidden benefits. AI can strip labour out of one part of the system while quietly loading review burden or exception handling onto another, and a business case that measures only the first half will look excellent right up until it does not.
None of this is an argument to slow down. It is an argument to keep the numbers honest. Productivity gains that weaken trust, lift recontact or inflate remediation are not gains at all. They are deferred cost.
WHAT THIS ASKS OF TECHNOLOGY LEADERS
None of this makes the technology function smaller. It makes it more consequential.
The organisations that get this right will not be the ones with the best models. They will be the ones where the technology leader and the customer leader are looking at the same map – with a tier written against every step, an owner named against every decision, and a business case that counts the whole system rather than the convenient half of it.
The strategic question is not what your AI can do. It is whether anyone has decided what it should be allowed to do, and whether that decision is written down.
The full perspective – the AI stack layer by layer, the three-tier classification model, the structural roles and the honest economics – is set out in Customer Centricity 4.0: Decision architecture in AI-enabled customer experience. [Download the paper here.]
