Frequency, not difficulty, decides what to automate first, the task you hate least is often the one worth fixing

Ask a team what to automate first and the answer comes quickly. They will name the task they hate most.

Almost always, that task happens rarely. The quarterly return. The annual audit pack. The year end reconciliation that ruins a fortnight. Genuinely miserable, genuinely infrequent, and worth roughly one afternoon a year once it is fixed.

Meanwhile the thing that runs twice a day gets no mention at all, because it is only mildly tedious and everybody stopped noticing it years ago.

Pain is memorable, frequency is expensive

The mismatch is not stupidity, it is how memory works. An unpleasant task leaves a mark. A dull one that takes eleven minutes every morning leaves nothing behind, because there was never a moment worth remembering.

The cost works the other way round. Time spent is duration multiplied by the number of repeats, and the number of repeats is the term that moves. A task that takes a full day but happens twice a year costs sixteen hours. A task that takes twenty minutes and happens every working morning costs around eighty. The second one has never been raised in a meeting.

Do the multiplication before you rank anything

The correction is not clever. It is arithmetic, and it takes an afternoon. For every candidate on the list, write down three numbers: how long it takes, how often it happens, and how many people do it.

Two things usually fall out. Something everybody wanted turns out to save four hours a year and drops off the list. Something nobody mentioned turns out to be the largest single line on it, and it is often also the simplest to fix, because small repeated tasks tend to be mechanical by nature.

Frequency has a second effect

Repetition does not only multiply cost, it changes the character of the work. A task performed twice a year is done carefully, because it is unfamiliar and everybody is paying attention. A task performed twice a day is done on autopilot, and autopilot is where errors come from.

So the frequent task is usually costing twice over. Once in the time it takes, and again in the mistakes it produces, which get found later by somebody else and cost more to unwind than they did to create.

Then ask who is waiting

Duration and frequency get you most of the way. The remaining factor is what sits downstream.

A ten-minute task that only affects the person doing it is a ten-minute task. A ten-minute task that three colleagues cannot start until it is finished, and which only gets done when that person next checks their inbox, is a queue. The elapsed cost of a queue has very little to do with how long the work takes.

This is why handovers, approvals and anything with the word request in its name tend to rank higher than their duration suggests. The work is trivial. The waiting is not.

Where the threshold sits

As a rough working rule, anything that happens twice a week or more is worth costing out properly. Below that, the arithmetic rarely justifies a build unless the task is long, error prone, or blocking other people.

It is a rule of thumb rather than a law, and the exceptions are honest ones. A quarterly task that takes three people a week each is worth fixing. A daily task that takes forty seconds is not. But as a first filter for a long list, frequency sorts it far better than irritation does.

What this looks like in practice

A useful version of the exercise: take your current list of automation ideas, in whatever document it lives in, and add three columns. Minutes per run. Runs per week. People affected.

Sort by the product of the first two, then move anything that blocks other people up a few places.

The order that comes out will not be the order the list was written in, and it will usually be uncomfortable, because the item at the top is rarely the one anybody was arguing for. That discomfort is the point. A list sorted by annoyance reflects who complained loudest. A list sorted by frequency reflects where the hours actually go.