When automation is the wrong answer

Most articles about automation assume the decision is already made. This one does not. Roughly a third of the processes people bring to us should not be automated, at least not yet, and finding that out during a scoping call is considerably cheaper than finding out after a build.

Here is how to tell the difference.

The process changes every few months

Automation encodes a process. If the process is still moving, you are encoding a moving target, and every change to how the work is done becomes a change request against the system.

The signal to watch for is not how often the process changes on paper, but how often the people doing it disagree about what the steps are. Ask three people to describe the workflow. If you get three different answers, you do not have a process yet, you have a habit. Automating a habit produces a system that encodes one person's version and quietly breaks for everyone else.

Fix the process first, on paper, with the people who run it. Then automate the version everybody agrees on.

The volume does not justify the maintenance

A build has two costs: the one you pay once and the one you pay forever. The second is the one that gets left out of business cases.

An integration that touches three external systems will break when any of those three changes. Someone has to notice, diagnose and fix it. That is not a one-off cost, it is a standing commitment, and it does not scale down for low-volume processes. A workflow that runs eleven times a month can easily cost more to keep alive than it saves.

The rough test: if a person could do the whole month's volume in a day, automation is probably about convenience rather than economics. That is a legitimate reason to build something, but it should be argued as such rather than dressed up as savings.

Nobody owns the output

Automated systems fail quietly. A person who is behind on invoices tells you. A pipeline that silently stopped writing rows three weeks ago tells nobody, and you find out when someone asks why the numbers look wrong.

Before automating anything, name the person who will notice when it stops. Not the person who requested it, and not the vendor. Someone inside the business who looks at the output regularly enough to spot when it goes strange. If you cannot name them, you are not ready, because the failure mode of an unowned automation is worse than the manual process it replaced: you get wrong data instead of late data, and wrong data is harder to catch.

The hard part is judgement, not effort

Some tasks look repetitive but are not. Reviewing a contract is mechanical until the clause that matters is phrased unusually. Qualifying a lead is mechanical until the prospect is a strange fit that a human would recognise instantly.

If the value of the work sits in the exceptions rather than the volume, automation moves your costs rather than removing them. You save the easy 80% and hand your team a queue of the hard 20% with no context, which is often slower than doing all of it in sequence.

Where this does work is a human in the loop: the system handles the clear cases and escalates the rest with everything the reviewer needs to decide quickly. That is a different, more expensive build than full automation, and it should be scoped as one.

It is also worth being clear about what you are buying before you start. The distinction between an agent and an automation decides most of the cost, and the two are sold interchangeably.

The questions worth asking first

Before committing budget, get honest answers to these:

1. Can three people describe this process the same way?
2. How many times does it run per month, and what does one run actually cost in time?
3. Who will notice within a day if it stops working?
4. What fraction of cases need a judgement call, and what happens to those?
5. What breaks downstream if the output is wrong rather than missing?

If questions one to three do not have clean answers, the problem is not technical yet.

What to do instead

Not automating is rarely the end of the conversation. Usually one of these is the better next step:

• Standardise before you build. Get the process written down and followed consistently for a quarter. If it holds, automate it. If it does not, you have saved yourself a build.
• Automate one step, not the workflow. Document extraction is often the genuinely mechanical part of a process whose decisions are not. Take that piece and leave the rest.
• Fix the input. A surprising number of automation requests are really data quality problems. If the reason someone re-keys data is that the upstream export is unusable, fixing the export is cheaper than building a system to cope with it.

The rest of the workflow automation guides assume you have already been through this filter. If you would rather have someone else run it with you, that is what an AI readiness audit is for: the deliverable is a shortlist of what is worth building, which sometimes comes back empty.

Frequently asked questions

How do I know if my process is stable enough?

Ask three people who run it to describe the steps independently. If their answers match, it is stable. If they do not, write down the version you want, run it manually for a quarter, then revisit.

Is a low-volume process ever worth automating?

Yes, when the cost is not time. Compliance checks that must never be skipped, or steps where a human error is expensive, can justify a build at low volume. Argue it on risk, not on hours saved.

What if we already built something that is not being used?

That is usually an ownership problem rather than a technical one. Find out whether anyone was ever responsible for the output. Rebuilding without fixing that produces the same outcome twice.

Can we start small and expand later?

That is the right instinct, and it is why we scope prototypes before full builds. The thing to avoid is a prototype that quietly becomes production without anyone deciding it should.