Business process automation consulting: what to expect, and what to demand

The McKinsey Global Institute's study of automation, published in 2017 and still the reference, found that fewer than 5 percent of occupations could be automated entirely with demonstrated technology, while about half of all the activities people are paid to do could be. Data collection and data processing were near the top of the list. That gap between occupations and activities is the whole business of business process automation consulting: nobody's job goes away, but the hours spent keying an invoice, chasing a signature or reconciling two systems can. What varies enormously is what a buyer gets for the money. Three kinds of firm sell under the same label, and the contract each one offers tells you which you are talking to.

Three firms sell under one label

The first is the strategy firm. It runs an assessment, interviews the process owners, produces a heat map of automation candidates and a roadmap, and leaves. We have described why that engagement ends in a deck in why your AI consultants left you a deck: the people in the room can advise but not build. The second is the systems integrator or robotic process automation shop. It builds bots on a platform license, bills by the hour, and hands over a configuration that the buyer's IT team now owns. The third is newer. It builds the automation, runs it in production, and is paid on the savings it produces, so it stays on the result. We set out the delivery models and the customer each one assumes in the customer all four delivery models leave behind.

The label has also become less reliable. Gartner, in a June 2025 forecast, warned of agent-washing, the relabeling of existing automation software as agentic, and predicted that more than 40 percent of agentic AI projects will be canceled by the end of 2027. A buyer who cannot tell the three firms apart by their deliverable will not be able to tell them apart by their vocabulary either. The deliverable is the test: a document, a configuration, or a running process.

Discovery: how the consultant learns your process

Every engagement starts by establishing how the process runs today, and the method chosen here decides most of what follows. The traditional method is the workshop: process owners describe the steps, the consultant draws them, and the drawing becomes the map. The trouble is that the drawing records the process as designed, and the process as designed is rarely the process as run. Documented processes drift the moment they are written, for reasons we set out in why documented processes rot. The exceptions are the part that matters, and they are the part nobody remembers in a workshop. Ardent Partners, in its 2023 State of ePayables report, put the average invoice exception rate at 20.7 percent; an automation designed from the clean path alone will stall on a fifth of the volume.

The alternative is observation. An agent that records how the work is done, across the applications a team uses and over enough weeks to catch the month-end, produces a map that includes the workarounds, the re-keying and the judgement calls. It also compresses discovery from months to weeks, which changes the economics of the whole engagement, as we argue in the length of the discovery phase is a business-model decision. Ask any firm how it will learn your process. An answer that consists of interviews is an answer that will miss the exceptions.

The redesign is where the savings are

Automating a process as it stands is the most common mistake in the field and the most expensive. Michael Hammer made the point in 1990 and we take it up in Don't automate. Obliterate.: most steps in a mature back-office process exist to move information between people who cannot see each other's systems, and the right treatment for those steps is removal rather than acceleration. A three-way match is a good example. Automated as designed, it produces a faster version of a queue that still routes every mismatch to a person. Redesigned, the tolerances, the vendor rules and the receipt timing are changed so that most of the mismatches never occur, and what reaches a person is the residue that needs judgement. We worked the example in three-way match, rebuilt.

The MGI activity-level finding is the reason redesign pays. Automation removes activities, and a redesign decides which activities remain to be automated at all. A firm that goes straight from the map to the build has skipped the step where most of the hours are found.

The build: workflow tools, RPA, or agents

The building blocks have changed in the last three years. Robotic process automation scripted the screen and broke when the screen changed, and it could not read a document it had not been shown; we take that objection seriously in RPA failed, so why would agents be different. Workflow and no-code tools handle the structured path well and hand the unstructured one back to a person. Agents built on current language models read the invoice, the email and the PDF, decide the routine cases, and route the rest, which is what moves the exception rate. They also require controls that the older tools did not: every action logged, attributable and reversible, with a person able to see what the agent did and undo it. We describe those in controls for autonomous agent actions. A consultant proposing agents without describing the controls is proposing a demo.

The exceptions also decide whether the automation pays. Once a process is in production, the clean path costs close to nothing at the margin, and the bill is set by the fraction of cases that route to a person and by what each one costs to resolve. An automation that clears 80 percent of the volume and leaves the hardest 20 percent to a queue can cost more than the manual process it replaced, because the queue strips out the context that made a clerk fast. We work through the arithmetic in the unit economics of the exception tail. The practical consequence for a buyer is that the exception rate, and the plan for driving it down, belongs in the proposal, and a firm that quotes only the share of volume it will automate has told you half the price.

What to write into the contract

Four things, and they are the same four that buyers now put into procurement for any AI delivery, as we set out in how enterprise AI procurement is changing. A baseline, measured before the work starts: hours per month, cost per transaction, exception rate, by the method in baselining a process for outcomes. An exception-rate target, so the result is falsifiable. A reversibility and audit requirement for anything that writes to a system of record. And a fee tied to the measured saving, which is the only clause that makes the firm lose money when the process still needs the same people afterwards. Add one more: who runs the automation after go-live, and for how long. A process that is built and abandoned decays the way the documentation did.

A reasonable counter, answered

A reasonable counter is that a no-code automation tool costs a few hundred dollars a month, an operations manager can learn it in a week, and business process automation consulting is an expensive way to buy what the tool already does. For a process that is already clean, with structured inputs and no exceptions, that is right, and we say so in when not to automate. The consultant's value lies in the discovery and the redesign, the two steps that decide what the tool should do, and in the accountability for the process running afterwards. The tooling is cheap and getting cheaper, so buy the tool for the clean process. Hire the firm for the one with the 20 percent exception tail, and pay it on what that tail costs you today.