Context
Almost every AI project I get called into was already decided before I arrived. Someone saw a demo, someone else heard a competitor was “doing AI”, and the budget existed before anyone had watched the work being done.
That is a strange way to spend money. Nobody buys a machine for a factory floor without measuring the floor.
This is a blueprint, not a client story - it describes how I run an audit and what comes out of it. The numbers in the walkthrough are illustrative. The method is the part I actually use.
The problem: the decision happens before the analysis
The failure mode I see is not technical. Teams pick a process that looks impressive in a slide, spend four months on it, and end up with a pilot that three people use out of politeness. Then the whole company concludes “AI does not work here”, which is the expensive part, because usually two other processes in the same building would have paid back in a quarter.
Three things go wrong, and they are all decided in the first week:
The chosen process has low volume. A task that happens eleven times a month cannot repay six weeks of engineering, no matter how annoying it is. Annoyance and volume feel like the same thing when you are the one doing the task, and they are not.
The chosen process has no tolerance for being wrong. Anything that touches money leaving the company, legal commitments, or medical advice needs a human sign-off, and if a human reads every output anyway, you have automated the typing and kept the cost.
Nobody agreed what success looks like. Without a number defined before the build, the project ends in a meeting where everyone describes the same pilot differently.
An audit exists to catch all three before the invoice.
What the audit is
Five days. Not a workshop, not a slide deck about the state of AI.
Day one and two: I watch the work. Interviews with the people who actually do the task, not the managers who describe it. This matters more than it sounds. The described process and the real process differ in every company I have worked in, and the difference is where the automation either lives or dies. The real process has a spreadsheet somebody maintains privately, a step that exists because of one client who complained in 2019, and a person everyone quietly routes the hard cases to.
Day three: I count. How many times per month, how long each run takes, what an error costs, and who fixes it. If nobody knows the volume, that alone is a finding. I would rather spend a day pulling numbers out of a ticketing system than build on someone’s guess.
Day four: I price it. Model calls, integration work, the ongoing maintenance nobody budgets for, and the cost of the failure cases. An agent that runs a thousand times a month with a 6% failure rate needs somebody to handle sixty failures, and that person’s time belongs in the estimate.
Day five: I write it down. The deliverable is a document, not a conversation. It has to survive being forwarded to a CFO who was not in any of the meetings.
The four questions I ask about every process
Every candidate process gets the same four questions, and each one can kill it on its own.
How often does this happen? Volume is the whole economic argument. I want the monthly count before I want anything else.
What does being wrong cost? Not “is accuracy important” - everyone says yes. I want to know what actually happens downstream when the output is wrong, who catches it, and how long it takes to catch. A wrong product description gets fixed in five minutes. A wrong invoice amount does not.
Is the input structured enough to be judged? If two experienced people in the company would disagree about the right answer, an LLM will not settle it. That is not a model problem, it is an undefined process, and automating it just makes the disagreement faster.
Who owns it after launch? Every automation is a system that will break. If no name goes in this box, the project is already scheduled to die quietly six months in.
The part clients remember: the do-not-automate list
This is where the audit earns its money, and it is the section people are least expecting.
Out of eight to twelve candidate processes, I usually recommend building two or three. The rest get written up with the reason they were rejected, because a rejection without reasoning gets re-proposed by the next person to attend a conference.
The rejections tend to fall into a few shapes. Some processes are too rare to repay the build. Some have a human reading every output anyway, so the automation saves keystrokes and nothing else. Some are better solved by fixing the process itself - I have looked at approval workflows where the honest recommendation was to delete two approval steps, which is free and works immediately. And some are already covered by a $40 a month tool the company would be building a worse version of.
That last one is a real answer and I give it often. Part of the audit is telling you where not to hire me.
An illustrative walkthrough
To make the shape concrete, here is how the numbers typically fall for a mid-sized services company. These figures are made up to show the arithmetic, not drawn from a specific engagement.
Say eleven candidate processes come out of the interviews. Four die on volume - they happen a handful of times a month and could never repay a build. Two die on tolerance, because they touch client contracts and a lawyer reads the output regardless. One turns out to be an off-the-shelf purchase. One is a process problem wearing an AI costume, where the fix is removing a duplicate data entry step between two systems that were never connected.
That leaves three. The document-heavy one, where staff retype the contents of supplier PDFs into an internal system four hundred times a month, is where the payback is obvious - high volume, structured output, and errors that get caught by a validation rule rather than a person. The other two get sequenced behind it.
Three funded projects out of eleven ideas is a good outcome. Eleven funded projects out of eleven ideas is how companies end up with a graveyard.
What you get
A ranked opportunity map with the effort and expected return for each item, so the ordering is arguable rather than asserted. A written do-not-automate list with reasoning. A build-versus-buy call on every surviving item. A cost estimate that includes the running cost, not just the build. And one defined success metric per project, agreed before anyone writes code.
Then you can hire me to build them, hire someone else, or do nothing. The map is yours either way, and a company that decides to do nothing this year has still saved more than the audit cost.
What it proves
The model was never the hard part. Picking the right process is the hard part, and it is a business question that gets answered with a stopwatch and a spreadsheet before anyone opens an editor.
I have come to think the strongest signal that an AI consultant is worth the money is how quickly they will tell you not to build something. Anyone can say yes to a budget.