When Automation Is the Wrong Answer

We build automations. The most frequent advice we give in a first call is still: not yet.

That is not modesty. An automation built on an unsettled process does not improve it — it makes it faster, less visible and harder to correct. Six situations where we advise against it.

1. The process is negotiated, not decided

If three people in the business handle the same case differently and all three ways work, there is no process — there are three. An automation forces one of them to become the standard without anybody having made that decision deliberately.

The consequence is predictable: two thirds of the team work around the system. After that there are four variants, one of them with software.

Settle first: which variant counts, and who decided?

2. The frequency is too low

A case that occurs twice a quarter practically never pays off. Not because of build time but because of maintenance: by the next run an interface may have changed, and nobody notices because nobody is looking.

Low-frequency automations are broken more often than they are working.

3. The decision is "it depends"

Rules can be automated; judgement cannot. If the honest answer to "what do you decide that on?" is a pause, the process is not ready for automation.

That is not permanent — judgement can often be turned into rules. But that is then the real work, and it happens before the build.

4. There is no baseline

Without a measured starting point — cycle time, error rate, cases per week — nothing can be demonstrated afterwards. The benefit stays an assertion, and the next investment gets decided on instinct.

Two weeks of measuring costs less than a workflow that convinces nobody.

5. The bottleneck is somewhere else

The classic case: quotes get generated automatically, but the bottleneck was never the generation — it was that nobody follows up. After automation the same quotes sit unanswered, faster.

Settle first: where does a case actually stall? That is rarely the step that annoys people most.

6. Nobody owns it

An automation needs a person who notices when it stops and knows what to do then. Without that person the workflow runs — until it does not. In practice that is not noticed immediately but when a customer asks.

We have lived this ourselves: an automated publishing process ran green for an extended period and published nothing, because the queue was empty and no check would have reported it. Green does not mean it is working.

Frequently asked questions

Does this mean we should not start at all?

No. It means starting with the most boring process rather than the biggest — high frequency, clear rules, low risk. That produces the experience that makes the second case faster and safer.

How do I recognise a good candidate?

By four properties at once: high frequency, clear rules, a stable data source, and noticeable pain. If one is missing, look closely before building.

What about AI models instead of fixed rules?

They move the boundary, they just do not move it as far as people hope. A model can classify unstructured text. It cannot decide which of your three ways of working is the right one.

And if we want to anyway?

Then we say what we see and build it afterwards. It is your decision — it should just not rest on an over-optimistic calculation.

What you can do today

1. Take the process you want to automate and work through the six points above. Honestly, not charitably.
2. Every point where you hesitate is the real task, not the workflow.
3. Measure the baseline for two weeks — cycle time, volume, errors.
4. Run the case through the AI automation ROI calculator, including build and maintenance.
5. If little remains after subtraction, that is a result — not a failure.

If you want a second opinion before committing budget: how we assess these cases is described under AI & automation — or talk it through in a first call.