How to choose the first process to hand to AI

A good first process already has an owner and a clear end.

Choose work that one named person is already responsible for, and that starts with a recognisable input and finishes with a recognisable output. Say a team that answers supplier emails about delivery dates. An email arrives, someone looks up the order, and someone replies. You can point to the start and the finish, which means you can say afterwards whether the job was done.

If nobody can say who owns a process today, nobody will own it once AI does the work. Settle that first.

It should run often enough to teach you something.

A process that happens a few times a month will take a year to show you where it goes wrong. Pick one that runs daily or weekly, so that within a few weeks you have enough real cases to see the pattern. Frequency also decides whether the effort pays back. Setting up a process and checking its results costs time, and that cost is only recovered if the work repeats.

You should be able to say how the work is decided.

Ask the person who does the work to explain how they decide what to do. If they can describe it in plain sentences, including the exceptions ("unless the customer is on a contract"), the process is a candidate. If the answer is "I just know," the knowledge is real, but nobody can yet check anyone's work against it, whether a person's or a machine's.

That is a reason to write the rules down before doing anything else. The exercise is worth doing even if you decide not to use AI at all.

A mistake should be cheap to find and cheap to fix.

Prefer a process where a wrong result is caught before it reaches a customer, or can be corrected afterwards at small cost. A draft reply that a person approves is a safer start than a payment that goes out automatically.

Starting with low-stakes work is sensible rather than timid. It gives your team practice at reviewing results, and that habit is what makes it safe to take on riskier work later.

Two kinds of process look attractive and fit badly.

The first is the most painful process in the company. It is usually painful because it is a tangle of exceptions that nobody has fully described, and a tangle is a poor place to learn. Once you have a working process and a team used to reviewing, it becomes a reasonable second or third project.

The second is the process that would impress the board. Visibility is a fine reason to pick a project later. As a first choice it adds pressure to a project that needs room to be adjusted.

Check that the information can be reached.

Before committing, find out where the inputs actually live. If the facts needed to do the work sit in one person's private inbox or in a system nobody currently has access to, the first job is access, and the project should be planned around that. It is better to learn this in the first week than in the sixth.

When a candidate meets most of these conditions, test it with a small version, covering one team and one type of case for a few weeks. A process that survives that is a good first one.