Key takeaways
- Train on tasks, not on the technology. Nobody changes how they work because of a slide about a category.
- Three tasks per role beats twenty capabilities across the organisation.
- People must use their own real work during the session, not a demo scenario.
- Adoption fades for four specific reasons, and each has a different fix.
The standard AI training session covers what large language models are, what they are good at, a demonstration of some impressive general capabilities, and a reminder to be careful with confidential information. Attendance is high, feedback is positive, and usage three weeks later is roughly what it was before. This is not because the training was bad. It is because it answered a question nobody had.
The question people actually have is narrower and more practical: what, specifically, should I do differently tomorrow, on the work that is already on my desk?
Task cards, not capability tours
The single highest-leverage change is to organise everything around a small number of named tasks per role. Not "use AI for writing" but a concrete card with four parts.
- The task, in the words the team already uses for it. "The Thursday client update", not "stakeholder communications".
- The starting material, named specifically. Which file, which inbox, which system export.
- The prompt, written out and ready to copy, tested on real examples beforehand.
- The check, two or three specific things to verify before the output goes anywhere.
Three of these per role is enough to start. They should be the three most tedious repeating tasks that team has, which you find by asking them rather than by guessing. People adopt tools that remove work they resent, and they ignore tools that improve work they already enjoy.
A quick way to find the right tasks: ask each team what part of their week they would happily never do again. The overlap between that list and what AI genuinely handles well is where your adoption comes from.
A 45 minute session that works
Run it per team, not per organisation. Keep the technology explanation to almost nothing.
| Time | Segment | What happens |
|---|---|---|
| 0 to 5 min | The rules | Which tool is approved, what may go into it, what must not. Traffic lights, not a lecture. Then move on. |
| 5 to 15 min | Task one, demonstrated | Walk through the first task card live, using a genuine recent example from this team's work. |
| 15 to 30 min | Task one, done by them | Everyone does it on their own current work, right now, with help available. This is the part that cannot be skipped. |
| 30 to 40 min | Tasks two and three | Faster, because the pattern is established. Demonstrate, then let them try one. |
| 40 to 45 min | Where things live | Where the task cards are saved, who to ask, what to do when output looks wrong. |
The fifteen minute hands-on block is the whole session. Everything else is scaffolding. If time runs short, cut tasks two and three rather than shortening the practice.
Teach the check, not just the prompt
The most valuable skill you can transfer is not prompting. It is knowing what to verify. Staff who trust output uncritically will eventually send something wrong, and staff who trust nothing will keep doing everything manually. Both outcomes waste the investment.
Make the check concrete per task. For a summary: are the numbers the same as the source, and is anything important missing rather than merely wrong. For a client draft: is the tone right for this particular client, and does it commit to anything you have not agreed. For an extraction: spot-check three records against the original.
Framing this as ordinary professional review rather than a compliance step matters. People already check their own work. This is the same habit applied to a new drafting tool.
Why adoption fades, and what to do
Four weeks after training, usage typically drops. The cause is usually one of four things, and they need different responses.
They cannot think what to use it for
The most common. The training gave capability, not occasions. Fix it by adding task cards over time, one per month per team, rather than trying to cover everything at launch.
An early result was poor
Someone tried something ambitious in week one, got a mediocre answer, and concluded the tool does not work. Fix it by making the first tasks ones you have already tested and know produce good results. Early wins matter more than breadth.
They are not sure they are allowed
Especially in regulated or client-facing work, where the instinct when in doubt is to stop. Fix it with an explicit green list and a named person to ask. Ambiguity always resolves towards inaction.
The old way is still slightly easier
If reaching the tool means another login, or the file is somewhere awkward, habit wins. Fix it with single sign-on, browser bookmarks, and putting the task cards where the work already happens rather than in a separate training portal.
Measure the right thing. Licence count tells you nothing. Weekly active users per team tells you where adoption is real, and it will show you within a fortnight which teams need a second visit.
Champions, chosen properly
A named person per team who answers questions locally is worth more than any centrally produced material, because the barrier to asking is proximity.
Choose them carefully. The best champion is usually not the most technically enthusiastic person, who tends to answer questions in a register that makes people feel foolish. It is the respected, patient, moderately curious person that colleagues already ask when something is confusing. Give them ninety minutes of extra preparation and an explicit mandate.
What to give people afterwards
Keep it small. A guide nobody opens is the same as no guide.
- One page of rules, in traffic light form.
- The task cards for their role, on one or two pages, stored where they already keep working documents.
- A short note on which model to use for what, in plain language.
- The name of the person to ask, and where to suggest a new task card.
That is the whole documentation set for most organisations. The instinct to produce a comprehensive manual should be resisted, because comprehensiveness is what makes documents unopenable.
Frequently asked questions
How long should AI training be?
About 45 minutes per team, built around three tasks that team genuinely does, with people working on their own real material during the session.
Why do employees stop using AI after training?
Usually they cannot think what to use it for, an early attempt disappointed them, they are unsure whether they are allowed, or reaching the tool is marginally more effort than the old habit. Each has a different fix.
Should we train everyone at once?
No. Train by role. Specificity is what makes training stick, and the finance team's month end has nothing in common with the field team's job reports.
Do we need to teach prompt engineering?
Not as a discipline. Give people tested prompts for their actual tasks and teach them what to check. The general skill develops naturally from using working examples.
Get the guide written for your people
The Implementation Package includes an employee how-to guide and a rollout plan written with your team, so staff know exactly which tasks to use AI for and what to check before anything goes out. Fixed price, live in 30 days or less.