What to Automate First (And What Never To)

The task you most want to automate is usually the one that irritates you most. That's a feeling, not a ranking, and it produces a common outcome: three weeks building something that saves twenty minutes a month.

The honest ranking is frequency × stability, adjusted for what it costs to maintain.

Score the candidates

List every recurring task. For each, score three things 1–5:

| Factor | 1 | 5 | |---|---|---| | Frequency | A few times a year | Daily | | Stability | Changes most times you run it | Identical every time | | Time per run | Under two minutes | Over an hour |

Multiply. Then subtract for maintenance: does it depend on a tool that changes often, an integration that breaks, or a format someone else controls?

High frequency and high stability wins, almost regardless of how much you dislike the task. A ten-minute job you do daily is 40 hours a year. A two-hour job you do quarterly is eight.

That ordering is frequently the opposite of the emotional one, which is the point of doing it on paper.

Document before you automate

The rule that prevents most wasted automation work.

If you haven't run it manually enough to document it, you don't know what it is. You know the version you remember, which omits exactly the fiddly exception handling that makes the automation fail in week two.

So: run it, write the SOP, stabilise it, then automate. The SOP becomes the specification — and if writing it is hard, that's the signal the process isn't stable enough yet.

Automating an undocumented process means encoding your mistakes and making them faster and harder to see.

Count the maintenance

Every automation is a small system you now own. It breaks when an API changes, a tool updates its interface, a field gets renamed, or someone changes the spreadsheet it reads from.

Before building, ask:

• Who owns this when it breaks? If the answer is "nobody thought about that," it will break silently.
• How will you know it broke? Silent failure is the worst mode — an automation that quietly stops is worse than a manual task that visibly doesn't happen.
• What does it cost monthly? Tool subscriptions accumulate quietly.

A reasonable rule: if maintaining it will cost more than a quarter of the time it saves, it isn't worth building.

What should stay manual

Four categories, and the discipline is in leaving them alone.

Judgement. Anything where the right answer depends on context you can't encode — pricing exceptions, whether to take on a client, how to handle a complaint that isn't standard.

Exceptions. Automate the predictable middle and route the rest to a person. A process that handles 85% of cases cleanly and escalates 15% is far better than one that tries for 100% and mangles the hard ones.

Relationships. Automated personal contact reads as automated, and it costs more credibility than it saves time. Templates to help you write are fine; templates that send themselves as if you wrote them are not.

Rare things. A task that takes two minutes twice a year should be left alone. Some things are genuinely cheaper by hand, and the instinct to automate everything is its own kind of waste.

The usual first three

For most small businesses, the highest-return early automations are unglamorous:

1. Invoicing and payment chasing. High frequency, highly stable, and the manual version gets skipped when you're busy — which is exactly when cash matters.
2. Appointment scheduling. Removes an entire email thread per booking.
3. Recurring reporting. Anything you assemble the same way every week or month.

None of them is interesting. All of them pay back quickly, which is the actual criterion.

Start smaller than feels worthwhile

The most common failure is scope. Someone decides to automate "client onboarding," which is eleven steps across four tools, and abandons it half-built three weeks later.

Automate one step. Get it working and running reliably for a fortnight. Then the next.

Partially-built automation is worse than none — it's a process that works differently depending on which parts ran, and nobody is sure which those were.

The mistakes

1. Automating by annoyance. Ranks the wrong things first.
2. Automating before documenting. Encodes the mistakes at speed.
3. Ignoring maintenance. The build is the cheap part.
4. No failure alerting. Silent breakage is the worst mode.
5. Automating judgement. Produces confidently wrong outcomes.
6. Scoping a whole process. Abandoned half-built, leaving something worse than manual.

What to do next

List every task you did more than weekly last month and score each on frequency, stability and time. The top of that list is where to start — and it's frequently not the task you'd have picked.

Then before building anything, map the process properly.