Every AI program starts the same way. Someone books a conference room, writes “AI Opportunities” at the top of the whiteboard, and invites a cross-functional team to brainstorm. Two hours later, the team has 40 ideas, three different definitions of “AI,” and zero clarity on what to actually build first. Three months after that, a pilot is underway on a use case that sounded exciting in the room but turns out to be low-volume, data-sparse, and practically impossible to measure.
This pattern is not unique to any one industry or company size. It is, by most accounts, the dominant enterprise AI failure mode in 2026. Research compiled across multiple analyst sources puts AI project failure rates above 80% — roughly double the failure rate of non-AI IT projects. The RAND Corporation’s 2024 analysis confirmed the same figure. And when researchers dig into the root causes, the answer is consistent: organisations are not failing because their models are bad. They are failing because they started from the wrong workflow.
The selection problem precedes the technology problem. Bad discovery produces a bad candidate list, and no amount of rigorous scoring, careful piloting, or smart engineering can fix a fundamentally wrong starting point.
This article is about the work that happens before you score anything, before you write a business case, and before you stand up a proof of concept. It is a practical, systematic method for discovering which workflows in your organisation actually deserve to be on the AI candidate list — and which ones should never have been considered in the first place. The goal is not to generate more ideas. It is to generate better-qualified candidates through evidence, observation, and structured analysis.
The Discovery Gap: Why Most AI Portfolios Start With the Wrong Workflows
There is a structural gap in how most organisations approach AI adoption. The AI delivery machinery — vendor selection, model evaluation, architecture design, sprint planning — has matured considerably. What has not matured at the same rate is the upstream work of identifying which processes should be automated in the first place.
Most teams treat discovery as a one-time event rather than a repeatable discipline. They run a workshop, collect ideas, hand them to a scoring committee, and move on. The fundamental problem is that this approach mistakes ideation for discovery. Ideation asks: “What could AI do here?” Discovery asks: “What is actually happening here, how often, with what inputs, and at what cost to the business?” Those are completely different questions, and they require completely different methods.
The Three Most Common Starting Point Errors
The technology-first trap. Teams begin from a capability — “we have an LLM, what can we use it for?” — rather than from a business outcome. This produces use cases that are technically feasible but organisationally irrelevant. The workflow might be interesting as a demonstration but has no measurable connection to cost, revenue, risk, or customer experience. It sits in the portfolio consuming resources until someone finally asks what value it was supposed to deliver.
The loudest stakeholder trap. Discovery by committee tends to reflect the priorities of whoever is most senior or most articulate in the room. Senior leaders have strong opinions about strategic workflows, but they are often the people furthest from the actual day-to-day friction. The workflows that generate the most pain for operations teams — the ones that are genuinely high-volume, highly repetitive, and quietly expensive — rarely come up in executive ideation sessions because they are not glamorous enough to mention.
The polished process map trap. Many organisations have documented processes that look clean on paper but bear no resemblance to how work actually happens. Documented processes show the ideal path. Real processes show the detours: the spreadsheet someone built three years ago to handle an edge case, the Slack message that kicks off a task that should be in the system, the manual lookup that happens because two databases have never been integrated. AI applied to the documented version of a process will fail in production because production is the real version.
What Systematic Discovery Changes
Systematic workflow discovery replaces assumptions with evidence. It uses multiple data sources — system logs, desktop behaviour data, direct observation, and structured interviews — to construct an accurate picture of how work actually flows through the organisation. It quantifies that picture: how many times does this task happen per week? How long does it take? What percentage of instances require human judgment to resolve an exception? What happens when it fails?
This evidence base makes the candidate selection process far more defensible. Instead of a portfolio shaped by organisational politics and executive intuition, you get a portfolio shaped by volume, cost, measurability, and data availability. That is the foundation on which AI programs that deliver ROI are actually built.
The Four Primary Sources for Workflow Discovery
No single discovery method gives you the complete picture. The workflows that generate the best AI ROI are typically visible across multiple data sources simultaneously — and triangulation across sources is one of the most reliable signals that a candidate is worth serious investigation.
Source 1: Process Mining
Process mining reconstructs actual workflows from the event logs generated by enterprise systems — ERPs, CRMs, ticketing platforms, document management systems. Instead of relying on how people say work happens, process mining shows how work actually happens, derived from the timestamps, user IDs, and activity codes that systems record automatically.
The outputs are directly useful for discovery. Process mining reveals: which paths through a process are most common versus most costly; where bottlenecks, rework loops, and compliance deviations concentrate; how much variation exists across instances of the same workflow; and which workflow variants are most expensive in terms of time or error rates.
For AI discovery specifically, the most valuable output is the frequency-by-variant map: a view of how often different versions of the same process occur. High-frequency variants that follow predictable, rule-based paths are strong AI automation candidates. High-frequency variants with a high deviation rate tell you the process has too many exceptions for reliable automation — at least without significant redesign first.
Process mining tools have matured considerably. Platforms like Celonis, Minit, and UiPath Process Mining now include AI-assisted anomaly detection and ROI estimation, not just discovery visualisation. The convergence toward what vendors are calling “process intelligence” means teams can move from discovery to quantified impact assessment within the same platform.
Source 2: Task Mining
Task mining operates at the desktop level, using lightweight agents that record user interactions — keystrokes, application switches, form fields, copy-paste operations — to reconstruct the micro-tasks that make up a knowledge worker’s day. Where process mining shows the end-to-end workflow across systems, task mining shows the human work inside those workflows.
This distinction matters enormously for AI discovery. Many workflows look clean and automatable at the process level but are actually dependent on highly manual, judgement-heavy work at the task level that process logs never capture. Task mining makes those invisible tasks visible: the analyst who manually cross-references two systems before entering a value; the customer service agent who has to read three screens and decode an internal code before composing a reply; the finance team member who reformats data exports before running calculations.
Task mining also quantifies something that process mining cannot: time spent on tasks that exist entirely outside the system of record. These off-system tasks are often where the real friction lives — and where AI assistance (copilot-style or agentic) can deliver the fastest time-to-value, because they require no integration work beyond the desktop.
Source 3: Ethnographic Observation
Despite the sophistication of automated discovery tools, direct observation of work remains irreplaceable for identifying the nuances that data cannot capture. Shadowing a team member through a working day — not in an interview room, but at their actual workstation doing their actual job — reveals the informal workarounds, the unspoken judgment calls, the “it always breaks at this step” knowledge that lives in people’s heads and nowhere else.
The method used is borrowed from product design: contextual inquiry. A discovery analyst sits alongside the worker (or uses a screen-share session for remote roles), observes without interrupting, takes detailed notes on every tool touch, system switch, and decision point, and only asks clarifying questions when the session is complete. The goal is to see the work, not a description of the work.
Three to five observation sessions per target function is typically sufficient to surface the patterns that matter. The most useful signals are: tasks the person performs that they consider too obvious to mention in a workshop; steps they skip when busy; and moments where they make a judgment that the process documentation would suggest is automatic but clearly is not.
Source 4: Operational and System Data Analysis
The fourth source is the least glamorous but often the most persuasive when building a business case: direct analysis of the operational and system data that already exists. This includes ticket volume trends, SLA breach reports, error logs, re-processing rates, headcount-per-process metrics, and customer complaint categorisation data.
Operational data answers the quantification questions that other discovery methods only partially address: How often does this workflow fail? How much does failure cost (in rework time, SLA penalties, or downstream errors)? What is the volume trend — growing, stable, or shrinking? Is the process seasonal or consistent? These numbers determine whether a workflow is worth the cost of building an AI solution — and they are available in most organisations right now, often in reporting systems that are never connected to the AI opportunity analysis.
The most underused source in this category is customer-facing data: contact centre reason codes, chat transcript themes, return reason data, and support ticket categorisation. These datasets directly reveal which process failures are visible to customers — a strong proxy for business value that immediately elevates the ROI case for any fix.
Building the Workflow Inventory: What to Document Before Scoring Anything
Before any scoring model is applied, the discovery phase should produce a structured workflow inventory — a standardised record of every candidate workflow that has been surfaced across the four discovery sources. The inventory is not a prioritisation list. It is a database of facts about each workflow, gathered systematically and independently of any judgment about whether the workflow is a good AI candidate.
The discipline of separating documentation from evaluation is important. When teams jump directly from discovery to scoring, the documentation tends to be shaped by the desire to justify a predetermined conclusion. Building the inventory first forces the team to gather the same structured information on every candidate, which makes subsequent comparison both more honest and more defensible.
The Eight Fields Every Workflow Record Should Contain
1. Process owner and functional context. Which team runs this workflow? Who is accountable for its performance? This determines who must be involved in any subsequent design and deployment work.
2. Trigger and termination. What starts this workflow and what ends it? This scopes the automation boundary clearly and prevents scope creep during design.
3. Task sequence and system footprint. A step-by-step list of the tasks involved and which systems they touch. This is not the documented process — it is the observed or mined process, including off-system tasks and informal steps.
4. Volume and frequency. How many instances occur per day, week, or month? Are there seasonal patterns? Exact figures from system data are preferred over estimates from interviews, because people consistently undercount how often repetitive tasks occur.
5. Cycle time and variability. Average time from trigger to completion. Standard deviation is as important as the mean — high variability often indicates a high exception rate, which is a negative signal for straightforward automation.
6. Error and rework rate. What percentage of instances require correction, re-processing, or escalation? High error rates signal either a data quality problem or a complexity level that may be beyond current automation capabilities.
7. Data inputs and availability. What data does the workflow consume? Is that data structured or unstructured? Is it currently accessible via API or only through manual export? Data availability is frequently the most binding constraint on AI applicability.
8. Current cost and outcome metric. What is the estimated fully-loaded cost of this workflow today? And what would “better” look like in measurable terms — reduced cycle time, lower error rate, fewer FTE hours, higher customer satisfaction score? If you cannot define a measurable outcome at discovery, the workflow is not ready for an AI business case.
The inventory does not need to be exhaustive across the entire organisation to be useful. The typical starting point is three to five business functions, with a target of 15 to 30 candidate workflows documented before any scoring begins. This creates enough surface area to find genuinely high-ROI candidates without creating an analysis paralysis problem.
The Six-Criteria Workflow Fitness Score
Once the inventory is populated, scoring can begin. The scoring model is not a replacement for judgment — it is a structure that ensures consistent, evidence-based evaluation across all candidates. The six criteria below reflect what the evidence from process mining research, enterprise case studies, and analyst data consistently identifies as the determinants of AI workflow success.
Criterion 1: Task Volume (Weight: 20%)
Volume is the most fundamental ROI driver in AI automation. A workflow that occurs 500 times per day at two minutes per instance represents a very different financial case than one that occurs 20 times per month. The scoring here is straightforward: high volume scores high. But the relevant measure is not the total number of users touched by the process — it is the number of automatable task instances per period.
Many teams inflate volume estimates by counting total employee exposure rather than task execution frequency. Invoice reconciliation might touch 200 people in finance, but if only 15 people run it regularly and the actual execution volume is 300 instances per week, 300 is the number that matters for ROI modelling.
Criterion 2: Data Readiness (Weight: 20%)
Data readiness is the single most common reason AI workflows fail in production. A process might be perfectly suited for AI in every other dimension, but if the input data is locked in an unstructured PDF archive, scattered across disconnected legacy systems, or inconsistently formatted, the automation will fail at the data layer before any model logic is ever tested.
Scoring data readiness requires assessing four sub-dimensions: availability (is the data accessible programmatically?), structure (is it structured, semi-structured, or free-form?), quality (is it consistent and accurate enough to trust?), and recency (does the data reflect the current process or a historical version of it?).
Criterion 3: Process Stability (Weight: 15%)
Stable processes are those where the rules governing the workflow are clear, consistent, and unlikely to change frequently. Unstable processes — those undergoing active redesign, subject to regulatory flux, or dependent on rapidly changing business logic — are poor AI candidates not because they cannot be automated, but because the automation will require constant rework to keep pace with the underlying process changes.
A useful proxy for stability is exception rate: what percentage of workflow instances require a human to make a judgment call that is not covered by documented rules? Workflows where more than 20–25% of instances hit exceptions are typically not stable enough for reliable automation without significant pre-automation redesign.
Criterion 4: Measurability of Outcome (Weight: 20%)
If you cannot measure the outcome, you cannot prove the ROI. This criterion asks: does the workflow have a clear, quantifiable success metric that will change in a measurable way if AI is applied? Reduction in cycle time, error rate, cost per transaction, customer satisfaction score on a specific interaction type, or SLA adherence rate are all legitimate metrics.
“Improved employee experience” is not a sufficient outcome metric for a discovery-stage business case. It is qualitative, it is difficult to attribute specifically to the automation, and it will not survive scrutiny in a CFO conversation. Workflows that cannot produce a defensible, quantifiable before-and-after metric score low here.
Criterion 5: Complexity and Exception Rate (Weight: 15%)
This criterion is scored inversely — lower complexity scores higher. Workflows with a high proportion of rules-based, deterministic steps and a low exception rate are the cleanest AI targets. Complexity in this context means: how many distinct decision branches exist in the workflow? How often do edge cases arise that require novel judgment? How many systems does the workflow touch, and how reliable are those integrations?
High complexity is not a permanent disqualifier, but it should move a workflow from the quick-win tier to the core build or strategic bet tier, with corresponding adjustments to timeline and resource expectations.
Criterion 6: Strategic Alignment (Weight: 10%)
All other criteria being equal, workflows that align with stated organisational priorities — cost reduction, customer experience improvement, compliance risk reduction, revenue growth — should be prioritised over those that deliver value in isolation. Strategic alignment also affects change management: workflows that leadership has already identified as priorities are far easier to resource, fund, and drive adoption for than technically superior candidates that no one at the top has ever heard of.
Ten percent weight reflects the reality that strategic alignment is important but should not override evidence. A workflow with a score of 85 on the first five criteria should not be displaced by a politically favoured workflow that scores 55 purely because of executive sponsorship.
The Three-Tier Candidate Stack: Quick Wins, Core Builds, and Strategic Bets
Scoring produces a ranked list, but a ranked list is not a roadmap. The final step in workflow prioritisation is organising candidates into a three-tier stack that reflects not just which workflows score highest, but what kind of investment and timeline each requires. This structure gives the organisation a portfolio — not a queue — and allows different tiers to progress in parallel rather than sequentially.
Tier 1: Quick Wins (Score 70+, High Volume, Low Complexity)
Quick wins are the workflows that should be in production within 90 days. They score highly on volume, data readiness, and process stability. They have low exception rates and clear outcome metrics. They are often not the most strategically exciting workflows in the portfolio, but they are the ones that generate the early ROI evidence needed to maintain organisational momentum and secure funding for the harder work ahead.
Classic quick win categories include: automated document classification and routing, invoice data extraction and matching, HR policy question answering via a knowledge-base-grounded assistant, IT ticket triage and initial response, and report generation from structured data sources. These are not trivial — even simple-seeming automation can generate hundreds of hours of recovered capacity per month at scale — but they are well within the capability boundaries of current AI systems when the underlying data and process conditions are met.
The strategic purpose of quick wins is often undervalued. They are not just cost-saving exercises. They are the organisation’s evidence base for what AI delivery actually looks like in practice — which teams and processes absorb change well, which governance controls work, and what the realistic time-to-value looks like for more complex workflows that follow.
Tier 2: Core Builds (Score 50–70, Moderate Complexity, Strong Strategic Value)
Core builds are the workflows that represent the main body of an organisation’s AI program. They typically involve more integration work, more data preparation, or more complex decision logic than quick wins — but they deliver proportionally larger returns when they land. Timeline to production for core builds is typically three to six months, and they require more significant change management investment alongside the technical work.
Examples in this tier include: customer service case handling (where AI handles the information retrieval and draft response, with human review before sending), financial forecasting assistance, supply chain exception management, contract review and clause extraction, and sales pipeline analysis. These workflows benefit from the copilot-first approach: AI assists human decision-makers rather than replacing them, which reduces deployment risk and builds organisational trust in the system before moving toward full automation of stable steps.
Tier 3: Strategic Bets (Score 40–55, High Complexity, High Potential Upside)
Strategic bets are the workflows where the potential value is significant but the path to production is uncertain. They may involve unstructured data at scale, complex multi-step reasoning, integration with multiple legacy systems, or regulatory constraints that require careful governance design. These workflows belong in the portfolio, but they require a longer runway, stronger executive sponsorship, and more robust evaluation checkpoints before meaningful investment.
The most important thing about strategic bets is not to treat them like quick wins on a longer timeline. They need a fundamentally different development approach: more discovery iterations, more early stakeholder involvement, more attention to failure modes, and explicit decision gates that allow the organisation to pivot or pause without sunk-cost pressure. Many strategic bets that fail do so because they were resourced and governed like core builds.
Running Discovery Workshops That Surface Real Pain — Not Curated Stories
Workshops remain a valuable discovery source, but only when they are designed to elicit evidence rather than opinions. Most AI discovery workshops fail not because the participants lack knowledge — they know exactly where the friction is — but because the workshop format inadvertently signals that polished, strategic-sounding ideas are what is wanted. Front-line workers self-censor the “boring” problems because they assume leadership is looking for transformation, not operational efficiency.
The fix is in the framing and the facilitation approach.
The “Day in the Life” Framing
Rather than opening with “What AI opportunities do you see?” (a question that invites projection and speculation), effective discovery workshops open with “Walk me through your actual day from the moment you sit down.” This framing directs participants toward concrete, observable experience rather than abstract ideas. The facilitator’s job is to ask drilling questions at every mention of a task: How often? How long? What happens when it goes wrong? What data does it need?
The difference in output quality is significant. A typical ideation workshop produces a list of broad themes: “automate customer communications,” “use AI for forecasting.” A day-in-the-life workshop produces specific, measurable candidate workflows: “I manually pull a report from System A, reformat it in Excel, and paste it into System B every morning — it takes 45 minutes and if I get it wrong the inventory numbers are off all day.” That is a discovery-ready workflow candidate. The ideation output is not.
Participant Selection for Authentic Signal
Workshops should include doers, not just owners. The people who run processes every day — analysts, coordinators, specialists — have information that managers and directors do not. A three-tier workshop structure works well: a senior stakeholder session to establish strategic context and outcome priorities; a manager session to understand process ownership, current performance metrics, and known problem areas; and front-line worker sessions to observe actual task behaviour and capture the informal workarounds and friction points that never make it into formal process documentation.
The senior and manager sessions inform prioritisation. The front-line sessions inform the workflow inventory. Both are necessary, but they serve different discovery functions.
Three Facilitation Questions That Consistently Surface Hidden Workflows
Beyond the day-in-the-life framing, three specific questions reliably surface the high-value, low-visibility workflows that ideation misses:
- “What do you do on Monday morning that nobody knows about?” This surfaces recurring off-system tasks that have become invisible through habit — the spreadsheet reconciliation, the data cleanup, the manual lookup that happens before the formal process begins.
- “What would break if you went on holiday for two weeks?” This reveals the workflows with the highest single-point-of-failure risk — those that depend on individual expertise or informal knowledge that has never been documented. These are often both high-value and high-urgency AI candidates.
- “Where do you spend the most time fixing other people’s mistakes?” This surfaces the downstream cost of upstream errors — often the highest-cost, most measurable workflows in the inventory, where AI can improve both speed and accuracy.
What Process Mining and Task Mining Actually Tell You — And What They Miss
Process mining and task mining are the closest thing to an objective data layer in the discovery toolkit. But they have documented limitations that, if not understood, can lead to discovery errors as serious as the brainstorming problems they were supposed to solve.
What Process Mining Tells You
Process mining is authoritative on: end-to-end cycle time across real instances, not estimates; the actual frequency distribution of process variants; bottleneck locations defined by queue depth and waiting time; rework loops and their frequency; and which variants are most costly in time or downstream error rates. For high-volume, system-heavy workflows — order-to-cash, procure-to-pay, incident-to-resolution — process mining provides a level of workflow intelligence that no interview or workshop can match.
It is also increasingly able to provide ROI estimation. Modern process intelligence platforms can calculate the cost of bottlenecks in FTE-hours, model the impact of automating specific process steps, and generate before-and-after projections that can anchor the business case conversation.
What Process Mining Misses
Process mining only sees what the system records. Any work that happens outside the system of record — which in many knowledge-work organisations is a substantial portion of total work — is invisible to process mining. Email threads, instant messages, phone calls, spreadsheet-based workarounds, and informal coordination between team members leave no event log trace. A process that looks clean and efficient in the mining output may actually depend on a large volume of undocumented coordination work to function.
This is why process mining and task mining should be run concurrently when resources allow. Task mining captures the desktop-level work that bridges system interactions — and the gap between what process mining shows and what task mining shows is itself a valuable discovery signal. A large gap means the workflow has significant off-system activity that the process log is not capturing, which changes both the automation design and the ROI calculation.
The Conformance Gap as a Discovery Signal
One of the most underused outputs from process mining is the conformance analysis: the comparison between how the process is supposed to run (the documented model) and how it actually runs (the event log data). Conformance gaps are not just compliance problems — they are discovery signals. Every major deviation from the documented process represents either a workaround (someone found a faster path) or an exception (something the documented process cannot handle). Both are important for AI discovery.
High-conformance workflows are generally better automation candidates because the process is stable and understood. High-deviation workflows may need process redesign before AI can be effectively applied — but the deviation data itself tells you exactly which parts of the workflow are broken and at what frequency.
The Human Signal Layer: Shadowing, Interviews, and Artifact Analysis
Data tools surface patterns. Human observation surfaces meaning. The workflow inventory built from process and task mining tells you what is happening and how often. The human signal layer tells you why it happens that way, what the hidden costs are, and what would actually change if you fixed it.
Conducting Effective Shadowing Sessions
Shadowing is not observation from a distance. It requires a dedicated analyst sitting with the worker — physically or virtually — for a minimum of two to four hours of actual work, not a demo or walkthrough. The analyst’s job is to watch, note, and remain quiet. The worker should be asked to narrate their actions as they work (“now I’m checking this field because…”), not to explain or justify the process.
The output is a raw task log: a timestamped record of every action taken, every system touched, every decision made, and every moment of hesitation or correction. This raw log is then coded for automation signals: high-frequency repetitive tasks, decision points with clear rules, data retrieval and entry patterns, and copy-paste or reformatting operations that indicate manual data bridging between systems.
Shadowing is most valuable for knowledge-worker roles where the process is largely cognitive and interpersonal — customer success managers, financial analysts, HR business partners — because these are the roles where task mining provides the least context. Seeing what a financial analyst actually does when preparing a monthly variance report reveals far more about the automation opportunity than reviewing their calendar or event logs.
Structured Interviews vs. Artifact Analysis
Structured interviews for discovery should follow a standardised question set focused on observable facts, not opinions. The most useful interview questions are those that force quantification: “How long does that step take on a normal day?” “How often in a month does that exception happen?” “Can you show me the last three examples of that output?” The follow-up question “Can you show me?” is one of the most productive in discovery work — it moves conversation away from generalisation and into specific, examinable evidence.
Artifact analysis — reviewing the actual documents, spreadsheets, templates, and outputs produced by a workflow — is a complementary method that is rarely mentioned in AI discovery literature but consistently yields valuable findings. Spreadsheets are particularly informative: a spreadsheet that is being used to bridge two enterprise systems, or to manually track data that should exist in a database, is a near-certain signal of a high-value automation opportunity. The spreadsheet is the workaround. The AI opportunity is addressing whatever created the need for the workaround in the first place.
From Discovery to Business Case: Building the Evidence Package
The output of a systematic discovery process is not a list of ideas — it is a structured evidence package for each candidate workflow that makes the business case self-evident. The evidence package is what transforms discovery into investment decisions. Without it, every AI proposal is asking stakeholders to take something on trust. With it, you are presenting data that the organisation already owns, organised in a way that makes the ROI case for the proposed workflow obvious and defensible.
The Five Components of a Discovery Evidence Package
Component 1: The Workflow Baseline. A documented, data-grounded description of how the workflow currently operates: volume, frequency, cycle time, error rate, and current cost. This is not a process diagram — it is a set of quantified operating parameters derived from the discovery methods above. The baseline is the “before” state against which any improvement will be measured.
Component 2: The Pain Evidence. Specific, attributed examples of how the current workflow generates cost, error, or customer impact. This includes quotes from shadowing sessions and interviews, specific examples of failure instances from operational data, and process mining visualisations showing bottlenecks or rework loops. Pain evidence connects the quantitative baseline to qualitative human experience — which is what moves stakeholders from intellectual understanding to motivated action.
Component 3: The Automation Fit Assessment. The six-criteria score, with evidence for each dimension. Data readiness confirmed by data architecture review, not assumed. Complexity assessed from the actual task log, not the documented process. This is the section where most business cases are weakest — asserting fit rather than demonstrating it. The discovery process exists to make this section evidence-based rather than aspirational.
Component 4: The Financial Model. A conservative ROI estimate based on the actual baseline numbers, not benchmarks from vendor case studies. The financial model should include: current cost of the workflow (FTE time at fully-loaded cost rate, plus downstream error costs where quantifiable), projected reduction in workflow cost post-automation (with an assumed capture rate that accounts for exceptions, edge cases, and adoption lag), implementation cost estimate (build, test, deploy, and maintain), and payback period.
Conservative estimates are more credible than optimistic ones. A business case that promises 80% automation of a workflow when the exception data suggests 35–40% is achievable in the first year will damage credibility when production results come in. A case that promises 40% and delivers 55% builds the programme’s reputation for accuracy.
Component 5: The Governance and Risk Register. What could go wrong? What oversight is required? Who is accountable if the AI system makes an error? Which regulatory requirements apply? This component is increasingly required by enterprise AI governance frameworks in 2026, and it is better addressed at discovery than after deployment. The discovery phase surfaces the sensitivity of the data involved, the regulatory context of the workflow, and the business impact of errors — all of which inform the governance design before any build begins.
Common Traps in Workflow Discovery (And How to Avoid Them)
Even teams that adopt structured discovery methods encounter a set of recurring traps that can corrupt the output just as reliably as no method at all. Awareness of these traps — and their specific remedies — is part of what separates organisations that consistently discover high-ROI AI opportunities from those that discover interesting ones.
Trap 1: Automating a Broken Process
Perhaps the most expensive trap in AI automation is automating a workflow that should have been fixed or eliminated before automation was considered. AI applied to a dysfunctional process does not fix the dysfunction — it accelerates and scales it. The classic example is a customer service workflow with a high error rate: automating the customer contact step without fixing the upstream error that generates the contact in the first place simply means the errors are handled faster, not resolved.
The remedy is a mandatory process quality gate in the discovery scoring model. Before any workflow proceeds to the automation design phase, it should pass a basic process health check: Is the process operating within acceptable error and exception thresholds? Is it documented at a level that could support automation design? If the answer to either question is no, the workflow’s first intervention is redesign, not AI.
Trap 2: Underestimating Change Management as a Discovery Input
Change management is treated as a deployment concern in most AI programs. In reality, its input is needed at discovery stage. A workflow that is technically excellent as an AI candidate but owned by a function with a history of resisting automation, or dependent on a team that lacks the digital fluency to work alongside an AI system, will fail for adoption reasons that the scoring model never captured.
The discovery process should include an explicit assessment of change readiness: Is the workflow owner engaged and motivated? Is there a track record of successful technology adoption in this function? Does the front-line team have concerns that need to be understood and addressed before a proof of concept begins? Workflows that score poorly on this dimension may still be pursued, but they require proportionally greater investment in adoption planning from the outset.
Trap 3: Conflating Automation Potential With AI Potential
Not every workflow that can be automated should be automated with AI. Many high-volume, rule-based workflows are better suited to traditional RPA or workflow automation tools than to AI systems. Applying a large language model to a task that a deterministic rule engine could handle with higher reliability and lower cost is a common mistake driven by AI enthusiasm rather than engineering judgement.
The discovery scoring model should explicitly distinguish between automation potential (is this workflow a good candidate for any automation?) and AI potential (does this workflow require capabilities — natural language understanding, pattern recognition, generative output, judgment under uncertainty — that only AI systems provide?). Routing clearly rule-based workflows to the appropriate non-AI automation tool is not a failure of the AI discovery process. It is the discovery process working correctly.
Trap 4: Discovery as a One-Time Event
Workflow discovery done once provides a snapshot of the organisation’s AI opportunity landscape at a point in time. It does not capture the new workflows that emerge as business models evolve, the previously poor candidates that have become viable as data matures, or the quick-win automations that have now been deployed and have freed up team capacity for more complex work.
Organisations that treat discovery as a continuous capability — running light discovery cycles every quarter and deep discovery annually — build a compounding AI portfolio rather than a one-off project list. The inventory from Year 1 becomes the baseline against which Year 2 opportunities are assessed. Workflows that were not viable at initial discovery become viable as data readiness improves. The programme learns what good candidates look like in that specific organisation, which makes each subsequent discovery cycle faster and more accurate.
Trap 5: Ignoring the Denominator in ROI Calculations
ROI calculations in workflow discovery consistently overstate the numerator (the benefit) and understate the denominator (the total cost). Implementation cost estimates routinely exclude: ongoing model maintenance and monitoring, data pipeline maintenance as source systems change, retraining or prompt engineering as the workflow evolves, governance and oversight staffing, and the productivity cost of change management and adoption support.
The standard remedy is to use a two-year fully-loaded cost model rather than a build-cost-only estimate. Over two years, maintenance and governance costs typically add 40–60% to the initial build cost for AI workflows — and this delta is the difference between a business case that survives post-deployment scrutiny and one that quietly disappears from the programme report when actuals come in below projection.
What Systematic Discovery Actually Changes in Practice
The argument for systematic workflow discovery is ultimately empirical: organisations that invest in evidence-based discovery before committing to AI builds consistently outperform those that do not. The performance gap shows up at every stage of the programme.
At the selection stage, systematic discovery produces a candidate list where the top-quartile workflows have demonstrably better deployment outcomes. Workflows with documented high volume, confirmed data readiness, and a clear baseline metric enter development with a fundamentally lower risk profile than those selected through brainstorming or stakeholder advocacy.
At the pilot stage, the evidence package replaces the need for extended internal selling. A well-documented workflow with a quantified baseline, a conservative ROI model, and a completed risk assessment moves through governance review faster because every question that would have been raised in the review has already been answered in the documentation.
At the scale stage, the discipline of tracking actual outcomes against the discovery-stage baseline creates an institutional learning loop that most AI programmes lack. When a quick win delivers the projected ROI, the programme has validated its scoring model. When it does not, the discovery evidence identifies precisely which assumption was wrong — data quality was lower than assessed, exception rate was higher than expected, adoption was slower than modelled — which improves the accuracy of every subsequent discovery cycle.
The compounding effect of this learning loop is what separates organisations that are building genuine AI capability from those that are building a portfolio of pilots. Discovery, done systematically, is not just the first step in the AI use case lifecycle. It is the mechanism by which the entire lifecycle gets progressively better.
A Practical Starting Point: The First Two Weeks of Discovery
For organisations that have not yet formalised their discovery process, the following two-week starting point provides a working foundation without requiring significant resource investment or tool procurement.
Week 1: Intelligence Gathering. Pull operational data from the three highest-cost or highest-volume functions in the business. This means ticket reports, SLA breach data, headcount-per-process estimates, and any existing process documentation. Identify the five workflows in each function that account for the largest share of team time. Run two to three shadowing sessions per function — even a single two-hour observation yields significant signal. Extract any available event log data from key enterprise systems and run a basic process mining analysis if tooling permits, or use the raw data to build a manual frequency and variant map.
Week 2: Workshop and Inventory. Run one day-in-the-life workshop per function with a mixed group of front-line workers and their immediate managers. Use the three facilitation questions above to surface off-system workflows and high-friction tasks. Compile all findings into a structured workflow inventory using the eight-field template above. Apply the six-criteria scoring model to each candidate. Segment the resulting scored list into the three tiers.
The output of two weeks of structured discovery is typically a shortlist of four to six high-confidence AI candidates with documented evidence packages — enough to populate a credible initial programme roadmap and make a compelling business case for the first quick win deployment.
Conclusion: Discovery Is the Work
There is a tendency in AI programmes to treat discovery as preliminary work — the administrative step before the real work of building begins. This framing has it backwards. Discovery is the work. The quality of everything that follows in an AI programme — the design, the build, the deployment, the adoption, the ROI — is a function of the quality of what was discovered and how rigorously it was documented.
The systematic method described here is not complex. It does not require expensive tooling, large teams, or months of lead time. It requires the discipline to gather evidence before forming conclusions, to document facts before applying judgement, and to build a business case from data the organisation already has rather than from aspirations about what AI might one day deliver.
The workflows that generate the best AI ROI in 2026 are not hidden behind difficult technology problems. They are hidden behind the assumption that ideation is the same as discovery. Close that gap, and the path from blank page to business case becomes considerably shorter than most organisations expect.
Key Takeaways
- Start from evidence, not ideas. Use the four discovery sources — process mining, task mining, ethnographic observation, and operational data — to build an inventory of what is actually happening before scoring anything.
- Document before you evaluate. Populate a structured workflow inventory using the eight standard fields. Separation of documentation from evaluation produces more honest, more defensible candidate lists.
- Score on the six criteria. Volume, data readiness, process stability, measurability of outcome, complexity, and strategic alignment are the dimensions that determine AI workflow fitness. Weight them, score every candidate, and sort by tier.
- Build a three-tier portfolio. Quick wins, core builds, and strategic bets require different investment levels, timelines, and governance approaches. Treat them as a portfolio, not a queue.
- Run workshops to surface real pain. Day-in-the-life framing and the three diagnostic questions consistently surface the high-value, low-visibility workflows that ideation sessions miss.
- Use the evidence package to accelerate governance. A well-documented workflow with a quantified baseline and conservative ROI model moves through internal approval faster because every question has already been answered.
- Make discovery continuous. Organisations that treat discovery as an ongoing capability build compounding AI portfolios. Those that treat it as a one-time event build a project list that ages out of relevance.
