Automation has an ongoing cost
The build cost is visible and gets estimated. The ongoing cost usually does not: an automation is a small piece of infrastructure that has to be monitored, updated when an upstream changes, re-credentialed, and understood by whoever inherits it.
That cost is worth paying many times over for the right workflows. For the wrong ones it quietly exceeds the manual effort it replaced, and it does so in a form nobody is tracking.
Frequency has to clear the maintenance bar
A task done twice a year takes a few minutes each time. Automating it costs a day to build and then needs to still work six months later, by which point the upstream API has moved and nobody remembers how it was set up.
The arithmetic that matters is not build cost against time saved. It is build cost plus maintenance against time saved over a realistic horizon. Low-frequency tasks frequently lose that comparison, and the honest answer is a good checklist instead.
Unstable rules are a moving target
If a process changes shape every few weeks — new exceptions, new approvers, a rule that depends on this quarter's priorities — automating it means rebuilding it every few weeks.
Wait for it to settle. A process that has held its shape for a few months is a candidate. One still being argued about is a specification that has not been written yet, and encoding it just moves the argument into a tool where it is harder to see.
Judgement-heavy work resists the useful part
Some tasks look repetitive but are actually a person applying context each time — knowing this client is sensitive about timing, that this request is a follow-up to a bad experience, that the exception is warranted this once.
Automating the mechanical shell of that work while removing the context usually produces something technically correct and situationally wrong. The better move is to automate the parts around it: assemble the information, draft the option, and leave the decision with the person.
- Does the same input reliably produce the same correct output?
- If not, what is the person using that the system would not have?
- Can that context be supplied, or does it live in their head?
- What does being wrong cost here?
No owner means no automation
If nobody will own it after launch, it should not be built. Unowned automation does not fail immediately — it fails in three months, invisibly, and whoever depends on it discovers the failure downstream of some other problem.
"Owner" here means a specific person who would be told if it stopped, not a team name. If that person cannot be named before the build starts, that is the answer.
Documenting beats automating more often than people expect
A written procedure with the exact steps, the actual field values, and the edge cases is fast to produce, needs no credentials, does not break when an API changes, and can be followed by anyone.
For infrequent, unstable, or judgement-heavy work it is usually the better tool. Choosing it is not a failure to automate. It is the same analysis, reaching a different answer — and it leaves the automation budget for the workflows that will actually repay it.
Ask what the process is for before automating it
Some steps exist because of a constraint that no longer applies — a system that was replaced, an approval for a risk that has passed, a report nobody reads. Automating those makes a redundant step permanent and harder to remove, because it is now in a tool rather than in a habit.
Before building, ask what each step is for and who consumes its output. The answer is occasionally that nobody does, and deleting a step is a better outcome than automating it.
Partial automation is a real answer
The choice is not between fully automated and fully manual. Most of the value often sits in the boring middle: gather the information, pre-fill the form, assemble the draft, then stop and let a person decide.
This shape is cheaper to build, much cheaper to maintain, and keeps judgement where judgement belongs. It also tends to be where the actual time goes — the decision is usually quick, and the gathering is what takes twenty minutes.
Beware the process that is really a conversation
Some workflows look like data movement and are actually negotiation: chasing a late invoice, handling a complaint, agreeing a delivery date. The steps can be described, but what makes them work is the person reading the situation.
Automating the visible steps while removing the reading produces something technically correct and relationally wrong. Automate the record-keeping around the conversation instead, and leave the conversation alone.
Write the decision down either way
Whichever way it goes, record it: what was considered, what was decided, and why. Otherwise the same proposal returns every six months and gets re-argued from scratch by people who do not know it was already examined.
A short note saying "we looked at automating this in March and chose a checklist because it runs twice a year" saves that whole conversation, and makes it easy to revisit properly if the frequency changes.