The most expensive AI project is not the ambitious one that fails. It is the modest one that succeeds at doing something the business should have stopped doing.
We were asked recently to automate a weekly report. Data pulled from two systems, reconciled, formatted, and circulated to a distribution list every Monday. A person spent most of a day on it. The automation was straightforward and would have paid back quickly. Before building it we did what we always do and asked who reads it. The answer, after some checking, was that one person skimmed the first table and nobody had opened the rest in over a year. The report existed because it had existed. Automating it would have been a technically successful project that made a pointless thing cheaper and permanent.
Automation is an amplifier, and amplifiers are indifferent
This is the part worth internalising. Automation does not evaluate. Point it at a well-designed process and you get that process, faster, consistently, without the errors that come from fatigue. Point it at a muddled one and you get the muddle, faster, consistently, and now with the authority of a system rather than the hesitancy of a person.
The second half is what catches businesses out. In most manual processes there is somebody quietly absorbing the flaws. They notice the order that looks wrong and check before it ships. They know the customer whose file is coded incorrectly and mentally correct for it. They pause when a number is implausible. None of that is written down anywhere, and much of it is invisible even to the person doing it. Automate the documented steps and you remove the undocumented judgment along with them. The process now runs faster and the error rate goes up, and the reason is genuinely hard to see from a dashboard.
Three questions, asked before anything is built
Ask why the process exists, and keep asking until the answer is about a business outcome rather than about history. A surprising proportion of recurring work turns out to serve a client who left, a regulation that changed, or a manager who retired. The best possible outcome of an automation review is occasionally deleting the work.
Ask what the person doing it actually does, as opposed to what the procedure says. Sit with them. The gap between the two is where the judgment lives, and it needs to be either built into the automation as an explicit check or deliberately kept as a human step. What it must not be is silently dropped.
Ask how you will know it went wrong. A person who makes a mistake usually notices and mentions it. A system that makes the same mistake makes it identically four hundred times before anyone looks. Anything worth automating is worth putting a number on and watching, with a threshold that raises a hand.
This is why we start with the process, not the tool
It is also why we are wary of engagements that begin with a technology and go looking for somewhere to apply it. Starting from “we should be using AI” produces a search for candidate processes, which finds the most visible ones rather than the most valuable ones. Starting from where the business actually loses time and money produces a shorter list, and roughly a third of the time the honest recommendation is that the process needs fixing or discarding before anything gets automated at all.
That conversation is the cheapest part of the whole exercise and the part most often skipped, usually because it is nobody’s job. It is one of the reasons deciding what to build and building it work better as one relationship than two. The firm that will have to operate the automation at eight on a Monday morning asks different questions in the design meeting than the firm that will have moved on by then.