How to Score AI Use Cases Before Anyone Builds Anything

The easiest part of an AI programme is collecting ideas.

Ask a private markets team where AI could help and you will get a long list quickly. Investment committee prep. Portfolio monitoring. CRM hygiene. DDQ responses. Board pack summaries. NDA review. Fundraising materials. Meeting notes. Market maps. Pipeline updates. Internal knowledge search. The backlog fills itself.

That is useful. It is just not the point.

As I have said before, this is not about collecting hundreds of use cases, although that may naturally be the start. It is about delivering a few core use cases that people actively use. Not once in a workshop. Not once because the AI lead asked them to test it. Actually use. In the normal flow of work, when there is pressure, when the meeting is tomorrow, when nobody has time to admire the prototype.

The difference between an AI ideas list and an AI programme is a scoring model.

Not a heavyweight committee process. Not a spreadsheet that takes three months to maintain. Just a transparent way to decide what gets built, what gets parked, what needs unblocking, and what should be killed before it becomes another expensive demo.

01The backlog is not the strategy

A big use-case backlog can make an organisation feel productive. It looks like momentum. It gives leadership something to point at. "We have identified 147 AI opportunities across the business." Fine. Good start.

But a backlog is not a strategy.

In fact, an unscored backlog can become a problem. Every idea looks roughly equal. The loudest team gets attention. The most exciting demo wins. The most politically convenient use case gets prioritised. Meanwhile, the dull workflow that would save hundreds of hours every quarter sits untouched because nobody made it sound glamorous.

Private markets firms should be especially careful here. The highest-value AI use cases are often buried in ordinary work: comparing versions of documents, pulling facts from board packs, turning meeting notes into portfolio actions, checking whether an IC memo answers the obvious questions, routing DDQ requests, finding precedent language, summarising fund reporting packs, and keeping CRM data alive.

None of that sounds like science fiction. That is usually where the useful work is.

The job is not to ask, "Could AI do this?" The answer is usually "sort of". The better question is:

Could this become a repeatable, approved, trusted workflow that the team will still use in week six?

If the answer is no, do not build it yet.

02Score four things

I like scoring use cases across four dimensions:

1. Value
2. Feasibility
3. Risk
4. Adoption

Give each one a score from 1 to 5. Keep the language simple enough that the business can understand it without needing a consultant in the room.

For risk, the score should be reversed. A high score means the risk is manageable. A low score means the risk is high, unclear, or currently unapproved.

You can weight the model, but do not over-engineer it. A sensible starting point is:

That last category is where many AI programmes fall apart.

Teams are usually quite good at estimating value. They are sometimes good at estimating feasibility. They are getting better at talking about risk. But adoption is often treated as an afterthought, which is strange, because adoption is the whole game.

An unused tool is not "phase one". It is a failed project.

03Value: is the work worth changing?

Value is not only time saved, although that is a useful part of it. In a private markets firm, value can show up in several ways:

• hours saved on recurring work;
• faster turnaround during live deals;
• better quality of investment materials;
• fewer missed questions in diligence;
• lower operational risk;
• improved LP response quality;
• better reuse of firm knowledge;
• more consistent portfolio monitoring;
• fewer senior people doing low-leverage admin.

The best value test is frequency multiplied by pain.

A task that happens once a year and annoys everyone for two hours is probably not your first build. A task that happens every week, across five teams, with messy handoffs and visible frustration, deserves attention.

There is also a seniority multiplier. If a workflow saves junior analysts time, that matters. If it also improves the work that reaches a partner, IC, LP or portfolio board, it matters more.

A simple value scoring guide:

Do not let vague excitement score a 5. "AI could transform this" is not evidence. "This happens every Monday, takes three people half a day, uses the same source material, and causes delays" is evidence.

04Feasibility: can the approved stack reach the work?

Feasibility is where the romance usually dies, which is healthy.

A use case might sound brilliant until you ask where the data lives. Is it in SharePoint? Outlook? Teams? Salesforce? DealCloud? iLEVEL? A data room? A folder of PDFs? A protected finance model? Someone's desktop? A system with no API? A spreadsheet called final_final_v7?

The first feasibility question is not "which model should we use?" It is:

Can the approved tooling safely reach the inputs?

Then:

Can the workflow be repeated?

Can the output be checked?

Can the user run it without a specialist sitting next to them?

Can the process live where the team already works?

A lot of use cases fail because they need a beautiful AI system and the organisation can only currently support a controlled Copilot workflow, a Power Automate flow, and a SharePoint folder. That does not mean the idea is bad. It means the idea has to be staged properly.

Score feasibility honestly:

This is where a transparent assessment helps. People are much more patient with a blocked use case if they can see the reason. "Legal is blocking it" is vague and corrosive. "This needs client-confidential data from a system Copilot cannot access yet; IT is assessing connector options" is different. It gives the business something concrete.

05Risk: what has to be true for this to be safe?

Risk should not be a theatrical no. It should be a practical design input.

Some AI use cases are low risk. Summarising an internal meeting transcript for your own notes is not the same as generating external investor communications. Searching approved policy documents is not the same as making a regulated recommendation. Creating a first draft of a slide is not the same as changing a valuation model.

The scoring should consider:

• data sensitivity;
• external impact;
• regulatory relevance;
• reliance on factual accuracy;
• hallucination tolerance;
• audit trail requirements;
• human review points;
• whether the output changes a decision or just helps prepare one.

For private markets, I would be particularly cautious around anything that touches valuation, investor reporting, MNPI, client-confidential information, legal conclusions, regulated advice, or automated decision-making. That does not mean "never". It means the control design matters.

Risk scoring:

The question is not whether risk exists. It always does. The question is whether the risk is understood, proportionate and controllable.

06Adoption: will this survive contact with Tuesday afternoon?

Adoption is the category that saves you from building clever things nobody wants.

Score it properly. Do not assume adoption because the idea came from a senior person. Do not assume adoption because the demo worked. Do not assume adoption because people nodded in the meeting. Nodding is not usage.

Ask:

• Is the current pain strong enough for people to change behaviour?
• Does the tool live where the work already happens?
• Is there a named business owner?
• Are there champions in the team?
• Can the old process be retired or reduced?
• Is the output obviously better, faster or safer?
• Can a normal user operate it after a short training session?

If the answer to most of those questions is no, the use case may not be ready.

Adoption scoring:

This is where the best AI consultants become slightly annoying in a useful way. They ask who will use it. They ask when. They ask what happens to the current process. They ask what the week-six metric is. They ask what would make the team quietly stop using it.

Those questions are not pessimism. They are how you avoid orphaned tools.

07Make the assessment visible

The scoring model only works if people trust it.

That means the assessment should be transparent. Not necessarily public in every detail - some use cases will involve sensitive systems, clients or internal priorities - but transparent enough that the business understands how decisions are being made.

People should be able to see:

• which use cases have been submitted;
• how they are scored;
• what is being developed;
• what stage each use case is in;
• what is blocked;
• why something has been parked;
• who owns the next step.

This is often overlooked. Firms spend time collecting ideas, then the whole process disappears into a steering group. Three months later someone announces two pilots. Everyone else wonders what happened to their idea.

That is bad adoption design.

Transparency with the whole business matters because AI adoption is partly social. People want to see what other teams are building. They want to reuse patterns. They want to know that their idea was considered properly. They want confidence that the programme is not just a black box controlled by IT, compliance or one enthusiastic sponsor.

The pipeline should be visible, even if some details are restricted.

08Use stages, not vibes

Every use case should have a stage. My preferred stages are:

The important thing is that "prototype" and "embedded" are not treated as the same thing.

A prototype proves that something can be shown.

An embedded workflow proves that something can be used.

That distinction saves a lot of wasted build time.

09What gets built first?

Once the scoring is done, the prioritisation is usually obvious.

Start with high-value, high-feasibility, manageable-risk, high-adoption use cases. These are your first wins. They build trust. They create internal examples. They give champions something real to show.

Then look at high-value use cases with one clear blocker. These are worth unblocking if the prize is big enough. Maybe the data connection is missing. Maybe the approval route is unclear. Maybe the team needs a better source library. Maybe the vendor landscape needs reviewing. Fine. Give the blocker an owner and a deadline.

Be ruthless with low-adoption use cases. If nobody owns it, nobody feels the pain, and nobody will change the workflow, do not dress it up as innovation. Park it.

And be comfortable killing ideas. A killed use case is not failure if the assessment saved the firm from wasting time.

10The output

The output of a good scoring process is not a longer spreadsheet. It is a business-wide view of the AI pipeline:

• the few use cases being actively delivered;
• the next set being unblocked;
• the ideas parked for later;
• the tools and data gaps that keep appearing;
• the teams with strong champions;
• the workflows that are actually changing.

These are great examples of how AI adoption can become much more practical.

Collect the ideas, yes. Encourage the business to bring forward the messy, annoying, repetitive work. But then score the ideas in the open. Show the trade-offs. Tell people what is being built. Tell them what stage it is in. Tell them why something is blocked. Tell them when it moves.

The goal is not a giant use-case register.

The goal is a small number of AI workflows that are trusted, governed and used.

The rest can wait.