The Automation Reflex
There is a version of AI strategy that amounts to looking at an organisation's operations and asking: what can we automate? It's an understandable starting point. AI tools are good at automating tasks. Automation reduces cost. Therefore, more automation equals more value.
This logic breaks down quickly when it meets operational reality.
Not everything that can be automated should be. Not everything that seems amenable to AI turns out to produce value when automated. And critically, the sequence in which automation is pursued matters — automating the wrong things first consumes the budget, goodwill, and executive attention that should have been deployed elsewhere.
Organisations that have pursued automation without a deliberate framework for selecting targets have a consistent experience: scattered pilots, limited production deployments, staff who are sceptical of AI promises, and leadership that is quietly questioning whether the investment was worthwhile.
The problem is not AI. The problem is that automation was applied without clear criteria for where it creates value.
Why Technically Feasible Is Not the Right Criterion
AI makes it technically possible to automate a much wider range of tasks than traditional software could handle. Natural language processing, document understanding, pattern recognition across unstructured data — these capabilities have expanded the automation frontier dramatically.
The expanded frontier creates a selection problem. If almost anything can be automated, how do you decide what to automate?
The criterion that tends to get applied is technical feasibility: what tasks can an AI system plausibly handle? This is the wrong starting point. Technical feasibility tells you what is possible, not what is valuable. A technically feasible automation target that doesn't address a significant operational pain point, doesn't free up meaningful staff capacity, and doesn't improve quality is not a good investment regardless of how well the technology works.
The right starting criterion is operational value: where are the genuine pain points, inefficiencies, and error-prone processes that, if addressed, would create measurable improvements in cost, speed, quality, or staff experience? Technical feasibility is a filter applied second, not first.
A Framework for Identifying High-Value Automation Targets
Evaluating automation opportunities requires four questions, applied in sequence.
Is this a real pain point? Automation is most valuable when it addresses something that staff or operations actually experience as a problem. High-volume repetitive work that consumes significant staff time. Error-prone manual processes where mistakes have downstream consequences. Bottlenecks that delay decisions or service delivery. Processes that require staff to do low-value work before they can do high-value work.
If the process isn't a genuine pain point — if staff manage it efficiently, errors are rare, and nobody considers it a burden — automation is unlikely to produce significant value. The efficiency gains on an already-efficient process are marginal.
Is the process stable enough to automate? AI automation works best on processes that are well-defined, consistent, and don't require constant human judgement to navigate edge cases. A process that changes frequently, has high exception rates, or requires contextual judgement that cannot be specified is a poor automation target — not because AI can't handle it at all, but because the ongoing maintenance and edge-case management consume the efficiency gains.
This is a criterion that organisations frequently overlook. The excitement about what AI can handle in a clean demo leads to underestimating how much of a real process consists of exceptions, special cases, and judgement calls that the automation will need to either handle or escalate.
What happens when the automation fails? Every automated system fails sometimes. The relevant question is what the consequence of failure is, and whether the process can tolerate the failure mode.
Automating a low-stakes internal process where an error is easily caught and corrected is low-risk. Automating a client-facing decision with significant consequences, where errors are hard to detect and may affect people before they can be corrected, requires a much higher standard of reliability and a robust human oversight mechanism. Some processes should not be automated without oversight mechanisms that are more expensive than the automation saves.
Can the value be measured? If you cannot specify, before the automation is built, how you will measure whether it has delivered value, you should not build it yet. Not because measurement is mandatory for bureaucratic reasons, but because unmeasured automation cannot be evaluated, improved, or compared to alternative investments. "It feels faster" is not a business case for production deployment.
The Sequencing Mistake
Even when individual automation targets are correctly evaluated, organisations frequently sequence them badly. They start with the most technically interesting problem, or the one that the most enthusiastic internal champion has proposed, rather than the one that creates the most value relative to effort.
The result is that the first AI automation project — which sets the tone for everything that follows, determines whether leadership remains committed, and shapes staff attitudes toward AI — is often not the organisation's most impactful opportunity.
The first project should be selected for three properties: high operational value, moderate technical complexity, and clear measurability. High value because the first project needs to demonstrate returns that justify continued investment. Moderate complexity because a first project that is too technically ambitious tends to run long, cost more than estimated, and deliver later than promised. Clear measurability because the first project needs to generate evidence — not just positive anecdotes — that AI automation works in this organisation.
What Gets Automated Too Early
Several categories of automation consistently get pursued before they should.
Customer-facing conversational AI in contexts where the conversation is genuinely complex and where errors have significant consequences for the customer. The technology works — the challenge is that making it work reliably in a complex service context takes more than most organisations budget for.
Knowledge management and internal search automation in organisations whose underlying knowledge base is disorganised, poorly maintained, and inconsistently structured. Automating access to a poor knowledge base creates a fast path to wrong information.
Decision support automation for decisions that the organisation hasn't yet defined consistent criteria for. If your human experts make the same type of decision inconsistently — using different criteria, weighting factors differently — automating that process doesn't create consistency, it systematises the inconsistency.
The Discipline of Starting Right
AI automation that starts with the right targets, in the right sequence, with clear success criteria creates compounding value. Each successful deployment builds organisational confidence, generates evidence for subsequent business cases, and develops internal expertise.
Automation that starts by chasing what's technically interesting, or by responding to vendor enthusiasm, or by automating whatever process happened to attract the most internal champion energy — that automation creates the opposite: scepticism, budget exhaustion, and a graveyard of pilots that leadership quietly stops talking about.
The discipline of identifying the right targets is not exciting. It requires systematic process analysis, honest assessment of pain points, and willingness to deprioritise technically interesting problems in favour of operationally valuable ones. But it is what separates organisations that extract real value from AI from those that spend real money on it.