When automation is worth the cost, and when it is not

The question we get asked most is not which model is smartest. It is whether a particular piece of work deserves to be automated at all.

That second question matters far more. Automation attached to the wrong task adds a maintenance burden without lifting the load off anybody, and it does so permanently, because now somebody has to keep the automation working too.

Three tests decide it. A task has to pass all three.

The work repeats in the same shape

Work whose shape changes every time is hard to automate at a sensible cost. Not because it is impossible, but because each new variation demands an adjustment, and the adjustment can take longer than simply doing the task by hand would have.

A rough measure: if you can explain the steps to a new employee in a single page, the work has enough of a pattern to be worth automating. If explaining it requires sitting beside them for a week, it does not.

Mistakes can be checked quickly

An AI agent will occasionally be wrong. That is not a reason to avoid using one, but it is a strong reason to pick work whose output can be verified fast.

Summarising a document is safe, because a person can skim the summary and notice immediately if something is off. Deciding whether to approve a credit application is not safe without an approval gate, because the mistake only surfaces months later when the loss is already real and unrecoverable.

If you cannot tell within thirty seconds whether the output is wrong, the flow needs a human approval step before that output goes anywhere.

There is enough volume to pay it back

Automation carries a fixed cost in design, testing and ongoing maintenance. That cost is only repaid when the work repeats often enough.

For something that happens twice a month, doing it by hand is almost always cheaper across a three year horizon. For something that happens twenty times a day, the arithmetic reverses completely and the manual version becomes the expensive option.

What usually passes all three

• Reading incoming documents and moving their contents into a record system
• Assembling a periodic summary from data that has already been collected
• Answering repeat questions from a fixed set of internal documents
• Checking a submission for completeness before a person looks at it
• Routing an incoming request to the right department

Those five share the same traits. They are patterned, their output is easy to check at a glance, and they happen constantly.

Start there. Not with whatever is most interesting to talk about in a meeting.

When none of the three hold

If a task fails these tests, automation is usually not the answer, and it is worth saying so plainly rather than building something that will be quietly abandoned.

What is often needed instead is much smaller: a tidier form, one integration between two systems that currently do not talk, or simply deleting a step that nobody has questioned in four years. Those changes cost a fraction as much and they tend to hold up better, because there is less of them to break.