AI Opportunity Discovery

Executive summary

AI opportunity discovery converts technology enthusiasm into a defensible portfolio of use cases. You inventory cognitive work, test whether AI is the right lever (versus rules, workflow, or data fixes), form value hypotheses with baselines, score candidates on value × feasibility × risk, and leave with artefacts that survive CFO and CISO review—not a slide of “40 GenAI ideas.”

When to use this page

• When stakeholders arrive with “we need AI” before naming a business problem, success measure, or owner.
• Before architecture, vendor selection, or model choice—discovery determines whether and which, not how.
• When a portfolio has too many ideas and no credible pilot recommendation.
• When a prior AI initiative failed and leadership asks “what should we try next?”
• Pair with Opportunity Discovery for workshop delivery and Business case and prioritisation once candidates are scored.

Executive view

Ask whether the team can produce a prioritised pilot recommendation backed by baselines, not vendor demos. Challenge any use case that cannot state annual cost of the problem in pounds or hours.

Decision required: Which one or two pilots enter structured business-case development this quarter?

Technical view

Map workflows, data sources, control points and error costs before naming LLM, RAG or agent patterns. Capture suitability decisions (AI vs rules) in writing.

Build scoring models the client can rerun when priorities shift. Missing metrics and process maps are discovery findings, not blockers to ignore.

Why this matters

Most failed enterprise AI programmes do not fail on model quality. They fail because the organisation chose the wrong problem, applied AI where deterministic automation would suffice, lacked a baseline to prove value, or prioritised by executive enthusiasm instead of value × feasibility × risk.

An AI Solution Engineer owns the translation from ambiguous demand (“add GenAI everywhere”) to a ranked opportunity set with a credible pilot and a kill list. That translation is not brainstorming. It is structured discovery: inventory cognitive work, test suitability, quantify hypotheses, score candidates and produce artefacts that connect to Business case and prioritisation.

Weak discovery produces expensive pilots that cannot show payback, erodes sponsor trust, and forces delivery teams into heroics on use cases that should never have been funded. Strong discovery produces a one-page pilot recommendation a CFO can challenge constructively and a CISO can map to controls.

Learn

What counts as an AI opportunity

An AI opportunity is a recurring business activity where judgement under uncertainty creates measurable cost, delay, error or missed revenue—and where improved cognition (classification, retrieval, generation, prediction, ranking, optimisation) could change an outcome if data, controls and adoption allow.

Patterns that often fit AI (after suitability check):

Pattern	Typical signal	Example
High-volume classification	Thousands of similar decisions per week	Triage inbound emails to the right queue
Search and synthesis	Experts spend hours finding answers across fragmented sources	Policy lookup for contact-centre agents
Document extraction and structuring	Unstructured inputs block downstream automation	Extract fields from supplier invoices
Prediction and ranking	Historical outcomes exist; delay has cost	Prioritise collections cases by recovery likelihood
Generation with guardrails	Drafting is repetitive but must stay on-policy	First draft of RFP response sections from approved library
Optimisation under constraints	Many variables; human heuristics suboptimal	Route field engineers given skills, SLA and travel time

Patterns that often do not need AI first:

• Broken workflow with no owner
• Missing master data
• Policy ambiguity humans cannot agree on
• Low volume (<50 cases/month) where manual handling is cheaper than platform cost
• Decisions that must be 100% deterministic and are already codifiable as rules

Discovery questions that surface real opportunities

Use these in interviews, workshops and process observation. Answers become rows in your use-case inventory.

Who and how often

• Who performs this task today? Role, band, location, FTE fraction?
• How many times per day/week/month?
• What triggers the work item?

Time and cost

• Minutes per case at median and P90?
• What is fully loaded cost per hour for that role?
• What is the annual cost of this activity at current volume?

Quality and error

• What error rate is tolerated? What happens when wrong?
• Regulatory, financial or reputational cost of a bad decision?
• Rework rate and average rework time?

Data and evidence

• What inputs are used? Structured, unstructured, tacit?
• Where do they live? Quality, freshness, access constraints?
• Is there labelled history for prediction or evaluation?

Control and trust

• What must remain under human approval?
• Which decisions are irreversible?
• What would “good enough” accuracy mean for go-live?

Alternatives

• Could a rule, form change, or workflow fix solve 80%?
• Has automation been attempted before? Why did it stall?

Suitability: rules, workflow, data fix, or AI

The most common discovery failure is applying AI to a problem that rules or process engineering would solve faster and cheaper. Run every candidate through a suitability gate before scoring value.

Decision sequence (apply in order):

1. Process fix — Is the workflow broken, duplicated or missing an owner? Fix that first.
2. Data fix — Is the blocker bad master data, missing fields or no single source of truth?
3. Deterministic automation — Can you express the decision as explicit rules with high confidence?
4. AI-assisted — Human in the loop; AI drafts or ranks; human approves.
5. AI-automated — Low-risk, high-volume, reversible decisions with monitoring.

Rules vs AI — practical tests

Test	Favour rules	Favour AI
Decision logic	Stable, written, agreed	Tacit expert judgement
Input format	Structured fields	Unstructured language, images, mixed docs
Volume	Any	High enough to amortise platform cost
Explainability requirement	Must cite exact rule clause	Can cite sources + confidence
Change frequency	Rare	Frequent policy/language drift
Error cost	Must be zero	Tolerable with human review

Example suitability call: “Classify mortgage applications as accept/refer/decline against published criteria” → rules engine + workflow, not LLM. “Summarise 200-page credit memo for committee reader” → RAG + human review, not rules.

Document the suitability decision in one sentence per use case. Reviewers will ask “why not RPA?” or “why not a form change?”—your note is the answer.

Value hypotheses and baselines

A value hypothesis states: if we apply [intervention] to [workflow], then [metric] will improve by [amount] within [timeframe], because [mechanism].

Without a baseline, “30% faster” is meaningless. Baselines anchor business cases and post-implementation reviews.

Baseline types

Baseline	What to capture	Source
Time	Median and P90 handle time	Workflow logs, time studies, sample audit
Cost	Fully loaded FTE + error/rework cost	Finance, operational metrics
Quality	Error rate, CSAT, compliance findings	QA samples, complaints, audit
Volume	Cases per period	Ticketing, CRM, operations dashboards
Revenue	Conversion, retention, upsell where relevant	Sales and product analytics

Hypothesis quality bar

• Metric is measurable within the pilot window (90 days, not “strategic transformation”).
• Mechanism is plausible (e.g. “agents stop searching five systems” not “AI magic”).
• Assumptions are labelled (volume stable, policy corpus complete, adoption ≥70%).
• Sensitivity noted: if adoption is 40% not 70%, value drops to X.

Example hypothesis (retail banking): “If Tier-1 agents use policy Q&A with citations for card dispute eligibility, median handle time on dispute calls drops from 11.2 to 8.5 minutes (24% reduction) within 12 weeks, because agents no longer place customers on hold to search PDFs and SharePoint.”

Prioritisation scoring

After suitability filtering, score remaining candidates so prioritisation is explainable, not political.

Core dimensions (score 1–5 each)

Dimension	1 (weak)	5 (strong)
Value	<£100k annual benefit	>£2m or strategic must-win
Data readiness	No access, poor quality	Clean, labelled, governed
Technical feasibility	Novel integration, immature pattern	Proven pattern, existing platform
Risk and compliance	High autonomous decisions on regulated data	Low risk, human-in-loop, clear controls
Adoption complexity	Many BUs, union, channel conflict	Single team, willing sponsor
Time to value	>12 months to measurable outcome	Pilot outcome in ≤90 days
Sponsorship	No named owner	Executive owner + budget line

Composite approaches

• Value × Feasibility matrix — Quick portfolio view; bubble size = risk or cost.
• Weighted scorecard — Weights set with sponsor (e.g. value 30%, data 20%, risk 20%, time-to-value 15%, adoption 15%).
• RICE variant — Reach × Impact × Confidence / Effort; use Confidence to penalise weak baselines.
• Kill criteria — Auto-exclude if: no baseline, no owner, CISO red-line on data egress, or suitability = rules.

Record scores in a spreadsheet or Airtable the client can update. Version the weighting when steering committee priorities shift.

Discovery artefacts

Discovery is complete when these artefacts exist—not when the workshop ends.

Artefact	Purpose	Minimum content
Use-case inventory	Single register of all candidates	ID, workflow, owner, volume, suitability, status
Process snapshots	Current-state for top candidates	Swimlane or SIPOC, pain points, systems
Baseline sheet	Evidence for hypotheses	Metrics, source, date, confidence
Suitability log	AI vs alternatives	Decision, rationale, reviewer
Prioritisation matrix	Ranked portfolio	Scores, weights, rank, kill list
Pilot recommendation	One-page decision	Recommended pilot, why now, why not others
Assumption and constraint log	Risk for business case	Data, policy, org, technical
Discovery findings	Gaps discovered	Missing maps, metrics, owners

Align artefact depth with Opportunity Discovery workshop outputs before advancing to Business case and prioritisation.

Frameworks and methods

Cognitive work inventory (CWI)

Purpose: Systematically list where human judgement consumes time at scale.

Steps:

1. Select a value chain or function (e.g. claims FNOL, KYC onboarding, L2 support).
2. List activities with frequency × handle time (from interviews and samples).
3. Tag activity type: search, classify, extract, draft, decide, predict, optimise.
4. Flag pain: rework, compliance exposure, customer wait, revenue leakage.
5. Merge duplicates; rank by annualised cognitive cost (hours × loaded rate).

When not to use: Strategy off-sites without access to operators—you will invent fiction. Pair with real shadowing or ticket samples.

AI suitability ladder (ASL)

Documented in Learn above: process → data → rules → AI-assisted → AI-automated. Every use case gets a rung. Pilots should start at AI-assisted unless risk assessment explicitly allows more automation.

Value-feasibility-risk (VFR) bubble chart

Plot value (Y) vs feasibility (X). Bubble size = residual risk. Quadrants:

• Quick wins — High value, high feasibility; default pilot zone.
• Strategic bets — High value, lower feasibility; need spike or PoC funding.
• Hygiene — Low value; deprioritise unless compliance-mandated.
• Traps — High feasibility, low value; often “cool demos” that steal capacity.

Discovery-to-business-case handoff checklist

Before closing discovery:

• Top pilot has named business owner and success metric
• Baseline captured with source and date
• Suitability documented (why AI, why now)
• CISO/data privacy engaged on data classification
• Kill list communicated (manage expectations)
• Scoring model agreed with sponsor
• Assumptions registered for business-case sensitivity

Discovery workshop facilitation

Discovery workshops fail when they become brainstorm theatre—sticky notes with no owners, no volumes, no kill criteria. Structure workshops to produce inventory rows, not enthusiasm.

Pre-work (mandatory):

• Send pre-read: strategy excerpt, partial metrics, list of known ideas
• Interview at least six stakeholders: buyer, process owner, two users, data, security
• Prepare blank inventory template and suitability ladder poster

Agenda (3–4 hours):

Block	Duration	Output
Context and success definition	30 min	Problem statement, success metric candidates
Current-state walkthrough	45 min	Process snapshot, pain points on map
Cognitive work storm (silent then share)	40 min	Raw inventory rows with frequency estimates
Suitability filter (facilitated)	45 min	Kill/defer list with reasons
Baseline reality check	30 min	Flags: “we don’t measure this”
Prioritisation draft	30 min	Top five for scoring homework

Facilitation rules:

• No vendor demos in discovery workshops
• Capture dissent when suitability kills a sponsor’s favourite idea
• Assign homework owners for missing baselines with dates
• End with next decision date, not “we’ll socialise”

Connecting discovery to the business case

Discovery artefacts feed directly into Business case and prioritisation. The handoff is not a hand-wave—it is a package:

Discovery output	Business-case input
Baseline sheet	Current-state cost in benefit formula
Value hypothesis	Benefit scenarios (base/upside/downside)
Assumption log	Sensitivity variables
Suitability log	Capex/opex split (rules vs AI)
Pilot recommendation	Phase 1 scope and funding ask
Kill list	Explicitly excluded costs

If discovery cannot supply a baseline, the business case must label benefits as hypothesis-led learning investment with a capped ceiling—honesty preserves steering trust.

Pattern library — discovery red flags

Red flag heard in workshop	What it usually means	Discovery action
“Everyone knows this is broken”	No metric	Assign baseline capture; downgrade confidence
“AI will figure it out”	Data/policy not ready	Suitability cap at assisted; data workstream
“We just need a chatbot”	Undefined workflow	Issue tree; refuse architecture
“Compliance will sign later”	Late veto risk	Early CISO/DPO slot; log as constraint
“Volume is huge” (no number)	Unvalidated economics	Demand source; sample audit
“Same as [competitor]”	Strategy cargo-cult	Reframe to own P&L and controls

Architecture or operating-model notes

Discovery sits between strategy and delivery. Typical ownership:

Role	Discovery responsibility
AI Solution Engineer	Facilitate, synthesise, score, draft recommendation
Business owner	Validate workflow, adopt metrics, own outcome
Process analyst / BA	Process maps, volume validation
Data steward	Data readiness assessment
Risk / legal / security	Early constraint flags, not late veto
Finance	Challenge baselines and benefit sizing

Timebox discovery: 2–4 weeks for a single function portfolio; 4–8 weeks for enterprise-wide idea dumps. Longer discovery without decision is workshop theatre.

Demand ("40 AI ideas")
    → CWI + interviews
    → Suitability filter (often cuts 40 → 12)
    → Baselines + hypotheses (12 → 8 with data)
    → Scoring (8 → 3 finalists)
    → Pilot recommendation (1–2)
    → Business case

Real-world scenarios

Scenario A — Retail banking contact centre (UK)

Context: A retail bank’s contact centre leadership submits 38 “AI opportunities” after a board mandate on productivity. Volumes: 2.1 million inbound contacts per year; 4,200 FTE across voice and chat; fully loaded agent cost ~£42/hour.

Discovery work:

• Cognitive work inventory on top five complaint drivers shows policy lookup consumes 18 minutes of average 42-minute dispute handle time (sample of 120 calls).
• Suitability: Eligibility rules exist but are scattered across 340 PDFs and an outdated intranet. Rules engine possible for decision but not for natural-language agent questions in live calls → AI-assisted RAG with citations, not autonomous resolution.
• Baseline: 380,000 dispute-related contacts/year × 18 min search = 114,000 hours ≈ £4.8m/year addressable cognitive cost (upper bound if search fully eliminated).
• Scoring: Value 4, data readiness 3 (PDFs available, ACL complex), risk 4 (human-in-loop, no payment execution), adoption 3 (union consultation needed), time to value 4 (90-day pilot).
• Kill list: “Fully autonomous complaint resolution” scores risk 1, data readiness 2—removed despite executive interest.
• Recommendation: Pilot policy Q&A copilot for Tier-1 on card disputes (800 agents), target 25% handle-time reduction on pilot queue, measure at 90 days.

Outcome framing: Pilot cost £320k; if 15% handle-time reduction on 380k contacts materialises, annual benefit ~£720k—payback under 12 months if scaled. Steering approves pilot; autonomous resolution deferred.

Scenario B — Industrial equipment aftermarket (manufacturing)

Context: A B2B manufacturer with £1.2bn aftermarket revenue wants AI on field service. 1,100 field engineers; 450,000 work orders/year; average 2.3 hours searching parts catalogues, service bulletins and prior job notes before on-site fix.

Discovery work:

• Inventory shows search and synthesis dominates, not prediction. Failure to find correct part first time drives 12% revisit rate (~54,000 revisits), £180 average revisit cost ≈ £9.7m/year rework.
• Suitability: Parts matching against structured SKU database → rules + improved UX for exact match; ambiguous symptom-to-part mapping across 40 years of models → retrieval + ranking over bulletins and notes.
• Baseline: Engineer search time 2.3 h/job × 450k jobs × £65/hour loaded ≈ £67m time cost (theoretical max); realistic target 30% search reduction in pilot region.
• Data readiness challenge: 60% of valuable content in unstructured PDF bulletins; OCR and metadata project required—feasibility score 2 for enterprise rollout, 4 for regional pilot with curated corpus.
• Scoring: Value 5, feasibility 3 (data engineering prerequisite), risk 4 (recommendation only, engineer confirms part), sponsorship 5 (SVP Aftermarket owns P&L).
• Recommendation: 90-day regional pilot on top 200 failure codes; parallel data pipeline for bulletin ingestion; kill “autonomous parts ordering” until error cost model approved.

Numbers for steering: Regional pilot £480k; expected benefit in pilot geography £1.4m/year if revisit rate drops 3 percentage points and search time drops 25%—3:1 benefit-to-cost over three years at scale.

Scenario C — Health payer prior authorisation (US)

Context: Regional health plan; 1.8 million prior auth requests/year; 220 nurses doing medical necessity review; 72-hour regulatory turnaround pressure; denial overturn rate on appeal 34% (indicator of inconsistent decisions).

Discovery findings:

• Not all auth needs AI—60% are straight-through protocol match → rules engine and form redesign first.
• Remaining 40% need clinical synthesis across policy, member history and submission notes → candidate for AI-assisted summarisation and checklist, nurse approves.
• Baseline: Nurse review 23 minutes median; £52/hour loaded; 720k complex cases ≈ 276k hours ≈ £14.3m/year.
• Risk: High—wrong auth affects care and fines. Suitability capped at AI-assisted; full automation excluded.
• Prioritisation: Rules STP project ranks #1 (value 4, feasibility 5); AI summarisation ranks #2 for phase 2.

This scenario illustrates portfolio ordering: the best “AI opportunity” may lose to a rules project discovered in the same discovery pass.

Scenario D — Logistics carrier dispatch optimisation

Context: European parcel carrier; 8,200 drivers; 18 million parcels/week peak; dispatch planners spend 45 minutes per shift adjusting routes after traffic and SLA exceptions. Planner fully loaded cost €38/hour; 620 planners across hubs.

Discovery work:

• Optimisation pattern candidate—but 60% of delays stem from bad address geocoding (data fix), not routing algorithm.
• Remaining 40% is dynamic re-routing under SLA pressure → AI/optimisation hybrid with human approval for bulk replans.
• Baseline: 620 planners × 0.75 h/shift × 2 shifts × 250 days × €38 ≈ €8.8m/year planner adjustment time (theoretical max).
• Suitability: Autonomous replan without human confirm excluded—missed SLA fines €2m/year historical.
• Scoring: Data fix (geocoding) ranks #1—value 4, feasibility 4, 6-month payback; AI routing assist ranks #2 pending clean addresses.

Pilot recommendation: Phase 0 master-data programme (£1.1m); Phase 1 routing assist pilot in three hubs (£290k) with human confirm step; kill “full autonomous dispatch” until SLA error model signed by operations and risk.

Numbers for EXCO: Geocoding fix expected −12% failed-first-attempt deliveries (baseline 7.8% → target 6.9%); routing assist target −15% planner adjustment time in pilot hubs—combined €3.2–4.1m/year benefit range at scale vs €1.4m phased investment.

Practice exercises

Primary exercise — Retail banking portfolio (90 minutes)

Brief: Your client is a UK retail bank. Marketing has proposed five use cases:

1. GenAI marketing copy for 200 products
2. Voice summarisation for mortgage advice calls (FCA-regulated)
3. Policy Q&A for card dispute agents
4. Chatbot for balance enquiries
5. LLM fraud detection replacing rules engine

Tasks:

1. Run each through the suitability ladder; document one-sentence rationale.
2. Estimate relative value using provided assumptions: agents £42/h, 380k dispute calls/year, marketing copy £0 marginal cost already outsourced.
3. Score on value, data readiness, risk, time to value (1–5).
4. Plot VFR bubble chart; write one-page pilot recommendation.
5. List kill list with reasons.

Acceptance criteria:

• At least two use cases killed or deferred with written suitability rationale
• Pilot recommendation names one primary pilot and one backup
• Baseline stated for recommended pilot (even if approximate, source labelled)
• No vendor names in the recommendation

Stretch exercise — Enterprise idea dump (half day)

Brief: CIO gives you 45 ideas from a hackathon. You have interview notes from six functions and partial volume data.

Tasks:

1. Build use-case inventory spreadsheet (45 rows minimum columns from artefacts section).
2. Cluster into ≤8 workflow themes; deduplicate.
3. Select top three for baseline deep-dive; write value hypotheses.
4. Facilitate mock steering: 10-minute readout script + 5 anticipated CFO questions with answers.
5. Produce discovery-to-business-case handoff checklist (completed).

Acceptance criteria:

• Scoring weights documented and sum to 100%
• Assumption log with ≥10 entries
• Steering readout ≤500 words, BLUF in first two sentences

Questions you should be able to answer

1. What is the annual cost of the problem today, and what baseline proves it?
2. Does this need prediction, generation, search, classification, optimisation or automation—and what is the minimum viable pattern?
3. Why is this better than a rules engine, workflow change or master-data fix?
4. What volume and frequency make the economics work after platform and change cost?
5. What must remain under human control, and who approves exceptions?
6. What error rate is tolerable, and what is the cost of being wrong?
7. Which data sources are required, and are they governed and accessible under policy?
8. Who is the economic owner of the outcome—not just the IT sponsor?
9. What kills this use case in the next 90 days if assumptions fail?
10. How will you measure success at pilot end vs baseline?
11. Why this pilot before the other scored candidates?
12. What is on the explicit kill list, and how was that communicated?
13. Which regulatory or model-risk constraints cap the automation level?
14. What adoption threshold is required for benefits to materialise?
15. What discovery gaps (missing maps, metrics, owners) remain, and who closes them?
16. How do you rerun prioritisation when the sponsor changes weights mid-quarter?
17. What is the confidence level on each baseline, and what would upgrade it one notch?

Worked example — scoring five retail banking use cases

Use case	Value	Data	Feasibility	Risk	Adoption	T2V	Sponsor	Weighted (30/15/15/20/10/10)
Policy Q&A (disputes)	4	3	4	4	3	4	4	3.65
Marketing copy GenAI	2	4	5	3	4	5	2	3.15
Mortgage voice summary	4	2	2	2	2	2	3	2.55
Balance chatbot	1	5	5	4	5	5	2	3.05
LLM fraud replace rules	3	1	1	1	1	1	2	1.45

Weights reflect buyer who prioritises risk and value over speed. Pilot: policy Q&A. Kill: LLM fraud (suitability = rules; data readiness 1). Defer: mortgage voice until FCA guidance workshop completes.

This table is the kind of artefact steering should receive—not a bullet list of “high/medium/low.”

Pilot recommendation one-pager — template structure

Use this skeleton when writing the primary practice output:

TITLE: Pilot recommendation — [use case name] — [client/function]

BLUF: Recommend pilot [name] with [budget] over [duration]; defer [X]; kill [Y].

PROBLEM (baseline): [metric] today = [value], source [system/report], date [ISO].

HYPOTHESIS: If [intervention], then [metric] → [target] by [week N].

WHY AI (suitability): [One sentence why not rules/workflow alone].

WHY NOW: [Gate, cost of delay, sponsor priority].

WHY NOT OTHERS: [Top two alternatives scored lower because …].

RISKS (top 3): [Risk] — mitigation — owner.

SUCCESS CRITERIA: [Measurable at pilot end].

KILL CRITERIA: [Stop if …].

NEXT: Business case by [date]; owner [name].

A completed one-pager should fit one printed page with normal margins—if it spills to three pages, you are writing a memo, not a recommendation.

Portfolio roadmap phasing

Discovery should end with a phased view, not a single pilot in isolation:

Phase	Timeframe	Content	Funding character
0 — Fix foundations	0–6 months	Data, rules STP, process owners	Often non-AI capex
1 — Assisted AI pilot	3–6 months	Human-in-loop, eval harness	Pilot opex
2 — Scale	6–18 months	Rollout, change, platform	Programme capex/opex
3 — Automation	18+ months	Only where risk tier allows	Requires model risk sign-off

Publishing this roadmap manages expectations: stakeholders see their idea in phase 3 rather than “killed.”

Negative cases — when discovery fails

Vendor-first discovery

Symptom: Workshop opens with platform demo; use cases shaped to product features.

Impact: Pilots fit vendor roadmap, not P&L; baselines never captured; post-pilot “success” is usage counts not business metrics.

Fix: Ban demos until CWI complete; suitability gate before any architecture.

The infinite backlog

Symptom: 40 ideas scored equally; no kill list; “we’ll do them all eventually.”

Impact: Team spread across thin pilots; nothing reaches production; sponsor fatigue.

Fix: Force rank; cap active pilots to capacity; publish kill list with reasons.

Baseline-free enthusiasm

Symptom: “AI will save 30%” with no current-state measurement.

Impact: Business case rejected at CFO; impossible to prove value later; credibility damage.

Fix: Timebox baseline capture; if impossible, downgrade confidence score and size pilot as learning investment with explicit ceiling.

Autonomy before policy clarity

Symptom: Pilot targets fully automated customer decisions while policy corpus is contested.

Impact: Compliance stop; rework; reputational risk.

Fix: Suitability ladder caps at AI-assisted until policy and evaluation harness exist.

Ignoring the rules-engine win

Symptom: Team jumps to LLM for codifiable decisions because “AI is the mandate.”

Impact: Higher cost, worse explainability, slower delivery than BPM/rules.

Fix: Mandatory “why not rules?” field on every inventory row.

Discovery without control functions

Symptom: CISO learns about customer-data RAG at architecture gate.

Impact: Late veto; redesign; blame on AI team.

Fix: Risk/legal/security in discovery interviews, not approval meetings.

Output

Expected outputs for this topic:

• Use-case inventory — Complete register with suitability decisions
• Cognitive work inventory — Frequency × time ranked activities
• Baseline sheet — Metrics, sources, confidence for top candidates
• Value hypothesis register — If/then/because statements with assumptions
• Prioritisation matrix — Weighted scores and rank order
• VFR bubble chart — Visual portfolio view
• Pilot recommendation (one page) — Primary pilot, backup, kill list
• Assumption and constraint log — Handoff to business case
• Portfolio roadmap — Phased view: rules vs AI-assisted vs future automation

Practice checklist

• I can explain suitability (rules vs AI) without naming a vendor first
• I completed the primary practice exercise with a written pilot recommendation
• My recommendation includes a baseline and labelled assumptions
• I produced a prioritisation matrix with explicit kill list
• I can defend scores in a mock CFO or CISO challenge
• I linked discovery artefacts to business-case inputs
• I documented at least three negative cases relevant to my industry

Related playbook content

• Opportunity Discovery — Workshop structure, stakeholder groups and discovery outputs
• Business case and prioritisation — Benefit sizing, scenarios and funding gates
• Consulting and Problem Solving — Issue trees and hypothesis-driven problem framing
• Product Management — Backlog prioritisation and outcome ownership
• Commercial and Financial Modelling — Benefit formulas and sensitivity
• Responsible AI and Governance — Risk constraints on automation level
• VALUE gate — Quality bar before stage advance
• How to use this Learning Map — Reference-depth study method
• 8D Framework — End-to-end engagement lifecycle

Supplemental scenario — hospitality group contact-centre portfolio

Context: Hotel chain; 47 use cases in workshop backlog; steering allocated £600k pilot envelope only.

Prioritisation snapshot (weighted matrix excerpt):

Rank	Use case	Value score	Feasibility	Risk	Decision
1	Loyalty policy RAG (agents)	82	71	Medium	Pilot
2	Booking modification rules bot	76	88	Low	Rules-first ship
3	Revenue management "AI pricing"	91	34	High	Kill (no baseline)
4	Guest sentiment social listening	68	52	Medium	Defer Q3

Pilot recommendation one-pager numbers: Baseline handle time 6.8 min (Fact: ops sample n=2,400); hypothesis −25% at 55% adoption; kill if adoption <35% week 6.

CFO challenge handled in discovery readout: "Rank 3 scores highest value—why kill?" Response: no trusted baseline on price elasticity; Hypothesis only; steering asked for kill list explicitly—rank 3 fails feasibility gate <40.

Handoff: Business case receives use-case inventory, baseline sheet, assumption log—not slide photos of sticky notes.

Key takeaways

• Discovery decides whether and which—not model vendor or architecture. Run suitability before scoring.
• Every ranked use case needs a baseline, a hypothesis and an owner; otherwise it is a hobby project.
• Kill lists build trust; portfolios of 40 equal priorities build fatigue.
• Rules and workflow wins are discovery successes, not AI failures—capture them explicitly.
• Hand off to business case only when pilot recommendation, baselines and assumption log are steering-ready.

What to do next

1. Complete the primary practice exercise and file the pilot recommendation in your pattern library.
2. Continue with Product Management for backlog and outcome ownership.
3. Run the Opportunity Discovery Guide chapter on your next live workshop.
4. Open the interactive playbook for prioritisation workshops.