An AI opportunity assessment should turn a broad ambition into a defensible decision about a specific workflow. Before choosing a model, I want to understand who is struggling, what a better outcome looks like and whether AI improves on simpler options.
My approach starts with the work itself: the inputs, decisions, handovers, delays and checks that determine whether a service is useful. I then compare the opportunity's value, feasibility and evidence, before recommending a bounded next step.
The method below combines established guidance with my own assessment questions. It is a practical synthesis, not a certified framework or a claim about results achieved for clients. A useful assessment can lead to an AI pilot, further discovery, a conventional software improvement or a decision to stop.
Key takeaways
- Start with observed workflow friction, a baseline and a clear outcome.
- Compare AI with the best process or conventional software improvement.
- Keep data permissions, accountability and acceptable consequences separate from ranking scores.
- Use evidence confidence and sensitivity checks to decide the next useful test.
- Define pilot success, stop criteria, ownership and a review date before building.
AI opportunity assessment versus AI readiness assessment
I use opportunity assessment to examine a particular problem and the options for improving it. I use readiness assessment to examine the organisation's ability to support change, including its data, skills, infrastructure and governance. Both matter, but they answer different questions.
A capable technical team can still select a weak use case. Equally, a promising opportunity may need better data or clearer ownership before a pilot is sensible.
The UK Government's AI Playbook recommends beginning with business and user needs and considering where AI offers an advantage over established techniques. Although written for government, that problem-led selection principle is a useful starting point for this method. (Government Digital Service)
Discovery should produce a short opportunity record: the affected users, the workflow boundary, observed friction, current volume and quality, a desired outcome, available evidence and an accountable owner. Record the proposed AI contribution separately, so the problem remains clear if the solution changes.
Measuring AI business value against non-AI alternatives
Start with a baseline that someone can check. Observe representative tasks, speak with the people doing the work and distinguish active working time from time waiting for an approval or missing information. Record variation and difficult cases as well as averages.
I separate expected benefits into three categories:
- Cash savings: spending that would actually fall, such as a supplier charge that can be removed.
- Released capacity: time available for reducing a backlog, improving service or easing workload. Explain how it will be used; unchanged payroll is not a cash saving.
- Customer outcomes: improvements such as fewer mistakes or faster resolution, measured against the current service.
Compare AI with process redesign, clearer instructions, better search, templates and rules-based software. Include data preparation, integration, evaluation, inference, maintenance, review, rework and adoption costs over a common assessment period. Separate one-off setup from recurring work.
Illustrative calculation: suppose a team completes 200 tasks each month at 12 minutes per task, or 40 hours. An assisted process taking three minutes to prepare, four to review and two to rework uses nine minutes per task, or 30 hours. That releases 10 hours. If recurring upkeep takes two hours, the net capacity released is eight hours, before one-off setup effort. These are invented inputs to show the calculation, not measured savings or a financial return.
Harvard Business School's research on the jagged technological frontier illustrates why task-level evaluation matters: AI capability varies across tasks and human–AI configurations. The study does not establish a productivity forecast for another organisation or today's models. (Harvard Business School) My discussion of agentic AI in media publishing explores the related question of whether a workflow creates a more useful service.
Conducting a rigorous AI feasibility assessment
I separate conditions for proceeding from criteria used to rank viable opportunities. A large potential benefit should not conceal missing permission to use data, absent accountability or consequences outside the organisation's accepted risk tolerance.
- Permitted data use: identify the data owner, approved access and processing, confidentiality requirements and relevant restrictions. Consider training rights where training is actually proposed.
- Accountability: name the person responsible for the operational outcome, review arrangements, escalation and correction. This is an operating responsibility, not an assertion of personal legal liability.
- Acceptable consequences: assess the severity of plausible errors, who could be affected, how errors will be detected and whether the process can be paused or reversed safely.
An unresolved condition may justify a smaller discovery task or a different design. It does not automatically mean the underlying business problem should be abandoned.
NIST AI RMF 1.0 provides a useful risk-management reference through Govern, Map, Measure and Manage. Governance runs across the functions; they are ongoing activities, not four mandatory sequential implementation steps. (National Institute of Standards and Technology) MAP 1.4 addresses business value and context, while the Map discussion informs an initial decision about proceeding. (National Institute of Standards and Technology) This supports a considered decision, but supplies neither a commercial ranking nor certification of the method here.
For related operating questions, see my guide to practical AI governance for small teams.
Adapting RICE prioritisation for machine learning
For opportunities that can proceed, RICE can make assumptions easier to compare. Intercom's framework combines reach, impact and confidence, divided by effort. Reach has a defined time period, and effort represents team time in person-months. (Intercom)
RICE score = (reach × impact × confidence) ÷ effort
Before scoring, agree a common objective, assessment period and interpretation of impact. Comparing a revenue score for one project with a time-saving score for another creates an unclear ranking.
- Reach: use observed users or events within the same period.
- Impact: state the expected change and the evidence behind it, including quality and service consequences.
- Confidence: record what supports the estimates and what remains uncertain. A percentage used in a scoring model is a judgement, not automatically a calibrated probability.
- Effort: include implementation and the ongoing work required over the assessment horizon, using consistent units.
For illustration, reach of 1,000 events per quarter, impact of 1, confidence of 0.5 and effort of one person-month produces a score of 500. Doubling effort reduces it to 250. These are relative priority units, not pounds, hours saved or proof that AI will work.
Keep an evidence-strength column beside the score. If plausible changes reverse the ordering, investigate the assumptions carrying the decision. McBride also recognises that dependencies and other constraints can justify choosing a lower-scoring project first. (Intercom)
A practical framework for AI use case prioritisation
These tools are useful for different decisions. I use them together while keeping their limits visible.
| Tool | Useful contribution | Limit to recognise |
|---|---|---|
| Value–feasibility matrix | A simple discussion aid for an initial shortlist. | Its placement depends on assumptions; it does not establish data readiness or demand. |
| RICE | A relative ranking with explicit estimates of reach, impact, confidence and effort. | It supplies no separate decision on permitted data use or acceptable risk. |
| NIST AI RMF 1.0 | A structured reference for context, responsibilities, evaluation and risk management. | It does not calculate commercial return or rank an investment portfolio. |
For each candidate, I would complete the following criteria record. The questions are my proposed synthesis; their importance should reflect the organisation's objectives.
| Criterion | Evidence to request |
|---|---|
| Problem and value | Observed friction, affected users, baseline volume and the desired outcome. |
| Data readiness | Permitted access, quality, coverage, freshness and representative difficult cases. |
| Task fit | A comparison with the best non-AI option and a small task-level evaluation. |
| Delivery and operating cost | Integration effort, review, rework, maintenance and ongoing service costs. |
| Adoption and ownership | A responsible owner, user feedback, training needs and a place in the workflow. |
| Risk and reversibility | Error consequences, detection, escalation and a tested way to pause or recover. |
| Evidence confidence | Observed results, assumptions, missing information and the next useful test. |
Apply any agreed ranking weights to viable candidates and document why those weights suit the objective. Keep the conditions for proceeding separate. Recheck the shortlist with plausible ranges for the uncertain inputs.
Hypothetical example: a content operations team is considering three improvements. These are illustrative proposals, not client results.
- Editorial briefing assistant: an approved source archive and a named reviewer make a small, supervised pilot plausible, subject to testing representative briefs for accuracy and review effort.
- Structured report routing: if routing follows stable fields and explicit rules, test a conventional rules-based solution first. The useful improvement can proceed without an AI build.
- Autonomous publication: if source permissions, error handling and publication accountability are unresolved, defer this design. Investigate a narrower, reviewed workflow before reconsidering it.
The assessment prioritises the next justified action. A high-potential idea with weak evidence may deserve a discovery test rather than a large implementation budget.
Running controlled pilots with defined stop criteria
A pilot should resolve a decision that discovery could not settle. Define that decision before choosing tools, and give the pilot a named owner, a bounded scope, a budget and a review date.
Use representative cases and a credible comparator: the current workflow or the best simpler alternative. Measure output quality and error severity alongside working time, review, rework, cost and user acceptance. Include difficult cases and decide what evidence would be sufficient to expand.
Set success and stop criteria for the particular workflow. A material confidentiality failure, unacceptable error consequences or review effort that removes the expected benefit may require stopping or redesign. There is no universal error percentage that makes every AI use case acceptable.
Before proceeding, check that you can answer:
- What problem and baseline are we improving?
- Why is AI preferable to the best simpler option?
- Which assumptions are observed, and which still need testing?
- Who approves the data use, owns the outcome and handles corrections?
- What will the pilot measure, and what would make us stop?
- What decision will be made at the review date?
A good assessment ends with a reasoned choice: pilot, investigate further, choose a simpler improvement or stop the proposal. It should leave the team clear about what evidence would change that choice.
If you are exploring where to start, my workflow diagnostic offers an initial look at friction, handovers and readiness. It can help scope the deeper assessment described here.
Frequently asked questions
What should an AI opportunity assessment produce?
A defined workflow problem, a baseline, a comparison of options, the conditions for proceeding and a prioritised next action. The record should also show evidence gaps, an accountable owner and what would change the decision.
How do I prioritise an idea with weak evidence?
Keep potential value separate from evidence strength. Identify the assumption most likely to change the decision, then consider a bounded discovery task to test it. A promising idea does not need to receive a full implementation budget before its feasibility is understood.
Can a non-AI solution be the best outcome?
Yes. The purpose is to improve an operational or customer outcome. A clearer process, better search, a template or rules-based software may meet that need with less effort and uncertainty. Record why that option was chosen and compare its results with the same baseline.