Most corporate AI workshops fail in a specific and predictable way. The room is engaged, the feedback forms are glowing, and six weeks later nothing has changed. I have run sessions for Coca-Cola, HP, Lenovo, Apple, EPAM, IIFL Capital and the Department of Economy and Tourism in Dubai, and the pattern is consistent enough to plan around.
The fix is structural. A day that is mostly demonstration produces admiration. A day that is mostly construction produces habits. Here is the agenda I use, and the reasoning behind each block.
The short version of the agenda
| Time | Block | What happens | Why it is there |
|---|---|---|---|
| 9:30 to 11:00 | Shared foundation | One mental model, live demos, safety rules | Everyone starts from the same place |
| 11:15 to 13:00 | Role specific labs | Split by function, hands-on prompting | Generic examples lose the room |
| 14:00 to 16:00 | Build block | Each person ships one working workflow | This is what survives the week |
| 16:00 to 17:00 | Policy, demos and next steps | Show and tell, rules, 30 day plan | Turns a day into a programme |
Six hours of contact time. Nobody presents for more than 20 minutes at a stretch.
Block one: the shared foundation (90 minutes)
The goal here is not to teach people what a large language model is. Almost nobody needs that, and it is the fastest way to lose the half of the room that is already using ChatGPT daily.
The goal is to give everyone the same working mental model, which I frame as three ideas:
- The model is a very capable intern with no memory and no context. Everything useful follows from that. Good prompting is just good delegation: context, examples, constraints, format.
- Your leverage is the context you bring, not the model you pick. The person who uploads the actual brand guidelines, the actual last three campaign briefs, and the actual customer transcripts gets output nobody else can get from the same tool.
- Verification is part of the workflow, not an afterthought. Every workflow you build needs a step where a human checks the thing that would be expensive to get wrong.
Then I do live demos, unscripted, using whatever the room throws at me. This matters more than it sounds. A pre-recorded demo signals that the result is fragile. Taking a request from the floor and building it in front of 300 people signals that this is repeatable, and that is the belief you need before anyone will try it themselves.
The last 15 minutes of this block is safety rules, and it needs to happen before anyone touches a tool, not at the end of the day when half the room has left. Cover three things: what data never goes into a public tool, which accounts are approved, and what has to be human reviewed before it goes out.
Block two: role specific labs (105 minutes)
This is where most agendas quietly go wrong. Finance, HR, sales and engineering have almost nothing in common in terms of useful AI workflows, and every minute spent on a generic marketing example is a minute the finance team spends checking email.
Split the room. A workable set of tracks for a mixed corporate audience:
- Sales and customer facing: call transcript analysis, proposal drafting from a discovery call, objection prep, account research before a meeting.
- Marketing and content: brand-voice-grounded drafting, campaign variant generation, repurposing long form into channel formats, creative review against a brief.
- HR and internal comms: job description drafting, structured interview scoring rubrics, policy document Q and A, onboarding material generation.
- Finance and operations: variance commentary, reconciliation checks, structured extraction from PDFs and invoices, board pack summarisation.
- Engineering and technical: spec drafting, code review assistance, test generation, internal tool prototyping.
Each track works through the same four steps so the day still feels coherent: take a real task, write a first prompt, look at what is wrong with the output, then add the missing context and constraints until it is usable. People learn more from watching a bad output become a good one than from being handed a prompt template.
On tools, I keep it deliberately narrow. Depending on the client this is usually some combination of ChatGPT, Claude, Gemini and NotebookLM for the thinking and writing work, then Gamma for decks, and n8n, Lovable or Replit when the room is ready to build something that runs without them. Eight tools introduced properly beat thirty tools name-checked.
Block three: the build block (120 minutes)
If you cut anything from the day, do not cut this.
Every person leaves having built one thing that works on their own real data and that they will use again within a week. Not a demo. Not a saved prompt. A workflow.
What that looks like in practice:
- A recruiter with a working screening rubric that takes a job description and a CV and returns a structured scorecard.
- A finance analyst with a NotebookLM notebook loaded with the last four quarterly reports that answers questions with page citations.
- An ops lead with an n8n automation that watches a shared inbox, extracts the fields they care about, and writes a row into a sheet.
- A marketer with a Gamma deck generated from a real brief, then corrected to brand.
The facilitator's job in this block is floor work, not presenting. This is why headcount per facilitator matters. Above roughly 60 people in a hands-on session you need extra floor support, or the room silently splits into those keeping up and those who have stopped.
Block four: policy, demos and the 30 day plan (60 minutes)
Three things close the day.
Demos from the floor. Six to eight people show what they built, two minutes each. This does more for adoption than any slide, because the credibility comes from a colleague rather than from the person who was flown in.
The policy conversation. Now that everyone has actually used the tools, this lands differently. Agree on the approved tool list, the data rules, the review requirements, and who to ask when something is unclear. Write it down before people leave the room.
The 30 day plan. Name the workflows that will be maintained, who owns each one, and when the group reconvenes. A date in the calendar before people leave is the difference between a training and a programme.
What to measure
Feedback scores tell you whether people enjoyed the day. They do not tell you whether it worked. Three measures that do:
- Workflows still in use at day 30. Count them directly. Ask each attendee for the one thing they built and check back in a month.
- Time returned on a named task. Pick two or three tasks per function, measure them before the session, measure them again at day 30.
- Second order spread. How many people who did not attend are now using a workflow that someone who did attend built. This is the real signal that something took root.
The most common mistakes
- Starting with theory. Tokens, parameters and model architecture are interesting and almost entirely useless for a room that needs to draft a board pack on Thursday.
- Demoing instead of building. Admiration is not adoption.
- Mixing all functions through the whole day. A shared foundation is useful. A shared afternoon is not.
- Skipping the policy conversation. Teams that have no rules do not become cautious, they become quiet about what they are already doing.
- No follow up date. Without one, week two is when it all goes back to normal.
If you are planning a session for your own team and want to pressure test the agenda against what your people actually do, that is what the scoping call is for.