Insights / Scoping
What not to automate
Four categories of work where automation reliably costs more than it saves, and the questions that identify them before anyone writes code.
The most useful outcome of a scoping conversation is sometimes the conclusion that nothing should be built. That is an unusual thing for a technology practice to say, so it is worth explaining why it is the correct answer more often than the industry admits, and how to recognise the cases where it applies.
Automation has a fixed cost that does not scale down. Every automated process needs to be built, connected to systems that authenticate, monitored, documented, and maintained as the things around it change. That overhead is worth paying when the task is frequent, stable, and expensive. It is a bad trade in at least four situations.
1. Work that is genuinely infrequent
A task performed twice a year taking two hours costs four hours annually. Automating it might take fifteen hours to build properly, plus ongoing maintenance, and the intervals between runs are long enough that upstream systems will have changed by the next execution. The automation will need repair more often than it will run.
There is a specific trap here worth naming. Infrequent tasks often feel disproportionately painful because they are unfamiliar and disruptive when they arrive. That pain is real, but it is a pain of context-switching rather than of hours, and automation addresses the hours. A checklist usually fixes the actual problem for a fraction of the cost.
2. Processes that are about to change
If a business is mid-migration between platforms, restructuring a team, or reconsidering how a function operates, automating the current process encodes a workflow with a known expiry date. Worse, it creates resistance to the change that was already coming, because now there is something built around the old way.
The scoping question is direct: is this process going to look the same in twelve months? If the honest answer is no, or nobody knows, the right move is to wait for it to settle. A process that is still being argued about is not ready to be encoded in software.
A related case. Sometimes the process should change and automating it would prevent that. If the work exists only because two teams do not share information, or because a form asks for something nobody uses, the correct intervention is to remove the step. Automating unnecessary work makes it permanent and cheap enough that nobody questions it again.
3. Judgment work wearing a procedural disguise
Some tasks look mechanical from the outside and are not. A person reviewing applications may describe their work as checking whether criteria are met, when what they actually do is weigh ambiguous cases against context accumulated over years. Ask how many are straightforward and the answer is often around eighty percent, which sounds like a strong case for automation until you examine the remaining twenty.
If the exceptions are where the value sits, and the routine cases are quick precisely because they are routine, automation captures the cheap part of the job and leaves the expensive part untouched. Meanwhile the reviewer now has to check the automated output, which is a new task.
The distinguishing question is whether two experienced people performing this task would reach the same answer. If they would, it is procedural and a candidate. If they would reasonably differ, it is judgment, and encoding one person's judgment as a rule produces a system that is confidently wrong in the cases that matter most.
4. Anything where a quiet error is expensive
Some categories of work carry consequences that make silent failure unacceptable regardless of how well the system is built. Regulated recordkeeping, controlled inventory, safety documentation, and anything with legal weight fall here. This is not an argument that these domains cannot benefit from automation. It is an argument that the failure mode changes what can responsibly be delegated.
In practice the useful split is between the system doing preparation and a person confirming. Assemble the record, surface the discrepancies, prefill the form, flag what looks anomalous, and stop. A human confirms and commits. That captures most of the time saving while keeping accountability where it needs to sit, and it is a materially different design from a system that files on its own.
The questions that surface these early
Four questions asked before any build reliably identify most of the above.
- How often does this actually run, and how long does one instance take? Not how long it feels like. The number, in hours per month.
- What happens today when it goes wrong, and who notices? This surfaces both the real failure modes and whether anyone is monitoring the manual version either.
- Would two experienced people handle every case identically? The judgment test.
- Is this process stable, or is it under discussion? The expiry test.
A scoping conversation that ends in a recommendation not to build is not a failed conversation. It is a finding, and it is worth considerably more than a system that gets switched off in month four.