How to choose your first AI use case

Start with a task, not a department

“AI for sales” is too broad to fund sensibly. “Prepare a draft account brief from approved CRM notes before a discovery call” gives you an input, an output and a user. Watch the current task happen before selecting a tool. Record where people search, copy information, wait for approval and correct mistakes. Sometimes the biggest delay sits outside the activity AI can help with.

Ask the person doing the work what a good result looks like. Ask the manager what happens when the result is wrong. These answers reveal whether you are improving a convenience, a bottleneck or a decision with serious consequences. Those are different project classes and should not share the same approval threshold.

Score the opportunity on five dimensions

Use a simple one-to-five scale for frequency, avoidable effort, input readiness, ease of checking and reversibility. Keep the scores visible rather than combining everything into an impressive but opaque number. A frequent task with clean inputs may be attractive even when each instance is small. An occasional task with messy records may consume more implementation effort than it returns.

Estimate net effort, including preparation and review. If drafting takes ten minutes but checking the draft takes fifteen, the workflow has not improved. Compare the proposal with ordinary alternatives too: a better form, a saved search, an integration or clearer responsibilities may solve the problem more reliably.

Treat uncertainty as a design input

The NIST AI Risk Management Framework provides a useful broad structure for governing, mapping, measuring and managing AI risk. For a first project, translate that into concrete questions: who is affected, which errors matter, what evidence is required and who can stop the workflow? This is a voluntary reference framework, not a certification of your proposed system.

A narrow scope makes those questions easier to answer. Limit the first version to approved documents, internal users and draft outputs where appropriate. Do not quietly expand the task from summarising information into making commitments on behalf of the business.

A hypothetical shortlist

Imagine a building-products supplier considering three ideas: an internal product-information assistant, automatic customer quotations and a weekly enquiry summary. The quotation idea sounds commercially attractive, but prices, installation conditions and exceptions require careful controls. The enquiry summary may be a better first experiment if the inbox export is available and the sales manager can judge its usefulness.

The product assistant could follow once the team has resolved conflicting specification sheets. This sequence is not a ranking of AI sophistication. It is a way to learn about data quality, review behaviour and ownership before giving a system greater responsibility. No performance improvement should be assumed until measured.

Write a one-page selection brief

Before building, put the candidate through a short decision meeting. The brief should be understandable without a technical presentation. Include one real input, an example of an acceptable output and an example that must be rejected. Agree who supplies the baseline and who evaluates the pilot.

• Name the exact task, its owner and the users who will test it.
• List approved inputs and information the system must not use.
• Define success in terms of quality and total human effort.
• Document the most consequential failure and the fallback process.
• Set a review date with explicit continue, revise and stop options.

Choose for learning as well as value

A good first use case teaches your team how to evaluate AI in its own operating environment. OpenAI’s evaluation guidance emphasises task-specific tests; the business implication is straightforward: judge the workflow against your work, rather than a generic model ranking. Save representative examples so future changes can be compared consistently.

Proceed when the owner, inputs and quality standard are clear. Narrow the scope when value seems plausible but checking is difficult. Defer when nobody can explain how an incorrect result would be detected. Ambition becomes more credible when the first commitment is precise enough to keep.