Where to start with AI — how to pick the first process

Picking the first process matters more to a rollout than picking the tool. A tool can be swapped after a month. A failed first process leaves the sentence "we tried AI and it doesn't work" inside the company, and that sentence outlives any licence agreement.

In the companies we talk to, this decision usually takes five minutes and lands on whatever currently annoys the person chairing the meeting. Annoyance is a signal. It is not a criterion.

Below: four properties of a good first candidate, three choices that reliably go wrong, and how to set the success criterion before anything starts.

Four properties of a good first process#

All four at once. Three out of four is the standard recipe for a rollout people describe a month later as having "almost worked".

Recurring. Done several times a week, not once a quarter. Recurrence gives you data to judge by after a month and practice for the team. With a quarterly process you wait a quarter for the second measurement, by which time everyone has forgotten how the tool works.

Measurable in hours. You have to be able to say how many hours a week the process consumes today. "It takes a lot of time" is not a measurement. "Three people, roughly ninety minutes a week each" is.

Cheap to get wrong. Ask what happens if the output is wrong and nobody notices for a day. If the answer is "someone gets a stale summary", it qualifies. If it is "a customer gets an invoice for the wrong amount", it does not — even if the saving would be larger. Start with processes where a mistake stays inside the company and can be reversed.

Owned on the business side. One named person who does the work today or answers for it, and whose day looks different afterwards. Not a department. Not whoever signs off the budget.

Who exactly is the owner#

The fourth condition drops off the list most often, because next to the other three it sounds soft. In practice it is the one that decides.

The owner is the person who, after a month, says "I do this faster now" or "I still do it the old way, because that thing doesn't work". Both answers are useful. No answer is not.

The sponsor is someone else: the person who approved the spend and wants a result. That distinction comes back later, when you judge pilots that never reach production. At the selection stage one thing is enough: when you pick a process, you are picking a named person along with it, not a budget.

The practical consequence: the owner takes part in the configuration rather than being handed a finished thing. On platforms where a process is described in words rather than coded, and the agent acts only after a human approves, that is achievable — the person who knows the process lays out its steps instead of explaining them to someone who never saw it.

Three processes not to start with#

The one most visible to the board. Tempting, because everyone sees the result. Everyone also sees every mistake, and a rollout like that gets judged by impression rather than measurement. The most visible processes usually touch customers too, which means the highest cost of error.

The hardest one. The logic "if AI can handle this, it can handle anything" is backwards. The hardest process is hard for reasons unrelated to AI: data in three places, more exceptions than rules, half the knowledge in one person's head. A model will not repair that — it will inherit it.

The one with no owner. You recognise it because five people touch it and none has it in their job description. The classic case is the weekly report assembled from three departments' data. Everyone complains about it, nobody answers for it, so after a month nobody reports success or failure.

Set the success criterion before you start#

Three things written down before day one, ideally on one sheet of paper.

The starting number. Not from memory — have the people who do the work log it for one week. Memory inflates the irritating and deflates the routine, and this is the number your decision rests on.

The target number and a date. For instance: four hours a week down to one within thirty days. Three hours saved a week is one hundred and fifty-six hours a year — a figure you can set against the cost of a tool. "Things will run more smoothly" gives you nothing to compare.

What you do if you miss. What happens if after thirty days the number is three hours, not one. Three answers are honest: extend by a month with one specific change, switch processes, or stop. "We'll see" means the project has no end, and a project with no end is never declared a failure, so it teaches nobody anything.

The owner does the measuring. If the person who chose the tool measures the result, the result is known in advance.

When no process meets all four conditions#

This happens often and is not a reason to abandon the idea. It tells you what to do first.

Narrow the process rather than swapping it. You rarely need "order handling" whole. "Answering a question about order status" is enough. A slice can satisfy all four conditions when the whole thing satisfies none, and the gain shows up in the same week.

Check whether the real problem is the data. If the condition that fails is measurability, the same information usually lives in several places and nobody knows which is true. Then the first job is not AI — it is getting that information into one place.

Summary in one paragraph#

A good first process recurs, can be measured in hours, is cheap to get wrong, and has one person who genuinely cares. A bad one is showy, hard, or nobody's. Before you start, write down three numbers — where you are today, where you want to be, and by when — because without them all you will have after a month is a discussion about impressions.

The steps that follow, from putting the data in order to expanding to a second process, are covered in the guide on AI adoption for companies with no IT department.