The short answer
A useful AI workshop is scoped before it starts: you gather the team's real workflows in advance, spend most of the day building against them, and send everyone away with artefacts they will use on Monday. Keep the group small enough for live help, pick one or two use cases per person, and schedule a follow-up checkpoint before the day ends.
Key takeaways
- Run intake before the day — collect real tasks, tools and blockers per attendee.
- Aim for 60–70% of the day building, not presenting.
- One or two concrete use cases per person beats a survey of ten tools.
- Finish with saved prompts, templates and a one-page guardrail sheet.
- Book the four-week follow-up while everyone is still in the room.
A bad AI workshop looks like a good day. Everyone is engaged, the demos land, people leave saying it was interesting. Three weeks later nothing has changed, because "interesting" was the only outcome anyone designed for.
A workshop earns its day when people leave with rebuilt workflows they will use immediately, and a manager who knows what to check on in a fortnight. Here's how to structure one — whether you run it internally or bring someone in.
Decide the outcome before the agenda
Write one sentence: "After this day, [these people] will do [this work] differently, and we will know because [this measure] changed." If you cannot finish that sentence, you are booking entertainment.
Common valid outcomes:
- A function's three most time-consuming recurring tasks rebuilt with AI in the loop.
- A team confident enough to use AI on client-adjacent work within agreed guardrails.
- One internal process documented and semi-automated, with an owner.
- Leaders able to judge which AI proposals in front of them are worth funding.
Notice none of them are "understand AI".
Scope the agenda to the business, not the tool
Two weeks out, collect from each attendee: their role, the workflow that eats their week, and one example artefact — a real brief, a real report, a real quote. That intake is what turns a generic curriculum into a session about their business.
This is why we scope agendas per client rather than running a fixed list of topics. A finance team and a marketing team need the same underlying skills taught through completely different work.
Pre-work that takes ten minutes and saves ninety
- Accounts created and logged in on the device they'll bring.
- One workflow named per attendee, in a sentence.
- One real document or example uploaded or brought along.
- IT sign-off on what data may be used in the session.
- Manager attending, or at minimum briefed on the guardrails segment.
A sample one-day agenda
This is a shape, not a script. The proportions matter more than the timings: less than half the day on input, more than half on building.
| Time | Segment | Output |
|---|---|---|
| 9:00 | Where AI actually helps — and where it doesn't | Shared language, honest limits |
| 9:45 | Working with a model: instructions, context, iteration | Each person gets one usable prompt for their own task |
| 10:45 | Live build 1 — the group's highest-volume workflow | A rebuilt workflow, saved and reusable |
| 12:15 | Lunch | — |
| 13:00 | Judging output: what's good enough to send | A review standard the team agrees on |
| 13:45 | Live build 2 — each attendee's own workflow | Individual artefacts, one per person |
| 15:15 | Guardrails: data, review, and what never touches AI | A written one-page policy |
| 16:00 | Commitments and the two-week checkpoint | Named actions, owners, and a diary date |
The five segments people skip — and shouldn't
- Honest limits. Teach where AI is unreliable early. It buys you credibility and prevents the confident-but-wrong outputs that kill trust later.
- Judging output. The scarce skill is not generating, it is deciding whether the result is good enough. Practise it on real work with a real standard.
- Guardrails written in the room. Agreed live, with the manager present, so it is a decision rather than a memo nobody reads.
- Individual build time. Every attendee leaves with something of their own, not a copy of the facilitator's example.
- The checkpoint in the diary. Booked before the room empties, or it never happens.
Facilitating well
Run it as a build session, not a lecture. Walk the room during build segments. Fix the person who is stuck instead of finishing the slide. When someone's output is bad, diagnose it publicly and calmly — that is the most valuable ten minutes of the day.
Keep one running list visible: things this team should try next. It becomes the input to the follow-up cycle.
The two weeks that decide whether it worked
Habits form after the room, not in it. Three things carry the day forward: the rebuilt workflows in use on real work, a manager asking about them in normal one-to-ones, and a checkpoint where people show what they changed.
If your workshop has no follow-through mechanism at all, shorten the session and spend the saved budget on the follow-up instead.
Running it in-house vs bringing someone in
| Consideration | Internal facilitator | External facilitator |
|---|---|---|
| Context on your workflows | Strong from day one | Needs intake and pre-work |
| Breadth of what's possible | Limited to what they've tried | Broader, cross-industry patterns |
| Authority to set guardrails | Depends on their seniority | Neutral, easier to land hard limits |
| Cost | Internal time, often underestimated | Per-seat or per-cohort fee |
| Repeatability | High once the material exists | Requires handover to build internally |
A common sensible path: bring someone in for the first cohort, have your future internal owner co-facilitate, then run the rest yourself.
See one in practice
Our upcoming workshops run on this structure — scoped agendas, live builds, and artefacts attendees keep. The Claude Cowork Activation and Claude Masterclass pages show how the day is put together if you want a concrete reference before designing your own.
Frequently asked questions
How long should an AI workshop be?
One full day works well for a team of eight to twenty when the agenda is scoped in advance. Half a day is enough for a single function with one or two workflows. Multi-day only makes sense when people are building something they keep.
How many people should be in the room?
Eight to twenty. Below eight you lose the cross-pollination between roles; above twenty the live-build segments stop working because the facilitator cannot see screens.
Should we mix seniority levels?
Mix roles within a function, and include the manager who owns the workflows. Avoid mixing executives who want strategy with practitioners who want their Tuesday back — those are two different sessions.
What pre-work is actually necessary?
Two things: accounts and access confirmed working, and each attendee naming one task they want to stop doing manually. Skip either and you spend the first ninety minutes on logistics.
Do attendees need their own AI subscriptions?
For a live-build session, yes — an account they can use during and after the day. Watching someone else build is not the same skill as building.
What should attendees leave with?
Working artefacts they will use next week: their own prompts, their own project setup, a rebuilt version of a real workflow, and a written guardrail on what AI may and may not touch.
What to do next
Write the outcome sentence for your team, then collect the three workflows that would prove it. Everything else about the day — length, tools, agenda — falls out of those two things. For the wider program around the workshop, see AI training for business.