When to automate a workflow, and when to leave it alone

Automation projects tend to start with "can this be automated" rather than "should it be." Almost anything repeated can be automated given enough time and budget. The better question is whether the volume, the error cost, and the stability of the process actually justify it — a task done three times a week by one person who already does it well is rarely the highest-value place to start, even if it's the easiest one to picture as a flowchart.

A simple way to sort the candidates

Three things matter more than how "manual" a task feels: how often it happens, how costly a mistake is if it's missed or done wrong, and how often the process itself changes. High frequency, high cost of error, and a stable process — invoice generation, stock-level alerts, appointment reminders — is the clearest automation case. Low frequency or a process that changes every few months is usually not worth the build cost yet, however tedious it feels in the moment. And anything that depends on judgment calls a system can't reliably make — assessing whether a customer complaint is serious enough to escalate, deciding how to phrase a sensitive message — should generally stay with a person, with the system handling the reminder and the paperwork around it rather than the decision itself.

The cost nobody budgets for

The build is usually the easy part to estimate. The ongoing cost — someone has to notice when the automated step fails silently, someone has to update it when the underlying process changes, someone has to be the person who understands it when the original builder has moved on — is the part that gets skipped in the planning conversation and shows up eighteen months later as "nobody knows why this stopped working." A workflow worth automating is one stable enough, and important enough, to be worth that ongoing ownership — not just one that's annoying to do by hand this week.