The meeting opened with a list of seventeen AI ideas. Over three hours, the team debated each one – the technical possibilities, the vendor options, the competitor implementations. By the end, they had narrowed it to four. They chose the one that generated the most enthusiasm in the room.
Eighteen months later, the project had consumed $1.2 million and produced a system used by fewer than a dozen people. The second item on the original shortlist – a simpler, less exciting use case – would have returned measurable value in four months. Nobody picked it because it did not generate excitement.
AI use case selection is where most implementations are won or lost. The choice made in that early conversation determines whether the organisation is still running the system in three years or quietly decommissioning it. And the choice is consistently made on the wrong basis.
The ROI Problem Starts at Selection
Deloitte’s 2025 AI ROI study, which surveyed 1,854 senior executives, found that only 6% of organisations reported AI payback in under a year. McKinsey’s 2025 State of AI research found that while 88% of organisations are now using AI in at least one business function, only 39% report any measurable EBIT impact.
The gap between AI investment and AI return is not primarily a technology problem. The technology is more capable than most organisations are using. The gap is a selection and scoping problem – organisations are building the wrong things, or building the right things without the data foundation to support them.
The most common pattern: use cases are chosen based on what is exciting rather than what is feasible. Generative AI applications generate more enthusiasm than process automation. Predictive analytics sounds more impressive than document classification. But enthusiasm and ROI are poorly correlated in AI. Feasibility and ROI are not.
The Three-Dimension Scoring Framework
A structured AI use case prioritisation should score each candidate across three dimensions. The use case that scores highest across all three is where to start – not the most technically sophisticated option, and not the one that wins the most votes in the room.
Dimension 1: Business Impact
Does this use case move a metric that the business cares about? Score it on specificity, materiality, and measurability.
High-impact use cases reduce a cost category by a quantifiable amount, increase a revenue line by a traceable mechanism, or eliminate a risk with a financial value attached to it. Low-impact use cases improve a process without clear financial consequence, or deliver convenience rather than business value.
Critically: the business owner – not the technology team – must be able to articulate the impact before development begins. If they cannot, the use case is not sufficiently defined to proceed.
Dimension 2: Data Availability
Does the data required to build this AI exist? Is it accessible? Is it of sufficient quality and volume?
Data availability is the single most common reason AI projects stall after approval. Gartner’s February 2025 research found that organisations will abandon 60% of AI projects due to lack of AI-ready data. A separate Gartner survey found that 63% of organisations either do not have or are not sure if they have the right data management practices for AI.
Score data availability on four sub-questions: Does the data exist? Can the AI access it? Is it labelled or structured in a usable form? Does it cover the full range of conditions the AI will encounter – not just successful outcomes, not just one business unit?
A use case with high business impact and poor data availability is not a good first project. It is a future project, once the data infrastructure is in place.
Dimension 3: Implementation Feasibility
Can this use case reach a working pilot in 60–90 days? What are the integration dependencies? What approval or compliance requirements apply?
Feasibility is not the same as simplicity. A technically complex use case can be highly feasible if the data is clean, the integration path is clear, and the compliance requirements are understood. A simple use case can be low-feasibility if it depends on legacy system access that requires IT approval over six months.
Score feasibility on: integration complexity, data readiness, regulatory requirements, and the availability of the business owner’s time and attention. The last point is underweighted in most assessments – a use case that requires significant business owner involvement during development will stall if that person’s calendar does not have the capacity.
Common Selection Mistakes and How to Avoid Them
The most frequent mistake is choosing a use case based on what the technology can do rather than what the business needs. Generative AI and large language models are genuinely powerful – and they are consistently applied to use cases where a simpler, more targeted solution would deliver better results faster.
The second most frequent mistake is choosing the use case with the highest ceiling rather than the highest probability of success. A first AI project that succeeds at something modest builds organisational confidence, executive sponsorship, and the institutional knowledge to attempt more complex projects next. A first project that fails at something ambitious destroys all three.
The third mistake is selecting multiple use cases simultaneously. Distributing implementation effort across a portfolio of parallel pilots reduces the chance that any of them reach production. Deloitte’s research found that organisations reporting AI payback concentrate their early investment in a small number of use cases with clear success criteria rather than spreading effort broadly.
What to Do With Lower-Priority Use Cases
Scoring use cases and selecting one does not mean abandoning the others. Lower-priority use cases go into a structured backlog – with the specific gap that is blocking them documented.
A use case that scores high on impact and feasibility but low on data availability goes into the backlog with a data readiness workstream attached. A use case that scores high on all three but requires compliance approval goes into the backlog with a compliance track running in parallel.
The backlog is a roadmap, not a rejection list. The discipline is in resisting the pressure to run everything simultaneously.
FAQ: AI Use Case Prioritization
How many AI use cases should a business pursue at once?
For most organisations, one to two use cases in active development at any given time produces better results than a broader portfolio of simultaneous pilots. Spreading implementation capacity across too many projects reduces the chance that any of them reach production. Concentrate effort, demonstrate ROI, then expand.
What is the most common reason AI use cases fail after selection?
Poor data availability is the most common post-selection failure – the data required to build the AI either does not exist, is not accessible, or is not of sufficient quality. This is almost always discoverable before development begins, through a data readiness assessment.
Should the technology team or the business team lead use case selection?
Both must be involved, but the business team should own the selection decision. Use cases chosen primarily by the technology team tend to prioritise technical interest over business value. The technology team’s role is to assess feasibility – not to determine which problems the business should solve first.
Comments are closed