Personalized AI infrastructure
Run an AI Use Case Workshop With Your Team in One Afternoon
A practical agenda and prompt set for an AI use case workshop for teams: collect repetitive tasks, score them together, and leave with a ranked shortlist.

An AI use case workshop for teams works best as one structured afternoon. Each person brings real repetitive tasks, the group describes them in the same short format, scores them against shared criteria, and leaves with a ranked shortlist of two or three candidates. The result is not a strategy document. It is a short list where every item has an owner, a known risk and a next step.
Key takeaways
- Collect tasks, not ideas. Ask people what they did last week, not what AI could do in general.
- Use one card format for every task, so that unlike things can be compared fairly.
- Score on a few shared factors, then discuss the disagreements instead of averaging them away.
- Finish with two or three ranked candidates, each with an owner and a clear boundary on what an agent may not do.
- Treat the workshop as the start of defining one first role, not as a commitment to build everything on the list.
Why run a workshop instead of sending a survey?
A survey asks people to imagine. A workshop helps them remember. When people are asked what AI could do for them, they tend to name vague things such as writing better emails or summarizing documents. When they are asked to walk through last Tuesday, they name the real work: reconciling two exports, chasing a missing approval, retyping an order into a second system.
The group setting also does something a survey cannot. When one person describes a task, someone else says, I do that too, but differently. That overlap is valuable. Tasks that several people perform in slightly different ways are often the best candidates, because the variation shows where the written rules are missing and where the real process lives.
Finally, a workshop builds shared language. Operations, finance and customer teams leave with the same vocabulary for frequency, risk and approval. That makes every later conversation, with colleagues or with an outside partner, shorter and more precise.
What should you prepare before the afternoon?
Preparation decides most of the quality. Aim for six to twelve participants from two or three teams, plus a facilitator who does not own any of the tasks being discussed. People who do the work matter more than people who manage it, but include at least one manager who can make approval decisions in the room.
Use this checklist a few days before:
- Invite people who have performed the work recently, not only people with opinions about it.
- Ask each participant to bring a list of five tasks they repeat, from memory or from their sent folder and task tracker.
- Prepare blank paper cards, one per task, and a wall or large table where cards can be grouped.
- Name a scribe who photographs the wall and types up the cards afterwards.
- Agree on what information must never be pasted into outside tools. If you have no written rule yet, a lightweight governance start is enough to settle this before the session.
- Tell participants plainly that the goal is to find work worth improving, not to find jobs worth removing. People share more when they trust the purpose.
What does the afternoon agenda look like?
The plan below fits in about three and a half hours including a break. Keep the times visible and protect the silent writing, because it is the part that produces honest material.
- Minutes 0 to 15, frame: state the goal, the output (a ranked shortlist) and the rules (tasks, not tools; no task is too small).
- Minutes 15 to 60, collect: everyone writes one task per card in silence, using the prompts in the next section.
- Minutes 60 to 90, share and cluster: each person reads their cards aloud, and the group places similar tasks together on the wall.
- Minutes 90 to 105, break: let the clusters sit while people step away.
- Minutes 105 to 135, complete the cards: for every cluster, fill in the card format described below, combining the variations people described.
- Minutes 135 to 175, score: rate each cluster on the shared factors, individually first, then compare.
- Minutes 175 to 200, rank and decide: sort by score, discuss exceptions, and choose two or three candidates.
- Minutes 200 to 210, assign: name an owner and a next step for each candidate, and agree what happens to the rest of the list.
The facilitator has one main job: keep the conversation on what happens, step by step, rather than on what AI might do. If someone says the agent could handle customer issues, ask them to describe the last three issues they handled.

Which prompts surface the tasks worth improving?
Good prompts are specific and anchored in the recent past. Hand these out on a sheet and let people write for a fixed period.
- What did you do last week that you have done many times before?
- Which task do you start on a certain day or after a certain message arrives?
- Where do you copy information from one place into another?
- What do you check, compare or look up before you can make a decision?
- Which question do colleagues or customers ask you again and again?
- What do you postpone because it is tedious, and who waits on you when you do?
- Which task would you struggle to hand to a new colleague because the steps live only in your head?
- Where have mistakes happened in the past, and what was the cause?
Then give every task the same card. A consistent format is what makes ranking possible later:
- Task name, in a verb and an object (for example, match invoices to purchase orders).
- Trigger: what starts it, and how often it occurs.
- Inputs: which documents, systems or messages it needs.
- Steps: the actual sequence, including the exceptions people handle by instinct.
- Output: what exists when the task is done, and who receives it.
- Check: who looks at the result, and what they look for.
- Cost of a mistake: what happens if it goes wrong and nobody notices.
The last line is often where the discussion becomes most useful. A task that is frequent, rule-based and low in consequence behaves very differently from one that is rare, judgment-heavy and expensive to get wrong.
How do you turn the long list into a ranked shortlist?
Score each cluster on four factors, using a scale of 1 to 5. Do it individually on paper first, then reveal the scores together. Differences between people are the most informative part, because they usually expose a hidden step or a different understanding of the rules.
- Frequency: how often does the task occur, and across how many people?
- Effort: how much working time does one occurrence take, including interruptions?
- Clarity: can the steps and the definition of a good result be written down in a page?
- Safety: if the output is wrong, how easily is it caught and corrected? A high score means mistakes are cheap and visible.
Add frequency, effort, clarity and safety for a total, then use judgment on top. A decision guide helps with the exceptions:
- High frequency, high clarity, high safety: strong candidate for a first role.
- High frequency, low clarity: write down the rules first. The documentation work is useful even if no agent ever follows it.
- High effort, low safety: keep a person approving every output, and start with drafting or preparation only.
- Fixed rules and structured inputs with no judgment needed: ordinary automation may fit better than an agent. AI agents vs RPA explains where that line sits.
- Rare and expensive to get wrong: leave it with the team for now.
If you want a fuller scoring method after the session, How to Prioritize AI Use Cases covers it in more depth. The workshop version only needs to be good enough to separate the obvious first candidates from the rest.
What does a finished shortlist look like? An illustrative scenario
This scenario is illustrative, not a real case. A distribution company brings together people from operations, finance and customer support. After clustering, three groups stand out: matching supplier invoices against purchase orders, answering the same delivery status questions by email, and compiling a weekly summary of open orders for managers.
The invoice matching scores high on frequency and effort, but the group finds that exceptions are handled by one person from memory. That moves it to the write-the-rules-first category. The delivery status questions score well on clarity and safety, since answers come from one system and a wrong answer is caught quickly. The weekly summary scores highest overall because the output is internal, checked by the manager who receives it, and the steps are already consistent.
The shortlist becomes: first, the weekly summary, owned by the operations lead; second, delivery status replies as drafts for a human to approve, owned by the support lead; third, documentation of the invoice exceptions, owned by finance. Nothing is built yet. Each item has an owner, a risk note and a next step.
How does Be Human handle the step after the workshop?
Be Human takes the shortlist as the input to a first engagement. That engagement defines one useful role, the memory and tools it needs, the approval boundaries, and an observable success criterion. Work is done remotely, in English or Portuguese, and the agent keeps its own identity, channels and permissions under the company's control. Managed operations can then include monitoring, recurring evaluations, integration maintenance, permission review, incident response and controlled improvements, so the role does not depend on one person remembering to check it.
What should happen in the week after the workshop?
Momentum fades quickly, so schedule the follow-up before people leave the room. A simple sequence works:
- Within two working days, circulate the typed cards, scores and the shortlist to all participants, and invite corrections.
- Choose one candidate to define first. Resist the urge to start three at once.
- Write the role down as you would for a new hire: purpose, inputs, tools, limits, and who approves what. Write a Job Description for Your First AI Agent Role gives a structure for this.
- Decide how you will know it worked, for example time saved on a named task or fewer corrections at review, before any work begins.
- Tell the wider team what was chosen, what was not, and why. People who shared tasks should see what came of them.
Two outside references are worth keeping nearby while you do this. Anthropic's guidance on building effective agents recommends starting with the simplest solution that works and adding complexity only when it earns its place, which matches the instinct to pick one clear task. The NIST AI Risk Management Framework gives a neutral vocabulary for discussing risk and oversight, useful when a manager asks what could go wrong.
Frequently asked questions
How many people should attend an AI use case workshop? Six to twelve is a good range. Fewer than six gives too little overlap between tasks, and more than twelve makes the sharing stage slow and quiet people stop contributing. If you have more teams, run separate sessions and merge the cards afterwards.
Do participants need to understand AI before they come? No. They need to understand their own work, and the prompts are written around that. A short explanation of what an agent can and cannot do at the start of the session is enough, and you can leave deeper training until a role has been chosen.
What if people are worried the workshop is about replacing them? Say plainly at the start what the goal is: finding repetitive work that slows the team down, and deciding together what stays with people. Keep approval and judgment tasks visibly in human hands, and let participants own the shortlist rather than present it to management afterwards. Trust grows when people see their input shape the outcome.
Should we run the workshop ourselves or bring in outside help? A capable internal facilitator can run it, provided they do not own the tasks being scored. Outside help is useful when your team lacks time or when you want a partner to turn the shortlist into a defined role afterwards. Either way, keep the cards and scores in your own hands, since they describe how your company actually works.
Be Human editorial guidance. Examples are illustrative unless explicitly attributed. Sources provide background; implementation choices depend on your workflow.


