Automation that pays for itself, and automation that just moves the work

The automation that fails is easy to spot and easy to stop paying for. The automation that quietly does not pay is harder, because it works. It ships, it runs, everyone agrees it is impressive, and six months later nobody can say what it saved.

I have built both. The difference between them is visible before you start, if you ask one question honestly.

What is the question?

What is the work after this exists, including the checking, and is that number clearly smaller than the work today.

Most proposals answer the first half. The task takes two hours a week, the automation does it in seconds, therefore two hours saved. The second half is where the saving usually goes: somebody now spends forty minutes a week confirming the automation did the right thing, handling the cases it could not, and fixing what it got wrong on the days the input was unusual.

Forty minutes is still better than two hours. But it is a saving of about one hour, not two, and that is a materially different case for spending a week building it.

What separates the two kinds?

Whether the output can be trusted without inspection, which depends almost entirely on how varied the input is.

Automation over structured, predictable input is genuinely near-free once built. Moving a form submission into a CRM, tagging it, sending a confirmation, notifying the right person: the input is a form, the shape never changes, and it either ran or it did not.

Automation over unstructured input has a permanent inspection cost. Reading emails, interpreting documents, deciding what somebody meant. It is enormously useful, and it never gets to zero human attention, and pretending otherwise is how the checking job gets created without anyone deciding to create it.

• Structured input, deterministic rules · approaches zero attention

  Form to CRM, invoice to spreadsheet, alert to the right person. Built once, genuinely runs.

• A scheduled report assembled from systems you already have · approaches zero attention

  The inputs are stable, so the output can be trusted without reading it.

• Interpreting what somebody meant · carries a permanent checking cost

  Useful, and it never reaches zero attention. Budget for the review surface.

• Anything with a customer at the other end · carries a permanent checking cost

  The checking is not optional here, so count it as part of the cost.

Neither column is bad. The mistake is buying the second while budgeting for the first.

Where does the money actually go when it goes wrong?

Into integration and into the review surface, almost never into the clever part.

The clever part is usually a few hours. Connecting it to the system that holds your customers, handling the case where that system is down, deciding what happens to the record that failed, and building the place a person looks to see what happened: that is the project. Anybody quoting you for the clever part alone is quoting for a demonstration.

I have written the operating version of this in what an AI agent can and cannot do for a small business, which covers the same line from the other side.

What should a small business automate first?

The thing that is high volume, low judgement, and visible when wrong.

Enquiry handling, almost always. It happens constantly, the right action is usually obvious, and if it goes wrong the owner finds out quickly because a customer says so. That combination makes it safe to automate and easy to prove.

The second thing is reporting, for a different reason. Nobody enjoys assembling it, it is entirely deterministic, and the automation removes a task that was being done badly and late rather than one that was being done well.

What should you not automate?

Anything you have not yet done manually enough times to know the edge cases.

This is the most reliable rule I have. Automating a process you have run fifty times encodes what you learned. Automating one you have run three times encodes your assumptions, and you will spend the next six months discovering them one at a time, in production, as exceptions.

If a process is new, run it by hand until it is boring. Boring is the signal that it is ready.

How do you know it worked?

You should be able to name the hour that came back and say what happens in it now.

That is a deliberately hard test and most automation does not survive it, which is useful information. The projects that do survive it tend to be small, dull and specific, and they compound, because each one genuinely removes something rather than relocating it.

If you want that assessed before anything gets built, it is where I start with clients, and the answer is sometimes that the automation is not worth building.