Choosing an AI use case is a business decision that gets treated as a technical one. The workflow you pick determines the cost, the risk, the integration work, and whether anyone uses the result. All of that is settled before a single line of code exists.

Most teams pick badly for an understandable reason: they choose the workflow that is most visible rather than the one that is most tractable. Visible work is usually customer-facing, judgement-heavy, and expensive to get wrong. Tractable work is usually invisible, repetitive, and owned by someone who would be glad to stop doing it.

What a good use case looks like

Five conditions do most of the work. A workflow that meets all five is worth scoping properly. A workflow that misses two or more is usually telling you to fix the process first.

1. It repeats often enough to matter

Automation recovers its cost through repetition. Work that happens daily can justify a build that work happening quarterly never will. Count the actual frequency rather than the perceived annoyance, because the two are frequently unrelated. The most irritating task in an operation is often not the most expensive one.

2. The inputs are consistent enough to reason about

Consistent inputs make exceptions countable, and countable exceptions can be designed for. When every input differs, scoping becomes open-ended discovery and the estimate stops meaning anything. The MIT Project NANDA report on stalled AI projects attributes much of the failure rate to brittle workflows and misalignment with day-to-day operations, which is what input variance produces in practice.

3. Somebody owns it

An owner defines what the exceptions are, decides what good output looks like, approves the new version, and is accountable for whether the team adopts it. Workflows that cross three departments with no single owner stall in review even when the technology works perfectly.

4. You can measure what it costs today

Without a baseline there is no way to judge the result, and the baseline disappears the moment the new process starts. Count people, hours, rework, and delay before anything changes. Our process cost calculator exists because this number is the one most teams have never written down.

5. A wrong answer is survivable

Error tolerance is a design input, not a quality target. Work where a mistake is caught easily and costs little can run with light review. Work with legal, financial, or safety consequences needs a person on the decisions that carry the risk, which is a legitimate design but changes the achievable time saving. Decide this at the start so it is priced in rather than discovered.

Where teams go wrong

Choosing the demo instead of the workflow

A use case selected because it looks impressive in a board meeting optimises for the wrong audience. The audience that matters is the team who will use the thing on a Tuesday in month seven.

Picking work nobody has defined

If three people do the task three different ways and all three are considered correct, the process has not been agreed. Automating it means choosing one version and imposing it, which is a management decision wearing a software costume. Make the decision explicitly first.

Assuming the problem needs AI

A large share of workflows framed as AI problems are integration problems, database problems, or removed-step problems. Those solutions are cheaper to build, cheaper to run, easier to trust, and fail in predictable ways. AI earns its place where genuine judgement over unstructured input is required. If the rules can be written down, write them down.

Starting where the data is worst

Teams often target the messiest corner of the operation because it hurts the most. That corner is usually messy for reasons that will also defeat an automated system. Starting somewhere tractable builds the internal credibility needed to attempt the hard one later.

A practical way to run the selection

This takes an afternoon and saves months.

  • List every recurring manual workflow anyone can name. Aim for breadth, not quality, at this stage.
  • For each one, write the frequency, the number of people involved, and a rough annual cost. Estimates are fine, and the ranking rarely changes once real numbers arrive.
  • Strike anything without a clear owner, then anything where the inputs are different every time. This usually removes half the list.
  • Of what remains, mark the error consequence for each: trivial, costly, or serious. Serious does not disqualify a workflow, but it means designing the review step as part of the system.
  • Check integration access for the top three. A workflow that depends on a system with no API and no export moves down the list regardless of how attractive it looked.
  • Pick one. Agree the measure and the baseline in writing before any build begins.

The use case scorecard turns this into eight questions if you would rather work through it that way.

When the answer is not to build

A selection process that never returns no is not a selection process. Deciding against a build is a result, and it is the cheapest result available. The common versions are that the process needs defining before it can be automated, that an existing product already covers it, or that the annual cost is simply too small to justify anything.

That last one deserves more attention than it gets. A workflow costing a few thousand dollars a year does not justify a custom build no matter how annoying it is, and the honest advice is to leave it alone or fix it without software.

Once a workflow clears this filter, the questions change from selection to delivery: integration, permissions, running cost, and review design. Those are covered in why AI pilots stall before production.