Run a short AI practice session for your team
Someone has suggested a two-day AI course for the team, and you can already picture it: a good trainer, a room watching somebody else's workflow, and nothing different on Monday.
What you'll make
a thirty-minute clinic, every fortnight for about six weeks, where one person does one real task from their week in front of the team, plus a shared page of seven-line entries that includes the failures.
What you'll need
the AI tool your organisation provides, with everyone signed in to their own work account; thirty minutes a fortnight; and one volunteer per session with a task they really have to do that week. No trainer, curriculum or slides. This doesn’t replace any training you’re required to run.
Example result.
Task: monthly supplier spend summary, from the ledger export
Who: Mira (accounts)
What we gave it: September ledger export (CSV) and last month's commentary
The request: "Summarise September spend by supplier, biggest changes first, in the same style as the attached commentary."
What we checked: every supplier name and the top five totals against the ledger. Corrected and rechecked
What it got wrong: merged "Hallam Packaging" and "Hallam Pack Ltd" into "Hallam Packaging Ltd", which isn't in the ledger
Would we do it again: yes, with every name matched back to the ledgerCourses teach a tool. People need to do their own job. A clinic flips that: the content is somebody’s real work, so at least one person in the room has a reason to remember it.
1. Check everyone can sign in before you book anything
Ask everyone to open the tool this week and reply with one word. Not “do you have access”: have them actually open it. Half an hour of password resets is a session gone, and it sets a tone of mild futility that takes two sessions to recover from.
Check that everyone is in the same kind of account: the one your organisation provides, not a personal one. Never share a sign-in. If someone can’t get access, they can watch, but say plainly that watching isn’t practising.
Why this works: the account decides what people may put into the tool, so it has to be settled before anyone brings real work.
What you should see: a one-word reply from everyone, from the right account.
2. Run the first clinic: one real task, done by someone else
Thirty minutes:
- Fifteen minutes doing. One person, one task they have to finish this week, on the shared screen. They drive. If you suggested all this, you’re specifically not going first: a session where the enthusiast shows off teaches the room that this is something other people are good at.
- Ten minutes on the checking. What did they check, against what, and what didn’t they check? What would have gone out of the door if nobody had looked? Microsoft’s own Copilot guidance says AI responses aren’t guaranteed to be factual and people should use their judgement before sending them on.
- Five minutes writing the entry. While it’s still true (step 3).
Before they start, the volunteer checks that the task’s material may go into the tool and be seen by the room. Removing names may not make a distinctive case anonymous. The volunteer can start from this and change it to fit:
Turn the material below into [result] for [reader]. Use only this material for facts. Keep every time, figure, condition and uncertainty. Put anything missing or conflicting under "Questions to resolve". Don't send, publish or change anything.
[material][result] and [reader] describe what they need and who it’s for; [material] is their source. Write your first useful prompt explains the parts.
Use a real task, with real deadlines and real mess; a demonstration task works every time, which is exactly what makes it useless. And let it fail in public. A session where the tool didn’t help is a successful session, and the person who ran it should be thanked rather than rescued. Say who will see the page, and never turn someone’s hesitation or typing speed into a judgement about them.
Why this works: watching a colleague check their own work for ten minutes teaches more than an hour on prompt technique.
What you should see: a finished task, or a clear failure, and a list of what was and wasn’t checked.
3. Write a seven-line entry while it’s still true
The page is a running log, not a handbook:
Task:
Who:
What we gave it:
The request:
What we checked: [checked and passed / corrected and rechecked / failed / not checked]
What it got wrong:
Would we do it again: [yes / no / only for …]“What it got wrong” is what gets the page read. A page of successes is marketing, and people treat it accordingly. A page that says “it invented a supplier name close to a real one” is a reference the next person reads before they start.
Why this works: quoting the request exactly lets the next person reproduce it, and the four check states stop a blank becoming a pass.
What you should see: seven short lines, with the request in quotes and an honest “what it got wrong”, even if that’s “nothing”.
4. Rotate, and stop when it’s finished
Let whoever goes next pick the task, and rotate so it isn’t the same three people. Early sessions feel slow. The middle ones are the useful ones, where a task half works and the room learns where the edge is. Later sessions get harder to fill.
That’s the finish line, not a failure. When two people in a row have nothing to bring, stop the series, keep the page, and put a standing five minutes in an existing meeting for anything new.
Why this works: a clinic that ends on time is remembered better than one that limps on until attendance decides for you.
What you should see: a page of entries, some of which say “don’t”.
Check the result
- Every entry quotes the request as typed, awkwardness included.
- “What we checked” uses one of the four states; nothing unchecked is recorded as fine.
- “What it got wrong” is filled in, including failures.
- No entry claims a time saving or percentage nobody measured.
The usual failure: the entry tidies the truth. If someone asks AI to turn rough session notes into an entry, the request gets “improved”, “not checked” becomes “fine” and the mistake disappears into “minor issues”. Spot it by reading the entry against the notes. Then:
Rewrite this entry from my notes only. Quote the request exactly as it was typed. Where something wasn't checked, write "not checked", not "fine". Put what went wrong in the words from my notes. Don't add a time saving, a recommendation or anything not in the notes.
ENTRY: [entry]
NOTES: [notes]Worked example: six fortnights in a finance and operations team
Fictional example. An operations manager with eight people runs six clinics over twelve weeks. Nine entries end up on the page.
- Week one, and the failure. Mira brings the monthly supplier spend summary. The checking finds two supplier names merged into one that doesn’t exist in the ledger. The AI-tidied entry said “What we checked: totals, fine. What it got wrong: minor naming issues.” The rewrite prompt, run on the notes, gave the example result, and “every name matched back to the ledger” became the team’s rule.
- Week three. Someone brings replies to technical customer questions. It doesn’t work: the model doesn’t know the product, and the answers are confidently wrong. The entry, “Would we do it again: no, not without a source document, and we don’t have one”, becomes the most-read on the page, because it’s the only one that shows where the boundary is.
- Week five. A reconciliation that turns out to need a lookup formula, not a draft. Entry: “no — this is a formula, not a drafting job”. Useful, and faintly deflating for the AI budget, which is also information. By week six, two people in a row have nothing to bring, so the series stops: nine entries, three of which say don’t.
Task kit for this job: Download (ZIP) · Reusable instructions
Go deeper
Optional training: When a clinic is the wrong method
If you have a formal training obligation (a regulator, an accreditation, a contract), a clinic doesn’t satisfy it. Run the required training, and the clinic as well. If the tool needs configuration first (connections to approve, permissions to set), do that before the first session, or every answer will be “we’d need IT to switch something on”. If people are anxious about their jobs, think hard about who chairs: a session run by the person who decides headcount is not a place where anyone volunteers a task they find difficult. And if half the team has no licence, that’s a procurement conversation to have first.
Optional training: Three situations that derail a clinic
The demonstration. Someone brings a polished example they’ve already run, and it becomes a presentation. Ask for a task they haven’t tried yet; the uncertainty is the content.
The policy question. Someone asks whether a document may go into the tool and the room spends twenty minutes guessing. Nobody present can answer it. Write it down with a name beside it, send it to the policy owner and get back to the task.
The hostile silence. Nobody volunteers. This usually means the room isn’t sure what the exercise is for. Say what happens to the page, who sees it and what it isn’t used for. Then go first yourself after all, with something you’re not good at.
Optional training: Remote teams, and the page afterwards
Remotely, record the decisions, not the screen. A thirty-minute recording won’t be watched; the seven-line entry will. If you can’t align times, one person does the task, writes the entry and posts it with one open question, but you lose the checking discussion, which is the best part.
Afterwards, give the page a named owner, a “last true on” date and a review trigger: a new model, a plan change, a feature switched on. If nobody will own it, keep only the two or three rules that came out of it. For a task worth repeating, see Save a useful AI task so you can reuse it; for claims about time, use Try a two-week AI pilot and count the checking.