AI Automation: How to Tell a Real Return From a Demo

What makes a process worth automating

The processes that pay back share one shape, and you can recognise it before building anything.

• Volume and repetition. A task done four hundred times a month is worth automating badly; a task done twice is not worth automating well
• Rule-based enough to be checkable. If you cannot describe when the output is wrong, you will not trust it, and someone will keep checking it by hand
• Sitting on a real bottleneck. A step with a queue in front of it changes throughput; a step that was never waiting changes nothing
• A named owner after launch. Somebody has to be responsible when it produces a wrong answer in month seven.

Rule, AI step or agent: which one you need

The three differ in cost and risk, and the least sophisticated one that solves the problem is almost always right.

• Rule-based automation follows a defined path. Predictable, cheap, easy to audit, and it covers most of what businesses actually need. Most problems described as "we need AI" are this
• AI-assisted steps use a model where a rule does not fit — classifying free text, extracting fields from an unstructured document. They are probabilistic, so the process around them has to tolerate being wrong sometimes
• Agentic systems pursue a goal across steps and decide their own path. The most capable, and the hardest to constrain, audit and cost

How to measure the return

Agree the measurement before you build — afterwards everyone finds a number that makes the project look good.

• Baseline the current state: how long the process takes, how often it errors, what those errors cost
• Count hours removed only where they went somewhere that matters. "Saved time" that quietly refills with other work is not a return
• Count avoided errors where errors cost something real — a rejected tax submission, a mispriced order, a missed renewal
• Count throughput where capacity was the constraint: same team, more orders processed
• Subtract the running cost: model or platform fees, maintenance, and the time spent checking output while trust is built

The order to do it in

Start where the work piles up — not where it is most annoying.

Fix the process before automating it. Automating a broken process produces broken output faster and hides the original problem.

Then check whether the data those steps rely on is structured and reachable. If it is not, that is your first project. Only then choose the mechanism.