How to spot AI use cases and tie them to management KPIs

Two separate skills, and most companies are missing one of them. Teams that spot good use cases cannot get them funded. Teams that start from the KPI pick projects nobody in the work actually wants.

You need both, in that order: find it in the work, then walk it up to the number.

Part one: where use cases actually hide

Stop asking "where could we use AI". Nobody knows. Ask instead what people are doing that is repeated, and contains a judgement step.

Four signals, in rough order of how reliable they are:

Somebody rewrites the same kind of thing every week. Quotes, handover notes, customer replies, incident summaries. Rewriting means the shape is stable and the content varies — which is exactly the shape a model fits.

Information is copied between two systems by a person. Every manual re-entry is a place where the source and the destination disagree about format, and a person is doing the translation in their head.

The answer exists but nobody can find it. "Ask Marc, he'll know" is a retrieval problem wearing a human face. It is also a risk: Marc leaves.

Work waits in a queue for one person's judgement. A bottleneck at a single reviewer usually means the easy 70% could be prepared for them.

And one strong counter-signal: if the task is done once a quarter, skip it. Not enough repetition to learn from, and by the next occurrence everyone has forgotten how it worked.

Do this with the team, not about them

Ten minutes in a normal team meeting, twice:

"What did you do last week that you have done many times before, and that needed you to decide something rather than just follow steps?"

Then, a week later, the more revealing one:

"What did you not get to, because that took the time?"

The second question is where the KPI lives. The task itself is a cost; the thing it displaced is the value.

Part two: walking it up to a KPI

A director funds a number they are already accountable for. So the exercise is not "invent a metric" — it is to find the shortest honest path from the task to a number that already exists in a report.

The chain has three links, and it must be genuinely causal at every step:

the task changes  ->  something measurable moves  ->  a reported KPI moves

Worked example:

If you cannot fill the right-hand column, you have a nice improvement and no business case. That is a fine thing to know in an afternoon.

Three tests before you take it to management

The report test. Point at the report the KPI already appears in. If it does not appear in one, you are asking for a new measurement system as well as a new tool, and you have doubled the size of the ask.

The owner test. Name the person whose review that KPI appears in. Not a department — a person. If nobody owns the number, nobody will defend the project when it needs three more weeks.

The counterfactual test. Write down what the KPI would have done anyway. Seasonality, a new hire, a big customer. Do it before you start, because afterwards everyone remembers the baseline being flattering.

Sequencing when you have several

You will end up with five candidates. Rank them by:

1. Frequency — weekly beats monthly, decisively.
2. Distance to the KPI — how many links in the chain, and how honest each is.
3. Whether the person doing the work wants it.

The third outranks the other two more often than people expect. A mediocre use case the team is enthusiastic about will beat an excellent one imposed on them, because adoption is the binding constraint, not capability.

What to present

One page, in this order: the task, who does it and how often, the measurable, the KPI, the owner, the baseline, and what you will do if it does not move. That last line is what separates a proposal from a pitch — and it is what makes the next one easier to get approved.