How to pick the first task to automate with AI

The first AI project sets the tone for every one after it. If it ships and people use it, the second is easy to fund. If it stalls, “we tried AI” becomes a reason to say no for a long time.

So the first task should be chosen for its odds of working, more than for how impressive it sounds. Here is a method for choosing.

Start with the people doing the work

Ask the team where their week goes. You want tasks, described plainly: “I read every inbound email and decide who should handle it.” “I copy order details from the PDF into the system.” “I write the first draft of every quote.”

Don’t assume leadership’s list of AI ideas matches the team’s list of time sinks. Start with the team’s.

Score each task on four questions

For every task on the list, answer these.

How many hours a week does it take, across everyone? A rough estimate is fine. You are sorting big from small.

What happens when it’s done wrong? Sort tasks into three kinds. Some mistakes are cheap and easily caught, like a draft a person will read before sending. Some are costly, like a wrong figure on a quote. Some are unacceptable, like anything touching safety, legal commitments or money leaving the business. Early projects belong in the first kind.

Is there a person in the loop already? Tasks where someone reviews the output anyway are ideal. The AI does the first pass, the person does what they already did, and errors get caught by a process that exists.

Can we get at the data? A task is only a candidate if the inputs can reach the system and the outputs can land where the work happens. If the data sits in a tool with no way in or out, the project becomes an integration project first.

Look for the boring middle

The best first task usually has these features. It takes real hours. It is repetitive. A person checks the result. Mistakes are cheap. The data is reachable.

That tends to describe things like sorting and routing inbound requests, drafting replies for a person to approve, pulling fields out of documents, or summarising long threads before a handover. None of these will make a conference talk. All of them can be in daily use within weeks.

Leave the ambitious idea on the list. It will be much easier once the team has watched a modest one work and learned what these systems are like to live with.

Write down what good looks like before you build

Before any building starts, collect twenty to fifty real examples of the task, with the right answer for each. This does two jobs. It forces agreement on what “right” means, which is often less settled than people assume. And it gives you a test you can run every time something changes.

Then set the bar in plain terms. “It sorts requests into the right queue often enough that the team prefers it to doing it by hand, and nothing urgent is ever left unflagged.” You can measure against that.

Decide how you’ll find out it’s wrong

Every system like this makes mistakes. The question is whether you see them. Plan for a log of what it did, a simple way for the team to flag a bad result, and a named person who looks at those flags each week.

A system that is mostly right and visibly wrong when it fails is one people come to trust. One that fails quietly gets switched off the first time it embarrasses someone.

A short version

List the tasks with the team. Score hours, cost of error, existing review and data access. Pick the boring one that scores well. Gather real examples before building. Make its mistakes visible.

If you’d like this done with you, it’s the first two weeks of our four-week AI review.