What You Should Automate First

Almost everybody picks wrong

Given the ability to automate something, most people reach for the most interesting task on their list. It is usually the one they do twice a year, involves four departments, and would need reviewing line by line anyway. They spend an afternoon on it, it half works, and they conclude automation is overrated.

The interesting task is almost never the right first task. The right first task is dull, frequent, and slightly irritating. Here is how to find yours.

The rough arithmetic

Frequency times annoyance, minus the cost of checking it. That is the whole method, and it is deliberately crude because a precise model would take longer than the task.

Frequency is the multiplier that matters most. Something you do twelve times a month has twelve chances a month to pay you back. Something you do twice a year has two chances a year, and by the second one you will have forgotten how you set it up. If it happens less than monthly, leave it alone for now.

Annoyance is not a soft factor. A task you resent is a task you delay, and delayed tasks cost more than their ten minutes. The Friday summary that slips to Monday is not a ten minute job any more, it is a ten minute job plus an awkward conversation.

The subtraction is where most enthusiasm goes to die. If the output needs a full careful read against the source before you can trust it, you have not saved much. You have swapped writing for proofreading, which for many people is the worse job. The tasks worth automating first are the ones where a quick scan is enough to tell whether the result is sound.

Below is a list of small recurring tasks I do. For each one, ask me nothing
and instead score it out of 5 on three things, then rank them.
FREQUENCY: how often it happens, based on what I have written.
ANNOYANCE: how tedious it sounds.
CHECKING COST: how carefully a human would have to verify the result,
where 5 means it needs a full line by line review.
Score = (frequency x annoyance) - (checking cost x 2).
Show the table, then name the single task I should automate first
and say in two lines why the runner up is worse.
Flag anything where a wrong answer could be expensive.
MY TASKS:
[list them, one per line]

What a good first candidate looks like

The two traps

The rare task. Annual and quarterly jobs feel like the biggest prizes because they are the most painful when they arrive. They are also the worst candidates, because you build the automation while the pain is fresh and then it sits untouched for eleven months, quietly going out of date. Everything it referred to has changed by the time it runs again. Write yourself a good checklist for those instead.

The expensive mistake. If a wrong result costs money, breaks a rule or damages a relationship, you will review it fully every time. That is correct behaviour and you should not talk yourself out of it. But it means the automation saves you a first draft and nothing more. Anything touching pay, pricing, legal commitments, safety or a person's employment sits in this bucket. Automate the preparation around them if you like, never the decision.

Find your candidates

Most people cannot list their own recurring tasks from memory, because the small ones are invisible by design. Work backwards from where your time actually went.

Here is a description of a typical fortnight of my work, plus my calendar titles.
Find the tasks that repeat. I am looking for the small dull ones I have stopped
noticing, not the big projects.
For each repeat: what it is, roughly how often, and whether it produces
something (a document, a message, a list) or is purely a decision.
Then tell me which three are the best candidates to set up on a schedule
and which one I should definitely not automate, with a reason.
MY FORTNIGHT:
[paste calendar titles and a few lines about what you did]

Once you have a candidate, write it up properly before you schedule it. Half of the value of this exercise is being forced to say exactly what good output looks like.

Help me specify a recurring task before I schedule it. Ask me each question
one at a time and wait for my answer.

What exactly comes back, in what sections and what length?
Where does the information come from, and is that source always available?
What should happen if the source is empty or unchanged?
What would a wrong version of this cost me?
How would I notice if it silently stopped running?
At the end, write the finished instruction as a single block I can copy,
including the rule for empty input.

Question five is the one everybody skips, and it is the entire subject of the next lesson.