Most AI programs stall not because the models are weak, but because the work is defined too vaguely to fund and execute. Early conversations often sound like “apply AI to customer service” or “use GenAI to boost productivity.” Those are themes. Themes can inspire, but you cannot build a theme. You cannot assign a single owner, define requirements, test results, or run governance on a theme.
An AI use case is the unit that turns ambition into delivery. It is specific enough to be designed, implemented, adopted, and measured, yet meaningful enough to move a KPI that leadership cares about. This chapter gives you a shared definition of a use case, a practical way to choose the right technical approach, a disciplined way to classify benefits, and a maturity ladder you can use to set realistic targets for autonomy. If you align on these definitions early, discovery sessions become dramatically more productive; people stop pitching slogans and start proposing buildable, comparable candidates.
2.1 Use case anatomy: decision, workflow, user, and measurable outcome
A strong AI use case is a small, explicit change to how a decision is made or how work gets done. That focus matters because value is created and captured in workflows, not in model demos. When a team says “we need an AI strategy,” what they usually need is a prioritized set of workflow improvements with clear ownership and measurable outcomes.
A practical definition is: AI use case: a specific decision or workflow step, performed by a defined user (or system role), where an AI capability changes inputs, recommendations, or actions in a way that produces a measurable outcome. The definition forces four elements. If you cannot articulate any one of them, you do not yet have a use case; you have a hypothesis that needs refinement.
Decision: the moment of choice you want to improve. A decision should be stated in plain language and, when possible, expressed as a binary choice or a ranked selection. “Reduce fraud” is not a decision. “Approve, decline, or step-up authenticate this transaction” is. The more specific the decision, the easier it becomes to define what data is needed, what counts as a good outcome, and how the result will be acted on.
Workflow: the surrounding steps and handoffs that make the decision real. Workflow context determines whether the AI output will ever be used. A churn risk score, for example, is only valuable if it triggers concrete actions: outreach, offers, service interventions, and follow-up accountability. A good use case describes where the AI sits in the flow (before, during, or after a task), what triggers it (event, schedule, user action), what systems it appears in (screen, queue, alert), and what happens when the AI is unavailable or uncertain (fallback behavior).
User: the person or system role that will act on the AI output. Users should be specific, not generic. “Finance” is not a user. “Accounts payable analysts who process invoices over $25,000 and handle exceptions” is a user. The user definition matters because adoption is rarely a technical problem. It is an incentive and friction problem. A good use case captures what the user is measured on, what time constraints they face, what exceptions they handle, and what would make them ignore the tool (for example, slow responses, too many clicks, unclear confidence, or fear of being second-guessed).
Measurable outcome: the KPI the organization is trying to move, with a baseline and an agreed measurement method. Outcomes should be expressed in operational terms first (cycle time, error rate, conversion, loss rate), then translated into dollars as needed. If the only metric you can name is “accuracy,” you have not connected the use case to business value. A good outcome definition also includes guardrails so teams do not optimize the wrong thing (for example, reducing handle time while harming satisfaction or increasing compliance exceptions).
To enforce this anatomy in workshops, require a single “use case sentence” before anyone discusses solution details. The sentence becomes a forcing function: it makes ambiguity visible immediately.
Use case sentence: For [user], improve [decision/workflow step] by using [AI capability] at [moment in workflow], so that [KPI] improves from [baseline] to [target] within [timeframe], while meeting [constraints].
Example: For live chat agents, improve customer issue resolution by using retrieval + response drafting in the first minute of a chat, so that average handling time improves from 6.2 to 5.7 minutes within 12 weeks, while meeting CSAT and compliance guardrails. Treat the numbers as placeholders; the structure is the point.
- Completeness check: Can you name the decision or workflow step in one sentence?
- User check: Can you describe the specific role and where they work (channel, segment, tier)?
- Trigger check: Do you know when the AI is invoked and what the user sees?
- Action check: Do you know what changes when the AI output is accepted or rejected?
- Metric check: Do you have a baseline, a target, and guardrails?
- Dependency check: Do you know the key data sources, owners, and approval gates?
Two additional practices will raise use case quality quickly. First, define boundaries explicitly. State what is in scope (the decision, the workflow segment, the user group) and what is out of scope (upstream data remediation, downstream process redesign) for this iteration. Second, write the “first operational release” as a concrete scenario: what the user sees, what they do with it, and what systems are updated. If you cannot describe the first release without relying on future enhancements, the use case is not yet specific enough to fund.
It also helps to distinguish use cases from adjacent concepts that often get mixed together. Use case vs feature: a feature is a reusable capability (transcription, retrieval, entity extraction) that can support many use cases; features belong in a foundations roadmap unless tied to a specific workflow and KPI. Use case vs product: a product bundles multiple use cases and enablers into an end-to-end experience (for example, an “agent desktop” that combines search, summarization, coaching, routing, and knowledge updates). Use case vs model: a model is a technical asset; a use case is a business change that may use one or many models and must include adoption, controls, and measurement.
Measurement deserves special attention because it determines credibility. A strong use case defines three layers of metrics. Primary KPI: the outcome leadership cares about (for example, net retention, chargeback losses, on-time delivery). Mechanism metric: the operational lever the AI changes (review time per case, quote turnaround time, first-contact resolution). Guardrail metrics: indicators that prevent gaming (customer satisfaction, error rate, compliance exceptions, escalations).
Then define how “better” will be judged relative to today. Baseline: current performance using historical data, ideally segmented to match the use case scope. Counterfactual: what performance would have been without the intervention. In discovery, you do not need a perfect experimental design, but you should decide whether you will use A/B tests, phased rollouts, matched cohorts, or before/after comparisons with seasonality adjustments. Without this agreement, teams spend months debating success instead of learning how to improve.
When you apply this anatomy consistently, weak ideas self-eliminate. They cannot name a decision, they cannot identify a real user, or they cannot define an outcome that can be measured. That is exactly what you want. A smaller backlog of well-formed candidates will consistently outperform a larger backlog of slogans every time.
2.2 ML vs GenAI vs automation: choosing the right tool for the job
Once the use case is defined, the next decision is the technical approach. Many organizations default to whatever is most visible in the market—today, that is often large language models—without asking whether the job requires generation, prediction, or execution. A better rule is to choose the simplest approach that meets requirements for correctness, speed, cost, explainability, and governance, then add complexity only where it creates measurable value.
Most enterprise solutions draw from three families. Automation: workflows, rules engines, and robotic process automation that execute known steps consistently. Machine learning: models that predict, classify, rank, or detect patterns from data. Generative AI: models that interpret and produce unstructured content—especially language—and support natural interaction. These families solve different problems, and the best designs often combine them: GenAI for language-heavy inputs and outputs, ML for scoring and ranking, and automation to enforce business rules, permissions, and audit trails.
A quick shortcut is to map the job to the tool family.
- Prefer automation: when requirements are explicit, the process is stable, and correctness matters more than flexibility.
- Prefer ML: when you need a score, probability, ranking, or anomaly signal from structured data.
- Prefer GenAI: when the work is dominated by reading, writing, summarizing, searching, or conversing over unstructured content.
- Prefer hybrid: when you need GenAI for understanding or drafting, ML for ranking or prediction, and automation to enforce rules, permissions, and audit trails.
A practical selection sequence can be captured in four questions. Question 1: Is the task deterministic? If the correct output can be fully specified, the environment is stable, and the cost of an error is high, automation should be the backbone. Examples include eligibility checks, validation rules, or routing based on explicit thresholds. Question 2: Is the task predictive or statistical? If you need a probability (churn risk), a score (fraud risk), or a ranking (next-best action), ML is often appropriate. Question 3: Is the task language-intensive? If the work involves reading, writing, summarizing, searching, or interacting with users in natural language, GenAI can add value. Question 4: Does the solution need to execute actions in enterprise systems? If yes, include an automation layer that controls permissions, logging, and fallbacks, even when GenAI is part of the interface.
To make this concrete, consider three common patterns. In sales, “lead prioritization” is usually ML (ranking) plus automation (assigned to reps by territory and capacity), with GenAI optionally drafting a first outreach message that a rep edits. In legal, “contract review” is often GenAI for extraction and summarization, ML for clause classification, and automation for workflow routing and approvals. In operations, “quality inspection” may use computer vision (ML) for defect detection, automation for line-stoppage rules and work orders, and GenAI to explain exceptions or generate a shift handoff summary.
GenAI deserves a specific caution. It is excellent at turning unstructured inputs into usable outputs, but unconstrained generation is a poor default when outputs must be exact and consistent (pricing tables, regulatory notices, journal entries). In those cases, use GenAI for interpretation and drafting, then force outputs into constrained formats and validated steps. Common guardrail patterns include Retrieval-augmented generation: ground responses in approved internal sources; Structured outputs: require the model to produce a form or JSON that downstream logic validates; and Tool calling: let the model request actions while an orchestration layer approves, executes, and logs them.
Machine learning has different traps. Teams often propose ML because it sounds rigorous, then discover the problem is mostly process clarity and data readiness. ML is appropriate when you have enough signal, a measurable target, and an operating capability to monitor and refresh models over time. If labeling is unreliable, if key features are missing or stale, or if deployment and monitoring are immature, consider whether a simpler approach—rules plus better instrumentation—can deliver value faster. Many organizations get more immediate benefit from making decisions measurable and consistent than from adding a sophisticated model on top of an unstable process.
Cost and latency belong in the selection conversation early. A GenAI assistant that takes several seconds to respond will be ignored in high-throughput workflows. A model that is cheap per call can still become expensive at scale across millions of interactions. During discovery, you do not need precision, but you should estimate order-of-magnitude operating cost: expected volumes, average response size, model class, and monitoring overhead. Include these estimates in the use case card so prioritization reflects net value, not just gross benefit.
Finally, tool choice is not purely technical; it is also a governance decision. If the use case touches regulated decisions, creates IP exposure, or carries high safety risk, the “right tool” is the one you can control, document, and audit. In some contexts, a constrained assistive tool with human review is the safest first step. In others, a highly automated system is appropriate because the process is stable and the error cost is low. Close the loop by stating Minimum viable approach: the simplest combination of automation, ML, and GenAI that can achieve the measurable outcome while meeting constraints on accuracy, speed, cost, and risk.
2.3 Benefit types: revenue, cost, risk, and experience
Benefit types are the language of prioritization. They let you compare very different use cases on a common basis, they prevent double counting across a portfolio, and they clarify who must own realizations. A use case with no identified benefit owner is not a use case; it is a science project.
Revenue: benefits that increase top-line or margin through higher conversion, higher average order value, improved pricing, faster sales cycles, or stronger retention. Revenue benefits are easy to overstate because they depend on customer behavior and market conditions. To keep them credible, tie them to an explicit mechanism (lead quality, win rate, discount rate, churn prevention) and state the operational change that drives the mechanism (faster follow-up, better targeting, better pricing guidance).
Cost: benefits that reduce operating expense through productivity, reduced rework, fewer errors, lower external spend, or automation of manual steps. Cost benefits often have better baselines, but they can be hard to realize if “time saved” is not captured. In discovery, require a capture path: capacity reduction, throughput increase without new headcount, or redeployment to higher-value work with a plan and accountable owner.
Risk: benefits that reduce losses, compliance exposure, fraud, safety incidents, or operational outages. Risk benefits can be large and strategically important, but proof can be slow because adverse events are rare. Pair lagging indicators (losses, incidents) with leading indicators (detection rate, control coverage, near misses, suspicious activity backlog). Agree up front with risk stakeholders what evidence is sufficient to proceed from MVP to pilot to scale.
Experience: benefits that improve customer, employee, or partner experience through speed, quality, personalization, and reduced friction. Experience benefits become investable when you connect them to operational metrics (wait time, first-contact resolution, time-to-quote) and to business outcomes (retention, repeat purchase, employee attrition). Treat experience as a real value driver, but avoid vague claims like “improve satisfaction” without a mechanism and measurement plan.
Most use cases produce a bundle of benefits. To keep sizing honest, identify Primary benefit: the driver used for the business case, and Secondary benefits: upside tracked in measurement. This reduces wishful stacking and forces coherent assumptions. For each benefit, include Owner: who is accountable for realizing the benefit in operations, and Measurement method: how it will be measured, how often, and relative to what counterfactual. If either is missing, treat the benefit as speculative until it is tied to a real operating plan.
2.4 Maturity levels: assist → augment → automate → autonomize
Not every use case should aim for full automation, and many should not. The right target is the right level of autonomy for the current risk posture, workflow stability, and operating maturity. Think in stages, start by assisting humans, then augmenting decisions, then automating well-defined steps, and only then moving toward autonomy where systems can act with limited oversight.
Assist: the system helps a human do the same job faster or with less cognitive load. Examples include summarizing cases, drafting communications, retrieving policy, extracting key fields, or highlighting missing information. Assist use cases often deliver early wins because they reduce friction without changing decision rights.
Augment: the system provides recommendations, rankings, or scores that influence human decisions. Examples include next-best action, claims triage, fraud scoring, or quality coaching. Augmentation creates more value than assist because it changes choices, but it requires clear guidance on how users should interpret the recommendation and what to do when confidence is low. It also requires attention to bias and fairness when decisions affect people.
Automate: the system executes a decision or workflow step under defined rules, with humans handling exceptions. Examples include auto-routing, approving low-risk transactions, or sending templated responses when criteria are met. Automation demands strong controls: thresholds, logging, auditability, fallbacks, and exception management so issues are caught and corrected quickly.
Autonomize: the system can plan and execute multi-step actions across tools, adapting to context, and escalating when constraints or risks are detected. Examples include resolving a bounded class of customer issues end-to-end or executing supply chain adjustments within approved limits. Autonomy can unlock step-change value, but it requires mature guardrails around permissions, policy constraints, monitoring, and incident response.
Choose a maturity target with three questions. Cost of error: what happens if the system is wrong, and who bears the consequence? Workflow stability: is the process consistent enough that automation will not be brittle? Observability: can you monitor outcomes and detect drift or failure modes quickly? Then plan the ladder explicitly. Define what must be proven to move upward: trust and adoption from assist to augment, control effectiveness and exception handling from augment to automate, and robust policy constraints and tool safety from automate to autonomize. This way, leadership funds a sequence of learning and capability-building steps rather than a single leap of faith.
