Automate the handoff that the most people repeat the most often. Rank every manual task by how many people touch it times how many times a week it happens, then spend a week measuring the real minutes on the top row before anyone writes code. The winner is almost always a step that moves information between two people — boring but frequent, and easy to verify.
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?"
How do you decide which task to automate first?
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.
Interruptions are not free even when the work still gets finished. A 2008 study of interrupted work by Gloria Mark and colleagues found people completed interrupted tasks in less time, with no drop in quality — and paid for it in stress, frustration, time pressure, and effort. The time never shows up in a status report, so nobody counts it.
Multiply the two numbers and sort the list. The top row is almost never the task anyone complained about.
How long does the task actually take?
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.
Why start with the handoff instead of 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.
The first automation we shipped for a DTC retailer in early 2026 was exactly this kind of handoff. Their Google Shopping campaigns ran against whichever products had made it into the last manual feed upload. A restock or a new release could take days to reach the ads. The retailer and its agency both owned that upload, and neither had anyone who built automations, so it stayed a chore someone had to remember. We pointed the BigCommerce catalog — roughly 1,200 variants — at the Google Merchant API and let it sync every morning before anyone's at a desk. Then we did the same for Meta, Pinterest, and TikTok. Nothing in that job needs a judgment call. The payoff is one less feed that depends on someone remembering, and a campaign that can finally see the whole catalog.
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 does a good first automation look 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.
Fail loudly is the one worth designing for on day one. That same catalog sync can add and update, and that's all it can do. Deleting stays a manual step a person supervises. A partial fetch from the store would otherwise diff half a catalog against the live one and quietly pull hundreds of offers with no one watching. A job that stops and asks costs you a few minutes. A job that guesses can cost you the catalog.
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.