Field guide / 1. Find
How to find AI and automation opportunities
How do you identify AI use cases in an organization?
Start with a measurable business objective, identify the processes that affect it, and interview the people doing the work. Look for repeated delays, manual handling, rework, exceptions, and judgment-intensive tasks. Document the problem, owner, baseline, and desired outcome before suggesting technology. Compare AI with RPA, IDP, workflow automation, process redesign, and no technology change, then send evidence-backed candidates for evaluation.
The method in short
Choose an objective and a boundary
Identify the department and process that influence an outcome. Define the trigger, end state, owner, and affected people before collecting ideas.
Observe the work and interview practitioners
Walk through normal cases and exceptions. Compare their account with operational records; include work outside logged systems.
Turn a problem into an opportunity brief
Record the baseline, root-cause hypothesis, desired outcome, affected steps, possible interventions, and evidence gaps. Do not treat a proposed AI feature as proof of need.
Validate and hand off
Ask the process owner to confirm the brief. Flag value, feasibility, and risk questions for assessment; score and prioritize only after evidence is sufficient, with investment and portfolio ownership downstream.
The shared framework
Fourteen stages, from objective to portfolio.
Every guide uses this sequence to connect a business problem to an accountable investment. Revisit earlier stages when new evidence changes the assessment.
Stage 1: Business Objective
Name the outcome the organization is trying to move, so every later idea has something to be measured against.
Stage 2: Department
Locate the team that owns the objective and the work that feeds it.
Stage 3: Process
Describe how the work actually runs today: steps, handoffs, systems, and exceptions.
Stage 4: People
Capture who performs and depends on the work, and what they know that no document records.
Stage 5: Problem
State the friction in plain terms: delay, rework, error, cost, or risk, with evidence.
Stage 6: Opportunity
Frame a specific improvement that addresses the problem, not yet tied to any technology.
Stage 7: AI/Automation Fit
Compare AI, RPA, IDP, workflow automation, process redesign, and no technology change.
Stage 8: Value
Estimate benefit in the objective's own terms, with assumptions written down.
Stage 9: Feasibility
Check data, systems, skills, and change capacity needed to deliver.
Stage 10: Risk
Surface compliance, quality, security, and adoption risks and the controls they need.
Stage 11: Scoring
Rate each opportunity on the same dimensions so comparisons are consistent and explainable.
Stage 12: Prioritization
Sequence opportunities by score, dependencies, and capacity, with reasons people can challenge.
Stage 13: Investment
Match approved effort to the sequence; people with budget authority decide what gets funded.
Stage 14: Portfolio
Track opportunities over time as a living set: delivered, in flight, waiting, and retired.
Signals worth investigating—not automatic reasons to use AI
Repeated handling and rekeying
People copy fields between applications, reconcile records, or maintain parallel spreadsheets. Investigate volume, rule stability, and system access. An API integration, RPA, or removing duplicate capture may be more suitable than AI.
Queues, handoffs, and waiting
Work stalls between teams or repeatedly returns for missing information. Distinguish time spent working from elapsed waiting time. A missing owner or unclear approval policy may require process redesign, not a model.
Unstructured information
People interpret emails, documents, images, or free-text requests before acting. Ask how varied the inputs are, what output quality is required, and how reviewers detect mistakes. IDP or AI may be candidates, subject to evaluation.
Recurring exceptions and rework
The same edge cases generate escalations or corrections. Find out whether upstream data, policy ambiguity, or an existing system defect causes them. Automating around a fixable defect can preserve the problem.
Judgment and knowledge bottlenecks
A small group interprets complex information or answers repeat questions. Determine whether the knowledge is documented, current, and appropriate to share. Standardized guidance may help before AI assistance is warranted.
Interview questions that reveal real opportunities
Ask for a recent, specific example rather than opinions about AI. Walk through one ordinary case, one exception, and one failed case where possible. Avoid collecting sensitive material unnecessarily; use authorized, redacted examples and note what the sample cannot establish.
Objective and process
What outcome are you responsible for? What starts this work, and what counts as finished? Who receives the output? What happens if it is late or wrong?
Actual work
Can you show how you handled the last case? Which systems and spreadsheets did you use? Where did you copy information or ask another person for help? What work is not visible in the official process map?
Variation and failure
What makes a case difficult? How often does work come back? What causes the queue to grow? Which decisions require judgment or formal authorization? How is a mistake noticed and corrected?
Evidence and value
Where are volumes, effort, waiting time, and rework recorded? Is this period representative? If this step improved, what would people do with the capacity released? Which outcome would prove the change helped?
Alternatives and ownership
What have you already tried? Could a simpler rule, clearer responsibility, or removal of a step solve the issue? Who can validate this description, authorize a test, and own the result?
Triangulate interviews with operational evidence
Interviews explain intent, hidden work, and exceptions. Logs, tickets, and process observations help establish scale and variation. Neither source is complete: logs can miss off-system work, while interview estimates can overrepresent memorable failures. Keep disagreements visible instead of averaging them away.
Record the source, time period, process scope, and confidence of each baseline. Separate handling time from waiting time, total process effort from one person's effort, and recurring demand from a temporary spike. If the data is unavailable, make gathering it the next action rather than inventing a precise number.
Look beyond the loudest department. Sample different roles, locations, shifts, and downstream users when those differences matter. Give practitioners a way to correct the process description without requiring agreement with the proposed technology.
Use a problem-first opportunity brief
Define
Name the business objective, department, process owner, affected people, trigger, endpoint, and problem. Describe the current consequence and desired outcome without embedding a vendor or model in the title.
Evidence
Attach baseline measures and representative examples. Label each fact as measured or estimated; list unknowns, conflicting accounts, and the source needed to resolve them.
Hypothesize
List candidate interventions and why each might help. Include no technology change as a comparison. State what observation would show that the initial solution idea is wrong.
Hand off
Name the assessor, next evidence-gathering action, and owner review. Carry value, feasibility, and risk questions into evaluation; do not call an unassessed idea investment-ready.
Illustrative example: incomplete service requests
Suppose a service team says it needs an AI assistant because requests take too long. Discovery finds that staff repeatedly contact requesters for missing fields. The problem statement becomes 'reduce clarification loops while preserving correct routing,' not 'deploy a chatbot.' This is a hypothetical example, not a customer case study.
The next step is to inspect authorized request samples, clarify the required fields, and measure repeat contacts. A better form and workflow validation may solve structured omissions. If information arrives in varied attachments, IDP may help. If staff must interpret ambiguous descriptions, AI assistance is a candidate to evaluate, with human review and a defined error test.
The discovery result is useful even if AI is rejected: a named owner has a bounded problem, a baseline plan, alternative interventions, and an assessment question. It is not yet a forecast of savings or a commitment to build.
Common mistakes when finding AI use cases
Asking only 'What could AI do here?'
That question encourages tool-led ideas and misses simpler improvements. Ask what prevents the business outcome, then consider interventions.
Recording themes instead of processes
'Finance AI' or 'better support' is too broad to assess. Narrow the candidate to a trigger, set of steps, output, and owner.
Skipping exceptions or downstream effects
The normal case can look automatable while exceptions carry most of the risk. Include those cases and check whether faster upstream output creates more downstream work.
Collecting once and declaring discovery finished
Keep intake open and revisit opportunities after policy, demand, or system changes. Discovery supplies a living portfolio rather than a one-time list.
Continue the guide
Common questions.
What are the best questions for an AI discovery interview?
Ask practitioners to show a recent case, explain what starts and ends the process, identify repeated handling and exceptions, and show where volume, effort, and errors are recorded. Then ask what simpler change might solve the problem and who can validate the desired outcome.
How do you find automation opportunities without process mining?
Combine structured practitioner interviews, direct observation, representative work samples, and available operational measures. Capture off-system tasks and exceptions explicitly. Process mining can add evidence where event logs exist, but a useful problem record does not require it.
What should come out of an AI discovery workshop?
An AI discovery workshop should produce bounded problem records with owners, process boundaries, baseline evidence, desired outcomes, candidate interventions, and unanswered questions. It should not produce a funded AI project list without subsequent evaluation.
When is an opportunity ready for evaluation?
An opportunity is ready for evaluation when its process owner confirms the problem and boundary, the desired outcome is measurable, and the available evidence and gaps are documented. Evaluation can then test value, feasibility, risk, and intervention fit without assuming AI is the answer.
Related practice notes
For focused interview techniques, examples, and scoring detail alongside this field guide:
A note on the product
VARA, IntakeOS's AI business analyst, supports structured process interviews so discovery does not depend on a single workshop facilitator. IntakeOS connects that context with 8-dimension deterministic scoring, process maps, and delivery documentation. Practitioners and owners still validate the evidence; qualification supports a human decision rather than making an investment decision for the customer.
IntakeOS supports this work and does not make funding decisions; those stay with your leaders. Learn about VARA, how we handle data on the trust page, or the wider platform.
See a demo