How to run an AI workflow audit and find your first automation wins.

An AI workflow audit is a short, structured look at how work actually gets done in your business, run before you buy or build anything. It takes one to two weeks. The output is a map of the real process, hard numbers on where the hours go, and a ranked shortlist of two or three automations worth building first. Done right, it is the difference between an automation that pays for itself in weeks and a pilot that dies after the demo.

The method has four steps. Map the work as it actually happens, not as the process doc says it happens. Time the handoffs, because that is where the hours hide. Score every candidate on volume, variance, and risk. Then pick the one or two builds that pay back fastest and prove the case for everything after.

You do not need special software to run one. You need a notebook, a stopwatch, and permission to watch people work. Here is how we do it.

Step 1: Map the work as it actually happens

Every process has a written version and a real version. The written one lives in a doc nobody has opened since it was approved. The real one lives in someone's head, a shared inbox, and a spreadsheet only one person knows how to update. An audit is only worth running if it captures the real one. We have argued before that the work has to be designed before the tech; the audit is where that principle becomes a method.

So do not run it from a conference room. Sit next to the people who do the work and watch one full cycle happen end to end. An invoice from arrival to payment. A lead from form-fill to first call. A support ticket from inbox to resolved. While it happens, ask dull, specific questions:

• What did you just do there, and why that way?
• What makes you stop and double-check something?
• Where does this go when you are done, and who touches it next?
• What breaks when you are on holiday?

That last question is the sharpest one we know. If a step falls apart when one person is out, you have found a rule that lives in a head instead of a system. Write every one of those down. They are usually your strongest candidates.

Collect artifacts as you go. Ten recent, real examples of the thing — actual invoices, actual tickets, actual deal memos — with all their mess intact. The edge cases in that pile will shape any future build more than any interview will.

Step 2: Time the handoffs, not the tasks

Here is where most audits go wrong. They time tasks. How long to code an invoice, draft a reply, update the CRM. Those numbers are real but small. The big number is elapsed time: how long the work sits still between people.

An approval that takes ninety seconds of attention can take four days of calendar time, because it waits in an inbox behind two hundred other things. So for every step on your map, record two numbers. Touch time, when hands are actually on the work. And wait time, when the work is sitting in a queue. In most back-office processes we audit, wait time beats touch time by ten to one or worse.

This changes what you build. If the bottleneck is waiting, the win is triage and routing — getting the right item in front of the right person with context attached — not shaving the ninety seconds. When we rebuilt inbox and comms handling for one client, average response time fell 68%, and almost none of that came from faster writing. It came from removing the sitting. The same pattern shows up in email triage and invoice processing alike: the work was never slow, the queue was.

Step 3: Score every candidate on volume, variance, and risk

By the end of the mapping you will have a list of ten or fifteen candidate automations, and most of them are wrong. Scoring keeps you honest. We score on four factors:

Factor	Question to ask	A strong candidate looks like
Volume	How many times a week does this happen?	Dozens or more, on a steady rhythm
Variance	How many genuinely different paths can it take?	A few paths, with exceptions you can name
Risk	What does a wrong output cost, and would anyone catch it?	Mistakes are visible and cheap to reverse
Wait time	How long does the work sit between steps?	Days of waiting wrapped around minutes of touch time

Volume times wait time tells you the size of the prize. Variance and risk tell you the price of claiming it. A weekly report with three exception paths and a human reviewer at the end is a gift. A quarterly judgment call that touches a customer contract is not an automation candidate; it is a place for a better checklist.

Notice what is not on the list: how impressive the automation would look. Exciting is not a scoring criterion. This scoring pass is the mapping half of our workflow design and build work, and it is the step clients most often say they could not have run alone. Not because it is hard. Because insiders stop seeing their own workarounds.

Step 4: Pick one or two wins that pay back in weeks

Resist the portfolio. A first automation has a second job beyond saving hours: it has to earn trust with the people who will live with it. That argues for one build, maybe two, and nothing that requires a town hall to explain. In our experience most AI pilots fail not because the technology fell short but because the first build was too ambitious to land.

The decision rule we use:

1. Take the highest score from step 3, with one tiebreak: prefer the candidate whose output someone already reviews, because that review is a free safety net during rollout.
2. Confirm it has an owner — a named person who wants it fixed and will use it on Monday morning.
3. Agree the measure before the build starts: hours back, response time down, error rate flat or better.
4. Set a payback ceiling. If the build cannot return its cost within a quarter, drop to the next candidate.

Modest first builds compound. An executive-assistant workflow we shipped began as a single calendar-and-inbox win; it now hands each executive back around 13 hours a week. Those hours did not come from one clever feature. They came from picking the right first thing and building outward from proof.

What the audit should hand you at the end

An audit that ends in a slide deck has failed. It should end in a build order.

Concretely, that means one page per workflow: the real map, the timed handoffs, the named exceptions, the score. One shortlist, ranked, with the losers recorded so nobody relitigates them in a month. One agreed measure of good for the first build, written down before anyone opens an editor. And one named owner who will judge the result against that measure.

If a vendor or an internal champion cannot produce that page, the audit did not happen. What happened was a sales process.

The mistakes that sink a workflow audit

Interviewing managers instead of operators. Managers describe the written version in good faith; they are usually two years out of date on the real one. Talk to the person whose hands are on the work.

Scoring by excitement. The candidate that would look best in a board update is rarely the one with the volume and the wait time. Boring, frequent, and reviewable beats impressive almost every time.

Auditing tools instead of work. Listing your software and asking which apps could use AI produces a procurement plan, not an audit. The unit of analysis is a workflow with a start, an end, and a person waiting on it.

Letting it run long. Two weeks of focused attention beats a quarter of ambient discovery. An audit that runs three months is a strategy project wearing a hard hat, and the shortlist it produces will be stale on arrival.

Doing it yourself versus bringing someone in

You can run this method with the steps above and a fortnight of attention, and some teams should do exactly that. The honest trade-off is speed and the outsider's eye. We have mapped enough back offices to know where the hours usually hide, and because we build what the audit finds, the map is drawn by people who have to make it work afterward. Our whole process is this shape: map the workflow, ship the build, then keep testing and tightening it as reality pushes back. If there is a workflow in your business that everyone complains about and nobody has fixed, that is almost always the place an audit should start — and we are glad to run the first one with you.