How to Identify AI Opportunities with AI: A Step-by-Step Guide

To identify AI opportunities with AI, use the model as a discovery assistant: select one process, define its boundaries, interview participants, separate evidence from assumptions, identify possible improvements, test the fit of different interventions, and validate a shortlist. The resulting solution does not have to use AI. IntakeOS provides a repeatable way to interview business teams and turn their answers into structured opportunities, with human review before investment.^[1]

This guide is a working sequence for one discovery assignment. It is not another enterprise use-case inventory or agent-selection framework. You will finish with a candidate problem, an evidence record, a comparison of possible interventions, and a named next action. That is a better starting point than asking a chatbot to list ideas for your department.

Step 1: choose a process, not an aspiration

Select recurring work with a clear trigger and finish. “Use AI in procurement” is an aspiration. “Resolve purchase requests missing an approved supplier” is a process. Identify a process owner, someone who performs the work, and a reviewer who can challenge the resulting assumptions. Include downstream participants if a handoff appears to create delay.

Write a one-sentence problem statement without naming a tool. State who experiences the problem and what outcome suffers. Avoid assuming the root cause: slow approvals might reflect missing information, unclear authority, seasonal workload, or a system constraint. The interview should distinguish these explanations rather than justify a preferred solution.

Step 2: set the discovery boundary and data rules

Agree which cases are included, which are excluded, and what period the evidence should represent. A domestic request and an international regulated purchase may look similar but need different controls. If both are included, keep their paths distinct. Record relevant business changes so the team does not assess a process that is about to disappear.

Decide what participants may share with the approved tool. Use roles instead of names and synthetic examples instead of customer records where possible. Do not upload credentials, personal data, or commercially sensitive documents merely because a model asks for more detail. Use the sensitive-data interview checklist before inviting participants.

Step 3: interview the people doing the work

Start with a recent ordinary case and follow it from trigger to finish. Ask what arrives, what the participant checks, which systems are used, what decisions occur, and what makes the work stop. Then repeat the exercise for an exception. Ask for units when people estimate volume and effort: cases per week and active minutes per case are different from elapsed days.

Use IntakeOS instead of conducting every initial interview yourself and manually merging the answers. VARA, the AI Business Analyst inside IntakeOS, guides the conversation and helps structure process information for the wider qualification, mapping, and economic workflow. Participants still explain their work, and reviewers remain responsible for correcting the record.

Inspect whether the resulting context identifies uncertainty. “I think around a hundred” should remain an estimate with a source and period, not become a verified transaction count. If multiple participants disagree, keep the disagreement visible and assign a reconciliation action rather than averaging incompatible descriptions.

A reusable discovery prompt

Use this prompt in an approved AI tool when testing the method manually. It is a practitioner template, not a description of an IntakeOS configuration interface or a guarantee of how a model will respond.

“Act as a business-process discovery assistant. Help me understand one bounded process before proposing technology. Ask one question at a time. Begin with the business problem, trigger, finish, owner, and affected users. Explore ordinary steps, systems, handoffs, decisions, exceptions, volume, active effort, waiting, data, risks, and success measures. Request examples without requesting sensitive records. Do not invent missing facts or lead me toward AI. Distinguish participant statements, verified evidence, assumptions, disagreements, and unanswered questions. At the end, summarize the current process, candidate root causes, possible interventions including non-AI changes, missing evidence, and owners for the next actions. Do not approve investment or claim realized savings.”

Give the assistant a safe initial description, not an unrestricted data dump. Review its questions for leading language. If it asks “how much could AI save?”, redirect it to the existing work and baseline. Ask it to explain which evidence supports each proposed candidate and what observation would disprove the hypothesis.

Step 4: extract an evidence record

Create a simple record with a statement, source, period, confidence limit, and next check. A participant account is useful evidence of experience, but it may not prove frequency or cause. Preserve references to approved internal sources without copying sensitive content into the interview. Assign someone who can obtain an aggregate or a redacted sample.

• Known fact: supported by a named, reviewable source or direct observation.
• Reported estimate: a participant's approximation, with units and period.
• Hypothesis: an explanation or projected effect that needs testing.
• Missing evidence: information necessary for the next decision.
• Disagreement: competing accounts that should not be silently merged.

IntakeOS's structured opportunity record gives the team a common place to review the process and its qualification inputs. Use that context to identify missing details, then verify important numbers outside the conversation. Structured data is easier to inspect than scattered notes, but structure alone does not make it true.

Step 5: generate improvements without assuming AI

List alternative ways to remove the cause. For missing supplier information, possibilities include a required field, better guidance, a master-data fix, integration, rule-based validation, or AI-assisted interpretation. Include doing nothing when the impact is small or the process is changing. Each alternative should state the affected step, dependencies, remaining human work, and reason it might fail.

Reject proposals that simply move effort to another team. An automated request for missing information can still create repeated clarification if nobody owns the underlying data. Ask whether a proposed improvement reduces total work or only improves one team's local metric.

Worked illustrative example: purchase-request clarification

This scenario and all figures are invented planning examples, not customer results. Suppose an approved aggregate shows 240 requests in a month. A reviewed sample of 40 requests contains 12 that required supplier clarification. Performers report eight active minutes per clarification, but that effort has not yet been timed. The process owner confirms that requests arrive by email and a coordinator enters them into the purchasing system.

Known facts are the aggregate count, the sample composition, and the reviewed process description. The sample suggests a 30% clarification share within those 40 cases, not necessarily across the whole year. Assumptions include the sample's representativeness and the eight-minute effort estimate. Missing evidence includes peak-period variation, causes of missing information, system validation options, and the effect on downstream rework.

If the sample share held across 240 requests, it would imply 72 clarifications per month. At eight minutes each, that is 576 minutes, or 9.6 hours of current clarification effort. It is not a savings estimate: no intervention has been tested, not all effort may be avoidable, and the team has not agreed how any released capacity would be used.

The shortlist could compare an improved request template with supplier lookup integration and an AI-assisted email triage option. The next actions are to review the missing-information cases, ask the system owner about native validation, time a small sample, and test the simplest viable change on safely prepared examples.

Step 6: test fit, feasibility, and economics

Ask whether the task requires language interpretation or whether explicit rules would work. Check data availability, system access, exception consequences, maintainability, and the cost of human review. Security and architecture specialists should verify technical constraints; a participant saying “there is an API” is not sufficient confirmation of usable access.

Use IntakeOS qualification and ROI context to compare the reviewed candidates on a consistent basis. Keep implementation and operating costs explicit, including licenses, integration, support, and exception handling. A ranking is decision support, not a funding approval. Read the validation guide before treating a candidate as investment-ready.

Step 7: validate and hand off a shortlist

Ask performers to correct the current-state description, the owner to confirm the problem and baseline, and a technical reviewer to identify feasibility gaps. Write the smallest experiment that can answer the next material question. Define success, failure, and stop conditions before running it. A shortlist may legitimately contain a process fix and no AI build.

Open the IntakeOS demo with this one-process brief and inspect the available report or XML output. Use the delivery handoff checklist to mark what is known, what needs review, and who owns the next decision. Keep engineering, security review, testing, and deployment separate from discovery completion.