Most teams pick the wrong first automation. They pick the loudest one — the thing someone complained about in a meeting — or the most impressive one, because a demo is easier to get budget for than a fix. Both choices tend to produce an automation nobody uses six weeks later.
The better question is not "what is annoying?" It is "what is repeated by the most people, most often?"
Count the people, then count the repetitions
Write down the tasks your team does by hand every week. For each one, note two numbers: how many people touch it, and how many times a week it happens.
A task done by one person forty times a week is a personal workflow. Automating it helps one person and breaks when that person changes their process. A task done by nine people twice a week is a system. Automating it removes eighteen interruptions, and the shape of the work is already agreed on, because nine people are doing it the same way.
Multiply the two numbers and sort the list. The top row is almost never the task anyone complained about.
Measure the hours before you build anything
Estimates are wrong in a predictable direction: people underestimate work that is fragmented and overestimate work that is concentrated. A task that takes four minutes but happens eleven times a day feels smaller than a task that takes an hour once a week, and it is not.
Before you build, have the people doing the task track it for one week. Actual minutes, not remembered minutes. You will get two things out of it. First, an honest baseline you can point at later when someone asks whether the automation was worth it. Second, and more useful, you will find out the task is not one task. It is usually three, and only one of them is worth automating.
Start with the handoff, not the work
Here is the pattern we see most often. The interesting part of a job — the judgment, the writing, the decision — is already fast. What takes the time is moving the result from one place to another. Pulling numbers out of one tool so they can be pasted into another. Renaming a file so the next person can find it. Telling someone the thing is ready.
Those handoffs are boring, which is exactly why they are the right first target. They have no judgment in them, so an automation cannot get them wrong in an interesting way. They have clear inputs and outputs, so you know within a day whether it works. And they sit between two people, which means two people notice immediately when it breaks.
Automating judgment is possible and sometimes worth it. It is a bad place to start, because when it is wrong you will not find out for weeks.
What a good first automation looks like
It should be finished in under two weeks. It should replace something you can measure, so you can say what changed. It should fail loudly rather than quietly. And someone on your team should be able to read it and understand what it does without asking you.
If your first automation clears that bar, the second one gets easier — not because the work is simpler, but because the team now believes the next one will land. That belief is most of what determines whether you get to a fifth one.