Why AI training fails, and what a champions program does instead

The standard AI rollout looks the same everywhere I see it. Buy the seats. Run a lunch-and-learn with a demo that gets genuine applause. Send a memo from the CEO. Then watch the usage chart: a spike in week one, a slide through week four, and by week eight you’re back to the same 15% of natural enthusiasts who would have found the tools on their own. The other 85% went back to how they worked before, and the company is now paying enterprise pricing for their inactivity.

I’ve watched this curve enough times that I treat it as a diagnostic. If your usage looks like that, you didn’t run an adoption program. You ran an announcement.

One session can’t teach a hundred workflows

The reason one-shot training fails is not that the training is bad. It’s that AI competence isn’t tool-generic. It’s workflow-specific, and the research says so plainly.

The MIT study on ChatGPT and professional writing found that workers finished writing tasks 40% faster with 18% higher quality — on writing tasks. The GitHub Copilot study found developers completed a coding task 55.8% faster — on a coding task the tool was built for. Neither study found a general “AI makes you better at your job” effect, because there isn’t one. The gains concentrate exactly where the task fits the tool, and they thin out fast everywhere else.

Now look at what a lunch-and-learn actually teaches: how to open the tool and ask it something. It cannot teach a tax senior how to draft a client memo from precedent, an audit senior what she’s even allowed to put in the prompt box, and an admin how to chase document requests, because those are three different competencies and the trainer knows none of the three jobs. A month later, each of those people hit one wall specific to their work, had nobody to ask, and quietly stopped. Multiply that by every role in the company and you get the curve.

Training assumes the skill transfers from a conference room to a workflow. It doesn’t. Somebody has to be standing next to the workflow.

What a champions program actually is

The fix I install at clients is a champions program, and I want to be precise about what that means, because the phrase gets used for everything from a Slack channel to a t-shirt.

A champion is one named person per department. Not the department head — the person other people already ask when something breaks. Chosen for credibility, not title. In an accounting firm that’s usually a senior or a manager, someone close enough to the work that their advice is about this Tuesday’s deliverable, not about AI in general.

And the role has real duties, written down:

Weekly office hours. Thirty minutes, same time every week, where anyone in the department can bring the thing that didn’t work. This is where the workflow-specific skill actually transfers, one stuck person at a time.

Feeding the precedent library. When someone in the department finds a prompt or a workflow that works, the champion captures it and files it where the next person can find it. Without this, every win stays in one person’s head and the department relearns it from zero.

First-line judgment calls. “Can I put this in the tool?” gets answered in minutes by someone who knows the data policy, instead of dying in an email to IT.

Flagging near-misses without drama. When someone almost pastes client data into the wrong place, the champion reports it as a coaching moment, not an incident. The moment near-misses become punishable, they become invisible.

That last duty matters more than it looks. A KPMG and University of Melbourne study of 48,000 people found that 57% of employees hide their AI use and present the output as their own. Microsoft’s Work Trend Index found 78% of AI users bring their own tools to work. Your people are already using AI. The only question is whether they have someone safe to be honest with about it.

Measure from the admin console, not the survey

The other half of the program is measurement, and here the KPMG number settles the method: if 57% of employees hide their AI use, then self-reported adoption data is fiction. Surveys measure what people think you want to hear.

What I actually track is weekly active users by department, pulled from the tool’s admin console. Every enterprise AI product exposes this. It costs nothing, it doesn’t lie, and it turns “how’s adoption going?” from a vibes question into a chart. At one client engagement — the one documented in my sample plan — the firm went from 41% weekly active in April to 64% in June, and we knew which departments moved because we looked every week, not because anyone filled out a form.

Department-level matters because company-level averages hide everything. A 64% average can contain a department at 71% and a department at 39%, and those two need completely different conversations.

A stalled department is one of three problems

When a department’s number flattens or drops, I’ve found it is always one of three things, and each has a different fix.

A seat problem. The people who’d use it don’t have licenses, or the tool isn’t in their workflow at all. Fix: move seats. This is logistics, not psychology, and it’s the cheapest fix on the list. Check it first.

A skill problem. They have access, they tried, they hit a wall specific to their work. Fix: the champion, office hours, and one worked example from their actual job. Not another all-hands training.

A fear problem. They’re not sure what’s allowed, or they suspect the usage data is a layoff list. Fix: leadership says out loud what the tools are for and what the data will never be used for, and the near-miss handling proves it. No amount of training touches a fear problem.

The diagnosis matters because the default response to a stalled department is “schedule more training,” which only treats the second problem and actively worsens the third.

The department at 39% wasn’t failing

Here’s the example I keep coming back to, from the sample 90-Day Adoption & Training Plan — the client in it, an 118-person accounting firm, is a fictional composite, but the pattern is one I’ve seen for real.

The audit team sat at 39% weekly active while tax was at 71%. The instinct is to call audit a failure and send in the trainers. But when we ran the three-problem diagnosis, it wasn’t a skill gap. It was partly correct behavior: audit workpapers were classified in the most restricted data tier, out of approved scope for the general tools, and the auditors knew it. The cautious half of that 39% gap was people following the rules.

The fix was not more training. The fix was scope definition: a written list of what audit work the tools could safely touch — planning memos from anonymized templates, internal methodology questions, drafting that never contained client financials — signed off by the audit partner. Give a careful professional a bright line and they’ll walk right up to it. Give them fog and they’ll stay home.

That’s the whole shape of the thing. Training treats adoption as an information problem, solvable in a conference room in an hour. It’s actually an infrastructure problem: a named person in every department, a library that compounds, a number pulled weekly from the console, and a diagnosis framework for when the number stalls. There are more of these program mechanics in the full sample at /examples.

The lunch-and-learn is fine, by the way. Run it. Just know that it’s the kickoff, not the program — and that everything that determines whether the chart spikes-and-slides or actually climbs happens in the weeks after the pizza is gone.