The Approval Ceremony

Organisations have become remarkably good at proving that change has happened. We approve business cases, establish budgets, create programmes, assign owners, define milestones and build dashboards that tell us if delivery remains on track. When the work is complete, we can usually demonstrate what was implemented, how much it cost and if the benefits promised in the original business case were realised.

The problem begins when we assume that successfully changing the thing we decided to measure means we successfully changed the organisation around it.

I have been thinking about this as AI, automation and self-service become embedded in more parts of business. My concern is not the technology. It is how easily we can draw a boundary around an initiative, calculate the benefits inside that boundary, and then treat improvements within it as evidence that the wider system became better.

The things that justify an initiative are usually the things we can see. A software licence has a price. An implementation has a budget. A support team has a salary cost. A transaction has a processing cost. A project has milestones. These fit comfortably into spreadsheets and dashboards because they produce observable events and attributable numbers.

What happens elsewhere is harder to see. Work moves into another department. Customers change their behaviour. Organisational knowledge disappears. Risk emerges later. A purchase never happens. A customer quietly finds an alternative rather than complaining.

None of that necessarily makes the original decision wrong. It simply raises a more important question than whether the initiative succeeded:

Did the system actually become better?

I have started thinking of the gap between those two questions as the approval ceremony.

When Human Oversight Becomes Ceremonial

AI-assisted software development provides a useful example. AI can now generate an extraordinary amount of code in very little time. A developer who might previously have written a change gradually can suddenly be presented with hundreds or thousands of lines to review. The obvious concern is whether meaningful human scrutiny can keep pace.

The reassuring answer is that a human remains in the loop. AI generates the code, an engineer reviews it, automated tests run, the pipeline passes and somebody approves the change before it reaches production. Those controls matter, but they can also create more confidence than they deserve if we confuse reviewing the change with understanding the system the change is entering.

Even if an engineer carefully reads all 2,000 lines, the code does not exist in isolation. It interacts with other code, APIs, libraries, databases, configurations, infrastructure, batch processes and perhaps years of legacy decisions. Automated tests can validate expected behaviours extremely well, but they are still influenced by what somebody anticipated needing to test. The generated code can therefore be reviewed, the tests can pass, the pipeline can be green and a human can approve the change without anyone fully understanding what will happen when it meets the production environment.

There is an important difference between reviewing the change and understanding the system.

The same applies to the phrase human in the loop. A human approval only provides meaningful oversight if that person has the time, information, context and authority to exercise judgement. Remove those conditions while preserving the approval step and the human is still technically in the loop, but the oversight has become ceremonial.

The €1 Million AI Project

Now move the same problem into an executive meeting.

Imagine a company with a large customer-support operation proposing an AI platform to automate much of its L1 support. The business case looks compelling: invest €1 million in AI, automate routine interactions, provide faster responses and 24/7 availability, and reduce support headcount by €2 million annually.

Then the AI needs to know what it is talking about.

Many large organisations have accumulated knowledge environments containing outdated articles, contradictory procedures, duplicate information, undocumented exceptions and product information that no longer reflects reality. Experienced employees have learned which documentation to trust, which official procedure rarely works, and when a straightforward customer question signals something more complicated.

Imagine putting all of that into the original business case. Before spending €1 million on AI, perhaps the organisation needs €2 million of knowledge remediation. It needs governance so the information stays accurate, plus security, monitoring and ongoing platform expenditure. Engineering may need to become more involved, while L2 and L3 support may receive fewer cases but a much higher concentration of difficult ones. The workforce saving may still happen, but later and with more uncertainty.

The exciting €1 million AI initiative has suddenly become a €3 million-plus organisational transformation with a much less attractive payback period.

It might still be the right investment. It is simply much harder to approve.

Nobody needs to be dishonest for the simpler business case to win. The AI leader wants the initiative funded. The vendor wants the technology purchased. The executive sponsor wants progress. Finance wants measurable ROI. Very few people receive much organisational reward for saying that before the exciting AI programme can begin, the company should spend millions cleaning years of boring information architecture.

So the boundary becomes narrower. Approve the initial investment, discover a dependency, fund the remediation, discover another problem and add whatever work becomes necessary. Once the organisation has already spent €1 million, another €500,000 to make the investment work feels very different from being asked at the beginning to spend €3 million on an uncertain transformation.

Sometimes a hidden cost could not reasonably have been predicted. Sometimes we simply do not look very hard because finding it would make the decision harder to approve.

The sequence creates another risk. If the business case depends on reducing L1 support capacity, people may begin leaving as soon as the AI appears capable enough. Only afterwards does the organisation discover how much work is required to make its knowledge reliable.

At that point, who knows which information is actually correct?

An external consultant can clean a document repository. AI can help classify thousands of articles. Neither can magically know that paragraph four of Article 742 is technically official but has been ignored for eighteen months because Engineering changed the product and nobody updated the documentation. That knowledge exists because somebody encountered the problem repeatedly, learned what worked and carried that understanding with them.

The organisation has not merely removed capacity. It has removed organisational memory.

There is a circular dependency here that deserves more attention: the people whose work AI is supposed to replace may be exactly the people whose knowledge AI needs in order to replace their work successfully.

We risk removing the cost before proving that we have removed the need.

The spreadsheet knows exactly what the employee cost. It has no line for the knowledge that walked out of the building.

The Curry With No Curry

There is a simpler way to explain the same problem.

Imagine ordering a chicken curry from a restaurant. When the meal arrives, you discover that what you have actually received is chicken sitting in hot water because somebody forgot the curry. You complain, the restaurant investigates and determines that the missing curry component represented fifty cents of the total cost. It therefore refunds you fifty cents.

Viewed through the process, the resolution is almost perfect. A component was missing, the component was identified, its monetary value was calculated and the customer was compensated. The complaint can be closed.

Except nobody ordered fifty cents' worth of curry powder.

You ordered dinner.

Food makes the distinction between components and outcomes obvious. Remove one relatively inexpensive component and you can destroy the value of the entire meal.

Yet organisations make versions of this mistake all the time.

I recently experienced something remarkably similar with a food-delivery order for three families. The expected delivery was roughly 45 minutes, but it eventually took around twice that. As we waited, the estimated arrival time became increasingly strange, moving from a couple of minutes to five, then nine, then considerably longer, almost as though the food were travelling backwards. When the order finally arrived, the chips were missing from several chicken-curry meals.

The financial value of the missing chips was not particularly significant. Their importance came from the fact that the meals were no longer what had been ordered, three families had already waited far longer than expected, and there was no useful recovery mechanism available when recovery mattered. Eventually the incomplete food was discarded, replacement food was bought and we cooked instead.

Support has time-sensitive value. Compensation tomorrow does not feed somebody tonight.

I deleted the account and explained what had happened in the support ticket, including the fact that the account had been deleted. The initial response was automated. Eventually compensation was offered for the missing chips — as service credit to the account that had already been deleted.

There is something almost elegant about how completely that resolution satisfied the process while missing the problem. The order had been delivered, the missing items had been identified and compensation had been offered. Each statement was true while the overall outcome remained a failure.

The process had an answer for the missing chips. It had no answer for the failed dinner.

The same distinction exists in IT support. A customer with a production problem enters an AI support channel. The system recognises a question and provides a technically correct answer. Perhaps the interaction is even classified as successfully deflected because it never reaches a human agent. Yet the underlying problem remains unresolved because the question the system answered was only one part of a larger situation.

The support organisation measures the interaction it received. The customer experiences the outcome they needed.

Retail creates another version of the same problem, except nothing needs to fail.

Self-service checkout began with a useful proposition. If I walk into a shop for a Coke and two small items, I would much rather scan three barcodes, tap my card and leave than wait behind somebody buying a full trolley of groceries. In that situation, self-service removes friction.

But imagine I want a Coke, a bakery item and a banana. The Coke has a barcode. The bakery item may require finding the correct product on a touchscreen. The banana may require finding, identifying and weighing it. None of that is difficult, but I may simply decide the extra effort is not worth it and buy only the Coke.

The retailer records a successful €3 self-service transaction. Nothing failed. There is no abandoned basket, complaint or machine error. What it cannot record is the €8 transaction that might have happened under a lower-friction experience, because there is no telemetry for the banana I considered buying but never put in the basket.

Friction at checkout can shrink the basket before the sale ever exists.

The restaurant saw the missing component but misunderstood the value of the outcome. The retailer sees the successful transaction but cannot see the purchases that never happened. IT support sees the question it answered but may not know if the customer's problem was solved.

All three systems can produce accurate data.

The dashboard can be completely accurate about too small a piece of reality.

Saving the Nickel, Losing the Dollar

Retailers have spent decades learning how to persuade customers to add one more thing to the basket. Products are placed together because they complement each other. Stores encourage browsing. Impulse purchases sit near checkout. Someone coming in for a Coke may leave with peanuts, chocolate or something else they never intended to buy.

Every additional nickel matters.

Self-service can pull in the opposite direction when a technology designed for simple transactions becomes the default for complicated ones. The ideal self-service transaction is small, easy to scan and paid for quickly. The process is therefore most efficient for the customer buying very little.

Nobody has decided customers should spend less. The assumption is simply that purchasing behaviour will remain broadly constant while the retailer reduces the cost of processing the transaction.

But behaviour changes.

There is a Lidl close to where we live with self-service checkouts, while another branch roughly ten minutes farther away still has staffed checkouts. For a larger family shop, we deliberately drive farther. The nearer store receives no complaint from us. There is no abandoned checkout or customer-service case explaining why the revenue went elsewhere. The transaction simply never happens there.

The same can happen inside the basket. Coke, chocolate, sweets, peanuts and other discretionary purchases are easier to add when shopping feels pleasant and effortless. When the experience instead feels like find it yourself, scan it yourself, identify it yourself, pack it yourself, resolve the machine error yourself, pay us and leave, the customer can become equally transactional.

Fine. I'll buy exactly what I need.

The retailer may have reduced labour cost. Transaction throughput may have improved. The internal calculations supporting the transformation may all be correct. But measuring the cost of processing the basket without remaining curious about what happened to the basket itself can turn local efficiency into apparent business success.

Retailers historically obsessed over earning the next nickel. Some transformation programmes seem more interested in saving the next nickel, even when doing so may stop the customer spending the next dollar.

The same question belongs in the AI support business case. If support headcount falls by €2 million, the support organisation has produced a measurable saving. But perhaps engineering workload rises. AI platform expenditure appears. Knowledge-management costs increase. Security and monitoring become more expensive. L2 and L3 receive fewer but more complicated cases.

Support can still truthfully report that its costs fell by €2 million.

That is not the same as saying the company saved €2 million.

Costs move. Work moves. Risk moves. Customer effort moves. Expertise moves. Organisational charts make these movements surprisingly easy to miss because a cost that disappears from one budget can reappear in another without being connected back to the programme that moved it.

We approve locally and experience consequences globally.

The Things That Never Happen

The hardest consequences to measure are often the ones that never produce an observable event.

Imagine a customer who owns a good product. Something breaks and they try to get support through the company's new AI channel. The answers are inconsistent, reaching a knowledgeable person is difficult, and eventually the customer stops trying. They do not complain, demand a refund, complete a CSAT survey or create an escalation. They solve the problem another way, replace the product or buy from somebody else next time.

From the support dashboard, this customer may look remarkably inexpensive. There was no lengthy human interaction or expensive escalation. If abandonment is interpreted as successful deflection, the experience might even improve the automation statistics.

Commercially, the company may have lost years of future purchases.

The absence of an interaction is easily mistaken for the absence of a problem.

This is also why perfect statistics cannot answer every question raised by transformation. Evidence matters, but some effects are difficult to measure precisely because they are non-events. How do we measure the banana somebody considered but never bought? How do we attribute a purchase three years from now that never happens because of a support experience today? How do we survey the customer who decided the easiest way to resolve their problem was never to interact with us again?

The absence of clean measurement does not make the economic consequence zero.

Customers also adapt. If a subscription becomes frustrating, they find alternatives. If support becomes too difficult, they work around it. If a retailer transfers too much effort to them, they shop elsewhere. Technology makes many of those alternatives easier to discover.

There is an interesting symmetry here. Companies are using technology to become less dependent on employees while customers are using technology to become less dependent on companies.

Repeatedly force customers to work around your business and they eventually become very good at living without it.

Our food-delivery experience demonstrated this in a small way. Once the late and incomplete meal had failed, buying food ourselves and cooking did not feel like an inferior substitute. It was cheaper, the food was better, and we could add desserts and snacks while still spending less. It also teaches a different habit to the children. The default question can gradually move from Shall we order tonight? to Why would we order when we can make something better ourselves?

There is no churn survey for the future customer who never becomes a customer.

Looking Outside the Boundary

AI, automation and self-service can create real value. A self-service checkout can make a small purchase faster, a chatbot can solve a simple problem at 2am, and AI can make developers far more productive. The leadership challenge is understanding what changes around them.

An AI support transformation might initially look less attractive if the organisation preserves and structures its knowledge while the people who understand it are still there, introduces AI alongside the existing operation, and watches what happens to the work that remains. Escalations may become more complex. Costs may move. Customer behaviour may change. Some assumptions in the original business case may prove correct and others may not.

Only after observing that reality does the organisation really know what capacity is no longer required.

For a period, this can look inefficient because the company is paying for its existing workforce, remediation and new technology at the same time. But that overlap may be the cost of discovering the future operating model before dismantling the current one.

Transformation does not require leaders to predict every consequence in advance. It requires them to keep looking after the programme has crossed the boundary of what the business case originally measured.

The business case can be approved. The AI programme can be delivered. The generated code can pass review. The chatbot can go live. The headcount saving can be booked. The self-service programme can reduce labour cost. The support ticket can be closed. The missing chips can even be compensated according to policy.

Every individual dashboard can be green.

Meanwhile, organisational knowledge may have left with the employees. Engineering may have inherited work previously performed by Support. A customer may have stopped trying to contact the company. The banana may never have entered the basket. A family may be driving ten minutes farther to another supermarket. Three families may have deleted their food-delivery accounts.

None of those things necessarily appears on the programme dashboard, because reality has no obligation to respect the boundary we drew around the initiative.

The approval ceremony is not one person clicking Approve. It is an organisation accumulating approvals until everyone can demonstrate that they did their job, while nobody can demonstrate that the system became better.

Perhaps that is the question leaders need to ask when the implementation is complete and the dashboard finally turns green:

What changed outside the thing we measured?

Because a green dashboard is not evidence that nothing outside the dashboard turned red.