Automation has a marketing problem: it’s sold as always-good. In practice, automating the wrong task makes an operation more fragile, not less. You take something a person handled flexibly and freeze it into rules that break the first time reality doesn’t match the assumptions. The skill isn’t automating as much as possible — it’s knowing which work is actually worth automating.
What makes a task a good candidate
The repetitive work most worth automating usually shares a few traits:
- It’s frequent. Something done many times a day returns your investment quickly; something done twice a year rarely does.
- It’s rule-based. The steps are consistent and the decisions are clear. “If this, then that” — not “it depends on judgement.”
- It’s error-prone by hand. Copying data between systems, re-keying numbers, chasing the same updates — exactly the work humans do worst and resent most.
- It’s stable. The process isn’t about to change. Automating something you’re still figuring out just means rebuilding it repeatedly.
What to leave alone
Some work looks automatable but shouldn’t be. Tasks that need judgement, empathy or context — handling an unhappy customer, deciding an exception, reading a situation — lose something important when forced into rules. Infrequent work rarely justifies the build and maintenance. And a process that’s still changing shape every few weeks isn’t ready; automate it once it’s settled.
A good rule of thumb: automate the parts that are tedious and certain, and keep a person on the parts that are rare or need judgement.
The cost nobody mentions: maintenance
Every automation is a small system that now has to keep working. APIs change, edge cases appear, a supplier renames a field. Unattended automation that fails silently is worse than the manual process it replaced, because no one notices until the damage is done. Good automation includes error handling, alerts when something breaks, and a human who owns it — not just a script that ran once in a demo.
Find the work first
The best way to spot automation worth doing is to watch where people complain about the same task every week. Ask the team: what do you do over and over that a machine could do more reliably? Where do you copy the same information twice? What breaks when one person is away? Those answers point to real opportunities far better than a tool’s feature list.
Start small and prove it
Pick one painful, well-understood task. Automate it, measure whether it actually saved time and reduced errors, and keep a manual fallback until you’re confident. A small win that genuinely works builds more trust — and teaches you more — than an ambitious automation programme that tries to change everything at once. When we take on automation work, that’s where we begin: the smallest change that proves the value.