To find useful AI use cases, walk through a recent task with the person who did it and someone who uses or checks the result. Record where the work became difficult, what an acceptable output requires and which information was available. Then describe one specific way AI might help, alongside what you still need to verify.
You should leave with a candidate you can investigate, including its limits. A list of tools or a broad idea such as “AI for customer success” leaves too much unresolved. For the wider decisions about ownership, investment and rollout, start with the AI adoption strategy guide.
Start with work someone can show you
In a public Reddit discussion, one Reddit user described a familiar frustration. They had taken AI courses and already used LLM Suite for presentations, tables, rephrasing and summaries. They still found it difficult to identify further practical use cases. In later replies, they said they worked on a product in a regulated setting and were not a developer.
Their question deserves more than another catalogue of possible applications. Generic suggestions cannot tell you where a particular team's work gets stuck. A recent example gives the conversation something concrete to examine.
Choose a task with a recognizable beginning and end, such as a software account manager briefing the team that will set up a new customer's account, or a retail buyer comparing an invoice with the goods the warehouse received. Ask the person to show how they completed it last time, using material appropriate for everyone present. Include the recipient or reviewer when possible. They may see problems that were invisible to the person producing the first draft.
GOV.UK's guidance on contextual observation recommends studying work in its actual setting, with the equipment, documents and barriers people encounter. For this walkthrough, ask permission, explain the purpose and use an approved example. Do not turn discovery into covert monitoring or collect unnecessary customer or employee information.
Follow a recent task
Walk through the work in the order it happened.
Find the trigger
What request, event or deadline started this task?
Trace the inputs
Where did the person look, and what was missing or difficult to interpret?
Watch the decisions
Where did they compare, rewrite, check, ask someone else or make an exception?
Follow the handoff
Who received the result, and what did they need before accepting it?
Ask about an action you do not understand rather than guessing why it happened. Treat a narrated walkthrough as one piece of evidence: talking through a task can change how someone performs it, and one instance may hide an important exception.
Keep an observation record you can use later
Use the worksheet below during the conversation. Short notes are enough. Separate what happened from what you think might help, so an attractive idea does not quietly become an established fact.
That distinction follows GOV.UK's research-analysis guidance, which separates observations from interpretation. The worksheet applies it to AI use-case discovery.
| Record | What to capture |
|---|---|
Task and trigger | The specific request or event, and the output someone needs |
People and handoffs | Who performs, reviews and uses the work; where responsibility changes |
Current method | The documents, systems and steps used in this example |
Observed friction | A delay, repeated search, correction or difficult decision you actually saw or heard about |
Acceptable result | What must be correct, complete and usable; how the reviewer checks it |
Information and access | Which inputs are needed, where they come from and whether the proposed use is permitted |
Desired help | What the person wants assistance with, and which judgments or interactions they want to retain |
Candidate and unknowns | A possible AI role, an alternative worth considering, the unresolved question and its owner |
Keep the evidence attached to the note. “The software setup lead returned this handoff because it lacked the customer's agreed start date” is an observation about a particular attempt. “AI could prevent incomplete handoffs” is a hypothesis. The second statement needs investigation before anyone builds around it.
If someone estimates how often the problem happens, label it as an estimate and identify how you could check. Do the same with time: distinguish time spent working from time waiting for an answer. Avoid turning a remembered frustrating afternoon into an annual savings forecast.
Look closely at what causes the friction
Two tasks can both feel like repetitive administration while needing different solutions. A useful discovery conversation stays open to that difference.
Google's People + AI Guidebook recommends understanding existing workflows and checking whether AI adds value. It also describes situations where a rule or heuristic may be more suitable, including when predictable behaviour matters. Repetition alone is therefore a poor reason to select AI.
The possible AI use case is now narrow enough to discuss: help assemble a draft handoff from specified records, with a named person checking it before another team relies on it. You have also found a process improvement that need not wait for AI.
Record the checking work at discovery. In MIT Sloan's account of Rama Ramakrishnan's approach, the cost of applying generative AI includes reaching the required correctness and detecting and fixing errors. You do not need a full cost model yet. You do need to know who could judge the output and which mistakes would matter.
Ask what people want help with
A task can look suitable for automation to an observer while containing work the person values or wants to control. Ask which parts they would welcome help with and what they would still want to decide themselves.
The WORKBank study examined worker preferences and expert assessments of AI capability as separate dimensions. Its researchers collected responses from 1,500 US workers across 104 occupations and assessments from 52 AI experts. The comparison showed why desired assistance and assessed feasibility should not be treated as interchangeable.
The February 2026 paper version uses data collected from January to May 2025. These were reported preferences and expert judgments, not performance tests of your current tools or proof that a particular task can be automated. Use the distinction to ask better questions locally, then evaluate the proposed assistance on relevant work.
In the handoff example, the manager might welcome help organizing notes but want to write the judgment about the customer's main concern. That preference changes the candidate. It also gives a later trial something more specific to examine than whether a whole document can be generated.
Leave with a candidate and the next question
Turn the observation into a short statement that another person can understand. Name the task, the proposed assistance, the inputs and the check.
For the handoff example:
When the customer setup call is complete, help the payroll-software account manager draft the setup handoff from the approved meeting notes and agreed scope. The manager checks every commitment and unresolved question against those records before sharing the handoff.
Add the unresolved questions underneath:
- Information. Are the necessary records complete and available in an approved tool?
- Output. Can the draft preserve commitments, sources and uncertainty well enough to be useful?
- Review. Who can check it, and what work would that add or remove?
- Alternative. Would a better template or an existing feature solve enough of the problem?
- Ownership. Who will answer the next question, and when will you review the evidence?
This is enough to take the idea into prioritization. It is not yet permission to put customer information into a new tool or to rely on an untested output.
Start with one walkthrough, then examine another relevant instance before assuming the first represents the whole task. Choose the next example to challenge what you learned: a missing input, a different reviewer or an unusual request. Stop expanding the notes when you can describe the candidate and identify the decision needed to investigate it.
The weekly AI adoption routine for managers gives you a place to return to that question. Bring back the evidence, including a decision that the simpler improvement is the better option.
Questions about finding AI use cases
Can someone without a technical background discover useful AI use cases?
Yes. Someone who understands the work can identify where information is missing, what needs checking and what a useful result would look like. A payroll-software account manager can explain which customer commitments belong in a setup handoff without choosing an AI model or designing an integration.
Record the task, available inputs, proposed assistance and acceptance check in the observation worksheet. Then involve the appropriate technical and information-access specialists to assess what is feasible and permitted. Knowing the work helps frame a test; it does not establish that an AI tool can do it reliably.
Is repetitive work always a good AI use case?
No. Repetition tells you that a task recurs, not which solution fits it. If a software setup form repeatedly lacks the customer's agreed start date, a required field and a named person responsible for completing it may solve the problem more directly than AI. Assembling commitments scattered across call notes is a different candidate, with a different checking burden.
Compare the proposed AI help with the current method and a credible simpler alternative. The two customer-handoff problems show how similar complaints can point to different fixes. Keep the reviewer involved so you assess usable work rather than a fluent first draft.
How many people should we observe?
There is no universal number for this discovery exercise. Start with someone who performs the task and, where possible, the person who reviews or uses the result. For a payroll-software handoff, that means hearing from both the account manager and the setup lead, because each sees different gaps.
Add instances or perspectives that could change your proposed use case, such as a customer with unresolved setup questions or a handoff to a different reviewer. One walkthrough can reveal a useful question; it cannot establish how everyone works or how often a problem occurs. Use the four-step observation flow to keep the conversation grounded in actual work.
When does a use-case idea become a pilot?
An AI use-case idea becomes a pilot when the responsible people agree to a bounded test with an owner, permitted inputs and explicit measures of quality and effort. A promising discovery conversation is not permission to upload customer records to a new tool or use unchecked output in live work.
For the payroll-software handoff, the test would need approved records, a comparison with the existing method and someone checking every customer commitment against its source. Record the unresolved questions in the candidate statement, then use the strategy guide's pilot decision criteria to plan what evidence would justify continuing, changing or stopping.
