What we'd tell you not to automate

Most of what gets written about automation is about what to automate.

That is the easy half.

The harder half — and the part that usually decides whether the money was well spent — is knowing what to leave alone.

In our 20-minute check, we look not only for work that could be automated, but also for the things that probably should not be.

These are six of the signals we pay attention to.

1. Something too small to repay its own maintenance

Every automation has two costs.

The obvious one is building it.

The quieter one comes afterwards: somebody has to maintain it, understand it when the original developer is gone, fix it when the underlying system changes and notice when it stops behaving as expected.

As a rough rule, anything taking less than about an hour a week deserves extra scrutiny.

But time alone is not the decision.

A 30-minute task performed by an expensive specialist, or one where a mistake creates a compliance problem, may be well worth automating. A two-hour task may not be, if solving it requires a fragile integration that has to be repaired every few months.

The useful question is not:

How many hours can we remove?

It is:

Will the saving repay the build and the cost of keeping it alive?

The easiest jobs to automate are often the ones suggested first.

Easy and worthwhile are unrelated.

2. A process that is about to change

If the department is being reorganised, the pricing model is under review or someone is already choosing the system that will replace the current one, automating today’s process can make things worse.

It sets the old way in concrete.

And once money has been spent automating it, the old process suddenly has another reason to survive.

That does not mean you always have to wait.

A small, disposable automation may still make sense if the change is a year away or if the solution can be built so that the changing part is easy to replace.

But a large investment in a process you already know is temporary deserves a very high bar.

When possible, wait for the change.

Then automate the thing that survives it.

3. Judgement wearing a process costume

Some tasks look repetitive from the outside and are not.

Approving an unusual discount. Deciding which complaint deserves escalation. Looking at the history behind a supplier issue and deciding whether to call.

A useful signal is that two competent people might sometimes reach different conclusions and both answers could be defensible.

That is judgement.

It does not mean nothing can be automated.

It means the judgement should not be treated as if it were a deterministic rule.

Software can gather the information, check the obvious conditions, prepare the context and send the case to the right person.

It may even handle the routine 80% and leave only the unusual 20% for review.

Often, that is where the real saving is.

Not removing the decision.

Removing all the work somebody has to do before they are able to make it.

4. A system with no reliable way in or out

No API does not automatically make automation impossible.

There may be exports, database access, file-based integrations, email workflows or even UI automation.

But the route matters.

If the only way to move data in and out is through a brittle workaround that depends on screens, buttons and layouts staying exactly the same, the integration can quickly become the project.

That means more build time, more maintenance and more ways for something to fail quietly.

Sometimes that still makes sense.

Sometimes the honest answer is that the automation is not worth it until the underlying system changes.

That is not the same project, and it usually comes with a different budget.

5. Something your existing tools already do

This is one of the most common things we look for first.

Companies routinely pay for software they only use a fraction of.

Scheduling, reminders, templated documents, approval routing, automatic notifications, reporting — the capability may already be sitting in the CRM, ERP or booking system, switched off or simply unknown to the people who would benefit from it.

If an existing feature solves the problem well enough, turning it on usually beats building a replacement.

It is cheaper.

It is faster.

And it leaves you with one less system to maintain afterwards.

Sometimes the best automation project is no project at all.

6. The biggest and most complicated thing on the list

When people make a list of what they want automated, the biggest item is often first.

It hurts the most, so naturally it gets the most attention.

It also tends to have the most dependencies, the most stakeholders and the longest gap before anyone sees something useful.

That does not mean the big problem should be ignored.

It means it may not be the right place to start.

We would usually look for the smallest meaningful slice that creates real value, has manageable dependencies and can prove the approach.

A smaller first step does three useful things.

It creates a result earlier.

It gives you evidence for whether the next investment is justified.

And it shows you how your organisation actually responds to the change — information no plan can give you as reliably as doing the work.

Why we say what we would leave alone

The point of telling you what we would not automate is not to make the recommendation sound more credible.

It is part of the recommendation.

If the best answer is “use the feature you already have”, “wait until the ERP migration is finished” or simply “this does not save enough to justify building anything”, that should be useful information too.

And if several of the signals above apply to the process you brought us, the right answer may be to wait — or not automate it at all.

We would rather arrive at that answer during a short conversation than three months into a project.

That is why the written follow-up after our 20-minute check includes not only what we think is worth automating, but also what we would leave alone — and why.