Start With the Number, Not the Tool: How I Scope AI Use Cases

Technology is question six of seven. That is the single most useful thing I can tell you about AI use case scoping, and it is the part most teams get backwards.

On a recent 12-week agentic AI and automation programme with a global enterprise, nobody opened Power Automate or Copilot Studio in week one. Every delegate completed a seven-question scoping worksheet for a real process they owned instead. Nobody moved on until they could name a real person, a real process and a measurable outcome.

Twelve weeks later, the solutions that landed best with the sponsor were not the most technically ambitious. They were the ones with a before and after number on screen.

What AI use case scoping actually is

AI use case scoping is the work of defining a real business problem, who it affects, how the process runs today and what measurable outcome would count as success, before any technology is chosen. Done properly, it produces a baseline number and a target. That pair of numbers is what makes the result provable later.

It sounds obvious. In practice, most AI projects I see start at the other end: someone has a licence, a tool or a demo they liked, and goes looking for a problem to point it at.

Why most AI programmes measure the wrong thing

Ask an organisation how its AI programme is going and you will usually hear about adoption. Licences assigned. Prompts run. People trained. Those are inputs. None of them tells you what the work cost before and what it costs now.

Microsoft made the same point about its own transformation in September 2026. One of its sales teams stopped pushing adoption harder and started from the business goals, mapping how people actually spent their week. The business results followed the outcome focus, not the usage push. It is worth reading in full: What we’ve learned from Microsoft’s own AI transformation.

If Microsoft, with every tool and every licence it could want, had to learn that lesson, the rest of us should not expect adoption figures to do the job either.

The seven questions

The worksheet is deliberately short. Forty minutes for a first draft, then revisited every week of the programme.

1. Problem statement. One to three sentences on a real, named problem. Specific beats ambitious.
2. Beneficiary. The person or named role who is better off if this is solved. If you cannot name them, choose a different problem.
3. Today’s process. Step by step, end to end. Who does what, where the data lives and how long each step takes.
4. Outcome metric. One sentence naming the measurable outcome, with a baseline and a target.
5. Position on the automation spectrum. Deterministic, assisted or agentic, with a one-line justification.
6. Technology shape. Up to three technologies the solution might use. A sketch, not a commitment.
7. Governance one-liners. Who owns the data, who approves, what must never happen.

Why technology sits at question six

The ordering is deliberate. By the time you reach question six you already know the problem, the person, the process and the number. The technology choice is then a consequence, not a starting point.

It also stops a common and expensive mistake: reaching for an agent when a rules-based flow would do. Question five forces that decision. A good share of the use cases in that cohort turned out to be deterministic or assisted, not agentic, and were better for it. Cheaper to build, easier to govern and simpler to explain to the person who has to approve them.

What a good baseline looks like

The difference between a weak outcome metric and a strong one is usually one number.

A typical first draft reads something like: shorten the time it takes to resolve requests. Nobody can argue with it, and nobody can prove it either. There is no baseline, no target and nothing to put on screen in twelve weeks’ time.

Compare that with a draft from the same cohort: a monthly leadership KPI report taking around 20 hours to produce, with a target of eight hours or fewer. Or a failed invoice investigation taking roughly two hours per case, with a target of under 30 minutes. Both were estimates at that stage, and labelled as estimates. That is fine. An honest estimate gives you something to measure against. A vague aspiration gives you nothing.

The baseline does not need to be precise in week one. It needs to exist.

What happened twelve weeks later

The numbers below are the client’s own, approved for sharing, and I present them with the labels they deserve.

• One contract screening flow is set to replace around 1,500 hours a year of manual clause review.
• Another solution is projected, by the client’s own sponsor, to save in the region of $400,000 a year.
• Two delegate-built solutions were in production by the final session, with five more heading that way.

Those figures are client-reported projections, not yet measured results. I say that every time I quote them, and it has never once weakened the point. Audiences that matter can tell measurement from marketing, and the caveat is how they tell which one you are.

What I can say with confidence is this: every one of those numbers traces back to a baseline written down in week one, before a single flow was built. Without the scoping, there would have been working solutions and nothing to say about them.

Where scoping sits in The Gethyn Method

Scoping is the first of four stages in the framework I use for every capability programme: Scope, Build, Govern, Prove.

People develop new skills by solving a real business problem, with governance and evidence built in from the start. The organisation gets two things from the same activity: people equipped to solve the next problem, and a governed solution with evidenced outcomes.

The last stage only works if the first one was done properly. You cannot prove a benefit against a baseline you never wrote down. And every outcome carries one of four labels: measured, client-reported, estimated or aspired-to. The label travels with the number wherever it goes.

Try it on one process this week

You do not need a programme to start. Pick one process you own and answer the first four questions only.

1. Write the problem in three sentences or fewer, without naming any technology.
2. Name the person who benefits. A real name or a real role.
3. List the steps as they happen today, with a time against each one.
4. Add up the time. That is your baseline. Now write a target next to it.

If you cannot complete step four, you have found the first job. It is a better use of the next fortnight than another tool evaluation.

The takeaway is simple. AI use case scoping is not the paperwork before the real work. It is the part that decides whether you will have anything to show for the real work at the end.

Walk through the worksheet with me

I am taking people through the scoping method live in a free 45-minute session on Friday 9 October 2026, part of a four-week Friday series, Agentic AI Without Code, Live, which starts on 25 September. Bring one process you own and you will leave with the first four questions answered. Register for the free Friday sessions.