Your first AI automation: pick something boring

Your first AI automation should be boring. Pick a task your team does many times a week, that follows rules you could write on one page, where a mistake is cheap and easy to spot, and that somebody would be glad never to do again. The ambitious ideas can wait. A dull first project gives you hours back, and it teaches you how automation behaves in your organisation before anything important depends on it.

By AI automation we mean software that does a step in a workflow for you, such as reading an email, pulling out the details and filing them, with a language model doing the reading and writing.

What makes a good first candidate

Look for a task that passes most of these tests.

• It happens a lot. Daily or weekly, not once a quarter. Volume is where the time goes, and it gives you plenty of cases to test with.
• It’s the same steps each time. If the task changes shape every time, it’s a judgement job, and judgement is the hardest thing to automate.
• The rules fit on a page. If you can’t write down how your best person does it, software can’t follow it either. Writing the rules down often fixes half the problem by itself.
• Mistakes are cheap and visible. A wrongly filed email is a nuisance. A wrongly refused customer is a complaint, or worse.
• You have examples. Past emails, forms and finished work: real inputs with the right outputs. They’re how you’ll test whether it works.
• Somebody hates doing it. That person is your champion. They know the exceptions, they’ll test it properly, and they want it to work.

Score your shortlist

List three to six candidates and score each one from 1 to 3 on every line.

Test	1 point	2 points	3 points
How often	Monthly or less	Weekly	Daily
Same steps each time	Different every time	Mostly	Nearly always
Clear rules	In someone’s head	Partly written down	Fits on a page
Cost of a mistake	Could harm a person or break the law	Embarrassing but fixable	Mildly annoying
Past examples	None	A handful	Dozens or more
Someone hates it	Nobody minds	Some grumbling	Will volunteer to test it

Add up the totals, with one rule that beats the arithmetic: anything that scores 1 for cost of a mistake is out for now, however well it does elsewhere.

A worked example

This example is invented, to show the grid in use. Imagine a 20-person lettings agency. Its shared inbox gets a steady stream of repair requests from tenants, and a property manager spends the first hour of most days reading them, working out which property each one is about, logging it and replying to say it’s in hand. The team lists four ideas and scores them.

Test	Repair requests	Viewing replies	Property adverts	Tenant shortlisting
How often	3	3	2	2
Same steps each time	3	3	2	2
Clear rules	3	2	2	1
Cost of a mistake	2	3	2	1
Past examples	3	3	3	2
Someone hates it	3	2	1	2
Total	17	16	12	Out

Shortlisting tenants sounded the most impressive in the meeting, and it’s the one ruled out, because it scores 1 for cost of a mistake. Repair requests win: they arrive every day, the rules are clear, there are years of past emails to test against, and the property manager would very much like that hour back. They only score 2 for cost of a mistake, because a missed leak matters, so the design keeps a person on every one.

The first version reads each new email, pulls out the address, the problem and how urgent it sounds, then drafts a log entry and a reply. The property manager approves, edits or rejects each draft. Anything that mentions gas, water coming through a ceiling, no heating or electrics skips the queue and goes straight to a person. It doesn’t decide who pays, book contractors or answer complaints.

Keep a person in the loop

A person in the loop means someone checks each output before it does anything that matters. For a first automation, that’s every output.

Track what happens to each draft: sent unchanged, lightly edited or rewritten. After a few weeks you’ll have real numbers instead of impressions. If one kind of request is nearly always right, you might move it to spot checks. If another keeps getting rewritten, take it out and leave it with a person. Agree those thresholds before you start, so the numbers make the call rather than whoever is busiest that week.

Make it easy to say no. A reject button with a one-line reason is worth more than hours of fiddling with prompts, because the reasons tell you what to fix. Our guide to telling whether an AI project worked covers the measuring in more detail.

What to leave until later

• Anything legally significant about individuals. Shortlisting tenants, credit checks, hiring: anything that decides what happens to a person. Since 5 February 2026, UK law allows solely automated decisions with legal or similarly significant effects only with safeguards, including telling people about the decision, letting them make representations, offering human intervention and giving them a way to contest it. Stricter rules apply to special category data such as health information. That’s a lot to get right first time, and our UK GDPR checklist has more.
• Anything with no examples. If the task is new, or the past examples are scattered across inboxes nobody can search, you have nothing to test against. Gathering the examples is often the real first project, and your spreadsheets are a good place to start.
• Anything you can’t undo. Payments, deletions and messages that go out unchecked. Software that takes actions needs more care, which we cover in agentic AI: when software takes actions.

Then do the next boring thing

Run the first one for a month. Measure it, and fix what the reject reasons tell you. Then pick the next candidate from your grid. It will go faster, because your team now knows what a good task looks like. For a second pair of eyes on your shortlist, should you automate this? is a good test, and we’d like to hear which one came out on top.