Most organisations have already decided that AI matters. That decision is not the difficult one anymore. The difficult question is which piece of work deserves the organisation’s limited attention first.
That sounds like a prioritisation exercise. In practice, it is closer to a capacity decision. The first AI initiative determines which data gets cleaned, which process gets redesigned, which employees learn new ways of working, and which leaders become accountable for the result. A weak first choice can consume the same resources as a strong one while teaching the organisation very little.
Our view is that the best first use case is rarely the most impressive demonstration. It is the one that changes a repeated decision or workflow, has a clear owner, and can be improved through use.
The model is not the bottleneck
Teams often begin with capability. They ask what a large language model can summarise, draft, classify, or automate. That produces a long list of plausible ideas and very little guidance about what to do next.
Microsoft’s own guidance starts in a more useful place: identify business problems before selecting AI capabilities. It points to repeated manual effort, slow approvals, and gaps between expected and actual results as signals worth investigating. The purpose is not to produce an exhaustive catalogue of use cases. It is to create a common view of where the business needs a better outcome.
That distinction matters because an AI feature does not create value by existing. It creates value when it changes the economics or quality of work. A summary that nobody acts on is a demonstration. A summary that removes a review step, improves a handoff, or lets a specialist handle more cases is an operating capability.
Consider a claims team at a regional insurer. Adjusters spend part of each morning reading incident reports, policy documents, emails, and photographs before deciding whether a claim needs investigation. An AI system could summarise the file. That is easy to show and difficult to value on its own.
The more useful question is different: can the system identify missing evidence, explain which policy conditions appear relevant, and route the claim to the right level of review while leaving the adjuster accountable for the decision?
Now the mechanism is clearer. The system does not replace judgement. It reduces the time needed to assemble the facts around a judgement. An adjuster sees the relevant policy language and unresolved questions earlier. A straightforward claim may move through the queue without unnecessary escalation. A complex claim reaches a senior reviewer with a more complete file. The customer may receive a faster answer, but the larger gain is that scarce expertise is spent where it is needed.
The organisation also learns something valuable from the first deployment. It discovers whether policy documents are current, whether claim records are consistently structured, which exceptions matter, and where employees do not trust the proposed workflow. Those lessons affect every later use case.
This is why the first project should be judged partly by what it makes possible next. A narrow tool with a visible owner can expose the conditions for scale better than a broad assistant released across the enterprise.
The ownership problem
Prioritisation fails when every idea is evaluated as a technology request. Someone submits a request for an assistant, a chatbot, or an agent. The technology team estimates the work. A steering committee ranks the proposals. The business waits for an answer.
The missing unit is the business problem. Who is making the decision today? How often does it occur? What information is used? What happens when the answer is wrong? Which person owns the result after deployment?
These questions force trade-offs. A use case that saves time but touches sensitive data may need stronger controls than a less valuable internal search tool. A high-value process may still be a poor first choice if its rules change weekly or its data is spread across systems nobody owns. A modest workflow may deserve priority because its inputs are stable, its volume is high, and its outcome can be observed.
The intake process itself is part of the operating model. A structured route can capture the problem, expected outcome, data sources, dependencies, sponsor, and risks before implementation begins. Guidance on Microsoft 365 environments describes this kind of workflow using familiar tools such as Forms, SharePoint, and Power Automate, with requests assessed and routed against consistent criteria.
The point is not to create bureaucracy around every experiment. It is to prevent the opposite problem: disconnected experiments that duplicate one another, expose data, or leave useful ideas stranded because nobody has authority to move them forward.
The strongest objection is that formal prioritisation will slow adoption. Employees are already finding useful applications for AI. If every idea must pass through a central committee, informal tools may become faster and more attractive than the approved path.
That objection is valid. Governance that adds friction without improving decisions will be bypassed.
The answer is not to remove governance. It is to make the governed route proportionate and useful. A low-risk drafting experiment should not receive the same review as an agent that can update customer records or approve payments. The review should become more demanding as the system gains access to sensitive information, affects external parties, or acts without a human confirmation.
Microsoft’s guidance for AI agents makes the underlying issue explicit. Agents can access data, make decisions, and take actions across business systems, so their ownership, identity, lifecycle, observability, security, and data access need defined controls. The choice of a first use case therefore establishes more than a pilot. It tests whether the organisation can control a system once it begins to act inside real work.
The first choice teaches the organisation how to choose
A sensible first use case has three properties. The business consequence is clear enough to observe. A named team can change the workflow around it. And the organisation can contain the risk while it learns.
Those properties are more durable than a list of fashionable applications. They also change the conversation with employees. People are less likely to experience AI as a vague instruction to become more productive when they can see which part of their work is changing, which decisions remain theirs, and what support they will receive when the system is wrong.
The insurer in the example does not begin by asking how many claims AI can process. It asks where expert attention is being wasted, what evidence a reviewer needs, and which decisions must remain accountable to a person. That framing turns implementation into a redesign of work rather than the installation of a feature.
The importance of choosing first is therefore easy to underestimate. The first use case allocates technical effort, but it also allocates trust, managerial attention, and organisational learning. It can make later adoption safer and faster, or teach teams that AI projects produce activity without improvement.
The organisations that move well will not necessarily be those with the largest inventory of AI ideas. They will be the ones that can distinguish an attractive capability from a consequential problem, then give the second one a clear path to become ordinary work.