“Where could we use AI?” is an easy question to answer. Almost every function has documents to summarise, information to find and messages to draft. A workshop can fill a wall with opportunities before anyone has decided which business problem deserves investment.
The resulting inventory is useful for exploration. It becomes a weak portfolio when the company ranks attractive demonstrations without examining the processes they are meant to improve.
I prefer a different opening question: which recurring operating problem would become easier to solve if the organisation had more reliable capacity to interpret information? That wording keeps the work visible and leaves room for the answer to be process repair, integration or a rule rather than AI.
The proposed intervention still has to work, fit the organisation and justify its cost.
Attention is scarce in particular places
A process may wait because someone must read a long document, reconcile inconsistent information or assemble evidence from several systems. AI can make some of that work easier. But not every delay is an interpretation problem.
A request may wait for an authorised decision, a physical part or missing customer information. Generating a faster summary does not remove those constraints. It can help a decision maker, but its value should be traced through the process rather than assumed from the task's time saving.
Locate the point where work waits or fails, then investigate competing explanations. Ask the people doing the work and inspect representative cases. Distinguish what is observed from what is inferred. The statement “engineering is our bottleneck” needs more evidence than a familiar complaint from another department.
This diagnosis also keeps AI investment proportionate. A better form or a dependable system connection may solve the problem without introducing a probabilistic component that needs continuing evaluation.
A worked service example
Consider a hypothetical industrial spare-parts service. Customers send incomplete descriptions, photographs and references from old manuals. Staff identify the correct component, check compatibility and prepare a quotation.
The team could start by buying an assistant to write quotations faster. Instead, it examines the journey from request to confirmed part. The most important unresolved question is whether the requested component has been identified correctly.
The diagnosis may reveal several causes. The catalogue uses inconsistent names. Customer requests omit the equipment version. Records in two systems disagree. Technical specialists repeatedly answer the same questions, while unusual compatibility decisions require their judgment.
Each cause implies a different response. Clean catalogue identifiers and an integration can remove avoidable ambiguity. Structured intake can capture the missing equipment version. AI may help interpret a description, retrieve possible matches and expose the evidence. Stable compatibility conditions may be handled by rules, while specialists retain responsibility for consequential exceptions.
The combined intervention is more interesting than the writing assistant because its mechanism connects to the service outcome. It might reduce clarification loops or make specialists' attention more useful. Whether it actually does so remains a question for evaluation.
Assistants and agents need the same economic test
An assistant can create substantial value while waiting for a person to initiate the task. A system that plans several steps and acts through tools may create more value in a suitable workflow, or more complexity than the work requires.
Do not use “agent” as a synonym for useful automation or “chatbot” as a synonym for failure. Describe the task, the actions permitted and the way success is checked. The architecture should follow that description.
In the service example, an assistant could prepare candidate parts with citations for a specialist. A bounded agent might retrieve records from authorised systems, request missing information through an approved route and update an internal draft. Neither should acquire permission to commit a customer to an incompatible part simply because it can complete several steps.
Evaluate the full process under the proposed arrangement. Measure time to a defensible identification, critical errors, clarification cycles, review effort and the effect on quotation or resolution. Compare it with an improved non-AI baseline. Include the cost of maintaining catalogue quality, integration and evaluation.
If the system saves ten minutes of retrieval but requires ten minutes of additional verification, it has not released net capacity on that measure. Other benefits may still matter, such as traceability or consistency, but they need their own evidence.
Make the scarce decisions explicit
The process owner should be accountable for the intended outcome and the changed work. Domain specialists should define important error classes. Data and technology owners should explain what can be supported. Risk and security functions should address the requirements of the proposed use.
Someone must be able to bring those decisions to a conclusion. That can be the existing operating leader with a delivery team; a new executive title is not a prerequisite. Where the problem crosses units, agree a sponsor and an escalation route rather than assuming collaboration will resolve every conflict.
Adoption also has a design. Staff need to know when to rely on the output, when to challenge it and how to handle an exception. A reviewer needs enough source information and capacity to perform the check. An acceptance button does not create either.
For a system that acts, write down the permitted actions and release rights. Test how it behaves with missing information, unavailable tools and conflicting records. A practical fallback belongs in the operating plan before wider use.
Fund the evidence that changes the next decision
The first investment may be diagnostic work or data repair. A later one may be an offline evaluation, a shadow trial or a limited deployment. Each stage should resolve a question whose answer can change the recommendation.
In the service example, an evaluation might first test whether candidate-part retrieval is reliable enough to help a specialist. A later trial could examine whether the combined workflow reduces clarification effort without increasing critical errors. Wider action authority would require additional evidence for the changed boundary.
Set review dates and conditional funding rather than promising that every selected opportunity must reach production within a fixed number of days. A delay may indicate a missing condition worth resolving. It may also show that the next increment of learning costs more than the opportunity warrants. Leaders need a way to choose between those possibilities.
Benefits should remain honest throughout. Released hours can create capacity. Cash savings require avoided hiring, a credible cost reduction or another realisation path. Faster service can create revenue only if demand and delivery conditions support it. Avoid counting the same improvement in several projects.
Return to the operating problem
At the investment review, ask the team to describe the original problem, the proposed mechanism and the evidence for choosing it over the alternatives. Then ask who will operate the changed process and what would cause the organisation to stop or narrow the intervention.
Those questions give the portfolio a stronger basis than the novelty of a tool. They also preserve ambition: a difficult process can be redesigned more deeply once the constraints and authority are understood.
The AI Opportunity Map supports this process. It helps record evidence, alternatives, delivery conditions and economics without claiming to rank every opportunity through a universal score. The useful result is a decision that the operating team can explain and a next step that can prove it wrong as well as right.