Most people selling automation have an incentive to tell you everything should be automated. I don't, so here's the version with the caveats left in.
A quick self-test before you build anything
Three honest questions, before any of the four reasons below. Has this process stayed the same, in practice, for at least a couple of months? Does it happen often enough that a person doing it manually actually notices the time cost? And does everyone who touches it agree, without an argument, on what "done correctly" looks like? A genuine "no" to any of these is worth pausing on before a single automation gets built.
The process isn't stable yet
Automating a workflow that's still changing every few weeks just means rebuilding the automation every few weeks. Worse, it bakes the current, half-finished version of the process into something rigid — and a broken process automated is a broken process that now breaks faster, at scale, before anyone's had the chance to fix the actual problem. I'd rather watch a client run something manually for one more month and get it right, than automate this month's version and quietly redo it three times before it settles.
There isn't enough volume to justify it
If a task happens four times a month, the build cost and the ongoing maintenance of automating it can easily outweigh doing it manually for the next year. Automation earns its cost through repetition. A low-volume, occasional task rarely clears that bar, no matter how satisfying it would be to never think about it again. This is the one clients push back on most, because "I never want to do this again" feels like a good enough reason on its own. It isn't, if the honest maths says the build costs more than the years of manual effort it's replacing.
The team hasn't agreed on the process it's automating
Automating a disagreement doesn't resolve it — it just locks in one person's version of "how we do things" in code, and creates a new argument every time reality doesn't match what the system assumes. I've seen a build get commissioned specifically to force agreement, on the theory that once it's automated one way, everyone will fall in line. It doesn't work like that. People route around a system they disagree with just as readily as they route around a policy they disagree with. Alignment has to come before the build, not after it.
The judgment call genuinely needs a human
Not every decision benefits from being faster. Some deserve someone actually thinking about them — a pricing exception, a difficult client situation, a call that depends on context a rule can't see. Forcing a judgment call into a rule-based flow to make it "efficient" trades a good decision for a fast, mediocre one. Speed isn't free if it costs you the judgment that made the decision worth making correctly. The right answer here usually isn't "don't automate this at all" — it's "automate the parts around the decision, and leave the decision itself with the person who should be making it."
What automation earns back, when it is the right call
None of this is an argument against automation generally — the rest of this site is built on the opposite case. It's an argument for sequencing. The businesses that get the most out of automation aren't the ones that automate first and figure out the process later. They're the ones who already have a process worth repeating, in enough volume to matter, that everyone actually agrees on — and who then remove the manual labour of running it, rather than the thinking behind it.
What I recommend instead, in these cases
Fix the process on paper first. Run it manually until it's genuinely stable and everyone actually agrees on how it works, not just how it's supposed to work. Only automate what's proven to repeat the same way, in the same order, most of the time — because that's the part a system can actually get right.
The honest pitch isn't "automate everything." It's "automate what's actually ready to be automated," and be told plainly when something isn't.