“We should use AI in customer support” is a direction, not an experiment. “Can an approved assistant draft a response from these permitted help articles, with the support agent checking every answer?” is a testable question. That level of specificity makes a use-case workshop worth holding.
Start from the workflow
Ask the process owner to describe the current task, who performs it, what good work looks like and where the friction appears. Sometimes the right intervention is a clearer process, better search or ordinary automation. Include those alternatives before assuming AI is required.
Record what is known and what is estimated. If the team has no baseline, collecting one may be the first experiment. A time-saving hypothesis should include review and rework rather than comparing generation time with the whole manual task.
Copy this use-case worksheet
The example below uses a fictional internal document workflow. It illustrates the level of detail to seek, not an achieved result.
| Field | Question | Fictional example |
|---|---|---|
| Workflow and owner | What task changes, and who is responsible? | Operations manager owns drafting internal meeting summaries |
| Current baseline | How do you assess today’s process? | Collect a sample of manual summaries and preparation time |
| Permitted inputs | What may the tool receive? | Synthetic meeting notes for the first test |
| Expected output | What should the tool produce? | A draft with decisions, actions and unresolved questions |
| Reviewer | Who decides whether the output is acceptable? | Meeting owner checks accuracy and missing actions |
| Evaluation | How will you compare the options? | Same review rubric for manual and assisted drafts; record total time |
| Dependencies | What is not ready? | Approved tool access and decision on handling actual meeting notes |
| Stop condition | What would prevent further use? | Unacceptable omissions, permission failure or review effort exceeding benefit |
| Next decision | Who decides what follows? | Sponsor reviews the test record before any wider pilot |
Keep sensitive examples out of the initial workshop pack. Agree what can be shared, retained and deleted before collecting actual materials.
Use an agenda that ends with decisions
This is a sample sequence. Adjust timing to the number of workflows and the people who need to decide.
| Sequence | Activity | Output |
|---|---|---|
| Preparation | Collect workflow descriptions and constraints | Comparable candidate cards |
| Shared context | Clarify objective, approved tools and boundaries | Agreed criteria and excluded tasks |
| Discovery | Describe problems before discussing solutions | Specific tasks and alternatives |
| Challenge | Check assumptions with process, technical and risk owners | Missing evidence and dependencies |
| Prioritisation | Compare candidates against the same criteria | Shortlist, deferred ideas and reasons |
| Experiment design | Define inputs, review and stop conditions | Bounded test plans |
| Closing | Assign owners and next decisions | Decision record and review dates |
If key decision-makers cannot attend, label the output a recommendation. Do not call it approved prioritisation.
Prioritise without hiding uncertainty
Use a discussion grid rather than a single persuasive score. A simple label — ready to test, needs evidence, or out of scope — can be more useful than a weighted total that nobody can defend.
Treat missing permission, unacceptable exposure or lack of an accountable owner as a gate, not a small score penalty. Mark disagreement explicitly and collect the evidence that could resolve it.
Separate three kinds of practical challenge
A business-team exercise can test a task with approved tools and synthetic inputs. A prototype sprint can explore an interaction or integration with technical support. A production project requires a separate design, security, testing and operational process. Calling all three a hackathon does not make their responsibilities interchangeable.
For non-technical teams, the output might be a reviewed workflow and evaluation record rather than code. For builders, mentor coverage and sandbox access should be part of the brief. Compare the formats before choosing a group activity.
Hand the shortlist to an owner
For each selected experiment, record the next task, the owner, permitted scope, missing approval and review date. For each deferred idea, record why it was deferred and what would change that decision. A smaller shortlist with real ownership is easier to act on than thirty unsupported ideas.
Use the thirty-day follow-up plan to organise the next review. If the main challenge is leadership agreement, review the AI strategy workshop.
Methodology
About this worksheet
Original AISB editorial planning template, published on 4 October 2026. The fictional example and criteria illustrate a scoping discussion. They are not a validated scoring model, client result or assurance of business value.
Turn your questions into a scoped workshop
Share the workflows, decision-makers and next decision. Keep confidential materials out of the initial enquiry.
Frequently asked questions
What should participants bring to an AI use-case workshop?
A description of a real workflow, its owner, current effort or error pattern, approved tools and data constraints. Use redacted examples or synthetic material until sharing permissions have been agreed.
How should we prioritise AI use cases?
Assess business relevance, evidence, feasibility, permitted data and risk separately. Do not let a high impact score override a missing owner or an unacceptable data dependency. Give each selected experiment a test and review date.
Does a workshop prove an AI use case is valuable?
No. It can produce a shared shortlist and test plan. Value and feasibility require evidence from the experiment and its context, including human review and total effort.
Published by
- AI Summit BarcelonaEditorial team
Related reading
Enterprise AI Adoption: From Awareness to Useful Experiments
A decision guide for companies moving beyond AI awareness. Diagnose the barrier, choose the appropriate format and define the evidence needed before expanding an experiment.
AI Executive Readiness Checklist
A practical checklist for leaders commissioning a briefing or workshop. Identify what is clear, what needs evidence and who owns the decision; this is not a maturity score or certification.
After the AI Workshop or Hackathon: A 30-Day Plan
A practical follow-up template for turning a decision record or demonstrator into an owned experiment. Separate event satisfaction, learning and operational evidence.