"We should be using AI" is a common starting point. It is rarely a good brief. The projects that deliver value tend to start somewhere much narrower: a specific decision or task that people make many times a day, and a clear way to tell whether it got better.

Start with the decision

Write down the decision or task you want to improve in one sentence. For example:

  • "Which incoming support requests need a senior engineer?"
  • "Which leads should sales call first this week?"
  • "What will demand for this product line be next month?"

If you can't write the sentence, the use case isn't ready yet.

A worked example

A support team of twelve handles around 400 tickets a day. Senior engineers spend part of every morning sorting the queue.

  • Decision: which tickets need a senior engineer today?
  • Data: two years of tickets with their final category and who resolved them — the history a classifier can learn from.
  • Baseline: how long triage takes now, and how often tickets are reassigned after the first pass.
  • Pilot design: the model suggests a route and a confidence; agents accept or change it; changes are logged as training feedback.

That is a use case that can prove or disprove its value in a few weeks. It might be built as a machine learning classifier or with a large language model, depending on how varied the tickets are.

Check the data you actually have

For that decision, ask:

  • Is there history? Past examples of the decision and its outcome are the foundation of most machine-learning approaches.
  • Is it accessible? Data spread across exports and inboxes needs work before it is useful.
  • Is it allowed? Confirm what data may be used, where it may be processed and who can see the results.

Generative AI can reduce the amount of historical data needed for some tasks, such as summarising or drafting, but quality still depends on giving the model the right context — which is what retrieval-augmented generation does with your own documents. If the data is scattered across systems, a little data engineering usually comes first.

Define success before you build

Agree how you will measure improvement — time saved per case, accuracy compared with today's process, or a business outcome such as conversion rate. Measure the current baseline first. Without it, even a good result is hard to prove.

Keep people in the loop

For a first use case, design for assistance rather than full automation. Let the system suggest, rank or draft, and let people approve. Send low-confidence cases to a human by default. This builds trust and produces the feedback you need to improve.

A one-page scope

Before starting, it helps to fit the whole use case on one page:

  1. The decision or task, in one sentence.
  2. Who uses the output, and where in their workflow.
  3. The data sources and any restrictions.
  4. The baseline and the success measure.
  5. What happens when the system is unsure.
  6. What "done" looks like for the pilot.

In short

A good first AI project is narrow, measurable and assisted by people rather than fully automated. If the one-page scope is hard to fill in, that tells you what to work on before building anything. Our AI consulting work starts exactly there, and if you'd like help shaping a first use case, get in touch.