Which processes do you automate first?

Most automation projects do not fail because the technology is not ready. They fail because the wrong thing was chosen first. Teams reach for the most painful, most complicated problem, the one everyone complains about, and discover it is painful precisely because it is messy and hard to pin down. The project drags, confidence drains, and the whole idea of automation gets a bad name inside the company.

The better move is almost the opposite. Your first automation is not really about saving the most hours; it is about proving the approach works. A clean, visible win, something that quietly does its job every day and frees people from a chore they never liked, buys you the trust to tackle bigger things next. This article gives you a simple way to spot that candidate and avoid the traps that sink early projects.

Score your candidates before you commit

Start by listing the repetitive tasks your team actually does, not the grand ambitions, the daily grind. Then score each one honestly against a handful of criteria. You do not need weighted formulas; a rough high, medium or low for each is enough to make the strong candidates stand out.

• Frequency and volume. How often does this happen? Something done fifty times a day is worth far more automated than something done twice a month.
• Time spent. How long does each instance take, and how much of it is dull manual effort a person resents doing?
• Error-proneness. Is this a task where tired humans make mistakes, mistyped figures, missed steps, things falling through the cracks? Consistency is where machines shine.
• How clear the logic is. Can you write down the steps, either as fixed if-this-then-that rules or as a task you could hand to a new colleague with a one-page instruction? Tightly ruled work suits classic automation; fuzzier language tasks like sorting or drafting now suit AI, provided the output is easy to check.
• Data availability. Is the information the task needs already in a system you can reach, a form, a database, an inbox, in a structured, reliable form? If it is scattered or lives only in someone's head, that is a hurdle.

Then weigh those upsides against two counterweights. The first is risk: what happens if the automation gets it wrong? A misfiled internal note is trivial; a wrong invoice sent to a customer is not. The second is variability: how much does the task change from case to case? Work that looks different every time resists clean rules and is a poor first choice.

What makes a good first candidate

Put those criteria together and a pattern emerges. The ideal first automation is repetitive, high-volume, structured, rule-based and low-risk, the kind of task where the right answer is obvious and the cost of a rare mistake is small. That points at a familiar set of jobs.

• Data entry and copying information between systems, where the same fields move from one place to another.
• Sorting, routing and triage, tagging incoming emails or tickets and sending them to the right person.
• Drafting standard replies to common, predictable questions, ready for a human to glance at and send.
• Report generation, pulling the same numbers into the same format on a schedule instead of by hand.
• Lookups and checks, such as retrieving an order status, verifying a detail, or gathering figures scattered across tools.

What these share is clarity. The steps are knowable, the inputs are tidy, and a person can easily check the output, exactly what you want the first time round.

What to leave for later

Just as telling is what not to start with. Some work is genuinely valuable to automate one day, but a terrible place to begin, because it will test the technology and your team's patience at once.

• High-judgement work that depends on nuance, context or negotiation, the sort of decisions people are paid for their experience to make.
• High-risk tasks where a mistake is expensive, hard to undo, or lands in front of a customer or regulator.
• Exception-heavy, messy processes where almost every case seems to need special handling and the rules keep bending.

None of this is off-limits forever. It simply belongs after you have a working track record and the confidence, yours and your team's, that automation earns its keep.

Rule-based or AI? Know which tool you are reaching for

In 2026 the word automation covers two quite different things, and knowing which one a task needs will save you a lot of grief. Classic rule-based automation follows fixed logic: given the same input it does the same thing every time, and when it fails it usually fails loudly and predictably. Move money between systems, generate a report on a schedule, route a form to the right queue, this is where deterministic automation still shines, and it should be your default whenever the steps can be pinned down.

AI models, the large language models behind most of today's smart features, are different in kind. They are genuinely good at the fuzzy language work that rules never handled well: reading messy text, classifying and tagging, summarising, extracting fields from a document, drafting a first reply. But they are probabilistic, not deterministic. They can be fluent and confident and still wrong, and they rarely fail in an obvious way. That single trait shapes where they belong first.

• Lean on AI where a person can glance at the output and catch a mistake in seconds, a drafted email, a suggested category, a short summary, not where its answer fires off unchecked.
• Keep the model proposing, not committing. Let it prepare the reply, the tag or the draft entry, and have a person or a hard rule approve anything that spends money, contacts a customer, or changes a record that is hard to undo.
• Feed it tidy, relevant inputs. AI copes with far messier data than old automation did, but rubbish in still means confident rubbish out, now dressed up in fluent prose.

The practical upshot: AI has widened what a sensible first project can be, but it has not repealed the rules in this article. If anything it raises the premium on low-risk, easy-to-review tasks, because the technology's mistakes are quieter and harder to spot than a broken script's.

Use impact versus effort, and start small

A quick way to make the final call is to plot your candidates on two axes: how much impact automating them would have, and how much effort it would take to build. The sweet spot for a first project is high impact, low effort, a meaningful chore that is also genuinely simple to automate. The high-impact, high-effort ideas are your second or third projects, not your first.

Pick the boring, obvious win first. A quiet success you can point to is worth more than an ambitious project that stalls.

Whatever you choose, start small and measure. Automate one narrow slice, agree in advance what good looks like, hours saved, errors reduced, faster turnaround, and check it against reality after a few weeks. And keep a human in the loop, especially early on: let the automation do the repetitive work and have a person review the output or handle the odd exception it flags. That keeps you in control and reflects the honest truth that the best results come from people amplified by AI, not replaced by it.

Do not automate a broken process

One pitfall deserves its own warning, because it catches out even careful teams. If a process is broken or full of workarounds, automating it does not fix it, it just makes the mess run faster and harder to see. You bake the flaws in and lose the human judgement that was quietly patching over them.

So before you automate anything, look at the process itself. Are there steps that exist only out of habit? Approvals nobody reads? Data entered twice? Fix or simplify the process first, then automate the clean version. Often the act of mapping it out reveals the improvements you should have made anyway.

A quick-win checklist for Monday

If you want something concrete to do at the start of the week, work through this short list. It takes an hour or two and usually points straight at your first project.

1. 1List the repetitive tasks your team does daily or weekly, the routine chores, not the big projects.
2. 2For each, jot a quick high, medium or low on frequency, time spent, error-proneness, how clear the logic is, and whether the data is easy to reach.
3. 3Cross out anything high-risk, high-judgement or full of exceptions for now.
4. 4Ask of what remains: is the underlying process actually sound, or does it need fixing first?
5. 5Pick the one that scores high on impact and low on effort, the boring, obvious win.
6. 6Define what success looks like in numbers, decide how a human will review the output, and start with that single task.

Get that first one right and the rest gets easier. You will have a working example to point to, a clearer sense of what your systems can support, and a team that has seen automation help rather than hinder. That is the foundation every bigger project stands on.