Most organisations do not struggle to find ideas for AI. They struggle to choose between them. A long list of possibilities gathered from workshops and vendor demonstrations can quickly turn into scattered pilots that never reach the business. The more useful question is not where AI could be applied, but where it will change a decision, a cost or a customer experience in a way that matters. This article sets out a practical way to find, test and prioritise use cases before committing budget and teams.
Start with business problems, not technology
The strongest use cases begin with a problem the business already wants solved. Look at processes where people spend significant time reading, classifying, searching, reconciling or responding, and where delays or errors carry a visible cost. Ask department heads which decisions they make with incomplete information and which tasks their best people wish they could hand off. Framing ideas this way keeps the conversation grounded in outcomes rather than capabilities, and it brings the people who own the process into the discussion from the start.
A common pitfall is starting from a tool, such as a chatbot or a large language model, and searching for somewhere to use it. This tends to produce solutions that impress in a demonstration but do not fit how work is actually done. Instead, write each idea as a short problem statement: who is affected, what happens today, what a better outcome looks like and how you would know it has improved. If a use case cannot be described in these terms, it is not ready to be assessed.
Assess value and feasibility together
Once you have a shortlist, score each idea on two dimensions. Value covers the size of the opportunity: time saved, revenue protected, risk reduced, service improved, and how many people or transactions are affected. Feasibility covers whether the data exists and is accessible, how complex the integration will be, how tolerant the process is of occasional errors, and whether there is a clear owner. Keep the scoring simple enough that business and technology teams can complete it together in a single working session.
Plotting ideas on a value and feasibility grid usually reveals a small group of candidates worth pursuing first. High-value but low-feasibility ideas are not discarded; they often point to foundational work, such as data consolidation, that should be planned separately. Be wary of ideas that score well only because their benefits are vague. A use case described as improving productivity across the organisation is harder to deliver and measure than one that reduces the time taken to process a specific type of request.
Check the data and the constraints early
Many promising ideas stall when teams discover the data is incomplete, held in disconnected systems or unsuitable for the intended use. Before prioritising, confirm what data the use case needs, where it lives, who owns it and what condition it is in. For language-based use cases in the region, check whether content exists in both Arabic and English and whether the chosen models handle both with the quality your users expect, including regional dialects where they matter.
Regulatory and policy constraints belong in the same conversation. Data residency requirements, sector regulations and internal classification policies can determine whether a use case can rely on public cloud services, needs in-country hosting or must stay on premises. Understanding this early prevents rework later. It also helps legal, risk and security teams feel involved in shaping the approach, rather than being presented with a finished design they are simply asked to approve.
Define success before you build
Every prioritised use case should have a measurable baseline and a target agreed before development starts. If the aim is faster handling of customer enquiries, record how long it takes today and how that is measured. If the aim is better forecast accuracy, agree which forecasts and over what period. Without a baseline, even a successful pilot becomes a matter of opinion, and securing funding to scale it becomes much harder than it needs to be.
It is also worth deciding what failure looks like. Set a time box and a small number of criteria that would lead you to stop or change direction. This is not pessimism; it protects budget and credibility. Stopping a weak use case early frees people and funding for stronger ones, and the lessons learned about data quality, user adoption or integration effort usually improve the next round of prioritisation.
Build a repeatable pipeline
Identifying use cases should not be a one-off exercise. As teams gain experience, they will spot better opportunities, and the technology will continue to change what is practical. A light governance process, with a standard intake template, a regular review forum and clear criteria, turns scattered ideas into a managed portfolio. It also helps leadership see where investment is going and which business areas are ready for more ambitious work.
Some organisations run this process entirely in-house. Others work with a partner such as MomentumX to facilitate discovery sessions, give an independent view on technical feasibility and bring patterns observed across different sectors. Either way, the priorities should remain owned by the business, with technology teams and any external advisers supporting the decisions rather than making them on the organisation’s behalf.
