A team sees a demo, someone buys a subscription, and a few weeks later there is another tool sitting next to all the others. There is a brief wave of enthusiasm, but the process barely changes. Not because the technology is useless, but because nobody decided which problem it was supposed to solve.

I see this pattern often in AI implementation. We quickly talk about models, agents, and automations, while the real opportunity usually starts somewhere simpler: recurring work that takes too much time, knowledge that is hard to find, or a handover that repeatedly leaves people waiting.

The tool question comes too early

‘Which AI tool do we need?’ sounds concrete, but it skips an important step. Without a clear view of the work, you cannot tell whether a tool improves anything. You also do not know what to measure, who owns the outcome, or when an experiment has succeeded.

I prefer to start with the process. Where does time disappear? Where is information copied from one system to another? Which questions are answered again every week? Where does quality depend too heavily on one person? These questions reveal potential AI applications, but they also show when a straightforward process improvement may already be enough.

A good first AI application does not need to be spectacular. It needs to be useful on Monday.

Four signs of a strong first use case

Not every problem is a good starting point. A first use case works best when it is small enough to control and important enough to matter. I usually look for four signals:

  • The work happens frequently. A small time saving therefore adds up every week.
  • There is a clear owner. Someone knows the process, can give feedback, and feels the result.
  • The friction is measurable. Think of lead time, search time, errors, waiting, or the number of manual steps.
  • The risk can be contained. Output can be reviewed before AI influences larger decisions on its own.

An internal knowledge assistant can be a strong starting point when employees search the same policy documents every day. An agent that makes customer decisions without review is usually not a sensible first experiment. The potential impact may be larger, but the learning process becomes much harder and riskier.

Start small, but not casually

‘Start small’ is sometimes interpreted as experimenting without commitment. Someone builds a prototype between other tasks, the team tries it once, and it quietly disappears. A small experiment only becomes valuable when you decide in advance what you want to learn.

Choose one workflow, record the current situation, and agree on a short test period. Then measure more than technical performance. Do people trust it, understand it, and actually use it? A technically impressive prototype that adds extra steps has not improved the process.

When coaching turns into building

This is why I often start with an AI coaching programme based on real workflows. The leadership team does not only learn what AI can do; they immediately use it to examine their own work. That creates internal understanding and reveals which application is worth the investment.

From there, three outcomes make sense. We stop because the problem does not need AI. We hand a working approach over to the team. Or we continue by building an automation, agent, or internal AI tool. Stopping can be a good result too: you learned early and avoided an expensive project without clear value.

A practical starting point for your next meeting

If you want to start using AI in your organisation, do not put the latest tools on the agenda first. Ask each team member to name one recurring moment when work stalls, information is missing, or unnecessary manual work appears. Then choose one process that happens often, has a clear owner, and can be tested safely.

That conversation may not produce a spectacular AI strategy. It will produce something more valuable: a first application everyone understands the purpose of. And that is where implementation that lasts begins.