One process, one task: how to choose where AI begins

The question many organisations start with when it comes to AI is: "What can it do?" The answer is almost everything. That is why it so often stays at a presentation, a trial account and a good conversation, while nothing happens in the work itself.

A smaller question works better: which work that comes back every week costs my team time for no good reason?

I always begin with one process and, within it, one task. In this piece I explain how to choose it, how to define the task, what to measure, where a person keeps deciding, and which mistakes I see most often. At the end there is a plan for Monday.

Why starting small is not a lack of ambition

The first process is not the process where the most is to be gained. It is the process with which you learn how it is done, with as little risk as possible and with an outcome you can measure.

What you learn there about instructions, checking, measuring and data, you use on the second process, and then it goes faster. Whoever starts with the hardest process learns the same lessons under pressure, with more that can go wrong. Then the chance is high that the team concludes after the first setback that AI is not for them.

So the first process is an exercise, and the better you choose it, the more you learn from it.

Step 1: choose the process

A process is a series of steps with a trigger and an outcome: a request for a quote comes in and a quote goes out. An invoice comes in and is paid or sent back. A customer emails a question and gets an answer.

Six characteristics make a process suitable as a first one.

1. It happens often. At least a few times a week, preferably daily. Then after a few weeks you have enough cases to be able to say something. A task that occurs once a year is a poor start: you learn too little from it.

2. It noticeably costs time, or it noticeably waits. Write down for a few days where the time goes. It is about working time per case, or about lead time: how long the work sits somewhere before it moves on.

3. It is well defined. It has a clear trigger, a clear outcome and not too many exceptions. If you cannot say when the task is finished, you cannot see whether AI did it well either.

4. Little is at stake if it goes wrong. A wrongly sorted email you put back in another folder. A sent email you cannot take back. Begin with work where a mistake is cheap and noticed quickly.

5. The data are manageable. Do not start with the process full of sensitive data if you do not yet know what happens to that data in the tool you use. Then you spend your whole first round on the question whether it is allowed, and you never get to the question whether it works.

6. Someone wants to pull it. An owner. This is the only characteristic that overrules all the others: a process without an owner drops out, however well it scores otherwise.

You can make this visible with a simple table. Put three to five candidates under each other, six columns next to them, and give each candidate a score from 1 to 3 per characteristic. Compare characteristic by characteristic and not process by process; that way you compare better. The total is an aid and not a decision: it shows what the conversation should be about. If a team picks the process with the second-highest score, for a reason it can explain, that is a good choice.

A process that scores high but that nobody wants to own is a signal. Usually everyone finds it useful and nobody finds it urgent.

Step 2: decide what the owner does

The owner is the most important choice, and gets less attention than deserved. It is the person who maintains the instruction, runs the trial, keeps the measurements and is the point of contact when someone sees an error.

That takes time, often a few hours a week in the first weeks. That time has to be real. An owner who has to do it next to the regular work drops out in the busiest week, and that is exactly when you want to know how the process holds up.

Choose someone who carries out the process themselves. A manager who does not do the process does not know what goes wrong at step four. The manager does have a task of their own: making sure the owner gets the time.

Step 3: define the task

Within the process you choose one task. Not "handle the quote request", but for example: "make a list from the incoming request of what is still missing." Three questions help to sharpen that task.

What goes in? Which information does the tool get exactly: the text of the email, a form, an attachment? The cleaner and more limited, the better.

What comes out? A list, a draft, a classification. Describe the outcome in such a way that a colleague can see whether it is good. If you cannot describe the outcome, the task is still too vague.

What is the next step, and who does it? The outcome of AI is seldom the end. A person reads it, adjusts it or passes it on. Record who that is.

A well-chosen task fits in one sentence that a new colleague understands: "For every new request the tool makes a list of what is missing, and Joost reads that list before he emails the customer." If the task does not fit in one sentence, it is two tasks.

Step 4: record beforehand when it has succeeded, and when you stop

This is the step that is skipped most often, and so the reason many pilot projects prove nothing.

Before you begin, write down two sentences.

Succeeded if: something you can count. "It goes faster" is not a criterion. "The lead time from request to quote falls from eleven to five working days" is. Choose one or two.

Stop if: what has to happen to say: this does not work, or not yet. Usually it is one of three things: it costs more time than it yields, something goes wrong that must not go wrong, or the people who do it do not get on with it.

Why beforehand? After three weeks you look differently. Whoever only then thinks of what success is will always find something that worked. And stopping does not become a defeat if it is an agreement you keep.

Step 5: measure beforehand, otherwise you know nothing afterwards

A bakery wanted to know whether AI could help estimate the Saturday orders. After six weeks someone asked whether it had yielded anything. The baker said it made a difference, I think. His wife said they still threw away as much. Neither could show it, because nobody had written down how much was thrown away before those six weeks.

(This is a composite example, not an existing bakery. It shows what happens if you do not measure beforehand.)

Measuring is the difference between an impression and a decision. It does not have to be complicated, and it does not have to be research. A few numbers, counted the same way as before the change, over a few weeks.

Measure the following, before and after, in the same way.

• Working time per case, including the check. Not only reading the proposal, but also going over it, adjusting it and doing the difficult cases yourself. Otherwise you flatter yourself.
• Lead time. From trigger to outcome, on the calendar.
• Quality. The number of errors, the number of customers who call back because something was unclear, the number of times something had to be redone.
• Uptake. Of the tool's proposals: how many were taken over as they were, how many adjusted, how many rejected?
• What it costs. The cost of the tool, and the owner's time.

And a sixth that is not a number but does count: what it is like to work this way. Ask everyone who works with the process at the end, with one question and a score from 1 to 5: do you prefer working like this or like it was?

A week of measuring beforehand is usually enough to fix the starting point. Afterwards measure for a few weeks in the same way. And repeat the measurement after a few months, because the first weeks are different from the rest: everyone pays extra attention and the new way is not yet normal.

Step 6: decide where the person decides

This is the step where the conversation about AI often gets stuck, because "may AI do this?" has no answer. The question "may AI at step four of our quoting process make a list of what is missing?" does have one, and usually it is given in five minutes.

That is why you choose per step, not per process. I use three colours.

• Green: AI does it. The result is used without a person reading it every time. A person checks by sampling. Green is for steps that stay internal, are easy to repair, and where a mistake is noticed quickly.
• Orange: AI prepares, a person decides. AI delivers a proposal: a draft, a list, a classification. A person reads it, adjusts or rejects it and carries out the step themselves. Orange is the colour of most of the work in a first process, and that is good.
• Red: AI does nothing. Not in this step, not now. Red is not a judgement about AI, but a choice about this step: the risk is too big, the data are too sensitive, the judgement is too personal, or the person prefers to do it themselves for a reason that matters.

Five questions decide the colour:

1. Is it reversible?
2. Does it go outside? What goes outside speaks on your behalf.
3. Which data go in?
4. Does it require a judgement someone answers for?
5. What does a mistake cost, and do you notice it in time?

My own rule is short: what goes outside or promises something gets a person's approval. Everything before that AI may prepare. Decisions about persons, such as selecting applicants or assessing employees, fall under the European AI Act in the high-risk category, with requirements a team in a first process does not get to. You stay away from that.

Begin strict. What you later make looser feels like progress. What you later have to make stricter feels like an accident. And when the team doubts, the strictest colour applies, with the open question attached.

A limit is a condition, not a brake

In my book AI-agenten die het werk doen I write about limits: "A limit makes the game possible instead of restricting it." As long as there is no limit, everything has to pass through you. Once there is a limit, work can happen while you are not there.

What I also write there: whoever can do something must also have something that stops them, and those two should be arranged in the same place and at the same moment. A limit you add later is drawn around what has meanwhile been happening. And what has meanwhile been happening feels normal.

A usable limit has three characteristics, and all three can be checked:

1. It is written down somewhere, not in the head of the one who enforces it.
2. It can be read beforehand, so before the action takes place and not after.
3. It intervenes by itself, so that it does not depend on who happens to be watching.

If the third is missing, it is an agreement and not a limit.

A worked example

An example, composed to show the steps. It is not an existing company, and the choices are illustrative.

An installation company with a few fitters and a planner receives dozens of quote requests every week, by email and through a form. The planner reads each request, finds out what is missing, emails the customer and only then makes the quote.

Choosing the process. The team puts three candidates side by side: sorting out requests, pricing quotes, making the schedule. Pricing scores low on risk: that is where the planner's judgement sits, with his knowledge of difficult attics and customers who have had maintenance for years. Sorting out requests scores high on frequency, time, definition and manageable data, and the planner wants to be the owner.

Defining the task. One sentence: "For every new request the tool makes a list of what is still missing, and a draft email to the customer. The planner reads, adjusts and sends."

Colours. Reading the request and checking what is missing: green, it stays internal and a mistake shows at the next step. The email to the customer: orange, because it goes outside. The price: red. The planner makes it himself.

Criteria beforehand. Succeeded if the lead time from request to quote falls. Stop if the planner spends more time checking than writing himself, or if once a document is requested that the customer had already sent.

Measuring. Before the start the planner keeps track for a few days of how long he spends per request and how often he has to ask a customer for something twice. After a few weeks he does it again, in the same way.

What such a measurement can show: sometimes the working time falls while the lead time barely moves because the waiting is somewhere else. Then it is not an AI problem but a process problem, and you only see that if you measure. Sometimes the gain is a different one than you expected: customers have to supply things twice less often, because the email now asks for everything that is missing and not for what the planner happened to think of at that moment.

The mistakes I see most often

Starting with the process where the most is to be gained. That is usually also the process with the most risks and the most sensitive data.

No owner. A process that belongs to everyone belongs to nobody.

Not measuring beforehand. Then "it feels faster" remains the only evidence, and that convinces nobody who has to decide whether it may stay.

Determining success afterwards. Whoever only thinks of what success is after three weeks always finds something that worked.

Not counting the check. If you only count the time of reading and not that of going over and adjusting, it looks better than it is.

Drawing the limit only when something went wrong. A limit you only discover by crossing it is not a limit but a punishment.

Too much at once. Whoever starts three processes at the same time no longer knows which change had which effect.

Comparing with what you read somewhere. Large percentages circulate about how much time AI saves. They are about other processes, other people and other ways of measuring. The only number that counts for your process is the number you measured yourself.

A bad outcome is also an outcome

If the measurement disappoints, you have learned something. Maybe the instruction is not right for a certain group of customers. Maybe the check costs more than it yields. Maybe the task was chosen too big.

A measurement is not there to show a number. It is there to find the place where it does not work. One customer group may then simply stay manual work, and that is a perfectly good outcome.

What you can do on Monday

1. Write down for a week where the time goes for three to five recurring processes: how often, how many minutes per case, how long it waits.
2. Put the candidates next to the six characteristics and give scores. Discuss the differences with a colleague.
3. Choose one process and one owner. Ask, do not assign. Arrange the time.
4. Describe the task in one sentence, with what goes in, what comes out and who does the next step.
5. Colour the steps green, orange or red, with a reason. When in doubt, the strictest colour.
6. Write down two sentences: succeeded if... and stop if...
7. Measure a week beforehand, in the way you will also measure afterwards.
8. Start small, see what it yields, and use what you learned for the second process.

That way, with your team, your board or your customers, you are not talking about what AI could do, but about what it already did here.

Which recurring work would you choose first?

This piece on LinkedIn

All pieces