What an AI audit actually involves (ours, anyway).
An audit is a fixed-fee, one-to-two week engagement where I watch how a specific part of your business actually runs, measure the real baseline, hours, error rate, cost, and hand over a written brief with a recommendation, even when that recommendation is "don't automate this." You keep the brief either way.
§ 01 — What happens during the audit, day to day?
It starts with picking the process, not the technology. I sit with the person who does the work (not just their manager) and watch it happen, ask what's tedious, what breaks, and what takes longer than it should. That's the same test from the five-question framework, applied properly rather than guessed at from a kickoff call.
Most of the audit is measurement, not analysis: how many hours a week, how many exceptions, what an error currently costs when it happens, what tools are already in play and whether they're actually being used. This is the least glamorous part of the work and the part most consultancies skip in favour of a slide about "digital transformation."
By the end of the one-to-two weeks, I've got a real baseline number, not an estimate. Everything that follows, whether that's a build or a "don't bother," gets measured against that number.
§ 02 — What's in the written brief, and what happens after?
The brief states the baseline (measured, not estimated), a target if automation is worth pursuing, an honest cost range for getting there, and the reasoning behind the recommendation either way. If the answer is "this isn't worth automating," the brief says that plainly and explains why, rather than quietly steering toward a build regardless of the finding.
You own the brief. If you take it to someone else, or shelve it, or do nothing, that's fine, it's paid for and it's yours. If you go ahead with a Build, the audit fee is credited against it. There's no follow-up call trying to talk you into anything the numbers didn't support.
“You keep the brief whether you hire me again or not. If the audit only pays off when it leads to a build, it isn't an audit, it's a sales pitch with extra steps.”— The house rule on audits, § 02
§ 03 — When don't you need an audit at all?
Two situations. First, you already know exactly what the problem is, you've timed it, you know what it costs, and you just need someone to build the thing. In that case an audit is a paid exercise in confirming what you've already told me, and I'll say so rather than bill for it.
Second, the business is small enough, or the process minor enough, that the audit fee doesn't make sense relative to what's at stake. If a task costs the business a few hundred dollars a year in wasted time, a fixed-fee audit to investigate it is the wrong tool regardless of how interesting the problem is. A five-minute conversation is the right amount of process for a five-minute problem.
The honest test is simple: if you can describe the baseline, the cost of the current process, and roughly what "better" would look like without my help, skip straight to a conversation about the Build. The audit exists for the more common case, where nobody's actually measured any of that yet.
If you're not sure which situation you're in, send the brief describing the problem and I'll tell you honestly whether it needs an audit or just a chat.
§ 04 — Questions people ask
If you've got a suspect inefficiency, send the brief. I'll tell you plainly whether it's worth fixing.
Send the brief →