Where should we start?
That is probably the most common question I hear from business leaders once AI comes up. You understand AI will affect the business. You can see the possibilities. But the step from “we ought to do something with AI” to what should we actually do is considerably harder.
In my experience the question is nearly always asked at the wrong level. It gets asked as a technology question — which tool, which model, which vendor — when it is really a question about operations.
Why the technology perspective leads you astray
When you start with the technology, two things happen.
The first is that evaluation becomes impossible. You compare features against one another without having anything to compare them to. Two systems can both “handle documents”, but if you have not decided which document, in which flow and with what outcome, the comparison is meaningless. So you choose on instinct, or on price, or on who gave the best demo.
The second is that the solution ends up homeless. A tool bought without a defined task belongs to nobody in the organisation. Nobody misses it when it goes unused, and nobody can say whether it does any good. A year later it is a licence cost nobody dares cancel, because nobody quite knows what it does.
Both problems disappear if you reverse the order.
Look at the business instead
The operational perspective means starting by observing your own company, before you look at a single vendor. Three questions get you a long way:
Where do people spend a lot of time on recurring work? Not difficult work — recurring work. The distinction matters. Difficult work is usually exactly what needs a human. Recurring work is what looks the same on the fiftieth occasion as it did on the first.
Where is information moved by hand between email and the ERP? This is the single clearest signal. Every time someone reads something in one window and types it into another, work is happening that adds nothing in itself — it just moves data from one place to another, with a chance of error at every step.
Where do waiting times, duplicated work or avoidable errors arise? Waiting means somebody could not do their job because somebody else had not got to it. Often what is being waited on is a task that takes three minutes but sits in a queue for three days.
Where all three questions point at the same place, you almost always have the best first use case.
A fourth question few people ask
There is one more signal, and it is the one I tend to weight most heavily: which work does nobody own?
Every business has tasks performed by whoever happens to have time. Confirmations sent by whoever sees the email first. Follow-up done when someone remembers. That work rarely appears in any process diagram, it is not in anyone’s job description, and that is precisely why nobody can say how much time it takes.
It is also the work that causes the most friction, because quality varies with whoever happened to do it. And it is the work that meets the least resistance when automated — nobody defends a task they never wanted.
The signals, briefly
| Signal in the business | What it usually means |
|---|---|
| Someone reads in one window and types in another | Manual data transfer, high error risk |
| The queue grows during holidays and sick leave | The work depends on people, not on a process |
| The same customer question every day | The information is in the system but not accessible |
| Nobody can say how long the task takes | The work is unowned and therefore unmeasured |
| Errors are caught only afterwards | The check happens too late in the chain |
An example: Bruzaholms Bruk
Bruzaholms Bruk casts wear- and heat-resistant iron, and has done so on the same site since 1660. Around sixty employees, customers across Europe’s asphalt, concrete, mining and boiler industries, and delivery precision measured at 98.3 per cent.
“Introducing AI” as a project would have led nowhere here. What did exist was a concrete operational problem: orders arrive in every form, in several languages, as call-offs and as enquiries in the middle of a production stoppage at the customer. Every order has to be interpreted, matched to the right item and alloy, registered in Monitor ERP and confirmed.
The work is not difficult. It is repetitive, continuous and impossible to set aside — and it lands on the same people who are meant to be having the technical conversations with customers. Under heavy load or absence, the queue of unconfirmed orders is the first thing to grow.
That is an operational problem, stated in the operation’s own terms. That a digital coworker — Sussie — then takes on incoming orders, quality checks against agreements, same-day confirmations and recurring customer questions is a consequence of how the problem was framed, not the starting point.
The difference is not semantic. It determines whether you can measure whether it worked.
What not to look for
Knowing what makes a poor starting point matters just as much.
The unusual and complicated. There is a pull towards the hardest task — it feels like the worthiest test. But a task performed five times a year yields neither a time saving nor enough volume to judge the quality.
Anything without a clear outcome. “Get better at analysing the market” cannot be assessed for success. “Send the order confirmation the same day” can.
Anything that requires something else to change first. If the task depends on data that is wrong in the system today, no automation fixes that. It just gets it wrong faster.
Anything someone is proud of. Even where it is technically automatable, it is the wrong place to start. You need the organisation with you on the first step, not against you.
From observation to first step
The operational perspective gives you a candidate. The next question is how to take it from observation to something that actually runs — which is about measuring before you change anything, scoping tightly, and deciding where the boundary to the human sits. Per Videgren has written about that separately in How to get started with AI in your business.
But it begins here. Start from the operational problem — not from the technology.
That makes AI considerably easier both to understand and to start using.