The most expensive mistake in AI adoption is choosing the technology first and then hunting for somewhere to put it.
A pattern I keep seeing is that an organisation buys a Copia lot licence or starts a Foundry environment, then holds a workshop to identify cases. The workshop generates forty ideas on sticky notes. Three of them get built. None of them changes anything.
The workshop is not the problem. The direction is. Starting from capability and searching for application produces ideas that are technically interesting and organisationally weightless.
Two axes, and only two
Every useful prioritisation I have seen reduces to the same pair of questions. What is this worth if it works, and how likely are we to actually get it working here? Everything else is decoration.
The top left quadrant is where good programmes go to die: high value, low readiness. Contract risk review is the classic: obviously valuable, obviously appealing to executives, and completely dependent on document management that nobody has touched in eight years. Teams start there because the value is exciting, then spend 9 months on data remediation that nobody scoped or funded.
Bottom right is the opposite trap. Meeting summaries work on day one, need nothing from anyone, and produce a benefit that is real but hard to bank. There is nothing wrong with them. They should not be your flagship, because when the board asks what AI delivered, no CFO has ever been moved by a summarised meeting.
What readiness actually means
Readiness gets treated as a vague sense of organisational maturity. It is more concrete than that, and it is worth being blunt about the components.
Is the data reachable today? Not could it be, with a project. Can a person with the right job title open it right now? If the answer involves a migration, an integration, or a data warehouse, you have found the actual project; it is not an AI project.
Are the permissions honest?. If the source is SharePoint and half the estate is shared with everyone, then grounding an assistant on it will surface things people should not see. Copilot respects existing permissions, which is the problem: your existing permissions are the problem.
Does one named person own the process? Not the system. The process. The person who decides how bids are written or how claims are triaged. If that person is not in the room, you are building something that will be politely ignored.
A scoring sheet you can defend
Steering groups reject ideas for bad reasons and approve them for worse ones. A visible scoring sheet does not remove politics, but it does force the argument into the open, which is usually enough.
The fourth question, “Would failure be visible?” is the one people ask. It sounds negative. It is the most useful item on the sheet. If an assistant stopped working tomorrow and nobody raised a ticket, then nobody depended on it, and any benefit you claimed would be real. Visible failure is evidence of genuine use.
Mapping candidates to Microsoft capability
Once you have a shortlist, the platform question mostly answers itself. The mapping below is not a rule but a reasonable default that saves a lot of circular architecture debate.
| Shape of the task | Where it usually lands | Why |
|---|---|---|
| Answering questions from documents the person can already open | Microsoft 365 Copilot, or an agent built in Agent Builder | Grounding through Microsoft Graph, permissions inherited, no build effort |
| A repeatable workflow across two or three business systems | Copilot Studio | Connectors, approval steps, and lifecycle management across environments |
| Classification or extraction at volume, with quality targets | Microsoft Foundry | Model choice, evaluation tooling, and a hosted runtime you can tune |
| Analysis across data that lives in several systems | Fabric first, then anything | The blocker is the data estate, not the AI |
For the practitioners
- Run the readiness check with SharePoint data access governance reports and Purview data risk assessments before you commit to a use case. It converts an argument about readiness into a report.
- Score volume honestly. A task that happens forty times a day is worth more than a task that happens twice a week, even when the second one feels more strategic.
- For anything involving unstructured content, check whether sensitivity labels are enabled for SharePoint and OneDrive. If they are not, label-based protections will not apply to the content your agent reads.
- Write the use case as a sentence in the form: when X happens, instead of a person doing Y, the system does Z and a person checks it. If you cannot write that sentence, the use case is not defined yet.
The discipline is saying no.
Most organisations do not have an idea shortage. They have an attention shortage. The people who understand a process well enough to change it are the same people who are already fully committed, and every additional initiative further dilutes them.
So the prioritisation exercise is really a rationing exercise. Three use cases, properly owned and properly measured, will produce more evidence in six months than fifteen half-supported experiments will in two years. And evidence is the thing you need, because the second wave of funding depends entirely on whether the first wave produced a number anyone believes.
The four ideas that come up in every workshop
Run enough of these sessions, and the same suggestions appear, in roughly the same order, in every organisation regardless of sector. They are worth addressing directly because they consume a lot of the available enthusiasm.
A chatbot on the public website. Universally popular, and among the worst possible starting points. It is customer-facing, so errors are visible externally. It needs content that is accurate and up to date, which almost nobody has. And Microsoft’s own guidance is explicit that public-facing agents must not access internal business data, which means building a separate content estate: high effort, high exposure, modest benefit.
Search across everything. Sounds like a foundational capability. In practice, it is a request to make an unremediated content estate more findable, which is the exposure problem described in the next post arriving early and by request.
Automating the thing nobody understands. There is usually one process that a single long-serving person runs, that nobody has documented, and that everyone would love to automate. The reason it is a candidate is the reason it will fail: you cannot specify what you cannot describe.
Meeting summaries and note-taking. Genuinely useful, genuinely easy, and worth doing. Just do not fund it as a strategic initiative, because it will not survive being asked to justify itself in those terms.
How to run the session so it produces something.
The mechanics matter more than they should. A few adjustments consistently improve the output.
- Invite the people who do the work, not only the people who manage it. Managers describe processes as they are documented. Practitioners describe them as they happen, and the gap between those two is where the opportunity usually sits.
- Ask what takes too long rather than where we could use AI. The second question produces answers shaped by what people have seen in demos.
- Insist on a recent concrete example for every idea. Not a category of work, an actual instance from the last fortnight, with the actual documents involved.
- Score in the room, visibly. Ideas that nobody will defend when a score is attached to them are ideas that were never going to get delivered anyway.
- End with three, not with a long list. A long list is a way of avoiding the decision, and it guarantees that the decision gets made later by whoever is most persistent.
One further note. The exercise is more useful if you also identify what will stop, because a use case that adds a step without removing one is a cost increase with better technology attached.
What to take away
- Prioritise on value and readiness. Ignore novelty entirely.
- Treat high-value, low-readiness as a data project with an AI outcome, and fund it as such.
- Insist on a named process owner before a use case enters the shortlist.
- Use a visible scoring sheet so that rejections are arguments about criteria rather than about personalities.
- Cap the shortlist at three. The constraint is attention, not ideas.
