The Pitch Is Always “Automate Everything”
Every automation project starts with the same slide: a messy, manual process on the left, a clean arrow on the right. Hours saved, errors gone, people freed up for better work. Sometimes that’s exactly what happens. But the slide never shows the part in the middle — the exceptions, the workarounds, the person who quietly knew what to do when an invoice looked odd.
Automation doesn’t remove that knowledge. It removes the place where it was being used. The task gets faster, the dashboard looks better, and somewhere downstream a problem that used to get caught at step two now turns up at step nine, with a customer attached.
What Makes a Process Worth Automating
The processes that automate well are usually unglamorous. They happen often, follow the same steps almost every time, have a clear definition of “done,” and fail in ways that are cheap to spot and cheap to fix — moving data between two systems, sending a reminder, building the weekly report, routing a ticket to the right queue. Nobody’s judgment is being used up on them; it’s only time.
A simple test: if you can write the steps down, and a new hire could follow them without asking a single question, you’re probably looking at a good candidate.
The Process That Gets Worse Quietly
The ones that don’t automate well look similar from the outside. A customer escalation, a pricing exception, a hiring screen, a refund that doesn’t quite fit the policy — each is mostly routine, right up until it isn’t. The routine bulk is exactly what makes the business case look good, and the unusual remainder is where a person’s judgment was hiding all along.
Automate the whole thing and you end up with something fast that handles the easy cases well and the hard ones confidently wrong. Nobody sees it happen, because the point of automating was that nobody had to be looking.
Measure the Whole Job, Not the Step
Part of why this goes unnoticed is how success gets counted. Time saved per task is easy to measure. Rework, complaints, and the slow loss of trust in the output are not — they land in other teams’ numbers, weeks later.
So the honest test for any automation isn’t “did the step get faster.” It’s “did the outcome at the end get better, and who is checking?” A process with no one looking at the result isn’t automated. It’s unsupervised.
Where This Leaves Us
The useful question isn’t “what can we automate,” because the answer is almost always more than you should. It’s “what are we sure we’d do the same way a hundred times in a row?” Start there, keep a person on the exceptions, and let the list grow only as fast as the checking does. Automation works best as a decision about what to hand off — not a target to hit.