Most AI training sessions open with prompt technique. Within twenty minutes half the room has decided this is a tool for people who like tools, and the other half is writing down phrases they will never use again.
The order is wrong. Prompting is the easiest part to learn and the least useful thing to learn first. What stops a team from adopting any of this is not technique — it's that nobody has told them where the line is, and nobody has shown them the thing working on a job they actually recognise.
Here's the sequence that holds a room, and why each block comes where it does.
Block one: where information goes
Fifteen to twenty minutes, and it goes first.
Every room contains someone who has been quietly avoiding these tools because they weren't sure whether it was allowed, and someone who has been using them on things they shouldn't. Both of those people need the same information, and until they have it, everything else you teach is either unusable or unsafe.
What this block covers: which tool and which account, what happens to text you paste in, what never goes in, and what stays with a qualified person no matter what. Concrete, with your own documents as the examples. Not a category list.
The reason it works first is that it converts the whole topic from a vague risk into a bounded one. People act inside a boundary. They freeze inside a fog.
If the principal or owner is not in the room for this block, the team leaves without permission and nothing changes on Monday.
Block two: one real job, start to finish
Thirty to forty minutes. Not a demo — a job from that business, chosen before the session, that at least half the room does regularly.
The monthly report. The tender response. The standard letter explaining a process to a client. The quote follow-up. The induction pack nobody has updated since 2023.
Two things have to be true for this to land. It has to be a job the room does, and it has to go all the way to something usable — not a promising first draft that someone would then rewrite anyway. The gap between "this produces text" and "this produces something I would send" is where most self-taught AI use gets stuck, and watching that gap get closed once is worth more than any amount of prompt advice.
Choosing the job for block two
- Done at least weekly by several people in the room
- Mostly writing or restructuring, not judgement
- No client information required to demonstrate it
- Currently done after hours, ideally
- Has a recognisable finished state, so "done" is obvious
Block three: the tool decision
Fifteen minutes, and it's shorter than people expect.
Teams don't need a feature comparison. They need a rule of thumb they can apply without thinking: long documents and sustained voice go one way, fast high-volume turnaround goes the other, and a third category goes to neither. We set out the rule of thumb we teach separately, and it's built to survive the next model release rather than describe this month's.
The reason this block exists at all is that a team without a rule defaults to whichever tool one confident person prefers, and then the work quietly reshapes itself around that tool's weaknesses.
Block four: the setup they keep
Twenty minutes, and this is the block that decides whether anything survives the week.
A session that teaches method produces a good afternoon. A session that ends with two or three saved setups — a project with your documents in it, a saved instruction that produces your format, a reusable brief for the job from block two — produces a change that's still there in a month, because the effort of getting a good result has dropped to near zero for at least one job.
This is the part that's hardest to do in ninety minutes and the reason a half day exists. It's also why a done-with-you workflow build is a different engagement shape rather than a longer workshop: one job, built properly on real work, with the owner in the room.
If you know which job you'd put in block two, you've done most of the preparation for a session already. Tell us what it is.
Start an enquiryWhat to leave out
- Model names and version numbers. They change, the skill doesn't, and naming them dates the training badly.
- Automation and integrations. A team that can't reliably get a usable draft doesn't need a pipeline yet.
- Long prompt libraries. Handing out fifty prompts teaches copying, not judgement. A handful that match your actual jobs beats a document nobody opens — which is why our starting prompt library is short on purpose.
- Anything requiring a paid feature the business hasn't bought. Nothing kills momentum like teaching something the team can't do on Monday.
How to tell whether it worked
Not by a feedback form at the end of the session, which measures whether people enjoyed themselves.
Ask, three weeks later: which job is now being done differently, and by whom? One job, named, done by more than one person, is a successful session. Enthusiasm with no named job is a pleasant afternoon that changed nothing.
That's the standard we hold our own sessions to, and it's why the curriculum is built as six foundations rather than a tour of features — each one is a thing you can point at afterwards and say yes, that's different now.