Identify AI use cases: a 90-minute workshop

Identifying AI use cases starts with specific tasks

A business starts with work rather than software. An AI use case needs a recurring trigger, available source material and a result someone can check. “AI in sales” is too broad. “List unanswered customer questions from an approved conversation note” describes something a person can perform and review.

Invite three people: someone who does the work, someone familiar with the data and software, and the decision-maker. Bring paper or a shared spreadsheet and a few relevant examples. The Fraunhofer AI toolbox recommends narrowing the search and comparing ideas using consistent criteria. Our 90-minute agenda adapts this approach for a small business.

The output is three completed task sheets and one test brief. The timings are our suggested format, not a validated promise of success. Buying another subscription is not on the agenda.

Minutes 0 to 25: collect tasks within one area

The team limits the search to one working area. Choose service intake, purchasing or quote preparation. Spend the first ten minutes agreeing what currently causes trouble: slow processing, duplicate entries or repeated corrections. A new chat interface alone is not an outcome.

From minute 10 to 25, each person writes individual tasks on separate notes. Describe the trigger, input and finished output. Replace “automate email” with “read a new service request and draft its topic and missing details for the responsible person to confirm”. Include work that actually repeats.

Prepare two ordinary examples and one difficult case per task. Keep these in the existing approved workspace; no material needs to be sent to an AI service during the workshop. Combine duplicate suggestions. Flag complaints with potentially serious consequences separately instead of hiding them among routine requests.

Minutes 25 to 40: give the workload a number

The comparison separates initial work from additional rework. Record monthly cases, person-minutes per case and extra correction time. Person-minutes add the work of everyone involved; an hour of waiting is not an hour of work if the person can do something else.

Use this formula: monthly workload = cases × processing minutes + correction cases × extra correction minutes. Only add corrections if the initial processing time excludes them. Multiplying frequency by time and error rate would be misleading: a time-consuming task with no errors would receive a score of zero.

These completed rows are a fictional calculation, not measurements from a real company. Each row lists task; monthly cases; processing time; corrections; total workload:

• Classify service requests; 120; 4 minutes; 12 × 5 minutes; 540 minutes = 9 hours
• Summarise quote documents; 20; 18 minutes; 4 × 15 minutes; 420 minutes = 7 hours
• Record meeting actions; 8; 25 minutes; 2 × 10 minutes; 220 minutes = 3 hours 40 minutes
• Send fixed reminders; 80; 3 minutes; no additional correction; 240 minutes = 4 hours

Minutes 40 to 55: try simpler rules first

The biggest number does not automatically justify AI. The reminders in our example might need only an existing due-date field and a fixed template. Keep that task on the improvement list, but remove it from the AI shortlist. A better input form might also prevent missing information at its source.

Google recommends using an optimised non-ML solution as a baseline when defining a machine-learning problem. Our practical suggestion: label each task “template”, “rule”, “existing software feature” or “interpret variable text”. Consider a language model, an AI system that processes and generates text, for the last group.

A topic selector on a contact form might solve the service-intake problem. For incoming messages written in varying ways, a draft reviewed by a person remains a candidate. Our comparison of rule-based automation and AI explores that distinction. Complexity does not earn a solution extra points.

Minutes 55 to 70: check three candidates

The team checks data access, reviewability and consequences of mistakes. Take no more than the three largest remaining workloads. Where a prerequisite is missing, record the specific question and defer that task. A large potential saving cannot offset missing data approval or outputs nobody can verify.

The NIST AI risk framework includes describing the use context, considering consequences of errors and providing human oversight. We translate this into four workshop questions. An unanswered field does not authorise a test:

• Data: Are suitable examples available and approved for the intended tool? Responsible person: ___; unresolved issue: ___
• Output: Can someone check correctness and completeness against the original material? Review method: ___
• Consequences: Does a wrong result remain reviewable before payment, commitment, sending or another action? Safeguard: ___
• Ownership: Who fixes errors and maintains the process, and how much time is available? Name/role: ___; time: ___

Service intake wins only if the conditions hold

Our fictional business chooses internal classification of service requests. It has relevant examples, an owner and topic categories that can be checked. A draft triggers neither a message nor an order. Quote documents remain second choice while responsibility for spotting technical omissions is unclear; price commitments are outside this first test.

The current nine monthly hours are not nine hours saved. For planning only, assume three minutes per request including input, review and corrections, plus one additional monthly hour of maintenance: 120 × 3 + 60 = 420 minutes. Compared with 540 minutes, that leaves two hours. The test still needs to establish whether this is achievable.

Fraunhofer includes preparation, integration, training and ongoing effort in the economic assessment. The workshop itself takes three people 90 minutes each, or 4.5 person-hours. At an assumed internal value of €35 per hour, that is €157.50 of effort. Freed time is not an automatic cash saving.

Minutes 70 to 90: write the test brief

The brief turns the idea into a bounded task. Copy these rows into a worksheet and duplicate it for the other two candidates. This preserves the reasons behind the selection. Our example values are filled in; complete the blanks during the meeting:

• Task and trigger: classify each new service request internally; owner: ___
• Input and output: approved message → suggested topic and missing details; data approved by: ___
• Current workload: 540 monthly minutes in this example; actual figure and evidence: ___
• Simpler alternative: contact form with a topic selector; unresolved question: ___
• Test: 20 new cases, including incomplete, contradictory and unrelated messages; start date: ___; decision date: ___
• Quality: review every output, leave missing details unresolved and send nothing automatically; reviewer: ___
• Stop if data approval is missing, actions escape review or errors remain unresolved; next action: ___

The first test decides whether to proceed

The business evaluates one task against fixed criteria. Twenty cases are our suggested starting sample, not statistical evidence of reliability. Record all working time, corrections and discarded results. A request subsequently handled manually still counts towards the workload. Compare similarly difficult cases using the same quality requirements.

What if no task passes? Resolve a data question or improve the template and form first. Must all three candidates start? No, one is enough. When should the scope grow? Only after an explicit decision based on quality, complete effort and costs. Our four-week plan for small businesses covers that next stage.

Schedule 90 minutes today with the three roles described above and bring example cases for each task. Fill in the workload rows first. If you need help selecting a task and implementing it, bring the three task sheets to our free introductory consultation.