Lesson 23: Automate One Manual, Repetitive Step
For most of my career I had automation backwards. I thought it was something you earned once you got big enough – a thing for companies with platform teams and budget lines. Then I watched a support rep do the same twelve-second copy-paste forty times in a morning, and I understood I’d been thinking about it wrong the whole time.
Automation isn’t about scale. It’s about consistency. A human doing the same small task forty times will get it right thirty-eight times. The machine gets it right forty. Those two misses are where your Friday night goes.
The Rule: Automate the Boring Thing, Not the Impressive Thing
Here’s where teams waste months. Somebody suggests automating the thing that looks worst – the gnarly, high-stakes, once-a-quarter process everybody complains about. It’s complicated, it has fifteen edge cases, and by the time it ships the process has changed anyway.
Meanwhile the actual money is sitting in a task so boring nobody thinks to mention it.
The filter I use now has three parts. The step happens at least five times a week. It’s error-prone, meaning a tired person gets it wrong sometimes. And it has a clear input and a clear output – you can describe it in one sentence without using the word “depends.”
If a task fails any of those three, leave it alone for now. You’re not ready.
A Real Example: Forty Percent, From One Morning’s Work
A support team I worked with had a billing escalation process that everyone accepted as just how it was. When a billing query came in, the rep opened the CRM, opened the billing system, opened the internal wiki, and hand-copied nine fields into a ticket template. Account number, plan tier, last payment date, and so on.
Nobody had ever raised it as a problem. It wasn’t a problem. It was just Tuesday.
We timed it. Eleven minutes per ticket, roughly thirty tickets a week. And because it was nine fields typed by hand under time pressure, something was wrong on about one ticket in six. Usually small – a transposed account number, a stale payment date. Small enough that finance caught most of them, which meant finance was spending time on it too.
A developer built the fix in a morning. One button in the CRM that pulled the nine fields from the canonical source into the ticket template.
Time per ticket dropped roughly forty percent. Field errors went to almost nothing. But the thing I didn’t predict was what it did to the reps. They stopped dreading billing tickets. Somebody had finally noticed the boring part of their job and done something about it, and the mood in that team shifted in a way no engagement survey would have picked up.
How To Do This Yourself
Give it a week and follow this:
- Ask your team one question: “What’s the most annoying thing you do more than once a day?” Don’t ask what’s broken. Ask what’s annoying. Different answers.
- Take the top three and time them properly. Not estimates – actually time them. People are terrible at estimating tasks they hate.
- Score each one on frequency, error rate, and whether the input and output are clean. Pick the highest score, not the one that sounds most impressive.
- Write down the current numbers before you touch anything: minutes per run, runs per week, error rate. If you skip this you’ll never be able to prove the thing worked.
- Build the smallest version that works. A template. A script. A form that pre-fills. It does not need to be elegant.
- Have a rollback. If the automation breaks, people need to know how to do it by hand, and that fallback needs to be written down somewhere they can find at 6pm.
Then measure the same three numbers again after two weeks and tell the team what changed.
The Honest Lesson
I’ve also seen automation go badly, and I’ve been the cause of it more than once.
The failure mode is automating something before you understand it. You take a messy manual process, wrap a script around the mess, and now you have a fast mess that nobody can debug. The person who understood the manual version has moved on, the script has no owner, and eighteen months later somebody is afraid to touch it.
So automate second. Map first, stabilize, then automate the step you now genuinely understand. That ordering is the whole reason this lesson sits at twenty-three and not at three.
And be honest about ROI. A morning of developer time to save four hours a week is obvious. Three weeks of developer time to save twenty minutes a week is a hobby, not an improvement. If you can’t write the payback period on one line, you haven’t thought about it hard enough.
Pick your most boring repeated task this week. Time it. Then decide whether it deserves a morning of somebody’s attention.
Next time, I’ll dig into “Re-align Incentives: Make the Signal Matter in Decision Forums” – see you there.