Practical AI automation: what pays back in 90 days, and what does not

The difficult part of applying AI inside a business has almost nothing to do with models. It is deciding which processes are worth touching. The technology will produce a plausible-looking output for nearly any task you point it at, which is exactly why it is such a poor guide to where the value is. A demo succeeds by producing something impressive once. A production automation succeeds by being right often enough that nobody has to check it — and those are very different bars.

So start with a filter rather than a tool. A process is a reasonable automation candidate when four things are true at once: it happens often enough that the effort amortises, its inputs arrive in a reasonably consistent shape, someone can tell within seconds whether a given output is correct, and the cost of an occasional wrong answer is bounded and recoverable. Remove any one of those and the economics usually invert. Rare processes never repay the build. Inconsistent inputs move the work from doing the task to correcting the input. Outputs nobody can quickly verify create a review burden larger than the original task. And unbounded downside is not an automation problem, it is a liability problem.

The second rule is duller and more frequently ignored: measure before you automate. If you cannot state today's throughput, today's error rate and today's cycle time, you will not be able to demonstrate an improvement afterwards — and you will be strongly tempted to substitute a vendor's benchmark for your own result. We would rather spend the first two weeks of an engagement instrumenting the current process than shipping something we cannot later prove worked. It is the least exciting part of the work and it is the part that determines whether anyone believes the outcome.

For structure around the risk side, the NIST AI Risk Management Framework is worth knowing about even at thirty employees. Released in January 2023 as version 1.0, it defines four core functions — Govern, Map, Measure and Manage — and it is explicitly intended for voluntary use. That last point matters: it is not a compliance regime you must satisfy, it is a vocabulary for making decisions defensible. A small business does not need a governance programme. It does need to be able to answer, when a customer or an insurer asks, who decided this system could run, what it was tested against, and what happens when it is wrong.

Now the useful part: where automation genuinely tends to repay inside a quarter. Structured extraction from unstructured documents — pulling defined fields out of invoices, forms, statements or correspondence — works well because the output is checkable at a glance and the input volume is usually high. Routing and triage works well because a misroute is cheap and immediately visible. Drafting with mandatory human review works well provided the reviewer is genuinely reviewing rather than rubber-stamping. Reconciliation and exception-finding works well because the machine proposes and a human disposes, and the failure mode is a false positive rather than a silent error.

And where it does not. Anything whose output leaves the organisation without a human in the path — customer commitments, pricing, clinical or financial advice, contractual language. Anything where the input format changes constantly, because you will spend the savings on maintenance. Anything genuinely low volume, where the honest answer is a checklist and twenty minutes a week. And anything where the current process is broken: automating a broken process produces the same wrong outcome faster and with a more confident tone, which is strictly worse than the manual version because it removes the friction that used to surface the problem.

That last point deserves its own sentence. The most common failure we see is not a model performing badly. It is a well-performing model faithfully automating a process that nobody had examined in years.

There is a security dimension that most SMB-facing AI material skips entirely. NIST's adversarial machine learning taxonomy, published in March 2025, categorises attacks on AI systems as data poisoning, evasion, abuse and privacy breaches. For a small business the relevant one is usually abuse — including prompt injection, where content the system reads is crafted to change what the system does. If your automation reads email, scrapes web pages, or ingests customer-supplied documents, then untrusted text is reaching a component that takes actions. That is not a theoretical concern, it is the ordinary operating condition of most useful automations.

Our own engineering rule follows directly from that, and we apply it to our internal systems as strictly as to anything we build for a customer: never put a language model in an irreversible path. If an action cannot be undone — sending an external message, moving money, deleting records, publishing something — a model may propose it, but a human or a deterministic rule must be the thing that commits it. This is not caution for its own sake. It is the design decision that means a successful prompt injection produces a rejected suggestion instead of an incident.

On cost, the arithmetic that matters is not the one vendors present. Token or subscription cost is usually the smallest line. The real costs are integration, the review time the automation creates, and the maintenance burden when an upstream format changes. An automation that saves ten minutes of work but generates four minutes of verification has saved six minutes, not ten — and if the verification is skipped because it feels redundant, it has not saved anything, it has transferred risk. Build the verification cost into the business case at the start, where it is an input, rather than discovering it later, where it is a disappointment.

What we explicitly do not recommend is making headcount reduction the first project. Partly because it is the hardest thing to get right technically, and partly because the organisational reaction to it will determine whether anyone cooperates with the second project. Start with something that removes a task everybody dislikes and nobody's identity is attached to. Reconciliation, data entry, document sorting, first-pass triage. Earn the right to attempt something harder.

The other thing we do not recommend is believing the pilot. Pilots run on curated inputs, with the person who built the thing paying attention. Production runs on whatever arrives on a Tuesday, with nobody watching. Those are materially different conditions, and a pilot that has not been exposed to the second one has not yet tested the thing that matters. Run it on unfiltered real inputs for a fortnight before deciding anything — including deliberately feeding it the ugly cases people usually handle by hand.

The checklist below is the assessment we run before agreeing that a process should be automated at all. A fair number of candidates do not survive it, which is the point. If you have a process in mind and want a second opinion on whether it qualifies, the scoping call is 15 minutes, and telling you not to automate something is a perfectly normal outcome of it.