How to choose your first enterprise AI use case

The most consequential decision in an enterprise AI program is made before any code is written: which workflow goes first. Choose well, and the first win funds and legitimizes everything after it. Choose badly, and the organization concludes — wrongly — that “AI doesn't work here.”

After running discovery sessions across finance, healthcare, insurance and accounting organizations, we use a simple filter: find the pain with the highest leverage that can be proven safely.

Look where the friction is visible

The best first use cases are rarely exotic. They are the workflows where people visibly spend hours searching, summarizing, reviewing, drafting, or moving information between systems. A service team assembling client context from four systems before every call. An operations team reading forty-page documents to extract six fields. A compliance team reviewing communications one by one.

If users can point at the pain without being prompted, adoption is half solved — they are already waiting for relief.

Score on two axes only

Discovery produces a list of candidates; the matrix that sorts them has two axes. Value: how much time or risk does this workflow consume, how many users does it touch, how visible is the result to leadership? Feasibility: is the data accessible, can value be shown with read-only access, is the scope narrow enough to prove in days rather than quarters?

The winner is almost never the highest-value item — it is the highest value among the clearly feasible. A 7/10-value use case that ships in two weeks beats a 10/10 moonshot that stalls in security review for six months.

Three tests before committing

First, the read-only test: can the POC demonstrate value without writing to any system? If yes, approvals accelerate dramatically. Second, the clear-user test: can you name the five people who will use it in the pilot? “Everyone” means no one. Third, the narrow-enough test: can you state success in one sentence with a number in it?

A use case that passes all three is important enough to matter and narrow enough to prove quickly — the exact combination that survives contact with a real enterprise environment.

Then stop choosing and start building

Selection paralysis kills more programs than bad selection. The framework above is designed to be completed in two focused sessions with business, technology, security and end users at the table — then move directly into a build. The second use case will be chosen with something the first one bought you: evidence.