Running an AI and automation audit before you build

The processes people complain about loudest are rarely the ones with the best return. Complaints track irritation; value tracks volume multiplied by effort multiplied by the cost of getting it wrong. A task performed twice a month by one person is memorable and irritating. A task performed four hundred times a week by six people, quietly and without complaint, is where the money is.

A process is genuinely worth automating when it runs often enough for the saving to compound, its rules can be written down without a dozen exceptions, its inputs arrive in a consistent form, and the consequence of an error is either small or detectable. When any of those is missing, automation tends to add a layer of fragile machinery on top of an unresolved problem.

An audit exists to make that judgement explicit and comparable across candidates, before anybody commits budget to a build. It usually takes days, not months.

Score each candidate process from 1 to 5 on four dimensions. Do it with the people who perform the work, not just their managers — the estimates change substantially when the practitioners are in the room.

• Volume. How many times does this run per week or month? 1 = rarely; 5 = continuously.
• Rule clarity. Can the decision logic be written down as rules today? 1 = mostly judgement and tribal knowledge; 5 = fully deterministic with documented exceptions.
• Error cost. What happens when it goes wrong? 1 = trivially corrected; 5 = financial, regulatory or customer-facing damage. High error cost does not disqualify a process — it dictates how much verification, logging and human review the design must carry.
• Manual effort. Minutes of skilled human time per instance, including the chasing, re-keying and checking around the task.

Reading the scores

• High volume, high clarity. Automate first. These are the boring, reliable wins that fund everything else.
• High volume, low clarity. Candidates for AI assistance rather than deterministic automation — or for a rules-clarification exercise first. Design them with a human in the loop.
• Low volume, high clarity. Cheap to automate but rarely worth the maintenance. Bundle several together or leave them.
• Low volume, low clarity. Leave alone. This is where automation projects go to die.

Rank by volume × manual effort to get the size of the prize, then use rule clarity to decide the approach and error cost to decide the controls. That ordering keeps the conversation about value rather than about which technology sounds most impressive.

Automating a broken process does not fix it; it industrialises it. Errors that a human used to catch by noticing something odd now propagate at machine speed, and the people who understood the workaround are no longer in the loop to spot it.

An illustrative example

Consider a hypothetical distributor — this is an illustration, not a client — whose invoice approval process takes four days. The instinct is to automate the approval routing. An audit finds that only about a day of the four is routing; the rest is spent resolving purchase orders whose line items never matched the delivery note, because the ordering team keys product descriptions by hand into a free-text field.

Automate the routing and you get a process that reaches the same unresolved mismatches one day sooner, with a new automation to maintain. Fix the data capture first — a controlled product list at the point of ordering — and most of the exceptions never occur. What remains is small, consistent and genuinely worth automating.

The test to apply before every candidate: if this process were performed perfectly by a diligent person with the current inputs, would the outcome be acceptable? If not, the problem is upstream, in the data or the process design, and that is where the first investment belongs.

The two get conflated in budget conversations, and the distinction is practical rather than philosophical: deterministic automation executes rules you can state, while machine learning infers patterns you cannot state precisely.

Signs it is workflow automation or RPA

• The steps are the same every time and the exceptions are enumerable.
• Inputs are structured — forms, spreadsheets, database records, API payloads.
• The work is moving and reconciling data between systems that do not talk to each other.
• Correctness is verifiable by a rule, so the output can be trusted unattended.

Note the ordering here: an API or a native integration is almost always preferable to screen-level robotic process automation. RPA earns its place where a system genuinely offers no interface — legacy applications, vendor portals — and should be treated as a bridge, with the maintenance cost of UI changes budgeted honestly.

Signs it is genuinely an AI problem

• Inputs are unstructured: email threads, scanned documents, contracts, call notes, free text in several languages.
• The rules exist only as experience — “you can tell from how it's worded” — and experts disagree at the margins.
• Classification, extraction, summarisation, drafting or matching against a large knowledge base is the core of the task.
• Being right most of the time, with review on the rest, is a real improvement.

Most valuable systems are hybrids: a model extracts and classifies, deterministic rules validate and route, and humans handle low-confidence cases. Design the confidence threshold and the review queue at the start — retrofitting them after go-live is far harder than building them in. Our automation enablement work almost always lands in this hybrid territory rather than at either extreme.

A first-pass audit fits into a half-day workshop with process owners, one or two practitioners, someone from IT and someone who can speak to risk or compliance. Work through these questions for each candidate and record the answers where everyone can see them.

1. What triggers this process, and what does “done” look like?
2. How many times does it run, and how long does one instance take end to end — including waiting?
3. Which systems are touched, and do they have APIs or only screens?
4. What proportion of instances are exceptions, and what are the three most common ones?
5. Where does the data come from, and who is accountable for its quality?
6. What happens today when it goes wrong, and who notices?
7. What is the regulatory, audit or contractual constraint on changing this?
8. If we changed nothing else, what single upstream fix would remove the most rework?
9. Who would own the automation after launch, and do they have the capacity to maintain it?
10. How will we measure whether it worked, using data we already collect?

The last two are the ones most often skipped and most often fatal. An automation with no owner and no measurement becomes an unexplained script that people work around within a year.

Weeks 1–3: baseline and choose

Finish scoring, measure the current state with real numbers rather than estimates where you can, and pick one process — not five. Fix the upstream data or process problems that the audit surfaced for that one candidate.

Weeks 4–8: build narrow

Deliver the automation for a single team, a single region or a single document type, with logging, an exception queue and a manual fallback path from day one. Keep the humans doing the work informed and involved; they will find the edge cases faster than any test plan.

Weeks 9–12: prove and decide

Run it alongside the existing process long enough to compare outcomes honestly. Report against the baseline you captured in week one: instances handled, exception rate, time saved, errors caught. Then make an explicit decision to scale, adjust or stop.

Ninety days is enough for one process to be genuinely in production and measured. It is not enough for a transformation programme, and framing it as one is the surest way to have nothing running at the end of it.