How to Choose Your First AI Use Case

The first one sets the pattern

The first AI use case an organisation delivers matters far more than its direct return. It establishes what the organisation believes is possible, who the internal advocates are, and whether the path from idea to production exists at all. Choose badly and you spend the next two years explaining why AI did not work here.

The instinct is to pick the most exciting use case. The better instinct is to pick the one most likely to reach production and be used.

Five criteria

1. It improves a decision that is already measured. If the organisation already tracks the number, you will not spend three months arguing about whether the benefit was real. Forecast accuracy, cycle time, rework rate, downtime and quote conversion are all good candidates because the baseline already exists.

2. The data is available and owned. Not perfect, available. Ask a simple question: could we pull the last two years of this data today, and is there a named person accountable for its quality? If both answers are no, the project is a data project with an AI label.

3. The process owner wants it. Enthusiasm from the technology function is not sufficient. The person who owns the process being changed must want the change and have the authority to make it. Without that, you will produce a tool that nobody adopts.

4. The consequence of being wrong is manageable. For a first use case, choose somewhere a human reviews the output before it takes effect. This keeps the assurance conversation proportionate and lets the organisation build trust in stages.

5. It is repeatable. Prefer a decision made weekly by many people over one made annually by the executive. Frequency is what turns a tool into a habit, and habit is what turns a project into a capability.

What to avoid first

Avoid anything customer facing and unsupervised. Avoid anything that requires integrating four systems that do not currently talk. Avoid anything whose benefit case depends on headcount reduction, because it will be resisted from the first day and you will learn nothing about whether the technology works. And avoid the enterprise platform selection as a starting point. Platforms are a consequence of demand, not a source of it.

Frame it properly before you build

Write a one page brief before any work starts: the decision being improved, the current measure and baseline, the target, the data required and its owner, the process owner, the assurance tier and what changes operationally if it succeeds. If the brief cannot be completed, the use case is not ready, and the discovery has cost you an hour rather than a quarter.

This is the work DEFINE does in the StratDo® approach, and it is the step most often skipped because it feels like delay. It is not delay. It is the difference between a pilot and a capability.

After the first one

Once the first use case is in production, resist the urge to scale it immediately. Instead, document the path it took: intake, decision, data, build, assurance, deployment, support. That path is the asset. The second use case should take half the time of the first, and the fifth should be routine.

Organisations that build the path get compounding returns. Organisations that build pilots get a portfolio of demonstrations and an executive team that has stopped listening.