Automation amplifies whatever process it sits on top of. If the underlying process is unstable, judgment-heavy, or rarely run, the wrong move is to encode it in software. Six situations where the right answer is to leave it alone.
Most articles about automation are about what to automate. This one is the opposite. There are workflows where automating makes the situation worse, and recognizing them up front saves real money.
Six situations where automation is the wrong answer
1. The process is changing. A workflow that gets revisited every couple of months is not ready to be encoded in software. The build will be out of date before it pays back. The tell here is when nobody on the team can confidently describe what the workflow looks like today, because it keeps shifting under their feet. Stabilize the process first. Automate it second.
2. The decisions inside it need human judgment. If most of the steps are mechanical but one of them requires reading nuance, weighing trade-offs, or making a call only a senior person can make, that one step is the bottleneck. Automating around it does not remove the bottleneck; it just builds expensive scaffolding around a slow part. Either the senior judgment is the actual product, in which case it should not be automated, or the judgment can be unbundled into clearer rules, in which case the rules need to be written down before any code gets written.
3. The volume is too low. A workflow that runs ten times a year does not justify a build, no matter how annoying it is each time. The math is simple: build cost divided by occurrences per year, divided by the time saved per occurrence. If the payback is longer than two years, automation is the wrong tool. A checklist, a template, or a scheduled assistant might do the same job for free.
4. The cost of getting it wrong is too high. Automation will, eventually, be wrong about something. If “wrong” means a tactless email goes to the right person, that is fine. If “wrong” means a six-figure invoice gets approved without review, or a regulatory deadline is missed, or a patient gets the wrong reminder, the system should not be running without a human between it and the consequence. Some workflows need automation up to a checkpoint, then a human, then automation again. Designing that is harder than designing fully automated end-to-end, but it is the right design for high-stakes work.
5. The team will not maintain it. Every automation has a small ongoing maintenance cost. APIs change. Rate limits get hit. Tools change pricing tiers. If there is no one on the team who will keep an eye on the system, the automation will quietly degrade and eventually break. A broken automation is worse than the manual process it replaced, because the team has stopped paying attention to the work and the failure goes unnoticed for too long. Either the team commits to ongoing care, or someone external is paid to do it. Without one of those, do not build.
6. The underlying process is broken. Automation amplifies whatever process it sits on top of. If your sales hand-off is dysfunctional, automating it makes the dysfunction faster. If your customer support is structurally undertrained, automating triage spreads the undertraining. The temptation to “fix it with software” instead of fixing the actual problem is one of the most common reasons automation projects fail to deliver. The build was sound; the foundation it was sitting on was not.
The pre-build conversation we keep having
A typical audit call surfaces somewhere between five and ten candidate workflows. Two or three of them are usually in one of the categories above. Saying so up front, before any build, prevents the disappointment that comes from delivering a working automation on top of a broken process.
The right answer for those workflows is sometimes “redesign first, then revisit”. Sometimes it is “leave it alone, the volume is too low”. Sometimes it is “this is the human part of your business and should stay that way”. The point is that not everything that can be automated should be, and the people you want to work with are the ones honest enough to say so before the invoice arrives.
That conversation, more than any specific build, is what saves SMEs the most money in the long run.