Finding repetitive work is rarely the hard part. Most teams can name five tasks they would happily never do again.
The hard part is choosing which one goes first.
The first automation sets the tone for everything after it. If it works, the team trusts the next one. If it stalls, the whole idea gets filed under “we tried AI and it didn’t really work”.
So the first choice deserves a little discipline. This guide assumes you already have a shortlist. If you do not, start with the 8-hour audit, which is a method for finding the task eating your week.
What makes a good first candidate?
A good first workflow is not the most impressive one. It is the one most likely to work, be checked and be kept.
Score each candidate from 1 to 5 on the seven questions below. Be honest. A rough score from the person who actually does the work beats a careful score from someone who has only heard about it.
1. How often does it happen?
Daily beats weekly. Weekly beats monthly. Frequency is what turns a small saving into a real one, and it gives you enough repetitions to see quickly whether the automation is behaving.
2. How much time does each occurrence take?
Include the waiting, the searching and the correcting, not just the typing. A five-minute task that interrupts someone twenty times a day costs more than the five minutes suggest.
3. How often does it go wrong today?
Re-keying, copying and transcribing produce errors. If mistakes are common and expensive to fix, reducing them may matter more than saving time.
4. How many exceptions are there?
Score this one in reverse: fewer exceptions, higher score. A task where nine cases in ten follow the same pattern is a candidate. A task where every case is “a bit different” is usually a judgement job wearing a process costume.
5. Is the data ready?
Can the inputs be reached without someone forwarding an email? Are they in a consistent format? Is there one place where the right answer lives? If the information is scattered across inboxes and spreadsheets, fixing that may be the real first project.
6. What happens when it is wrong?
Score this in reverse too. An internal summary that a person reads before acting is low risk. A message sent straight to a customer, a payment, or a change to a permanent record is not. Start where an error is cheap and visible.
7. Is it technically feasible with the systems you have?
Do the tools involved allow information in and out? A workflow that depends on a system with no export, no integration and no API is going to cost more than its score suggests.
How do you read the scores?
Add them up, but do not let the total make the decision on its own. Two rules override the arithmetic.
- Any candidate scoring 1 on risk waits. A high total does not make a dangerous first project safe.
- Any candidate scoring 1 on data readiness becomes a data project first. Automating a messy input produces a fast mess.
Among what remains, pick the highest total that one person can describe end to end in a few minutes. If nobody can explain the task clearly, it is not ready, whatever it scores.
An example shortlist
Imagine a small professional-services firm with four candidates:
- Copying invoice details from emailed PDFs into the accounting system: frequent, slow, error-prone, consistent format. Moderate risk because a person can review before posting.
- Drafting first-pass replies to routine client questions: frequent, but replies go to clients, so every draft needs review.
- Building the monthly management report: monthly, slow, but the data lives in four places that disagree.
- Deciding which enquiries to prioritise: frequent, but full of judgement and exceptions.
The invoice task is usually the strongest first candidate: high frequency, clear inputs, a natural review point, and an obvious measure of success. The report is a good second project once the data is consolidated. The prioritisation decision may be better supported than automated.
When should work stay manual?
Some tasks score badly for good reasons. Keep the work manual, or simplify it without AI, when:
- A checklist, template or form would solve most of the problem
- The task happens so rarely that maintaining an automation would cost more than doing it
- The value of the work is that a person did it, such as a sensitive conversation
- Nobody is willing to own the result once it is automated
- The cost of a plausible-looking error is unacceptable
Leaving a task alone is a legitimate outcome of this exercise, not a failure of it.
What should you measure before you start?
Before anything is built, write down how the task performs today:
- How many times it happens in a typical week
- Roughly how long each one takes, including waiting and corrections
- How often it goes wrong, and what fixing it involves
- Who does it, and what they would do with the time instead
Without this baseline, nobody can say later whether the automation helped. With it, the conversation about the second workflow is much easier.
Questions to ask before you commit
- Can the person who does this task describe it in a few minutes?
- Where does each input come from, and is it consistent?
- Who reviews the output, and when?
- What happens when the automation is unsure or wrong?
- How will we know, in numbers, whether it worked?
- If it works, what is the next workflow it makes easier?
The first automation should be boring, frequent and easy to check. Ambition can come second.
If you want a second opinion on your shortlist, MonoGrain’s AI Opportunity Audit ranks the candidates and says plainly where AI is not the answer.