Short answer
Train two skills, not a tool: recognizing which tasks a model suits, and checking an answer before acting on it. Do it on your own documents and your own clients, in short sessions attached to real work, starting with the people whose work is text-heavy plus one curious person per team. Judge it on whether the tool is still in weekly use a month later and whether someone can show you a task they now do differently — not on satisfaction scores. And make sure there is a job waiting for the skill, because training with nothing to apply it to decays within weeks.
The gap that training has to close
Give a team access to a capable assistant with no support and a predictable pattern follows. A few people work out how to use it well on their own. Most try it on something it handles badly, conclude it is overrated, and go back to what they were doing. A smaller group trusts an answer that was wrong.
None of that is a knowledge problem about how models work. It is two practical skills: knowing which of your tasks are a good fit, and being able to tell a solid answer from a fluent one. Everything worth putting in a training program serves one of those two, and material that serves neither — however interesting — is why so many sessions are enjoyed and forgotten.
Three levels, and where the value sits
It helps to be explicit about who needs what, because treating a whole company as one audience produces content that is simultaneously too basic and too abstract.
| Audience | What they need | Format that works |
|---|---|---|
| Everyone | What the approved tool is, what may and may not be pasted into it, roughly what it is good and bad at. | Short and once. Mostly about avoiding the two failure modes above. |
| People whose work is text-heavy | Structuring a request, working iteratively, and building a reusable prompt for a task they repeat — in the sense described in our guide to prompt engineering for business. | A session on their own material, then practice with somewhere to ask. Where the return is concentrated. |
| One or two builders | Connecting tools together and automating a process. | Building something small and real. Not a session at all. |
The middle group is the one companies systematically under-serve, usually because the first group is easier to schedule and the third is more fun to talk about.
What to teach that outlives the next release
Model-specific tips age badly and there is always another release. The content worth building is the part that does not depend on which provider you are using this year.
- Task fit. Which shapes of work suit a model — transforming a messy input into a structured one, drafting where a human will edit, summarizing where the source is available for checking — and which do not, such as anything requiring a fact the model has no access to.
- Giving context deliberately. The single largest quality difference in practice is whether the person supplied the source material, the audience and the constraints, or asked a bare question.
- Verification. How to check an answer proportionally to what it will be used for. A rewritten internal note needs a glance; a figure going into a client proposal needs the source opened.
- Recognizing confident nonsense. Fluency is not evidence. Naming this explicitly, with examples from your own domain, does more for output quality than any prompt template.
- What must not be pasted. Short, specific, and tied to the written rule rather than to a general appeal to caution.
A module earns its place if you can name the task someone will do differently that week. If the best answer is that they will understand the field better, it belongs in a newsletter, not in training.
Formats that work at this size
A company of ten to a hundred people cannot run a training function, and does not need one. What works is closer to coaching than to a curriculum.
- A short session on a task everyone shares, using real material rather than a demo scenario. The shared task is what makes the session concrete for a mixed audience.
- Practice on their own work, with somewhere to ask. A channel where people post what they tried and what came back is worth more than a second session, and it surfaces the specific confusions no course anticipates.
- A shared place for prompts that worked. Low effort, and it turns one person’s discovery into everyone’s baseline.
- A short follow-up a few weeks later, once people have hit real limits. Questions at that point are dramatically better than questions on day one.
What consistently underperforms is the single long day. Attention fades, nothing is applied immediately, and the material is generic by necessity.
Who to train first
Two criteria, applied together. Choose the roles where work is most text-heavy and most repetitive, because that is where a small skill gain compounds daily. Then add at least one naturally curious person per team regardless of role.
The second criterion is the one that gets skipped and it matters disproportionately. In a company this size most learning happens by asking the colleague two desks away, and that person needs to exist in each team. Training the leadership team first is the common inversion: it produces sponsorship, which is useful, and no practice, which is what was needed.
Resistance, and what it usually is
Reluctance is rarely about the technology. It is usually one of three things, and each needs a different answer.
- Concern about the job. Answer it directly, including the parts that are genuinely changing. Vague reassurance is read as evasion and costs more credibility than an honest answer.
- Fear of looking incompetent. Common in people who are good at their craft. Practicing on their own work privately, before any group session, removes most of it.
- A previous tool that was imposed and abandoned. This is a reasonable inference from experience. It is answered by a narrow first use that visibly works, not by a bigger launch.
Mandating usage produces a compliance number and no change in the work. A smaller group using the tool well is a better outcome, and it recruits the rest over the following months.
Knowing whether it took
Across LYVIA’s own sessions, satisfaction scores come back high almost regardless of content — an observation from client work rather than a published study — which makes them useless as a signal. Three observations are worth more.
- Usage a month or two later, rather than during the first weeks of novelty. Sustained weekly use by the target group is the headline measure.
- A task someone can point to and describe as done differently now. If nobody in a team can name one, the training did not connect to their work.
- The shape of the questions. Moving from “what can it do” to “why did it get this specific thing wrong” is the clearest sign of real competence forming.
Usage over stated satisfaction is not a training-specific rule — it is how tool adoption is judged generally, and it is covered in our guide to AI productivity tools for teams. What is specific here is the second observation: a named task, pointed at by the person who does it. When usage falls away sharply the cause is usually a missing job rather than a missing skill, which is why enablement and deployment have to be sequenced together, as set out in our guide to implementing AI in your business.
What not to spend on
Certification programs for staff who will never build anything, conference attendance in place of practice, and long generic courses bought per seat all absorb budget without producing the two skills that matter. Broad technical education is a fine thing to want and a poor substitute for someone being able to use the tool well on Tuesday’s actual work.
Spend instead on a small amount of tailored content built from your own documents, and on protecting the time to practice. Where the money goes across a full year is part of the wider sequencing question in our AI strategy roadmap.
Frequently asked questions
What should AI training for a team actually cover?
Three things, in this order: what the tool is reliably good and bad at, how to structure a request so the output is usable, and how to check an answer before acting on it. Everything else — model architectures, the vocabulary of the field, comparisons between providers — is interesting and does not change what anyone does on Monday. The test for any module is whether it maps onto a task the person already performs.
How long should it take?
Short sessions tied to real work beat a full day of theory, because the skill is built by using the tool on your own material rather than by watching someone else use it on theirs. A workable shape is a first session on a task everyone shares, then practice on their own work with somewhere to ask questions. What determines whether it sticks is having a specific job to do with the tool afterwards, not the number of hours delivered.
Who should be trained first?
The people whose work is most text-heavy and most repetitive, and at least one person in each team who is naturally curious about tools. The second group matters more than it looks: they become the person colleagues ask, which is where most of the real learning happens in a company this size. Training the leadership team first is a common and expensive inversion — it produces sponsorship without practice.
Should we build our own training or buy a course?
Buy the generic foundations if you want them, but the part that changes behavior has to be built on your own material — your documents, your clients, your tone. Generic courses teach the tool; the gap in most companies is knowing which of their own tasks the tool suits. A short internal session on real work usually outperforms a long external one, and costs less.
How do we know the training worked?
Not from satisfaction scores — across LYVIA's own sessions they come back high almost regardless of content, a pattern from client work rather than a published study, and they predict nothing. Look instead at whether the tool is still in weekly use after a month or two, whether people can point to a task they now do differently, and whether the questions being asked have become more specific. A sharp drop in usage after the first weeks usually indicates a missing job to apply the skill to rather than a training gap.
What about people who do not want to use it?
Distinguish between refusal and unmet concern, because they need opposite responses. Concern about job security or about being judged on output quality is answered by being explicit about what changes and what does not. Genuine disinterest in a tool that is optional for their role is a legitimate position. Mandating usage produces compliance metrics and no change in the work, which is worse than a smaller group using it well.
If your team has the tools and is not using them, the missing piece is usually a job to apply them to rather than more training. That is a short diagnosis. Book a call.
