How to identify what in your business is worth automating

Automation is the most popular answer to the most common problem in business. It is also the right answer about half the time, which is better than most business advice and considerably worse than it sounds.

Picking a tool is the easy part. N8N exists (if AI didn’t killed it yet). The hard part — the part that actually decides whether you save money or waste it — is figuring out which of your processes deserve one.

Most people cannot. So they pick the process that annoys them most this week and automate that. Sometimes that is the right choice. Frequently it is the process with the most hidden value in it, because the one that annoys you is the one somebody else already tried to fix and could not.

Here is the method I use. Seven steps, in this order. An afternoon of work.

Step 0: Ask whether the step should exist at all

Before any of this, look at the candidate process and ask if it is still needed.

Not “is it useful”. Is it still needed. Processes outlive the reasons that created them. A report nobody reads. An approval that has never been refused. A handoff that exists because that is how it worked in 2024 and nobody has proposed changing it.

Deleting a step costs nothing, breaks nothing, and removes the possibility of failure entirely. It is almost always cheaper than automating it.

This gets skipped because automation is something you can commission and deletion is something you have to talk people into. Every step you delete is a step that cannot need maintenance.

Step 1: Know what “automation” actually means here

Automation is a machine following a rule you wrote. That is the whole concept. Repetitive, rule-based, digital. No opinion required.

The moment a system has to guess, you have not automated anything — you have delegated a decision to something that will make it confidently and without telling you (yes with AI as well). That is fine for drafts and terrible for invoices.

Knowing this boundary is what stops you from buying an AI product to solve a copy-paste problem, which happens constantly and costs a great deal.

Step 2: Write down how the business actually runs

Not how it is supposed to run. How it actually runs, including the parts people do not put in the manual.

Every process, from order intake to invoicing to the reply a customer gets when something goes wrong. One page per process, in plain language, written by the person who does it rather than the person who designed it.

The gap between the documented process (which is most likly outdated, nobody wants to write SOPs) and the real one is where the money is hiding. That gap is the exceptions, the workarounds, the “we normally just do this”. Nine people doing the same task in nine slightly different ways is not a documentation problem, it is a design problem, and the fix is often one shared form rather than nine automations.

Step 3: Find what repeats

Not what is annoying. What repeats.

Daily, weekly, monthly — get the real number, not the theoretical one. Ask for the last three months. People are bad at this and will confidently tell you it runs weekly when it runs twice a quarter.

The rough test: if it ran at least five hundred times a year, it is worth looking at. If it ran forty times, the maths rarely works no matter how long each one takes.

Step 4: Price the hours honestly

Take the real frequency, multiply by the real minutes, then multiply by what that person actually costs you — fully loaded, not their hourly rate on the invoice.

Then subtract the hours the automation itself consumes. Building it, testing it, monitoring it, fixing it when the upstream vendor changes a field without telling you. The build is not the cost. The build is the smallest part of the cost.

And be honest about what an hour saved actually buys you. It does not automatically reduce a salary. What it usually buys is that the person can do the next thing on their list instead of re-keying data for the fortieth time. Sometimes it genuinely does let you grow without hiring. Both are worth having, but you should know which one you are buying before you claim it later.

Step 5: Set a payback window and respect it

A simple rule that filters out most bad ideas: if it has not paid for itself in twelve months, it was not worth doing.

Twelve is aggressive and I use it anyway, because the alternative is a collection of small automations that each save a little and collectively cost more in maintenance than they return. Those systems never get cleaned up. They just accumulate until the person who understood them leaves.

Step 6: Ask the people doing the work

Your team knows where the process hurts. You know what the process is supposed to do. Those are different things, and the second one is usually written down.

Ask two questions. What in this process is stupid? And what would break if we automated it?

The first gets you the opportunity nobody documented. The second gets you the constraint that decides the entire design — and it is nearly always the thing that was skipped when the process was first written down.

If two people describe the same process and give different answers, stop. You do not have a technical problem, you have a disagreement, and no amount of engineering fixes it. The automation will encode one of the two answers and quietly produce wrong results for the other case, which is worse than the manual process because it looks authoritative.

Step 7: Ship one, then watch it

Automate the single smallest thing on the list. Not the most valuable — the smallest. You want a fast, cheap win that teaches you what the real failure modes look like before you bet anything on the big one.

Then watch it properly, fix and improve it until is stable. Don’t forget to document it. Monitoring is as important as building it right. In code you can set alerts that can go to your main comunication tool - Slack, Teams, Email etc.

What this looks like in practice

Most of the work I do is exactly this and none of it is glamorous. An accounting system feeding an order intake process. A nightly manual export replaced by a job that logs what it did. Supplier data landing in our system reliably instead of a person copying rows between two systems.

These are small services — Python, a database table, a log somebody can read — and they pay for themselves by not recurring every single day forever. A product is a bet on new revenue. An integration removes a cost that is already being paid.

If you have a process you would like to stop doing by hand, describe it and tell me what it costs you today. You will get a straight answer on whether it is worth automating, and I will sometimes tell you that one of your steps should be deleted instead. That conversation is free and there is no discovery invoice — if it turns into a project, you will know the scope before anyone signs anything.