AI training that changes what people do on Monday

A completion rate is not an outcome. Most AI training is a capable demo on somebody else’s example, and it produces enthusiasm that decays within a fortnight because nobody’s actual Monday changed. The sessions that stick run on the team’s own documents, target one workflow per role, and are followed by a measurement four weeks later that somebody is accountable for.

Key takeaways

Generic training fails on transfer. People can follow the demo and cannot map it to their own work.
Teach one workflow per role properly rather than six capabilities shallowly.
The measurable outcome is adoption of a named workflow at week four, not attendance or satisfaction.
Without a written policy on what may be pasted into which tool, people either freeze or improvise badly.
Internal champions matter more than the trainer. The questions arrive after everyone has left.

Who this applies to

You have bought AI tooling and usage is lower than you expected, or you are about to run training and want it to produce something. Also relevant if you have run a session already and cannot tell whether it worked.

Why the standard session produces nothing

The pattern is consistent enough to describe.

A capable trainer demonstrates impressive things on a clean example. The room is genuinely impressed. Everybody leaves intending to try it. Within two weeks, the people who were already going to use it are using it, and everybody else is not - which is exactly the distribution you had before the session.

Three mechanisms cause this.

The transfer problem. A demo on a generic example asks each attendee to do the hardest part - mapping it onto their own work - alone, later, without help. Most will not, because the moment they hit friction there is nobody to ask.

Too much surface, no depth. Six capabilities in ninety minutes means nobody leaves competent at any of them. One workflow practised until it works beats six explained.

No permission. People are unsure what they are allowed to paste into which tool, so the safe move is to do nothing. Absent a policy, caution reads as compliance and nothing changes.

Build the session on their own material

The single change that matters most: use the team’s real documents, real tickets, real spreadsheets in the room.

That has a cost - somebody has to gather and redact them beforehand, and it makes the session harder to prepare and impossible to reuse. It also removes the transfer problem entirely, because the thing they practised on is the thing they do.

It has a second effect worth expecting. Working on real material surfaces the cases where the tool does not help, in front of everyone. That is uncomfortable and it is the most valuable ninety seconds of the day, because a team that has seen where a tool fails trusts it in the places it works.

One workflow per role

Ask each role for the task they would most like to stop doing by hand, and build the session around that one.

Role	The workflow worth teaching	What “it worked” looks like at week four
Support	Drafting a reply from the knowledge base, then editing it	Drafts used on a named ticket type, with handle time measured before and after
Sales	Turning call notes into a CRM summary and next actions	Summaries present on the majority of logged calls
Marketing	First-draft briefs from an outline and existing pages	Briefs produced without the writer starting from blank
Ops and finance	Extracting fields from a recurring document into a sheet	The manual re-keying step is gone for that document type
Managers	Reading a system’s output critically, and knowing when to escalate	Somebody has actually challenged an output and been right to

Depth per role beats breadth across the team. A support agent who is genuinely good at one drafting workflow will find the second one themselves; one who has seen six demos will find none.

The generic session peaks in the room and is gone by the fortnight. The session built on one workflow from their own files is still in use at week four, which is the only week that counts.

Write the policy before the session, not after

People need to know three things, in writing, before they will use anything freely.

What may go in. Which categories of information can be pasted into which tool. Name the tools. “Use your judgement” is not a policy and it produces the most cautious person’s behaviour across the whole team.

What must be checked. Which outputs can be used as-is and which require a human to verify before they leave the building. A support draft to a customer and an internal summary sit in different places.

What must be disclosed. Whether generated content going to a customer needs saying so. This is a decision to take deliberately rather than discover later - see responsible AI as an engineering decision.

Keep it to one page. A policy nobody reads is the same as no policy, and it is worse because it creates the impression that the question was handled.

Measure at week four, and pick the right number

Attendance and satisfaction tell you the session was pleasant. Neither predicts change.

The number to agree in advance is adoption of the named workflow, measured four weeks later, by somebody accountable for it. For a support team that is the share of tickets of a given type where a draft was used. For sales it is the share of logged calls carrying a generated summary.

Four weeks is deliberate. At one week you measure novelty, and at three months you have lost the thread and everyone has an opinion instead of a number. It is the same discipline as any other system: agree what would count as working before you build - see how to measure whether an AI system works.

Name the champions before you leave

Every question that decides adoption arrives after the trainer has gone. If the answer is a support ticket to an external party, the question does not get asked and the workflow quietly reverts.

Pick one or two people per team who were visibly engaged, give them thirty extra minutes, and make it explicit and public that they are the people to ask. It costs almost nothing and it is the difference between a session and a change.

What we do differently, and what it costs us

We require access to real, redacted material before the session and will move the date rather than run on generic examples. That is the whole method, and it means our sessions cannot be delivered off the shelf.

We also insist on the four-week measurement being agreed and owned before the session is booked - a named person, a named workflow, a number. That converts training from an event into something with an outcome, and it is the item most often resisted, because it makes a disappointing result visible. Which is the point.

The pushback we get most: clients want the broad “AI for everyone” session because it feels fairer and easier to schedule. Our position is that it reliably produces nothing measurable, and we would rather run three role-specific sessions than one general one. That is a harder sell and a longer engagement to describe.

Where our own method is weakest: we can produce competence in a room and we cannot produce management follow-through. Where a manager does not use the workflow themselves, adoption on that team is consistently lower regardless of session quality. We now ask for the manager to attend their team’s session rather than being briefed separately, which helps and does not solve it.

When training is not the answer

When the tool is wrong for the job. No amount of training fixes a workflow the tool cannot do. Check that first, honestly.

When the real blocker is a policy vacuum. If people are unsure whether they are allowed to use it, write the page and see what changes before booking anything.

When it should be automated instead. If the workflow is high-volume, rule-shaped and repetitive, training people to do it faster by hand is the wrong intervention - see where the hours actually go.

When nobody will own the follow-up. A session with no accountable measurement afterwards is an expense with a completion rate attached.

Frequently asked questions

How long should a session be?

Ninety minutes to half a day per role, on their own material. Longer than that and retention falls; shorter and there is no time to practise, which is the part that transfers.

Should we train everyone at once?

No. Role-specific groups, because the useful content differs completely between roles and a general session optimises for nobody.

What if people are worried about their jobs?

Address it directly at the start rather than letting it sit in the room. Say what the workflow is intended to remove and what it is not. An unspoken version of this question suppresses engagement for the whole session.

How do we keep it current when the tools change monthly?

Teach the workflow and the judgement, not the button positions. A team that understands when to check an output adapts to an interface change; one that memorised a sequence does not.

What is the cheapest useful version of this?

One role, one workflow, their own documents, and a measurement four weeks later. That is a half-day and it will tell you whether a wider programme is worth funding.

Next step

If you have tooling in place and low usage, the gap is usually a workflow nobody was taught and a policy nobody wrote. The AI training and enablement engagement runs role-specific sessions on your own material and leaves the policy and the named champions behind.