There's a quiet pattern to AI training that doesn't land: a half-day workshop, a slide deck, a flurry of post-session enthusiasm, and then, three weeks later, nothing in the team's day-to-day has actually changed. The tools aren't in use. The prompts aren't in shared files. Someone still spends Friday afternoon doing the report by hand.
The training itself isn't usually the problem. The problem is what didn't happen before the training: a hard look at what your team actually does, where the friction is, and who'll own the change. Three questions, answered honestly, will tell you whether the workshop you're about to book is going to stick.
1. What does my team actually do all day?
Not what their job title says. Not what their job description says. What they actually do, hour by hour, in a normal week. If you can't write this down for each role on the team, no amount of AI training is going to help, because you'll be teaching general skills against an unknown surface.
The exercise that always pays back: pick three people on your team, sit with them for thirty minutes each, and write a one-paragraph description of what their week actually looks like. Reading lists. Spreadsheets they keep open. Documents they re-write. Emails they have a template for. The repetitive work, not the interesting work, is where AI tends to land first. You can't see the repetition until you write the week down.
2. Where are we losing two hours a week?
AI doesn't transform a business in one go. It saves an hour here, two hours there, and the wins compound. The right question isn't “what could AI do for us?”. It's “which tasks, if we cut them in half, would meaningfully change someone's week?”
Look for the dull, structured, repeatable work first. Drafting standard responses. Summarising long documents. Cleaning up notes from meetings. Pulling data into a format somebody else expects. None of these is glamorous, and exactly because they're not glamorous, they're underbid for transformation budget. They're also where AI is consistently good, even small models, in a basic interface, with no integration work.
When you walk into the workshop, you should already have three or four named tasks in mind. Otherwise the trainer has to invent them on the day, which means the examples will be generic, which means the team will leave with general enthusiasm and no specific habit.
3. Who on the team will own the change?
This is the question most people don't ask, and it's the one that decides whether the training survives the first month. After the workshop, somebody has to be the person who keeps it alive. They build the shared prompt library. They send the “hey, I just used it for this” note in the team chat. They notice when someone slips back to the old way and gently nudges them.
It doesn't have to be the most senior person. In fact, it usually shouldn't be. The best owner is someone who's enthusiastic about the tools, well-liked by the team, and would have used them anyway. Find that person before you book the workshop. Make sure they know they're the owner. Give them a small budget to keep building (a Claude Pro subscription, an n8n account) and a half-hour a week, protected, to maintain the practice.
Without that person, the training is a one-off event. With them, it's the start of a habit.
What to do with the answers
If you can't answer all three questions clearly, don't book the training yet. Spend a fortnight in your team's actual work first. Write what they do down. Watch where the friction is. Find the person who'll own it. Then book the workshop, and book it for those specific tasks, with that specific person leading on what to take back.
It's slower. It's also the difference between a workshop your team mentions politely in their next 1:1 and a workflow change your team is still using in twelve months.