Scoping a use case

The question of what you could do with AI rarely produces a first project. The question that does is smaller: which route goes round the same loop here often enough that everyone feels it. A use case is that route, with a beginning, an end and somebody who suffers from it.

That is why we do not start with an inventory of the whole organisation, but with one route: how often it runs, what it costs and who walks it every time. A list of forty opportunities answers none of those three.

The first two signals are volume and repetition. Something that comes round daily or weekly rather than quarterly, and that takes the same steps in the same order every time: something arrives, somebody looks something up, copies it across and books it. The gain from an automation is the gain per run multiplied by the number of runs, and that second number does most of the work.

Then comes the question of whether the rules can be said out loud. Not somebody having a quick look, but: if the invoice number matches and the amount falls inside the margin, book it. Exceptions are fine, as long as you can name when you are in one. If you can explain it to a new colleague without sitting down beside them, you can put it into code as well.

It also helps if somebody can name the hours. If nobody in the company can say how long this work takes, that is information in itself: usually the work is spread across a lot of people, and then counting is the first step and building the second.

And there has to be somebody who wants it. A route without an owner produces no answers the moment a question comes up during the build, and those questions come. The best first case is one where the person doing the work today sits next to you now and again.

Count how often the route runs per week and how many minutes it takes for the people who walk it. Twenty times a week at twelve minutes each is four hours. That is the ceiling on what there is to gain, because there is always checking left over.

Then pick a number you can verify afterwards. Hours can be counted. More grip and less noise cannot, and a project sold on those ends in an argument nobody can win. Name that number in the diagnostic call, and you know what you will be looking at two weeks later.

The clearest example is the route that touches five departments and hangs off three systems that know nothing about each other. That is where the most is to be had in the long run, and precisely why it is wrong as a first project: you are months in before anybody sees something work, and by then half the assumptions no longer hold.

Harder to spot is the route whose rules live in one person's head and differ per client. That can be built, but then the project starts with writing those rules down, and that is a different project with a different lead time. Say so up front and it is a choice rather than a disappointment.

And then there is the category with no route at all: an AI strategy, an innovation track, a pilot without an owner. What goes wrong there is almost never the model, but a question that was never made small enough. Of the AI pilots at large companies, 95 out of 100 return nothing, and companies that hand the build to a specialist succeed twice as often as companies that try it themselves (MIT NANDA, The GenAI Divide, 2025).

We scope down to one route and give a price for it up front. Within two weeks a working first version runs on real data of yours, in an environment where nobody panics if something goes wrong. No presentation and no report.

That first version runs alongside the existing process first. You put what the people doing it today would have got out of it next to what the system produced, and only once that is the same answer does it go live. After that you decide which route is next. The second one is usually a good deal quicker, because the connections are already in place.

Two weeks is achievable through the scoping, not through working harder. What fits inside it is a route with a clear trigger, a handful of steps and an outcome somebody can check.

The exception is part of that. If the system sees something that does not match what it expects, the case goes to a person with the reason attached. That is the design and not a shortcoming: a system that handles everything also handles the cases it does not understand.

Beyond that, the final check and anything that goes out or moves money stay with a person. And then there are the pieces of work where we establish together in the conversation that automating them costs more than it returns. We say that in the conversation, not at the handover.