When a business process is worth automating — and when it is not

I have been on both sides of automation projects. I have watched them work, and I have watched a company spend a small fortune automating a process that was better off deleted. Both are common, and the second one is more common than anyone admits.

Here is how I decide.

The test that filters most things out

A process is worth automating when all three of these are true:

1. It happens often enough that the time spent is material.
2. It is the same every time — genuinely the same, not “usually the same”.
3. Getting it wrong is expensive or embarrassing.

Most processes people bring me fail one of these, usually the second. A step that looks standard usually has nine exceptions attached to it, and those exceptions are where the real work is hiding.

Ask what happens when the process does not go as expected. If the answer involves judgement, a phone call, or somebody who has been there a long time, you have found the constraint. That constraint is the actual project.

The four questions I ask

How often does this run? Not daily in theory — actually, with the real number. If it runs weekly and takes twenty minutes, the ceiling on what automation can save is small, and it will be consumed by the build.

How many people touch it? If one person does a task that four people are waiting on, automating it changes the whole team’s throughput. If three people each do their own version, the real win might be one shared form rather than three automations.

Where does the data come from, and where does it have to go? This is the question that determines whether you need software at all. A great many “automation projects” are an integration between two systems that already have APIs. No application. A small service that moves data and logs what it did.

What happens when it breaks? If the answer is “someone notices”, the automation is worse than the manual process, because you have made the failure silent. This is the most commonly skipped step and the one that determines whether you still trust the system in six months.

Delete it, automate it, or leave it

My default advice is more often to delete than to automate.

When I walk through a process with a client, the most common outcome is that one or two steps should simply stop happening. A report nobody reads. A handoff that exists for historical reasons. An approval that has never once been refused. These are free to remove and often worth more than the automation would have been.

This sounds obvious and is frequently skipped, because automation is something you can commission and deletion is something you have to convince people of. But every step you delete is a step that cannot fail, cannot need maintenance, and cannot be the reason someone is up at 3am.

If a step should stay manual, say so. Manual steps are not a failure of the project. Knowing what not to automate is as valuable as knowing what to.

What I have built

I have spent eight years integrating automations for corporations and building backends for SaaS companies. The integrations are less glamorous than the products and more valuable: connecting an accounting system to an order intake process, replacing a nightly manual export, getting data from a supplier’s system into yours reliably.

The work I do on these has more in common with plumbing than with application development. It is about getting data from place to place without a person touching it, and failing loudly when that is not possible.

I also build the surrounding products when there is a real product to build. A social media scheduling tool, a platform for small sellers trading on WhatsApp. Those taught me that an integration which nobody can operate is not finished — the person on the ground has to be able to see what it did and correct it.

The honest constraint

The thing that stops most automation projects is not technical difficulty. It is that the organisation cannot agree what should happen.

If two people describe the process and get different answers, no amount of engineering resolves it. The automation will encode one of those answers and quietly produce wrong results for the other case, which is worse than the manual process because it looks authoritative.

Budget time for that conversation. It is not overhead — it is the project.

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 it is not. 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.