How to Pick Which Task to Automate First

At a licensed apparel company a sales lead showed me how a pricing deck gets built. Pull the product list, apply the current pricing tier, format it, check it, send it. About ten to twelve minutes each time.

Ten minutes is nothing. Nobody has ever asked for help with a ten-minute job.

Then I asked how often. Several a day, across the team, all year.

That is the whole calculation, and it is the one most companies get backwards.

Complaint volume is a bad ranking signal

Every discovery produces a wish list, and the wish list is sorted by irritation. Top of it is always the quarterly thing that ruins somebody's weekend four times a year. Board pack. Annual audit prep. The commission reconciliation everyone dreads.

Those are real. They are also, almost always, a bad first build.

A task done four times a year gives you four chances a year to find out the automation is wrong. You will be debugging it in the same conditions that made it painful in the first place, under deadline, a year later, with nobody remembering how it works. And the total time it consumes, which is what you are actually buying back, is small.

Meanwhile the ten-minute job that happens six hundred times a year is a hundred hours. It has never been complained about once, because ten minutes never feels like anything.

The arithmetic

Frequency times duration. That is it.

Do it for every candidate before you rank them, and the list reorders itself, usually dramatically. The thing at the top is rarely the thing anyone nominated.

Two adjustments worth making.

Count the people, not the person. Ten minutes for one rep is a hundred hours a year for a team of six. The person telling you about it only sees their own share, and their share sounds trivial to them.

Count the switching, not just the task. The clock does not start when they open the file. It starts when they stop what they were doing, find the last version, remember the convention, and finish. And it keeps running afterwards, while they find their place in whatever they dropped. That tail is real and it is why timed observations come out higher than estimates.

Frequency is also what makes a build safe

There is a second reason the frequent task wins, and it matters more than the arithmetic.

A system that runs six hundred times a year is a system you will actually understand. Failures show up within days. Edge cases arrive early, while the people who built it are still around. The person using it develops a feel for when the output looks wrong.

A system that runs four times a year is a system nobody trusts and nobody remembers. By the third run, the person who commissioned it has left, and the output gets checked by hand anyway, which means you are paying for the automation and doing the work.

Build the thing that runs constantly. It teaches you the company. Then use what you learned to go after the quarterly monster, with a team that now believes you.

What this looks like in practice

We built a generator for that pricing deck, with a target of about a minute per deck, and that minute is a person checking the deck rather than building it. It is a target, not a measurement. Nobody has timed it yet, and I will not quote it as a result until someone does.

It was not the hardest thing we built for them and it was not the most impressive in a demo. It was the one the sales team noticed within a week, because the job comes up several times a day, every day, and each time it starts from a finished draft instead of a blank file.

That is the other thing frequency buys you. Adoption. Nobody needs convincing to use a thing that takes a ten-minute job off them this morning and again this afternoon.