Most companies don't struggle to find things AI could automate. They struggle to pick the right first one. Choose well, and the first automation saves real time, builds trust and makes the second one easy to approve. Choose badly, and a stalled pilot becomes the reason nobody tries again.
This guide gives you a practical way to choose: how to build a list, how to score it, which kinds of processes tend to work and which to leave for later.
Start with a list of real work
Don't start from AI capabilities ("what can a language model do?"). Start from where time goes today.
Ask each team lead a few questions and write down every answer, however small:
- Which tasks does your team repeat every day or every week?
- Where do people copy information from one system to another?
- What work piles up when someone is on holiday?
- Which requests come in by email or form and need sorting before anyone can act?
- Which reports does someone assemble by hand?
A first pass usually produces twenty to forty candidates. That's the right size. You're looking for the few that combine high value with low risk.
Score each candidate
Rate every candidate from 1 to 5 on four questions. Keep it quick; the goal is ranking, not precision.
| Factor | Question | High score means |
|---|---|---|
| Volume | How often does this happen? | Many times a day or week |
| Time | How long does each instance take by hand? | Minutes to hours of focused work |
| Rules | How clear is a correct result? | Someone can check the output quickly |
| Risk | What happens if one instance goes wrong? | Easy to catch and fix; nobody is harmed |
Multiply volume by time to get a rough sense of hours at stake. Then use rules and risk to filter: a high-hours process with unclear rules or serious consequences is a poor first project, however tempting.
Also note two practical points for each candidate: whether the data is accessible (an API, a shared inbox, an export) and who in the business owns the process. A process with no clear owner will have no one to tell you when the automation gets it wrong.
Processes that usually make good first automations
These patterns come up in almost every company, and they tend to combine high volume with outputs that are easy to check:
- Inbox and request triage. Reading incoming emails, forms or tickets, classifying them and routing them to the right person or queue, with key details extracted.
- Document data extraction. Pulling fields from invoices, purchase orders, delivery notes or application forms into a system of record.
- First drafts of routine replies. Drafting answers to common customer or supplier questions for a person to review and send.
- Data entry between systems. Moving information from emails or spreadsheets into a CRM, ERP or project tool.
- Recurring report assembly. Gathering numbers from several sources into a weekly or monthly summary, with a short written commentary.
- Meeting and call follow-up. Summaries, action items and CRM updates after sales or support calls.
What these have in common: a person can check the result in seconds, a mistake is visible and reversible, and the work is boring enough that nobody will miss doing it.
Processes to leave for later
Some processes look attractive and are poor first choices:
- Decisions about people. Hiring, performance evaluation and credit decisions carry legal obligations, including under the EU AI Act, and mistakes hurt individuals. They need careful design, not a pilot.
- Rare, high-stakes work. If something happens twice a year and matters a great deal, there's little time to save and much to lose.
- Processes nobody agrees on. If three people would handle the same case three different ways, automate after you've agreed on the process, not before.
- Anything without accessible data. If the information lives in someone's head or a system with no export, the integration work will dominate the project.
Design for review from day one
A good first automation doesn't need to handle everything. It needs to handle the common cases well and recognize the rest.
Build in three paths:
- Confident: the automation completes the work, and a sample is checked regularly.
- Uncertain: the automation prepares the work and a person approves or corrects it.
- Out of scope: the item goes to a person untouched, with a note on why.
Start with more items on the uncertain path than you think you need. As the team sees the automation handle those correctly, widen the confident path. Trust grows from evidence, and this structure produces it.
Run a small pilot
Keep the first pilot short and measurable:
- Measure the baseline. Before building anything, record how many items arrive and how long they take by hand for two weeks.
- Build the narrowest useful version. One process, one input channel, the common cases.
- Run it alongside the manual process for a week or two, comparing results.
- Switch over gradually, starting with the cases the automation handles most reliably.
- Report the result in hours saved, error rate and items needing review, against the baseline.
Measure before you build
The baseline is easy to skip and impossible to recreate later. Without it, nobody can say whether the automation saved time, and the case for the next one rests on opinion.
Plan who runs it
Before the pilot ends, agree who owns the automation: who receives alerts, checks samples, and updates it when the process or the inputs change. Automations without an owner degrade quietly, usually within months. Our article on why AI automations break covers the operating habits in detail.
The short version
List the repetitive work, score it on volume, time, clarity and risk, and pick a high-volume process whose results are easy to check. Design for human review, measure a baseline, run a short pilot and name an owner. Then use the result to choose the next one.