What I actually look at first in an AI opportunity audit

An AI Opportunity Audit is a roughly one-week engagement that ends in a ranked automation roadmap — plus a list of things I’m telling you not to automate. This post is the methodology behind it: what I actually look at, in what order, before any tool gets mentioned.

What should I automate first?

Nothing, until I know where the data already lives. Most small businesses run on a mix of a CRM, a shared drive, a few spreadsheets, and someone’s inbox. Before I rank anything, I want to see the actual system a task moves through — not the tool it’s supposed to use, the tool it’s really stuck in.

The ranking that comes out at the end isn’t “easiest AI win first.” It’s closer to: which process has data that’s already in one place, touched by one clear owner, with a single metric a pilot could visibly move. Processes that score high on all three get automated first. Processes that fail on any one of them go on the roadmap later, or not at all.

Where do I even start an AI audit?

With a walkthrough, not a tools list. I sit with whoever actually does the work — not the manager describing it secondhand — and watch the process happen, or have it described step by step. I’m listening for three things: where the data lives right now, how many hands it passes through before a decision gets made, and where the process quietly depends on someone’s judgment that isn’t written down anywhere.

That last one matters more than it sounds. A lot of “automation opportunities” turn out to be judgment calls dressed up as data entry. Automating the visible steps around a judgment call and leaving the judgment call itself untouched usually makes the process worse, not faster — you’ve sped up everything except the actual bottleneck.

Which tools overlap, and does that matter?

It matters, but later than people expect. Almost every business I’ve looked at has two or three tools quietly doing the same job — a spreadsheet tracking what the CRM should be tracking, a calendar holding information that belongs in a project tool. I note the overlap, but I don’t lead with “consolidate your stack.” Tool consolidation is a project in its own right, with its own switching cost, and bundling it into an AI roadmap usually just delays both.

What I do use overlap for is diagnosis: two tools tracking the same thing is a strong signal that nobody fully trusts either one, which usually traces back to the ownership question below.

Who actually owns this process?

This is the question that kills more automation candidates than any technical constraint does. A process with no single owner — three people who each do a piece of it their own way — is not ready for automation, no matter how mechanical the task looks. Automating an unowned process just encodes the inconsistency faster.

So part of the audit is genuinely a management question: who is accountable for this outcome, and do they agree on what “done well” looks like? If the answer is unclear, that goes in the roadmap as a prerequisite, not a blocker I quietly work around. I’d rather tell you the process needs an owner before it needs a tool than ship something that automates confusion.

What single metric would a pilot have to move?

Before anything gets built, I want one number that would actually change if the pilot worked — hours spent on a specific task, days something sits waiting for a decision, error rate on a specific step. Not a vague “efficiency gain.” If I can’t name that number in advance, I don’t rank the idea highly, because there’s nothing to check it against afterward.

This is also where I push back on ideas that sound impressive but don’t move anything measurable. A slick internal chatbot that nobody’s job changes because of isn’t a good first pilot, even if it demos well.

What ends up in the “don’t automate this” list?

Every audit I run ends with one. It’s not a courtesy add-on — it’s usually the most useful page in the roadmap, because it tells you where to stop spending money. Three categories show up repeatedly:

• Anything where a wrong output is silent. If a mistake wouldn’t get caught until real damage is done, and there’s no human checkpoint built in, that’s not a good automation candidate yet — the checkpoint has to exist first.
• Anything resting on a judgment call the business hasn’t actually standardised, per the ownership question above.
• Anything touching identifiable personal or clinical data without a clear, deliberate handling plan. In healthcare-adjacent work specifically, my own rule is stricter than most clients expect: nothing identifiable reaches a model, and a human still signs off on anything clinical before it moves. That rule shows up in every relevant audit, not as a caveat but as a starting constraint.

Telling a client “don’t build this yet” costs me a line item. I still do it, because a roadmap that only ever says yes isn’t an audit — it’s a sales pitch with extra steps.

What do you actually get at the end?

A ranked roadmap you own outright, and the “don’t automate this” list next to it. You can build the roadmap with me, hand it to someone else, or shelve it — the audit is the same either way. That’s the whole point of doing the process-and-ownership work first: the roadmap holds up independent of who implements it, because it was never really about the tools.

If this is the kind of audit you want run on your own business, the details are on /work.