AI opportunity discovery: identifying worthwhile business use cases

How can a business identify worthwhile AI opportunities?

AI opportunity discovery turns observed work problems into testable improvement hypotheses. Each result should identify a user, an obstacle, the current process, the proposed change and evidence of success or failure. Microsoft's adoption planning guidance starts with business problems before translating them into use cases.[S1] Begin with the work that needs to improve, rather than a general ambition to give everyone an agent. A useful opportunity can be rejected by evidence; a slogan cannot.

Step one: observe rework, waiting and information gaps

Repeatedly copying the same field, rewriting a document for another channel or reconciling inconsistent records may indicate rework. Waiting may involve approval, missing information or unclear responsibility. An information gap appears when a person cannot identify the current policy or connect a request with the correct specification. These categories are discovery prompts, not automatic arguments for AI. An integration may solve copying more reliably. Clearer decision rights may remove a queue. Knowledge maintenance may be necessary before generating any answers.

Step two: interview around a recent event

Ask participants to bring a recently completed, de-identified example. Reconstruct the steps from request to acceptance. Ask where they stopped, what they had to redo, who held the missing answer and how errors were detected. Asking which AI product they want usually produces preferences rather than evidence. Keep separate fields for the observation, the participant's explanation and the researcher's interpretation. One complaint is a useful signal, but not a measured description of the entire department.

Step three: write a complete use-case card

Record the user and trigger, current method and baseline, information sources, proposed AI role, required output and acceptance conditions. For a sales specification enquiry, the assistant might suggest candidate matches and flag missing information while citing approved product documents. It should not silently commit to custom features, delivery dates or prices. State a falsifiable value claim: searching and rework should decrease without reducing quality. If checking the output takes longer than doing the original task, the efficiency hypothesis is weakened.

End the card with the next uncertainty to resolve. Before building a prototype, it may be cheaper to establish whether the data can be used or whether enough requests can be answered from standard specifications. Small evidence-gathering steps can eliminate a weak opportunity before it becomes an expensive project. They also reveal whether the problem belongs to technology, information maintenance or organisational decisions.

The use-case card can also record frequency, peak arrival periods, input formats, the receiving role and the exception owner. Occasional monthly document preparation needs different support from a daily arrival spike. An output used privately also has a different checking burden from an artifact another department must act upon. Describe these conditions before asking the actual recipient whether the proposed output is usable. If that person must redo every case, the problem may be missing fields or evidence locations rather than writing quality. Keep these observations in the card because they change the trial scope; do not wait until a prototype is complete to discover the receiving team cannot use its results.

Step four: compare at least three solution paths

Consider simplifying the process, using established rules or integration, and adding AI assistance. Structured inputs with stable rules may suit validation and lookup. Variable natural-language material may benefit from interpretation or drafting. Missing responsibility requires an organisational decision. GOV.UK's technology assessment guidance supports checking needs, data and alternative approaches while retaining the ability to change course.[S2] The comparison proposed here is an editorial decision method, not a requirement that every task must use three commercial products.

Step five: define boundaries before autonomy

Specify which information can be read, which actions can be taken and which decisions require a person. Reading an approved manual is different from changing a customer record. Drafting a response is different from sending it. A pilot can progress from source discovery to an internal draft and only later to controlled execution. The availability of a tool-calling function does not establish business authority to use it. Make the boundary visible in both the workflow and the proposed acceptance test.

Illustrative scenario: purchasing enquiries

Imagine a purchasing team says that enquiries take too long. Observation reveals that incomplete specifications cause most delays, rather than slow email composition. A missing-information assistant may therefore be a better first experiment than an autonomous purchasing agent. It compares the request with an approved checklist and identifies absent dimensions, quantity, timing and certification requirements. A purchaser verifies the list before asking follow-up questions. The example is invented to explain the mechanism and does not describe an AiTOM customer or measured result.

Step six: test the mechanism with a small experiment

Use de-identified historical enquiries and have experienced staff identify the information that should have been requested. Compare the proposed solution on omissions, unnecessary questions, review time and invented requirements. Include cancelled orders, unusual specifications and handoff cases, rather than successful routine requests alone. A small set can expose obvious problems but cannot establish a reliable population-wide success rate. Choose subsequent sample sizes according to the decision's risk and the size of the effect that matters.

Also record occasions when an operator does not use the proposed assistance. Capture a reason such as incorrect missing-item suggestions, slow source checking, unsuitable special specifications or an existing process that already works well. Record whether the person switches to manual work, a form or search. The problem owner should inspect patterns across those reasons rather than collecting feedback only from completed uses. If failures concentrate around missing authoritative specifications, investigate source ownership first. If complete inputs still generate false alarms, revisit interpretation and test cases. Each opportunity can then produce an actionable next step, including preparation or rejection of the model approach, rather than leaving only a successful demonstration.

Manage opportunities as an evidence portfolio

Give each opportunity a stable name, problem evidence, current hypothesis, dependencies, next check and state. Suitable states include needs clarification, bounded experiment, prepare data, defer and stop. Discovery should not put every idea into a development queue. Similar names across departments are not sufficient grounds for combining work: inspect information, policies and permissions first. Reusable methods and software components may be shared while content access and approval responsibilities remain local to each use case.

When should an idea not proceed directly to a pilot?

Pause when sources cannot be verified, outcomes are undefined, nobody will review the result or the consequences of errors cannot be bounded. Infrequent, simple work may not justify development and maintenance. Discovery is not a sales funnel in which every problem must become an AI project. A reasoned decision to use an established tool, simplify a process or wait for better data is a useful result. Preserve the reason and the condition that would justify reconsideration.

Are more employee ideas always better?

Idea counts measure participation, not value. Track how many proposals connect to actual work, usable information and an accountable result. Consolidate repeated wishes into use cases and ask frontline users to confirm that the description is accurate. Better definition is often more valuable than another round of submissions.

Should the company buy a tool first?

Clarify the main problem and boundaries first, then experiment with approved existing tools where possible. A product's feature list should not define the company's needs. Before procurement, understand frequency, integration, information boundaries and operating ownership. Exploration can remain lightweight without ignoring those conditions.

Can a successful departmental solution be copied everywhere?

Check whether policies, information quality, access rules and acceptance criteria actually match. The use-case card, evaluation method and components can often be reused. Department-specific information and approvals must still be established. Replicating a screen is quick; replicating trustworthy operating conditions requires evidence.

Sources and evidence boundaries

1. S1 · Plan for AI adoption

   Microsoft Learn · Accessed 2026-10-22

   Supports the cited principle; operational steps and illustrative scenarios are editorial recommendations rather than reported customer results.

2. S2 · Assessing if artificial intelligence is the right solution

   GOV.UK · Accessed 2026-10-22

   Supports the cited principle; operational steps and illustrative scenarios are editorial recommendations rather than reported customer results.