Step 1: List the workflows that already cost you
Start with work, not technology. Write down the workflows in your business that already consume real time or money: claim triage, contract review, first-line support, reconciliation, document intake. You want tasks with volume and a cost you can name, because volume is what makes automation pay and a named cost is what lets you prove it did. Skip anything you are only considering because it would be interesting to try AI on. Interesting is not a business case. The output of this step is a short list of expensive, repeatable workflows, each with a rough sense of how much time or money it eats today.
Step 2: Attach a metric to each one
For every workflow, name the number you would move: hours per case, cost per transaction, time to resolution, error rate, backlog age. If you cannot attach a metric, drop the workflow from the list. This step is where most candidate use cases fall away, and that is the point of the method. A use case without a metric cannot be judged, which means it cannot be defended when someone asks whether it was worth it. Be specific about the baseline too. Knowing a workflow takes an average number of minutes per case today is what lets you claim a reduction later. The output is a shorter list where each item has a measurable target and a starting point.
Step 3: Name an owner for each outcome
Assign one person who is accountable for the outcome, not a steering committee. The owner is the one who will decide whether the result was worth it and who will answer for it in production. A use case without an owner is a use case that will stall the first time a hard decision is needed, because no one has the authority or the incentive to push it through. The owner should be close enough to the workflow to feel its pain and senior enough to change how it runs. The output is a list where every item has a single name next to it, and every name has agreed to it.
Step 4: Check the honest path to production
For each remaining candidate, ask what it would take to run it for real: who can see the data, what has to be logged, what controls a regulated setting requires, and whether the data even exists in a usable form. If the honest answer is that you have no plan for those, the use case is not ready, however good the demo would look. Data readiness usually bites here. A workflow that depends on data scattered across systems with no clean access path is a longer project than it looks. The output is a list scored by how close each item is to something you could actually ship this quarter.
Step 5: Pick the narrow winner and scope 30 days
Choose the candidate with a clear metric, a named owner, real data, and the shortest honest path to production. Scope a first governed workflow you can ship in about 30 days: one workflow, one owner, controls in place, the metric instrumented from day one. Value that is narrow and provable beats a broad ambition every time, because narrow ships and broad debates. Resist the urge to widen the scope before the first version is live and measured. Every feature you add before launch is a week you add before proof. The output of the full method is one use case you can start on Monday and measure by the end of the month, plus a ranked backlog of the runners-up for when it works.
A worked example: claims triage
Run the method on one workflow to see how it behaves. Step one: claims triage makes the list, because a team spends real hours reading each incoming claim to decide where it goes. Step two: the metric is average minutes to route a claim, with a baseline you can pull from current handling times. Step three: the owner is the claims operations lead, who feels the backlog and can change how routing works. Step four: the honest path to production needs read access to claim documents, a log of every routing decision the system makes, and a human check on any claim it flags as high value or ambiguous, all of which are achievable because the data already sits in one system. Step five: scope a 30-day build where the system proposes a route, a handler confirms it, and you measure minutes saved against the baseline. That candidate has a metric, an owner, real data, and a short path, so it wins over a flashier idea like a customer-facing assistant that would take two quarters and touch data you do not yet control. The method does not pick the most exciting use case. It picks the one you can prove.
Where the method fails
The method fails in one predictable way: a team runs the steps, finds that its most exciting idea has no clean metric or no usable data, and picks it anyway because it is the one leadership already fell for. Resist that. The whole value of the method is that it tells you no early and cheaply, before you have spent a quarter proving what a week of honest scoping would have shown. If nothing on your list survives all five steps this quarter, that is a finding worth reporting, not a failure to hide. It usually means the data work has to come first.