The five-minute AI workflow audit

Starting with a tool and looking for a use can produce a technically successful pilot without a useful outcome. Begin with the work you want to improve.

Use five minutes to start the audit, then collect observations over a working week and review them. The title describes a quick kickoff, not a complete assessment of a team’s workflow.

Collect the right week of evidence

Ask everyone to note one line whenever one of three things happens.

I did this again. Something repetitive, whether or not it felt burdensome.

I waited. For a person, an approval, a system, a reply. Note roughly how long.

I redid it. Work done twice because something was wrong, missing, or misunderstood.

Keep logging lightweight: a short note with the task, frequency, touch time, wait and any rework. A week is a starting sample; include longer cycles and exceptions before making a consequential investment.

Sort what comes back

Four buckets. The point of the exercise is the sorting, not the collecting.

Waiting may dominate a process, or it may not. Separate it from touch time. Ownership and handoff changes may help; AI triage or routing can also affect queues, but faster drafting alone will not remove an unrelated approval delay.

Re-keying and mechanical transformation. Copying between systems, reformatting, moving data. Cheap to automate, well-understood, and mostly not an AI problem either — scripts and integrations handle it more reliably and more cheaply than a model would.

Judgment at volume. Somebody deciding the same kind of thing repeatedly: which of these needs attention, which category is this, is this complete. This is the AI-shaped work. Repeated judgment, clear inputs, a right answer that a person could verify.

Genuinely hard, genuinely varied. Work that needs context, relationships, or real expertise. Leave it alone. Attempting it first is how programs lose credibility.

The result that surprises people

Look at which category actually dominates the observations. The answer may be waiting, repetitive handling, rework or a combination; do not assume the audit will confirm a standard ranking.

Some fixes need no new software, but still require people’s time and authorization. Compare process changes, conventional automation and AI against the same outcome.

A process fix can be a worthwhile result. Measure its effect and implementation effort rather than promising free wins or assuming it will secure support for a later proposal.

Score what is left

For each candidate, record frequency, time, consequences and dependencies. Treat these as separate dimensions rather than forcing them into an unexplained score.

How often does it happen? Record frequency alongside value per occurrence; a rare task may still have substantial consequences.

What does a wrong answer cost? Rework, a refund, a complaint, a clinician chasing a record.

How long does somebody wait for it?

Estimate benefit and risk separately; the automation path explores candidate selection in more detail. For time savings, start with task frequency multiplied by recoverable minutes, then subtract review and maintenance effort. Record error severity, data sensitivity, wait-time effects and implementation cost separately; a high failure cost is a reason for stronger controls, not a reason to prioritize autonomous deployment.

Put those assumptions into the first-automation decision workbook. Its fictional worked example and editable Markdown templates help compare candidates, distinguish released capacity from cash savings, and include human review, exceptions and maintenance in the estimate. Replace the example inputs with your own evidence before deciding what to build.

The mistake to avoid at this point

Having found a good candidate, the temptation is to build the full thing. Resist it for one cycle.

Make the work visible before making it automatic. Put the items in a queue somebody can see, with an alert when one has been sitting too long. Run that for a fortnight.

Check the volume, exception rate and available data instead of relying on memory. Use the observations to revise the estimate, and mark uncertainty rather than assuming the measured answer will always be worse.

What to do with the output

One page, three lists: process changes to test, contained automation candidates, and proposals needing deeper investment or risk review. Include an owner and rough effort for each.

Assign owners to straightforward process fixes and check their effects. Even an apparently free change can move work or risk elsewhere, so avoid changing a control without the responsible person’s agreement.

And write down what you are deliberately not doing, with the reason. Otherwise somebody concludes in two months that the exercise failed, when what actually happened is that the two largest items were consciously deferred at a price nobody has yet agreed to pay.

Who to involve, and who to leave out

The composition of this exercise determines its answer more than the method does.

Include the people doing the work. Obvious and frequently skipped in favor of asking their manager, who will describe the documented process rather than the real one. The gap between those two is usually where the cost lives.

Look for rework caused by unclear inputs or handoffs. If that is the cause, test a process improvement before automating the downstream symptoms.

Have the people doing the work compare observations and disagreements. Consensus in a meeting is not a substitute for checking the proposed cause against actual cases.

Three things that will distort the result

Averages. “It usually takes about twenty minutes” hides the tail, and the tail is where the escalations come from. Ask for the last one and the worst one in recent memory, not the typical one.

The loudest annoyance. The task everyone complains about is frequently low-volume; it sticks in the memory because it is unpleasant, not because it is expensive. Meanwhile the thing that costs real money happens two hundred times a week, takes ninety seconds, and nobody mentions it because nobody notices it.

The documented process. It describes what is supposed to happen. It rarely mentions the spreadsheet nobody admits to, the approval that waits three days for one person’s Tuesday, or the re-keying between two systems that officially integrate. Asking “walk me through the last one you did, click by click” gets past this reliably; asking “how does this work” does not.

Why start small

A short kickoff makes it easier to begin collecting evidence. Timebox the initial review, but extend investigation where the decision, exceptions or consequences require more than a first pass.

The first pass should produce a testable candidate and a reason for choosing it. Try a bounded change, measure what happened and revise the estimate before expanding it.

Technical review, October 10, 2026. References: NIST: AI Risk Management Framework; OpenAI: evaluation best practices.

Try this

Log repetitive work, waiting and rework for a week, noting rough frequency and time. Review longer-cycle exceptions too. Use the notes with process, cost and risk information to choose one bounded improvement to test.