AV

This one-hour method is for leaders, founders, and operations teams that need to decide whether an AI idea deserves further investment.

Most AI opportunities arrive as solution statements.

“We need an AI assistant.”

“We should automate document review.”

“We want an agent to handle customer support.”

These statements describe a possible technology. They do not describe the business problem, the workflow, the expected value, or the consequences of failure.

A 60-minute AI opportunity review cannot replace formal discovery, technical architecture, security assessment, legal review, or a controlled pilot. Its purpose is narrower: determine whether the opportunity is strong enough to justify those next steps.

Here is how I would run the hour.

1. Minutes 0–5: Define the Decision

The first five minutes establish what the meeting must produce.

I would write one decision question at the top of the page:

Should we invest in a structured discovery or prototype for this opportunity?

This prevents the discussion from becoming a brainstorming session about models, vendors, agents, or product features.

I would also define the decision options before the evaluation begins:

1. Proceed: The opportunity is sufficiently clear for deeper discovery.
2. Redesign: The problem appears valuable, but the workflow or proposed solution needs to change.
3. Stop: The opportunity is too weak, risky, premature, or poorly defined.

This framing matters because an opportunity assessment is not a sales exercise. A useful assessment must make stopping a legitimate outcome.

At this stage, I would also identify the decision owner. That person may be an operations head, business-unit leader, founder, product owner, or department manager. A technology team can help assess feasibility, but the person accountable for the operational outcome should own the opportunity.

2. Minutes 5–12: Describe the Workflow Problem

Next, I would ask the team to explain the problem without using the words AI, agent, model, automation, or chatbot.

A useful problem statement contains four elements:

• User: Who experiences the problem?
• Task: What are they trying to complete?
• Constraint: What makes the task slow, expensive, inconsistent, or difficult?
• Consequence: What happens because of that constraint?

For example:

Six support agents manually search product manuals and past tickets before answering technical questions. Complex cases take 25 to 40 minutes, and answers vary between agents.

This is more useful than:

We need an AI customer-support agent.

The first statement gives us a workflow, users, time range, source material, and quality problem. The second jumps directly to a solution.

I would reject statements such as “improve efficiency,” “enhance productivity,” or “use our data better” unless the team can translate them into an observable constraint.

This follows the same principle discussed in 5 Questions to Ask Before You Automate Anything: the problem should be expressed in operational terms before a tool is selected.

3. Minutes 12–20: Establish the Current Baseline

An AI opportunity has no measurable value without a baseline.

I would ask for the current numbers across five areas:

Baseline area	Example question
Volume	How many cases occur per week?
Time	How long does one case take?
Quality	What percentage requires correction?
Cost	How much labor or vendor expense is involved?
Delay	What waits because this task is slow?

Suppose a finance team processes 2,000 invoices each month. Each invoice requires an average of six minutes of manual review. About 8% require additional investigation.

Those numbers do not prove AI will solve the problem. They give us something against which a future pilot can be measured.

When reliable numbers are unavailable, I would mark estimates as assumptions rather than presenting them as facts:

• Known: Monthly invoice volume from the finance system.
• Estimated: Average review time based on two interviews.
• Unknown: Current exception-handling cost.
• Required: Two weeks of time sampling.

This distinction is important. False precision can make a weak opportunity appear financially convincing.

Google’s machine-learning guidance recommends establishing simple baseline behavior and metrics before pursuing more complex approaches. The same principle applies to business evaluation: first understand present performance, then decide whether a more sophisticated system produces a meaningful improvement.

4. Minutes 20–28: Map the Workflow and Handoffs

I would use the next eight minutes to draw the workflow from beginning to end.

The map does not need formal notation. A simple sequence is enough:

Trigger → Input → Review → Decision → Action → Approval → Record

For a support-response workflow, the map might look like this:

1. Customer submits a question.
2. Ticket enters the support queue.
3. Agent categorizes the issue.
4. Agent searches manuals and previous cases.
5. Agent drafts a reply.
6. Senior engineer reviews complex cases.
7. Agent sends the reply.
8. Resolution is recorded.

I would then mark:

• Repeated searches
• Manual data entry
• Waiting periods
• Judgment-heavy decisions
• Missing information
• Rework loops
• High-risk approvals
• System-to-system handoffs

This often reveals that the obvious task is not the real bottleneck.

Generating a draft reply may take two minutes. Finding the correct documentation may take 15 minutes. Senior approval may add another day. Automating the draft alone would improve the fastest part of the workflow while leaving the main delay untouched.

This is one reason AI can create more work when inserted into an unchanged process. Increased output can overload existing review queues and handoffs. I discuss that pattern in When AI Creates More Work, Not Less.

5. Minutes 28–35: Define AI’s Narrowest Useful Role

Only after understanding the workflow would I ask what AI should do.

I would test three levels of participation:

Assist

The system retrieves information, summarizes content, classifies an item, or prepares a draft. A person remains responsible for the decision and action.

Recommend

The system proposes a decision or next step. A person approves, changes, or rejects it.

Act

The system performs an action such as sending a message, updating a record, issuing a refund, or triggering another system.

The further the system moves from assistance toward autonomous action, the more evidence, controls, monitoring, and exception handling it normally requires.

For the support example, the narrowest useful role may be:

Retrieve relevant passages from approved documents and prepare a cited draft for agent review.

That is more controlled than:

Resolve customer tickets autonomously.

I would also compare AI against simpler alternatives:

• Better search
• Workflow redesign
• Rules-based automation
• Updated templates
• Form validation
• Staff training
• System integration
• Removal of an unnecessary approval

AI should not receive automatic preference. The purpose is to improve the workflow, not to maximize the amount of AI used.

Mid-page CTA: Request an AI opportunity review

6. Minutes 35–42: Test Data and Knowledge Readiness

A promising workflow can still fail because the required information is unavailable, unreliable, inaccessible, or poorly governed.

I would ask six questions:

1. What information does a person use to complete the task today?
2. Where is that information stored?
3. Is it current and sufficiently accurate?
4. Can the proposed system legally and technically access it?
5. Who owns the information?
6. Do we have examples of acceptable and unacceptable outputs?

For a document assistant, the organization may have hundreds of files but still lack a usable knowledge source. Documents may be duplicated, outdated, contradictory, scanned, incorrectly permissioned, or missing ownership.

For a prediction use case, historical data may exist but fail to capture the outcome the team wants to predict. It may also reflect an old process that no longer represents current operations.

I would classify readiness as:

• Ready: Suitable information exists and access is clear.
• Recoverable: Information exists but requires cleanup or integration.
• Weak: Important information is missing or unreliable.
• Blocked: Access, ownership, privacy, or compliance prevents responsible use.

A “recoverable” rating does not kill the opportunity. It makes data preparation part of the project rather than an invisible assumption.

7. Minutes 42–49: Review Risk and Human Oversight

Risk depends on context.

A poor internal meeting summary is inconvenient. An incorrect medical recommendation, credit decision, safety instruction, or employment decision may cause significant harm.

NIST’s AI Risk Management Framework organizes AI risk work around four functions: Govern, Map, Measure, and Manage. It emphasizes that risk assessment should consider the system’s context, affected parties, impacts, and lifecycle rather than model performance alone.[2]

During a 60-minute review, I would ask:

• What can go wrong?
• Who could be affected?
• How quickly would an error be detected?
• Can the action be reversed?
• Who reviews sensitive outputs?
• What happens when confidence is low?
• Who is accountable after deployment?
• What evidence must be logged?

The OECD AI Principles likewise emphasize accountability, robustness, security, transparency, and respect for human rights in the development and use of AI systems.

For higher-consequence opportunities, the one-hour review should not produce deployment approval. It should identify the need for legal, privacy, security, domain, regulatory, and impact assessments.

Microsoft’s Responsible AI Standard requires impact assessment for AI systems and provides a structured template for examining intended uses, stakeholders, potential benefits, and potential harms.

A practical first-use-case design usually keeps irreversible or high-impact actions behind human approval until the organization has sufficient evidence to justify a different control model.

8. Minutes 49–55: Estimate Value and Implementation Friction

I would not build a detailed ROI model in six minutes. I would estimate directionally whether the opportunity has enough value to investigate.

I would score four dimensions from one to five:

Dimension	1	5
Business value	Minor convenience	Material operational outcome
Feasibility	Major unknowns	Clear workflow and inputs
Risk manageability	Severe unresolved exposure	Controlled and reversible
Adoption readiness	No owner or user support	Owner and users are engaged

A strong candidate normally has meaningful business value, manageable implementation friction, identifiable users, a credible owner, and measurable outcomes.

However, the total score should not make the decision automatically.

A high-value use case with unacceptable risk should not proceed merely because its numerical total is strong. A moderate-value opportunity may be an excellent first pilot if it is measurable, reversible, and easy to contain.

The scoring model is a discussion tool, not a mathematical proof.

I would also record the main implementation frictions:

• Data cleanup
• Integration work
• User-interface changes
• Access control
• Evaluation design
• Human-review capacity
• Vendor dependency
• Process redesign
• Training
• Monitoring and support

This creates a more realistic picture than comparing only model capability and licensing cost.

9. Minutes 55–60: Make a Decision

The final five minutes should produce a decision, not another list of questions.

Proceed

Proceed when the problem is measurable, the workflow is understood, the system’s role is bounded, the required information appears accessible, and the risks appear manageable.

The next step might be a paid discovery, workflow audit, data review, or controlled prototype.

Redesign

Redesign when the pain is real but the proposed AI role is too broad, the workflow contains unresolved bottlenecks, or a simpler intervention should be tested first.

For example, replace “autonomous HR agent” with “policy retrieval and cited draft responses for HR approval.”

Stop

Stop when no meaningful baseline exists, the problem lacks an owner, the required data is unavailable, the economics are weak, or the potential harm cannot be managed responsibly.

Stopping is not failure. It prevents an attractive technology from becoming an expensive distraction.

The output of the hour should fit on one page:

• Problem statement
• User and owner
• Current workflow
• Baseline
• Proposed AI role
• Data status
• Main risks
• Success measure
• Decision
• Next evidence required

A deeper engagement can then turn that page into a discovery plan, architecture, evaluation design, pilot scope, and implementation roadmap.

For the distinction between those stages, see The Difference Between an AI Demo, a Pilot, and a Production System.

COMPARISON TABLE: WHAT THE REVIEW PRODUCES

Weak AI discussion	60-minute opportunity review
Starts with a model or vendor	Starts with a workflow constraint
Uses general efficiency claims	Establishes an observable baseline
Assumes AI is required	Compares AI and non-AI options
Discusses ideal outputs	Examines exceptions and failure modes
Treats available files as ready data	Reviews quality, access, and ownership
Leaves accountability unclear	Names a business owner and reviewers
Ends with more ideas	Ends with proceed, redesign, or stop
Moves directly toward implementation	Defines the next evidence required

FAQ

What is an AI opportunity assessment?

An AI opportunity assessment examines a business workflow to determine whether AI could produce measurable value. It typically considers the current problem, users, process, baseline, data, technical feasibility, risk, adoption requirements, and success measures.

Can an AI opportunity really be evaluated in 60 minutes?

A one-hour session can screen an opportunity and identify whether deeper discovery is justified. It cannot confirm production feasibility, legal compliance, security, return on investment, or model performance. Those require evidence, testing, and specialist review.

What makes a good first AI use case?

A good first use case has a clear owner, measurable baseline, narrow scope, accessible information, manageable risk, and a result that can be tested with real users. It should also have defined human approval and escalation points where errors could matter.

How do you measure the value of an AI opportunity?

Start with the existing workflow. Measure indicators such as task time, case volume, error rate, backlog, response delay, rework, labor cost, conversion, or service quality. A pilot should compare its results against that baseline.

When should a company reject an AI use case?

A company should pause or reject an opportunity when the business problem is vague, no accountable owner exists, required information is unavailable, risks cannot be controlled, users will not adopt the workflow, or a simpler solution would address the problem more effectively.

Should an AI opportunity assessment include risk?

Yes. Risk should be evaluated from the beginning rather than after a prototype has been built. The review should consider affected people, error consequences, privacy, security, human oversight, reversibility, monitoring, and accountability.