The best first task to automate is one that happens at least weekly, takes real time, has a clear definition of done, and produces something a person then picks up and uses. Start there rather than with your biggest or most painful process, because a first automation needs to prove itself quickly, and complex processes take too long to show whether they worked. The strongest signal is simple: find the job someone on your team quietly dreads doing every week.
Why the first one matters more than the rest
The first automation in a business does two jobs. It removes some work, and it settles an argument. Most teams carry quiet scepticism about this sort of thing, usually earned from a previous attempt that took months and changed very little. A first automation that works quickly and visibly resolves that, and everything afterwards gets easier. A first automation that drags on, half works, or solves something nobody cared about confirms the scepticism, and the next attempt is harder than the first.
So the selection criteria aren’t only about which task is technically easiest. They’re about which task will produce a clear answer fastest.
If you’re weighing whether the task needs an AI agent or straight automation, the guide to what an AI agent is draws that line. The rest of this piece is about which task to pick, whichever tool you land on. It’s also the logic behind our First Build Free offer: one task, built inside a month, running on your real work, so you get the answer quickly rather than a year in.
The five questions to ask
Does it happen at least weekly?
This is the first filter and it eliminates a lot. A monthly task gives you one or two runs before anyone can judge whether it works. A daily or weekly task produces enough repetitions to reveal the exceptions, build trust, and show a result inside a month.
Does it take real time?
Not necessarily hours at a stretch. Ten minutes, five times a day, is a better candidate than a two-hour job done fortnightly, both because of the volume and because frequent interruptions cost more than their clock time suggests.
Is there a clear definition of done?
You should be able to describe what a good output looks like in a sentence or two. If your team disagrees about what the finished thing should be, that’s a structure problem, and automating it will just encode the disagreement.
Are the inputs consistent enough to work with?
They don’t need to be uniform, that’s exactly what an agent handles well. But they need to arrive through a predictable route. Emails to a shared inbox, files in a folder, submissions from a form. If the input arrives differently every time from a different place, start elsewhere.
Does someone dread it?
The softest question and often the most reliable. Work people avoid is work that’s genuinely tedious, which usually means it’s repetitive and rule-heavy, which is exactly the shape that automates well. It also means someone will be pleased when it stops, and that person becomes your advocate for the next one.
The test that decides how you build it
Once you’ve picked a candidate, one question determines what’s actually involved:
Does the output land with a person, or land in a system?
If the finished thing goes to a person, a draft they review, a summary they read, a shortlist they act on, a report they use, then it can be built quickly and safely, because nothing is writing into a system of record. Nothing breaks if it’s wrong. Someone just doesn’t use that output.
If the finished thing writes into a system, updating a record, posting a transaction, changing a status, then the same work needs proper access, testing and change control. Still worth doing, but it’s a different scale of engagement and a much slower way to find out whether the idea works.
For a first automation, choose one where the output lands with a person. Prove the hard part, which is whether the judgment holds up on your real inputs, then connect it properly once you know.
What people usually pick, and why it’s wrong
The biggest process. It feels like the obvious place because that’s where the most time sits. But big processes have many steps, many exceptions and many stakeholders, so they take months and produce an ambiguous answer. Automate a piece of it later, once you’ve proven the approach somewhere smaller.
The most expensive problem. Often the expensive problem isn’t an automation problem at all. If work is stalling because nobody owns the next step, that’s structural, and automating it will move the stall rather than remove it.
The most technically interesting one. The task that’s fun to build is rarely the task that matters. Interest fades, the boring weekly job doesn’t.
Something nobody has to do. Occasionally a team picks a task precisely because it’s low-stakes, which usually means low-value. If it stopped happening tomorrow and nobody noticed, automating it proves nothing.
A quick way to shortlist
Ask three or four people what they do every week that they’d hand over immediately if they could. Don’t frame it as an automation question, just ask what they’d give away. The answers tend to be specific, honest and short, and the overlap between them is your shortlist.
Then run each candidate through the five questions above. Usually one or two survive clearly, and the choice makes itself.
What happens after the first one
The point of starting small isn’t modesty, it’s sequence. A first automation that works gives you three things: evidence the approach holds in your business, a team that’s more willing than sceptical, and a much clearer view of what’s actually worth doing next, because you’ve now seen your own process closely enough to spot the rest.
Most businesses find the second and third automations are obvious once the first is running. It’s the first one that’s hard to choose, and that’s mostly because it feels like it has to be significant. It doesn’t. It has to be frequent, clear and genuinely annoying.