Find the Repetitive Part: How to Spot Work Worth Automating

The usual failure is not technical. Someone automates the most annoying task rather than the most repetitive one, spends a week on it, and saves eleven minutes a month.

Annoying and repetitive feel the same from the inside. They are not the same thing.

The four questions

Before you automate anything, run the task through these. A good candidate answers yes to all four.

1. 01Do I do this at least weekly? Monthly tasks almost never repay the setup.
2. 02Is the input predictable? Same shape of data, same place, most of the time.
3. 03Is a mistake cheap and visible? If a bad output goes out unnoticed and costs you a customer, this is the wrong first project.
4. 04Could I describe the steps to a new hire in under five minutes? If not, you do not understand it well enough to hand it off yet.

That third question does most of the work. The best first automations are ones where you see the output before anyone else does — drafting, sorting, extracting, summarising. The worst are ones that touch a customer without a human in between.

Start with one step, not the whole flow

A weekly report might involve pulling numbers, spotting what changed, writing the commentary, and sending it. That is four tasks wearing a trench coat. Automate the one that is most mechanical — usually the extraction — and keep doing the rest by hand.

This is unsatisfying and it is correct. A partial automation you trust beats a complete one you have to double-check every time, because the double-checking is the cost you were trying to remove.

Decide in advance how you will notice it broke

Every automation eventually breaks quietly. The source format changes, an assumption stops holding, and the output keeps arriving — just wrong. Before you ship it, answer: what would I see if this stopped working correctly?

• —A number that should never be zero.
• —A row count that should be roughly stable week to week.
• —A step that fails loudly rather than skipping silently.

If you cannot answer that question, you have not built an automation. You have built a thing that will lie to you at an unknown future date.

Know when to step back in

Write down the conditions under which you take the task back: volume above some threshold, an input that does not match the usual shape, anything customer-facing during a bad week. Handing off a task is a decision you should be able to reverse on purpose rather than in a panic.

Automate the boring middle. Keep the judgement at both ends.

Coursium covers both halves of this: wiring a tool into work you already do, and handing off the repetitive parts without losing the thread.