Don’t waste your employees’ time. How to get real impact from AI training.
The version that fails is easy to describe: a room, a curriculum, and the hope that people apply it later. We have run more than 40 hands-on sessions with client teams across consumer brands, lenders, and software companies. The ones that changed how people worked had three things settled before anyone opened Claude: a specific objective, the setup done, and people grouped with others at roughly their level.
Counts and figures throughout are from Glia’s own client training work in 2025 and 2026, anonymized to role and industry except for SPANX, which has a public case study. The 63 of 65 figure is one team’s completion of our intake before design started; response rates vary, and a 30-person team elsewhere came in under half. Time savings are self-reported by the teams involved, and both multipliers use the midpoint of each range shown, so 45-60 minutes down to 10-20 is 3.5 times and 2-3 hours down to about 20 minutes is 7.5 times.
The short version
The trainings that changed how people worked started from something specific: get most of this team to a defined proficiency level, have every person ship one thing they use every week. Where the goal was to get people using Claude more, we got attendance.
Connectors, permissions, file structure, a running notes file. It is the least interesting hour of any training, and when it gets skipped the rest of the session tends not to survive contact with Monday.
Someone who needs help installing the desktop app and someone architecting a skill do not belong in the same session. We now assess proficiency first and split people into smaller rooms by level.
Every person builds a workflow they already own, sharing their screen, while we unblock them. A customer success team took case reviews from 45-60 minutes to 10-20. A new hire setup routine went from two or three hours to about twenty minutes.
Where adoption stuck, an internal champion had shadowed the real work first, and a leader defended protected build time out loud. Where a workshop happened and everyone went back to their inbox, there was neither.
We run this work in three shapes: hackathons, one-on-one tutoring, and large group training split into smaller rooms by proficiency. The shape changes with what a team needs. The five points above hold across all of them, and the rest of this post is the detail behind them.
Write down what has to be true at the end
AI training for employees is how a company teaches its staff to use AI tools like Claude on their real work, safely and well. The version that fails is easy to recognize because the goal is stated in terms of the tool. A data leader at a consumer brand described his own rollout to us plainly: “we gave everyone in the organization access to Claude and then we were like, go have fun.” Access went out, a few internal examples got shared, and most people settled into using it as a chat window.
“We need our people using Claude more” is not an objective. It cannot tell you who should be in which room, what anyone should build, or whether the training worked. So we start every engagement by writing down what has to be true at the end. Here are the three goals we set with a finance team this month, agreed with their leader before any curriculum existed.
Eighty percent of the team at level 3 or above on the four-level scale we score people against, meaning they can work with Claude as a coworker rather than as an assistant handed one task at a time.
Every person builds one thing they will genuinely use, a skill or a dashboard, and knows how to change it later without us.
People can tell whether what comes back is right, and their manager trusts it too. For a team whose work has to reconcile, this one is not optional.
These are the goals from one real kickoff, July 2026, with the finance team at a legal software company, and from the planning call ten days earlier. The proficiency scale is our own: four levels scored from what a person builds, which modes they use, what they have connected, and how they check their own output. The score combines each person’s own account of their work, a model’s reading of it, and our spot checks by hand, so treat it as a structured read on proficiency rather than a test result.
Specific goals also change what the training is allowed to be. If eighty percent of a team has to reach level 3, a lecture cannot get you there, and neither can a session that leaves the slowest quarter behind. The objective picks the format for you.
Setup is the least interesting hour and the one that decides the session
People do want the craft, and they ask for it by name. A chief executive at a nonprofit lender opened one of our sessions with a request that the techniques be written down somewhere, because “you gave me some great prompt tips the other night that are buried in my notebook somewhere.” The best moments in a session are usually the ones where somebody learns a way of working with the model they did not know was available. One person, after watching a colleague work: “Honestly, I have been underutilizing Claude.” None of that happens if the opening goes on installs and permissions.
In one 90-minute workshop with an operations and finance team at a real estate company, we opened with a few minutes of overview and turned the rest into a build: come off mute, share your screen, and we get into the weeds with you. Someone could not get their company’s cloud drive installed. Someone had scripts trapped on a local disk. Someone had spent ten hours inside one project with no notes to pick it back up from. Three things people said, verbatim.
“I just recently transitioned to Mac, so I am not the most efficient user at this point.”
an FP&A analyst at a real estate company
“Desktop Google Drive, I don’t have that and I need it to help me even get permission to install it.”
an operations analyst on the same team
“I thought I could only do one cowork at a time. I’m thrilled.”
the team’s internal champion
Two of those are access problems, and no course on prompting fixes either one. The third is the good kind of moment, the one people come for, and it landed because that person already had the boring parts sorted. So we do the boring parts first and on purpose: connectors, file structure, and a running notes file, in the room, before anyone tries anything clever.
The three quotes in the panel are verbatim from one client workshop of about 33 attendees, April 2026, anonymized to role and industry; the third speaker is that team’s own internal champion. The two quotes above it are from a different client, a nonprofit lender, in sessions in April and June 2026. A cowork is a Claude session that works alongside you on your files rather than answering in chat. The broader pattern, that missing connectors and weak setup read as low proficiency when the real blocker is access, is codified in our internal delivery playbook.
Find out where people are, then split the room
That workshop of 33 people contained someone who had just moved to a Mac and someone building multiple coworks at once. Both deserved a good session. Neither got the best possible one, because getting set up and learning to build are different problems and we had put them in the same room. Grouping people this way is a large part of what makes training feel generic: whatever you teach is wrong for most of the room.
Fixing it means knowing where people actually are before you design anything. So we send an intake that is itself a Claude skill: a 15 to 20 minute conversation that asks about someone’s role, what they have built, what they have connected, and which parts of their week they would hand over if they could. We use a conversation rather than a form because it can follow up on an answer. It does not ask a person who has built ten skills whether they have set up their email connector, and when somebody complains that the model made up a number, it can stop and show them why that happens.
Completion has been good, though it varies. One 65-person team returned 63 responses within days and another team finished inside 48 hours, while a 30-person team elsewhere returned fewer than half. The outputs give us a picture of each person and a ranked list of what the team actually finds painful, which is what the rooms and the tracks get built from.
Many projects moved at once, each person on their own build, progress shared in small groups. Buys camaraderie along with the output, which matters when a team is nervous about the tool.
Recurring sessions with one person and one build. Slowest per head, and where the workflows that need several passes get finished.
One short kickoff for context, then smaller rooms grouped by proficiency, each with its own track and its own facilitator.
We have not run a course, and we have shifted away from keeping a whole department in one room for a whole session, which is how our workshops of 31 to 35 people ran last spring. A short shared kickoff still earns its place, for context and for the goals. After that people pick a room against criteria we read out loud: is the desktop app set up, are the core connectors ready, are you in cowork most weeks. Yes to all three, go build a skill. Shaky on any of them, start in the setup room. We say plainly that there is no wrong room. What we avoid is running both groups together, because setup and building are “two very different problems to solve at the same time.”
What does not work
- One curriculum for the whole company
- Everybody in one room for the whole session
- Examples the facilitator picked, on sample data
- The same starting point assumed for a new user and a builder
- Success measured by attendance
What works
- Each person’s proficiency established before anything is designed
- Rooms split by level, so the session fits the room it is in
- One workflow per person, taken from the projects they already own
- Getting set up handled separately from learning to build
- Success measured by what is still running a month later
The intake is our own tooling, used with several clients in 2026; response figures are from two teams at a legal software company and one 30-person team elsewhere. We have not measured completion or the quality of what the intake tells us against a form or survey, so read the comparison as a description of how it works rather than a tested result. Attendance counts of 31 to 35 are from our own records for three workshops with one client in April and May 2026. The room criteria and the quoted line are from a client kickoff in July 2026. The two columns are our own delivery practice, not a controlled comparison: we changed several things at once when we moved to segmented rooms.
Train people on their own live work
Once setup is out of the way, the thing that makes training pay off is picking a real, recurring, tribal knowledge task the employee already does by hand, and building it with them. Not a sample dataset. Their monthly close, their checklist for setting up a new hire, their weekly note on why the numbers came in over or under budget. The work they would do anyway is the curriculum.
When that happens, the time savings are not subtle. A customer success lead at a fintech cut case investigations from 45 to 60 minutes down to 10 to 20 after we built the review into a Claude project on her own cases. A RevOps analyst at a legal software company rebuilt a new hire setup routine that took two or three hours as a skill she wrote herself; her verdict was “it was exactly what I wanted it to do and more,” and it now runs in about twenty minutes with a few minutes of review. A finance lead at the same company took a forecast review from two hours to 30 to 45 minutes.
Time on one real task, before and after
Each row is one team’s real recurring task, self-reported before and after, from our training sessions with a customer success team at a fintech, a RevOps team at a legal software company, and a finance team at that same company (2025 and 2026), anonymized. Figures are representative ranges, not audited averages. Each row is independently normalized to 100 percent of its own “before,” using the midpoint of each range, so the shrink is legible; the exact ranges are printed on each row. Each row is one team’s result, not a benchmark.
The honest version of this includes where it does not work, and that candor is worth more than a glowing testimonial. A lifecycle marketer told us a copywriting skill “saved me so many hours already,” and in the same breath that the design side was the tool’s weak spot: it does well when there is a strong reference and small changes, but hand it a brand new brief and it “can’t build anything new.” That is the right thing to learn in training, because it reshapes who does what. She writes the brief and a first pass, a designer takes it the rest of the way. Show only the wins, and the first time the tool stumbles, people stop trusting you.
One more shift showed up again and again. When a task drops from two hours to twenty minutes, the employee’s job does not disappear, it moves. It becomes directing and checking the output rather than grinding through it. The people who got the most out of training were the ones who learned to review well.
Attendance is not adoption
The most common way AI training fails is quiet. The session goes well, people are engaged, and then nothing changes. One champion we worked with put it plainly afterward. There was, in his words, “a lot of good nuggets that people took from the training,” but fewer actions came out of it. That is a common outcome rather than a bad day. A single session with no follow-through usually evaporates.
Three things prevent that, and none of them is more training. Protected build time a leader defends out loud, so using the new tool competes with real deadlines on equal footing; one team blocked Wednesdays for it. A named owner for each workflow, plus somewhere for an unfinished skill to go, which at several clients meant tutoring every two weeks for a couple of months rather than a single kickoff. And an internal champion who does the work alongside people.
The best champions start by mining the process rather than by evangelizing the tool. Kyla Robinson, who led the AI work at SPANX, described her approach this way: “I would sit down with the merchant teams and follow their exact process. So they understood, they trusted that we understood their pain points. It wasn’t just like an outside consultant looking at it.” That is the difference between a champion and a memo.
What we check after a session, not during it
- A named owner for every workflow that got built
- Protected build time on the calendar that a leader defends out loud
- Standing office hours or recurring tutoring, so an unfinished skill has somewhere to go
- A champion who does the work alongside people rather than cheerleading
- One review a month later: is the workflow still running, and who stopped
The champion’s “good nuggets” quote and the recurring tutoring cadence are from our own client work, anonymized; details are drawn from session transcripts and our internal facilitation playbook. The Kyla Robinson quote is from our own recording of a session with her. SPANX is named because that work is public in the SPANX case study.
Why this matters
Any organization big enough to need AI training has people spread across real differences: proficiency, skepticism, and how much they fear what the tool means for their job. A course that treats all of them the same cannot address any of it. So be deliberate instead. Write down what has to be true at the end. Find out where each person actually is before you design anything. Do the setup work first, group people with others at their level, and give every one of them a workflow from their own real projects, ideally in finance and operations to start, where the tribal knowledge tasks hurt most and the before and after is easiest to see.
What we keep running into is that the training problem is really three problems: a setup problem, an accountability problem, and a trust problem. Solving one and skipping the others is how a good session turns into nothing by the following month, so a training program has to take on all three. Want a second opinion on a plan you are drafting, or on why the last one did not stick? , we are happy to talk it through.
This post draws on more than 40 hands-on training and enablement sessions Glia ran with client teams in 2025 and 2026, across consumer brands, lenders, and software companies. Except for SPANX, which has a public case study, clients and employees are anonymized to role and industry. Patterns described here are what we saw across that work, not a controlled study.