The Process Problem Behind the AI Programme: Three Fixes UK Leaders Should Make First
There is a pattern I have now seen enough times to describe with some confidence. A UK business commits to an AI programme. A vendor is selected, a pilot is scoped, a small group of enthusiastic staff is trained. Six months later the tool is licensed, lightly used and quietly defended in steering meetings. The productivity gain has not arrived, and the explanation offered is usually adoption.
In my experience the explanation is rarely adoption. It is that the tool was pointed at a process nobody had actually described.
The pattern I keep seeing
Consider a distribution business I worked with. The stated aim was to use an AI assistant to speed up quoting. The pilot failed, not because the model was weak but because three different teams held partial responsibility for a quote: sales gathered requirements, operations priced fulfilment, finance approved discounts. No two teams used the same definitions, and the approval threshold changed depending on who was on leave. The AI was asked to accelerate a decision that had never been clearly defined in the first place.
A professional services firm showed the same shape from a different angle. It wanted AI to triage incoming client enquiries. But the routing rules lived in the head of one senior administrator, and three partners disagreed about what constituted a priority. Automating the triage simply automated the disagreement, at speed and with more confidence.
Neither failure was a technology failure. Both were operating model failures, exposed rather than caused by the AI ambition.
Fix one: map the hand-offs, not the org chart
Most process documentation describes departments. That is the wrong unit of analysis. What matters is the hand-off — the moment work moves from one team to another and something is lost, delayed or reinterpreted.
When I ask a leadership team to map a single customer journey end to end, the useful output is almost never the diagram. It is the discovery that step four waits on an email nobody owns, or that the same information is keyed three times because two systems do not speak. These are the points where AI could genuinely help, but only once the hand-off has been made explicit.
A practical approach is to pick one journey that matters commercially — quote to cash, enquiry to onboarding, order to delivery — and walk it with the people who do the work rather than the people who manage it. Record where the work waits, who authorises the next step, and where rework occurs. A single afternoon is often enough to reveal two or three friction points that no one had named.
Fix two: simplify the approval layers
Decision rights are the least fashionable topic in transformation and probably the most consequential. In many mid-sized UK firms, approval layers have accumulated incrementally: a discount above five per cent needs one signature, above ten another, and a new supplier needs a committee that meets fortnightly.
Each layer was once a sensible response to a specific incident. Collectively they now produce a business where the average decision takes nine days and nobody can say who ultimately owns the outcome.
AI cannot resolve this, because the problem is authority rather than information. What helps is a deliberate reset: list the decisions that recur, identify who should own each one, set explicit thresholds, and remove the layers that exist only because nobody has reviewed them. This is unglamorous work, it generates no press release, and it typically produces more measurable speed than any tool in the current market.
The test is straightforward. If a competent member of staff cannot tell you, without asking, whether they are allowed to make a decision, the decision rights are unclear — and any automation built on top will inherit that ambiguity.
Fix three: define service standards you can measure
Transformation theatre thrives on aspiration. Operating models need numbers. If the ambition is to improve customer response, the standard must state what good looks like in measurable terms: first response within four working hours, resolution within two business days, quote turnaround within one day for standard requirements.
Once those standards exist, two things follow. Staff know what is expected, and any intervention — including AI — can be assessed against a baseline. Without them, every pilot is judged on enthusiasm.
I have watched firms spend significant sums on automation while never defining the service level the automation was meant to improve. The result is a familiar cycle: the tool is deployed, the team reports that it feels faster, and no one can demonstrate whether the customer experienced anything different. Setting the standard first costs almost nothing and makes the subsequent investment accountable.
Where AI does earn its place
None of this argues against adoption. Once hand-offs are mapped, approvals simplified and standards defined, the opportunities become specific and testable: drafting first responses against a known template, summarising case notes for a defined hand-off, extracting data from documents that feed a named downstream step. These are narrow, measurable uses with a clear owner and an obvious baseline.
That is a far less exciting proposition than a company-wide programme. It is also considerably more likely to survive its second year.
A sequence for the next twelve months
For UK managers facing pressure to demonstrate AI progress in 2026, a credible sequence looks like this. Choose one commercially important journey. Map it with the people who operate it. Remove at least one approval layer and publish the resulting thresholds. Define two or three service standards and measure them for a quarter. Then, and only then, identify where a tool would remove genuine friction.
The order matters. Businesses that start with the tool tend to spend the following year explaining the absence of results. Businesses that start with the process tend to find that the technology question answers itself — and that some of the gains arrive before any software is switched on.
