AI for Operations: Automating the Work Nobody Wants to Own

Business process automation is the use of software to run a process end to end, from trigger to outcome, without a person carrying it between steps. AI changes what can be automated, because processes that used to break on judgment calls, unstructured documents and messy exceptions are now partly tractable. It does not change the thing that decides whether automation pays, which is whether the process was worth running in the first place.

Operations is where this bites hardest, because operations is where the invisible work lives: the handoffs, the approvals, the chasing, the re-keying of the same data into a third system. None of it appears on a strategy deck. All of it consumes the week.

The gap between adoption and value

The numbers here are unusually clear, and unusually awkward.

Roughly 88% of organisations now use AI in at least one business function (McKinsey, 2025). Only 17% have actually deployed AI agents, though more than 60% expect to within two years (Gartner, 2026 Hype Cycle for Agentic AI). And just 12% of CEOs report that AI delivered both cost and revenue benefits in the past year (PwC, 2026 Global CEO Survey).

Read those together and the shape is plain. Almost everyone is using AI somewhere. Very few have wired it into how work actually runs. Fewer still can show it moved the numbers. The gap between the first figure and the third is not a technology gap. It is the difference between using a tool and changing a process.

Gartner’s other projection belongs here as the counterweight: more than 40% of agentic AI projects are expected to be cancelled before the end of 2027, on escalating costs, unclear value, or inadequate risk controls. That is not an argument against automating. It is an argument for being unusually careful about what you automate first.

Automate the process, not the task

The most common and most expensive mistake is automating a step instead of a process.

A step-level automation takes one part of a workflow, does it faster, and hands back to a human who then copies the result into the next system. It feels like progress and it usually adds a handoff. The work did not leave; it changed shape and acquired a new coordination cost.

A process-level automation runs from trigger to outcome. An enquiry arrives, gets classified, enriched, routed, acknowledged, and appears in the right place with the right context, and a person is involved only where a person adds something. That is a different unit of work, and it is the only unit where the savings survive contact with reality.

The test is simple and worth applying honestly to anything being sold to you: after this is installed, does a human still have to move data between two systems? If yes, you have bought a faster step, not an automated process. This is the same distinction that separates an AI operating system from a drawer of subscriptions, and the same one that decides which marketing tools are worth paying for.

What makes a process worth automating

Not everything should be. Four properties, in rough order of importance, predict whether automation pays.

• Volume. It happens often enough that the build amortises. A process run twice a month rarely earns its maintenance.
• Rules you can state. Not necessarily simple, but describable. If nobody can write down how the decision is made, automation will encode whatever the last person happened to do.
• A measurable outcome. You can say what good looks like and count it. Without this you cannot tell whether the automation works, which means you will keep it regardless.
• Tolerable failure. When it goes wrong, and it will, the cost is recoverable and someone notices. Processes that fail silently and expensively should be automated last and watched hardest.

The inverse is the honest exclusion list: low-volume, judgment-heavy, unmeasurable work where failure is silent. That is most of what people most want to automate, because it is the work they most dislike doing.

Map before you automate

The discipline that separates the projects that pay from the ones that get cancelled is mapping the process before touching it. Automating a broken process gets you the broken outcome faster and makes it harder to fix, because now it is encoded.

The map does not need to be elaborate: every step, who does it, what triggers it, how long it takes, and where it waits. The waiting is usually where the cost is hiding. Most processes are not slow because the steps are slow; they are slow because work sits between steps in someone’s inbox.

Two things usually fall out of that exercise before any software is bought. Steps that exist only because a system could not talk to another system, which integration removes. And steps that exist because someone once made a mistake, which a control could replace. Both are cheaper to delete than to automate, and deleting a step is the highest-return automation available.

The part that decides whether it lasts

Automation creates a governance problem the moment it starts making decisions, which is why the governance layer every Head of AI owns is not paperwork bolted on at the end. If a process runs without a person in it, someone still has to be able to answer what it did, why, and on what basis, particularly where the output touches a customer, an employee or a regulator.

The other durable question is ownership. An automated process encodes how your company works, and that encoding is an asset. If it lives inside a vendor’s platform in a form you cannot export or reproduce, you have rented your operating model, which is a considerably worse trade than renting a tool. Keep the process logic and the context yours, and keep the models underneath swappable, which is the whole of the build-versus-rent decision applied to operations. Finance and the back office are where this pays first for most firms, which is a case worth reading on its own.

Where to start

Start with one process, not a programme. Pick the one with the highest volume and the most waiting, map it, delete what should not exist, and automate what remains end to end. Then measure it for a month before building the second.

That sounds slower than it is. The alternative, running four automation pilots at once, is how firms arrive at the 40% cancellation figure: several half-finished workflows, no measured outcome on any of them, and no way to say which was worth continuing.

The honest opening question is not what could we automate. It is which process, if it simply ran itself correctly every time, would give the team back the most hours this month. Usually everyone already knows the answer, and usually nobody has written it down.

If everyone already knows which process it is, tell Daniel what it is, what you have built around it so far, and what the business needs it to do. Book 30 minutes with Daniel.

Frequently Asked Questions

What is business process automation?

Business process automation is using software to run a process end to end, from trigger to outcome, without a person carrying work between steps. AI extends what is automatable into processes involving unstructured documents, classification and exception handling. The critical distinction is process-level automation, which removes work, versus step-level automation, which often just relocates it.

Why do most AI automation projects fail to show value?

Because using AI and changing a process are different things. About 88% of organisations use AI somewhere (McKinsey, 2025), only 17% have deployed AI agents (Gartner, 2026), and just 12% of CEOs report both cost and revenue benefits (PwC, 2026). Gartner expects over 40% of agentic AI projects to be cancelled before the end of 2027, largely on unclear value and inadequate controls.

Which processes should you automate first?

Ones with four properties: enough volume that the build amortises, rules you can actually write down, a measurable outcome so you can tell whether it works, and failure that is recoverable and visible. Low-volume, judgment-heavy, unmeasurable work where failure is silent should be automated last, even though it is often what people most want to hand off.

Should you map a process before automating it?

Yes, always. Automating a broken process delivers the broken outcome faster and makes it harder to change, because the flaw is now encoded. Mapping usually reveals steps that exist only because two systems could not talk to each other, and steps that exist because of one historic mistake. Deleting a step is the highest-return automation available.

What is the difference between task automation and process automation?

Task automation speeds up one step and hands back to a human, who typically still moves data into the next system. Process automation runs from trigger to outcome with people involved only where they add something. The test: after installation, does a human still move data between two systems? If so, you bought a faster step, not an automated process.

Who is accountable when an automated process makes a decision?

Someone has to be, and naming them is part of the build rather than an afterthought. Once a process runs without a person in it, the company still needs to explain what it did, why, and on what basis, especially where the output touches a customer, an employee or a regulator. That means an audit trail, a defined escalation path, and a named owner.