How to Audit Your Business for AI Opportunities: The Four-Phase Method I Use

Field notes. John Arndt, Soxoa. Published June 16, 2026.

I run software products of my own, and a few times a year each one goes through a full audit: inventory every feature the product claims to have, test whether each one actually works, fix what is broken in priority order, then retest to prove the fixes hold. It is unglamorous work, and it finds things, including in products I built myself and thought I knew.

The same four phases are how a business should decide where AI fits. The wrong question is “what can AI do?”, which produces brainstorms and slide decks. The right question is “what does this business do all day, and which parts of that are expensive or broken?” That one produces a ranked list you can act on.

Here is the method in full. You can run it with a spreadsheet and two honest afternoons, and I would rather you did than hire anyone to tell you what your own people already know.

Phase one: inventory

List every recurring task in the business. Not departments, not job titles, tasks. “Answer inbound phone calls.” “Prepare the Tuesday production schedule.” “Chase unpaid invoices.” “Re-key orders from email into the system.” Go person by person and ask each one what they do every day, every week, every month. Write down everything, including the things that seem too small to matter.

Two rules make this phase work. First, capture frequency and duration: how often does it happen, and how long does it take each time? Multiply those and you have hours per month, which is the number everything else hangs on. Second, capture the tasks that are not in anyone’s job description. Every business runs on invisible glue work: the office manager reconciling two systems by hand, the estimator retyping the same specs into three documents. The glue work is the first place to look, precisely because nobody has ever examined it.

Phase two: test

Now score every task on the list against four questions.

Score each question 1 to 3, add them up, and sort. This takes an afternoon, and it is the highest-value afternoon in the whole process, because it replaces “I feel like we should automate something” with a ranking you can defend to a skeptic. The top of the list is rarely what the owner would have guessed. Owners guess the tasks that annoy them personally. The scoring finds the tasks that quietly consume hours and require almost no judgment.

1. Is it frequent?

   Something done fifty times a month can justify automation that something done twice a year never will.

2. Is it low-variation?

   Does the task take roughly the same shape every time, or does each instance need fresh judgment?

3. Is the input digital, or easily made digital?

   A task that starts from an email or a form automates far more easily than one that starts from a phone call and a sticky note.

4. Is the output checkable?

   Can you tell, quickly and objectively, whether the task was done right? If you cannot check it, you cannot safely hand it over.

Phase three: fix

Take the top three tasks, not the top ten, and build them properly. Properly has a definition, and it is the list below.

Resist starting all ten at once. Three systems that ship and get adopted beat ten that stall in parallel, and the first three make the next three cheaper, because the plumbing and the review habit already exist by then.

This is also the phase where it pays to build in the room with the people who do the work. They know where the difficulty actually sits, and they will say so in a working session in a way they will not in a requirements interview. A team that watched the decisions get taken will operate the result; a team handed a finished box routes around it. That is the whole design of a Live Build Workshop: one day, one working automation, built live on your team’s own approved work.

Real tools

The system connects to the systems the work actually lives in, not to a tidy copy of the data prepared for a demo.

A named reviewer

One person owns review of anything customer-facing until the system has earned trust, and that person is chosen before the build starts, not after.

A log

Every action recorded somewhere a person can read it afterwards, in enough detail to reconstruct a bad day.

An escalation path

A defined route for the cases the system cannot handle, ending with a person who has the context to finish them.

A measured baseline

Write down what the task costs today. If invoice follow-up takes six hours a week in your shop, that number goes in the document, because in ninety days somebody will ask whether this was worth it and “it feels better” is not an answer.

Phase four: verify

Thirty days after a system goes live, retest it the way you would retest a feature. Is it still running? Is anyone quietly working around it? Did the hours come back, measured against the baseline you wrote down? Is the error rate acceptable, and are the errors being caught by the escalation path rather than reaching customers?

This is the phase everyone skips, and skipping it is how a company ends up “using AI” on paper while the staff reverted to the old way months ago. In software, an untested fix is assumed broken. Treat an automation the same way. The verification pass takes a couple of hours per system, and a system that passes it gives you something rare: an automation you can stop thinking about. Then go back to the ranked list and take the next three.

Run it yourself, or bring someone in

Everything above is doable in-house with a spreadsheet and some discipline, and if you run it yourself you will get value from it. The two places outside help changes the outcome are phase two, knowing what these systems can actually do reliably rather than what a vendor says they do, and phase three, building with guardrails that hold when the work gets strange. Scope and price are agreed before work begins.

If you want a second opinion on your ranked list, bring it and we will go through the top of it, including the possibility that the honest answer is to build nothing yet. Schedule a strategy call, or start with the readiness assessment: five dimensions, self-scored, runs in your browser, and your answers are not stored.