Use-Case Discovery Workshop
A structured working session that surfaces, tests and ranks candidate AI use cases by feasibility and business value, producing a shortlist you can act on.
A structured working session that surfaces, tests and ranks candidate AI use cases by feasibility and business value, producing a shortlist you can act on.
Most AI use-case lists fail for an unglamorous reason: nobody checked the data before falling in love with the idea. A session that ends with forty sticky notes grouped under headings like "Customer Experience" and "Efficiency," with everyone nodding, has produced energy, not a shortlist, and energy does not survive contact with a CFO asking which of those forty ideas actually has usable data behind it. The Use-Case Discovery Workshop exists to produce the shortlist instead.
This is not a brainstorming session, and it is not a technology demo dressed up as a strategy meeting. It is a working session, typically one to two days, built around a specific question: out of everything this organization could plausibly automate or augment with AI, which handful of candidates deserve real investment next, in what order, and why. The answer has to survive contact with a CFO, a compliance officer, and an engineering lead in the same room, which is precisely why it cannot be produced by enthusiasm alone.
Most organizations arrive at use-case discovery from one of two directions. Either they have already done the groundwork through our AI Readiness Check and strategy work under Beratung, and now need to translate a strategic mandate into a concrete list of candidate processes, or they have a mandate from leadership (often shaped by an Executive Alignment Workshop) to "find our AI use cases" without a defined method for doing so. Either way, this workshop is the hinge point between strategy and execution. It takes the abstract commitment to "become an AI-driven organization" and turns it into a ranked list of named processes, each with an owner, a rough effort estimate, and a stated rationale for why it belongs on the list.
What comes out of this room feeds directly into pilot selection. We are building out a dedicated Pilot Projects practice for exactly that next step, scoping and running the actual proof-of-concept work on the highest-ranked candidates. The discovery workshop is what makes that later work efficient: instead of a pilot team spending its first two weeks figuring out what to build, they start with a use case that has already been validated on feasibility, sized on value, and cleared by the people who would have to approve or fund it.
It also connects sideways to the other workshop formats. Where the Executive Alignment Workshop builds shared understanding and mandate at the leadership level, and the Team Enablement Workshop builds hands-on capability inside the teams that will use AI tools day to day, the Use-Case Discovery Workshop sits between them, translating mandate into a concrete backlog. Once a use case is selected and scoped, the is often the next stop for the specific candidates that involve building an AI agent or automation flow, where the actual prompt architecture, guardrails, and evaluation criteria get designed. Discovery answers "what and why." Prompt design answers "how, exactly." Confusing the two is a common way organizations waste both.
The single biggest determinant of whether this workshop produces something usable is the guest list, and getting it right requires resisting two opposite temptations: inviting only senior strategists who understand the business but not the actual mechanics of the work, or inviting only the AI/IT team, who understand the mechanics but not where the real friction and cost sit in the business.
The working group that tends to produce good results is deliberately mixed:
Eight to twelve participants is a workable range. Below that, you risk missing a critical process area or blind spot. Above that, the room stops being a working session and turns into a presentation, which defeats the purpose.
The workshop's quality is set in large part before day one. A discovery session that starts from a blank whiteboard wastes its most expensive resource, the collective attention of senior people, reconstructing information that could have been gathered in advance.
Preparation typically includes short structured interviews (20 to 30 minutes each) with process owners across the candidate functions, run in the two to three weeks before the workshop. The goal of these interviews is not to pre-select use cases but to build a rough inventory: what are the ten to twenty processes in this function that involve repetitive judgment, document handling, information retrieval, or pattern recognition at any real volume? Which of those already have someone quietly frustrated with how manual or error-prone they are? Where is data already digitized versus locked in paper, PDFs, or someone's personal spreadsheet?
Alongside the interviews, we typically request (and review) a small set of artifacts: existing process documentation if it exists, a sense of current tooling and system landscape, and any prior AI or automation attempts, successful or not, since those carry real information about organizational appetite and past failure modes. If the organization has already completed a readiness assessment through the , that output is folded directly into the prep material, since it already contains a structured view of data maturity, tooling, and organizational readiness that would otherwise have to be reconstructed from scratch in the room.
This preparation converts the workshop from a discovery exercise about which processes exist into an evaluation exercise about which of a known set of candidates deserve investment. That shift, from "what could we even do" to "of these fifteen documented candidates, which three make sense first," is what separates a productive session from a creative one.
A two-day format is the default for organizations with more than one function in scope; a single, tightly scoped function can sometimes compress into one focused day. The shape below assumes two days, with the understanding that timing gets adjusted to the size and complexity of the organization.
Day one, morning: grounding and inventory review. The session opens not with brainstorming but with a shared framing: what strategic direction has already been set (drawing on prior strategy work and the Executive Alignment Workshop output, if one took place), what the readiness assessment revealed about organizational constraints, and what the pre-workshop interviews surfaced as candidate processes. This is presented back to the room, corrected where participants' knowledge differs from what interviews captured, and expanded where gaps appear. The output of the morning is an agreed, de-duplicated long list, usually somewhere between fifteen and thirty candidate use cases.
Day one, afternoon: structured deep dives. Rather than discussing all candidates in the same shallow way, the group works through each one using a consistent template: what triggers this process, what inputs and outputs are involved, roughly how often it happens and how long it takes, what could go wrong if it were automated badly, and who would need to sign off on a change. This is deliberately unglamorous work. It is also the part that most reliably kills bad ideas before they consume real budget, because a use case that cannot be described concretely at this level of detail is usually not ready for investment regardless of how appealing it sounded in the abstract.
Day two, morning: scoring and prioritization. This is where feasibility and value get evaluated explicitly and separately, using a shared framework the group builds or adopts at the start of the session (more on the framework below). Each use case gets scored, not by a popularity vote, but against defined criteria, with disagreements surfaced and discussed rather than averaged away. The point of this block is to make the reasoning behind each score visible and defensible, since that reasoning is what someone outside the room, a sponsor, a steering committee, a board, will eventually ask about.
Day two, afternoon: shortlisting and next steps. The group narrows the long list to a shortlist, typically three to six use cases, sequenced by a combination of value, feasibility, and dependency (some low-effort, low-value use cases might still be sequenced first as a way to build organizational muscle and trust before attempting something harder). Each shortlisted use case gets a one-page summary: description, owner, rough effort and timeline estimate, expected value, key risks, and open questions that would need to be resolved before a pilot could start. The session closes with clear ownership of what happens next, who takes the shortlist to whom for sign-off, and how it connects into pilot scoping.
A handful of concrete techniques do most of the work in keeping this session grounded rather than aspirational.
Separating value scoring from feasibility scoring. The single most common distortion in use-case sessions is letting enthusiasm about business value contaminate the assessment of feasibility, or vice versa. A use case might promise enormous value and still be nearly impossible to build with current data and systems; another might be modest in impact but genuinely easy to ship in three weeks. Scoring these on two independent axes, then plotting candidates on a simple feasibility-versus-value grid, makes trade-offs visible instead of implicit. It also creates an honest category for "quick wins": modest value, high feasibility items that build momentum and organizational trust while bigger initiatives are being scoped.
Silent, written scoring before group discussion. When scores are called out loud one at a time, the first strong opinion in the room anchors everyone after it. Having participants write down their own scores first, independently, before any group discussion, surfaces genuine disagreement instead of manufactured consensus. Disagreements are then discussed explicitly, which is often where the most useful information in the whole workshop surfaces (a process owner and a compliance representative scoring the same use case very differently is a signal worth pursuing, not a nuisance to average away).
Explicit "kill criteria." Before scoring starts, the group agrees on a small number of disqualifying conditions, such as a hard regulatory blocker, complete absence of usable data, or a dependency on a system change that is already known to be a year out. Any candidate that trips a kill criterion gets removed from consideration immediately rather than scored and then quietly deprioritized, which keeps the group's energy on candidates that are genuinely still live.
Grounding every discussion in a real instance, not an abstraction. Rather than discussing "invoice processing" in the abstract, the group discusses last Tuesday's actual invoice batch: how many, how they arrived, what went wrong, how long it took, who touched it. Concrete instances resist wishful thinking in a way abstractions do not.
A visible parking lot. Ideas that are interesting but out of scope for this round (wrong function, too large, dependent on infrastructure not yet in place) get written down and kept, not discarded. This does two things: it respects the person who raised the idea, and it builds a running inventory for the next round of discovery, since organizational priorities and technical feasibility both shift over time.
Several patterns show up repeatedly in organizations that attempt use-case discovery without a structured format, and the workshop design is a direct response to each of them.
The first is technology-first framing, where the starting question is "what can this AI tool do" rather than "what problem, in this organization, is worth solving." Sessions that start from the tool almost always end with a shortlist of use cases chosen because they are impressive demos rather than because they matter to the business. The workshop structure deliberately starts from process inventory and business friction, not from a tool's feature list.
The second is enthusiasm bias, where the loudest advocate for a use case in the room, often someone with genuine passion for the topic, ends up determining the outcome regardless of whether their use case is actually the strongest candidate. The scoring structure and silent-write step exist specifically to counter this.
The third is boiling the ocean, where the group tries to scope an enterprise-wide transformation program instead of a shortlist the organization can actually staff and fund in the next quarter or two. Constraining the shortlist to three to six items, and being explicit that a parking lot exists for everything else, keeps ambition proportional to near-term execution capacity.
The fourth is shadow enthusiasm without governance, where a use case gets informally green-lit in the room but never actually gets sign-off from the people who control budget or risk exposure, and the whole exercise quietly evaporates a month later. Having the right authority in the room, and closing the session with explicit next steps and owners, is the direct countermeasure.
The fifth, more subtle failure is conflating discovery with design. Groups sometimes drift into debating exactly how a use case would be built, which model, which vendor, which prompt structure, before establishing that the use case is worth building at all. That level of detail belongs in the pilot scoping stage and in more technical formats like the Agent Prompt Design Workshop, not in a session meant to compare fifteen candidates against each other.
A successful discovery workshop does not end with excitement. It ends with clarity, and often with some quiet disappointment that a favorite idea did not make the cut, which is itself a sign the process worked honestly. The concrete deliverables are a ranked shortlist of three to six use cases, each documented on a single page with owner, effort estimate, expected value, key risks, and dependencies; a scored long list showing why everything else was deprioritized or parked, so the reasoning survives beyond the room; and a clear next step, typically a defined path into pilot scoping for the top one or two candidates.
Just as important as the documents is what participants carry out of the room: a shared, defensible answer to "why these and not those," which matters enormously the first time someone outside the room asks. Use-case lists that emerge from unstructured brainstorming rarely survive that question. Ones built through this kind of structured evaluation usually do, because the evaluation criteria and the reasoning behind each score were made explicit at every step.
From here, the shortlist becomes the input to pilot project scoping, where the highest-ranked candidates get built out as actual proof of concepts. If the chosen use cases involve building AI agents, automations, or anything requiring careful prompt and guardrail design, the is typically the next structured session. If broader organizational capability needs to be built alongside the pilots, particularly among the teams who will use the resulting tools day to day, the picks up that thread. And the shortlist itself, along with the reasoning behind it, becomes a working artifact inside the broader strategy engagement under , feeding governance discussions, ROI modeling, and roadmap planning well beyond the two days the workshop itself takes.
If your organization has a long list of AI ideas and no reliable way to tell which ones deserve real investment, this is the format built to answer exactly that question. Browse the full set of formats on the , or get in touch through to talk through scope, participants, and timing for your organization.