Most companies we meet have already had at least one AI meeting. Often several. Someone has tried ChatGPT, someone else has seen a demo, and somewhere there is a document called “AI strategy” that nobody has opened since the spring.
This is not a knowledge problem. It is an ordering problem. People start at the wrong end.
This article is about the order — the steps from a chosen process to something running for real. If you do not yet know which process to choose, start with The operational perspective instead.
Do not start with the technology
The most common starting point is picking a tool. It feels productive — there is something to compare, something to price, something to show. But a tool without a defined task becomes a licence cost nobody uses.
The second most common starting point is a strategy: a document describing where you want to be in three years. The problem is that you do not yet know how much work can actually be moved, or what it costs in time to move it. So you are writing a plan built on guesses.
Start instead at the end where you already have facts: the work you do every day.
Pick the process nobody wants to talk about
Look for a task that meets four conditions at once:
- It is manual. Someone moves information between systems by hand.
- It is repetitive. It looks roughly the same every time.
- It is measurable. You can say how many times a week it happens.
- It is boring. Nobody will defend it.
The fourth point matters more than it looks. An automation project that threatens someone’s professional pride meets resistance, however good it is technically. One that removes work nobody wanted gets help.
In practice it almost always lands on one of these: order emails typed into the ERP, supplier invoices matched against purchase orders by hand, stock levels checked manually before ordering, or customers emailing to ask where their order is.
Measure before you change anything
This step is nearly always skipped, and it is the reason projects later cannot be evaluated.
Before automating anything, count how many times the task is performed per week and estimate how long each occurrence takes. You do not need time studies — ask the person who does it. That number is your baseline, and without it you will, six months from now, have a feeling that things improved but nothing to show.
Note where things go wrong today as well. How often does a line quantity come out wrong? How often is an error caught only after the fact? Error rates are frequently where the largest value sits, but they are only visible if you measured them beforehand.
Automate one thing, not one area
The temptation is to take the whole order flow at once. Resist it. Take one step: the email that becomes a sales order. Not the entire chain from request to invoice.
The reason is not technical caution. The reason is that you are still learning where your own rules actually sit. What should happen when a customer orders a discontinued item? When the price in the email does not match the agreement? When the quantity is implausibly high? You have answers to these in your head but rarely written down, and they only surface once something genuinely runs.
A narrow process means you get to answer them at a pace you can keep up with.
Decide where the boundary to the human sits
This is what determines whether the automation ends up trusted or not.
Decide in advance what runs automatically and what stops and gets flagged. A good rule of thumb: anything that looks normal goes through, anything that deviates goes to a person. It sounds cautious, but that split is exactly what produces the effect — in most flows, 80–95 per cent of cases are entirely ordinary.
What matters is that the system never guesses. A case that stops and is flagged costs you a few minutes. A case that is guessed wrong costs you confidence in the whole solution.
Let it run for three months, then measure again
Once it is running, compare against the number from step two. How many cases were handled? How many reached a human? How much time was freed, and what was it used for?
That last question is the one management will ask, and it is hard if you have not thought about it in advance. “We saved two hours a day” only becomes interesting when you can say what those two hours went into instead.
And then — then you can write the strategy
Once you have one process running and a measurement that holds up, you know three things you did not know before: how much work can actually be moved, what it costs in time to move it, and how your organisation reacts when it happens.
Only then does a strategy become something other than a document. Now it is built on your own numbers rather than somebody else’s.
The companies that get the most out of digital coworkers did not start with a big rollout. They started with one process, measured it, and then decided whether they wanted another.