Discovery and prioritization only work when they are grounded in reality. A rapid current-state baseline is the fastest way to replace intuition with evidence without turning discovery into a months-long diagnostic. You are not trying to document every variation of every workflow or build a perfect enterprise data catalog. You are trying to answer four practical questions well enough to make funding decisions: Where do decisions happen and where does work get stuck? What data exists, what data is usable, and what will it take to use it responsibly? What systems must the solution integrate with, and what constraints will shape design? What is the “today” economics baseline—volumes, cycle times, unit costs, and loss rates—so value sizing is credible?
5.1 Process decomposition: where decisions happen and work gets stuck
A process baseline starts with a simple premise: AI creates value at decision points and at friction points. Decision points are where someone chooses what to do next (approve, route, escalate, contact, investigate, discount, reorder). Friction points are where the workflow slows down (waiting, searching, rework, handoffs, exception handling). If you can identify the highest-leverage decisions and the most expensive friction, you can generate use cases that are both meaningful and measurable.
For discovery purposes, you do not need a detailed “as-is” map with every swimlane. What you need is a shared, truthful view of how work actually moves today. The fastest artifact is a thin-slice map: a one-page depiction of the workflow from trigger to completion, with decisions highlighted, systems named, and common exceptions called out. Build it in a working session with frontline experts and the process owner, and update it live on the screen. The goal is speed and shared understanding, not documentation polish.
Thin-slice map: a compact workflow map (typically 8–15 steps) that includes triggers, key decisions, handoffs, and failure patterns, plus the systems used at each step. A thin-slice map is “good” when a frontline user can read it and say, “Yes, that is basically how my day works,” even if edge cases are simplified.
Start by defining scope in operational language. Specify the channel, segment, or tier you are baselining (for example, email support for product line A; claims under $10,000; invoices over $25,000; renewals for mid-market accounts). Then define the trigger and end state. Trigger: the event that starts the workflow (ticket created, transaction posted, invoice received). End state: the point at which the work is considered complete (case closed, payment posted, claim adjudicated and documented). Clear boundaries prevent teams from mixing fundamentally different workflows and arguing past each other.
Next, decompose the workflow into steps that reflect how people do the work, not how a policy manual describes it. For each step, capture four fields. Actor: the role performing the step. Decision: the choice being made (or “none” if it is purely execution). Inputs: the information used to make the decision. Outputs: what gets created or updated. This structure turns a vague map into a generator for use case ideas: every decision becomes a candidate, and every missing input becomes a potential AI support opportunity (retrieval, summarization, extraction, or prediction).
Once steps are listed, locate where work gets stuck. Ask for the top time sinks and error drivers, then link each to a specific step. This keeps the baseline practical and makes it obvious where interventions should land.
- Common time sinks: searching across systems; waiting for approvals; collecting missing documents; resolving data mismatches; exception handling.
- Common error drivers: inconsistent categorization; incorrect routing; missed policy constraints; manual rekeying; unclear rules that drive variance.
To turn the process view into decision-grade use cases, pressure-test the most important decision points with three prompts that connect work to value. Information prompt: What information is needed at the moment of decision, and how reliably is it available? Variance prompt: Why do two capable people decide differently, and what drives that variance (experience, missing context, unclear rules, workload)? Consequence prompt: If the decision is wrong, where does the cost show up (rework, losses, customer dissatisfaction, compliance issues)? These prompts help you distinguish “nice to have automation” from improvements that move the outcome.
Also capture the flow mechanics that drive cycle time. Queue points: steps where work waits for review or approval. Rework loops: steps where items bounce back for missing information or corrections. Escalation triggers: conditions that force senior review. Queues and rework loops often drive more cost and delay than the core work itself, which makes them high-leverage targets for better triage, better routing, and better information capture at intake.
Finally, translate the thin-slice map into a small set of “use case slots”—defined moments where solutions can land. A slot might be intake triage, investigation support, drafting and communication, exception handling, or quality control before closure. Slots prevent the backlog from becoming a random list and make coverage gaps visible: you can see whether you have strong candidates where the value leakage actually lives.
Process decomposition is complete when you can point to the two or three decisions that drive most of the outcome variance, and the two or three friction points that drive most of the time and rework, with at least one measurable indicator attached to each. At that point, discovery stops being abstract and starts being anchored to the real mechanics of performance.
5.2 Data landscape triage: availability, quality, lineage, access
Data is the raw material of AI, but “data exists” is not the same as “data is usable.” In discovery, the purpose of data triage is to prevent two expensive mistakes: prioritizing use cases that are blocked by data realities, and underfunding the enabling data work required to scale. A rapid triage gives you a grounded view of what is feasible now, what is feasible with targeted investments, and what should be deferred.
Keep triage tightly tied to the workflow and to a specific candidate use case. Start from the draft use case card and list the minimum data fields required to produce an output the user can act on. Then identify where those fields live, who owns them, and what it would take to access them reliably. The goal is not breadth. The goal is decision-grade truth about the data required for the portfolio you intend to fund.
Data triage note: a short summary for a use case that lists required fields and sources, describes known quality and timeliness issues, identifies the data owner and access path, and names the minimal data work required for an MVP.
Classify required data into four buckets because each bucket tends to have different readiness patterns. Transactional data: records of the work (tickets, orders, claims, invoices). Reference data: stable definitions (customers, products, policies, price lists). Behavioral data: signals about actions and interactions (clickstream, call metadata, agent actions). Unstructured content: text, documents, audio, images, and email threads. This classification is practical: transactional and reference data often exist but need definition alignment, while behavioral and unstructured data often need instrumentation, extraction, and governance to become reliable.
Evaluate readiness across four dimensions and insist on evidence, even if light. Availability: does the data exist at the needed granularity and history depth? Quality: is it complete, consistent, and accurate enough for the workflow? Lineage: do you understand how it is produced and which system is the source of truth? Access: can you obtain it within policy constraints, with realistic timing for approvals?
Quality should be assessed from the perspective of operational reliability, not just training feasibility. Ask two questions that surface deployment risk quickly. Coverage question: For what share of items will the required inputs be present at the decision moment? Freshness question: How stale can the data be before the output becomes useless or misleading? Many AI ideas fail these tests: the “right” fields exist, but only for a subset of cases, or they arrive too late to influence the decision.
Lineage is about trust. When stakeholders argue about numbers, they are often arguing about definitions and transformations. During triage, identify the system of record for each critical field and capture known transformations or overrides. You do not need a formal lineage graph, but you do need enough clarity to avoid building on a field that is inconsistently defined across regions or teams.
Access is where many “high value” use cases fail late. Treat access as a gating dependency. Identify the data owner, the approval steps, and the lead time. Clarify whether the data can be used for training, inference, or both. For GenAI use cases, clarify whether content can be included in prompts, whether outputs can be stored, and what retention rules apply. If constraints are unclear, record them as open issues with owners and deadlines, and do not treat the use case as MVP-ready.
When you find gaps, convert them into explicit enablers. “Data quality is poor” is not a plan. A plan names the work: fields to standardize, identifiers to reconcile, logging to add, labels to create, documents to extract, access controls to automate, and quality checks to monitor. This is also where you identify reuse: if multiple use cases need the same governed knowledge base or standardized event logs, fund it once as a foundation.
- Common data enablers: consistent IDs and keys; event logging standards; embedding stores and governed knowledge bases; labeling workflows; data quality monitoring; access request automation with audit trails.
Data triage is complete when, for each top candidate, you can say one of three things: the use case is data-ready for MVP; it is feasible with a defined data-enabler investment; or it should be deferred because the data constraints are too large for the current cycle.
5.3 Tech landscape triage: systems, integration points, constraints
AI solutions create value only when they show up where work happens. A brilliant model delivered in a separate portal will be ignored in high-throughput operations. Tech landscape triage is a pragmatic review of systems-of-work, integration options, and constraints that determine how quickly a use case can be delivered and whether it will be adopted. The output should read like a path-to-production sketch: where the AI will live, how it will get context, how users will act on it, and what must be logged for audit and learning.
System-of-work: the application where the user makes decisions and completes tasks (CRM, claims platform, underwriting workbench, agent desktop, ERP queue). Name the system-of-work early for each use case and treat it as a design constraint. If the AI cannot integrate into the system-of-work, either redesign the use case or be honest that adoption will be limited.
For each shortlisted candidate, map three integration points. Input integration: how the AI receives context and data (API pull, event stream, batch export, document pipeline). Output integration: how the user sees and uses the result (embedded panel, inline suggestion, queue field, alert). Action integration: how downstream actions are executed and logged (write-back to record, workflow trigger, human approval before execution). This framing forces concrete thinking and reveals whether a “fast pilot” is actually feasible.
Then capture constraints that shape design. Identity and access constraints determine whether the AI can see what a user is permitted to see and whether actions are authorized. Latency constraints determine whether the use case can be real time or must be asynchronous. Auditability constraints determine how decisions and outputs must be logged for compliance and incident response. Platform constraints include API availability, UI extensibility, eventing maturity, and the ability to write back into the system-of-work reliably.
To keep triage reusable, standardize on a small set of delivery patterns. Embedded assistant: a panel inside the system-of-work that retrieves context and drafts or summarizes content. Queue triage service: a scoring or classification service that writes results back into routing queues. Document processing pipeline: extraction and validation that turns documents into structured fields. Decision support API: a service called by other applications to provide a score, recommendation, or structured output.
Tech triage must include operational reality. If a use case will run in production, it needs monitoring, evaluation, and incident response. For ML, that includes performance tracking and drift detection. For GenAI, that includes prompt and retrieval management, safety testing, and evaluation of output quality. If these capabilities are immature, include them as foundations and design early releases to minimize risk (for example, assistive tools with strong logging and human review).
Tech triage is complete when you can describe, for each top candidate, the system-of-work, the integration pattern, the major constraints, and the foundational components it depends on. That clarity is what allows you to sequence the portfolio intelligently instead of discovering integration roadblocks after funding decisions are made.
5.4 Economics baseline: volumes, unit costs, cycle times, loss rates
An economics baseline turns process observations into an investable business case. Without it, value sizing becomes optimistic storytelling and finance will (correctly) push back. The baseline does not need accounting perfection, but it must be coherent, sourced, and consistent across use cases. The objective is to establish “today” performance and the driver model that links a use case to measurable impact: how much work flows through the process, how long it takes, what it costs per unit, and where losses or leakage occur.
Begin with simple driver structures and expand only when needed. For productivity and cost-to-serve, a common structure is volume × handling time × cost rate, adjusted for adoption and ramp. For risk and leakage, a common structure is volume × loss rate × loss severity, adjusted for detection or prevention effectiveness. These structures keep comparisons consistent and make sensitivity analysis straightforward.
Volume: the number of units processed in a period (cases per week, invoices per month, transactions per day), tied to a source report and definition. Cycle time: elapsed time from trigger to completion and, if available, active handling time. Elapsed time captures queue and approval delay; handling time captures labor productivity. Unit cost: the cost per unit, typically derived from loaded labor rates and handling time (and, when relevant, external spend). Loss rate: the proportion of units that result in losses or leakage. Loss severity: the average cost per loss event.
Segmentation is where baselines become credible. AI value is rarely uniform across all work. Identify two or three segmentation dimensions that drive variance—channel, case type, customer tier, geography, product, risk tier—and size baselines for the segments that match your scope. Segmentation also gives you a practical rollout path: you can pilot where value is concentrated and measurement is clean, then expand.
Baselining is also where you separate potential value from realized value. A tool can save time, but the organization only captures value if time is converted into something meaningful. Require a capture path for each productivity benefit and name the owner who will make the operational choice.
Benefit capture path: the mechanism through which an operational improvement becomes realized value, such as capacity release (overtime reduction, contractor reduction), throughput growth (more volume handled with the same team), or quality improvement (fewer errors, fewer escalations, fewer write-offs).
To make baselining repeatable, use a standard worksheet across use cases. Keep it lightweight, but strict enough to force comparable assumptions and transparent evidence.
- Baseline worksheet fields: scope and segment; volume and source; elapsed and handling time (or proxy); exception and rework rate; current KPI and target; unit cost assumptions; loss rate and severity (if applicable); adoption and ramp assumptions; constraints that affect capture; confidence rating with evidence notes.
When data is missing, triangulate rather than guess. Use samples, time-stamp analysis, queue reports, and targeted shadowing to approximate handling time. Use finance loss reports combined with operational reason codes to connect losses to workflow steps. Use ranges to reflect uncertainty, and write down what would tighten the range during MVP or pilot. This keeps the roadmap honest: leadership funds staged learning, not wishful certainty.
Economics baselining is complete when you can tell a coherent value story backed by numbers: what today looks like, where leakage occurs, which driver you will change, how much it is worth under realistic adoption and ramp assumptions, and what guardrails must hold. Combined with process, data, and tech triage, this baseline is what turns use case discovery from idea collection into a fundable roadmap.
