How many hours does Copilot training take, and how do you split them_

What does the number of hours depend on?

On four things, and headcount is not one of them.

▸ What you want people to do straight after the course. «Write better email» and «change how we put proposals together» do not fit in the same number of hours.

▸ How many different roles sit in the room. A group of salespeople moves faster than a group that mixes finance, operations and sales, because every example lands with everyone.

▸ Whether a written usage rule already exists. If it doesn’t, part of the hours goes into drafting one together, and that time pays for itself.

▸ Whether real company documents can come into the room. When they can, the same hour is worth twice as much: people work on your proposal rather than an invented one.

Headcount only matters above twenty or so, and not for the hours. It matters because someone needs to help during the exercises.

16 hours in four sessions: what’s in them?

This is the programme I run with most teams, and every session produces something written.

▸ How a tool like Copilot actually works: what it sees of your data, why it sometimes makes things up, where the limits are. This session produces a shared vocabulary, which removes both the fear and the wrong expectations.

▸ The anatomy of a request and the context around it: how to give the tool the right material. This session produces the first saved prompts, on the tasks people repeat every day.

▸ AI inside your own job, on real files: everyone works on their own documents while I move between the tables. This session produces a small set of examples the group can reuse.

▸ Security, privacy and usage rules: what goes in, what doesn’t, what gets checked before anything leaves the building. This session produces the draft of the internal usage rule.

Four sessions of four hours, or eight of two when people can’t step away for half a day. The difference between those two shapes is small. The gap between sessions is what matters.

Full immersion or spaced sessions?

Two full days are easier to schedule and deliver less. By the afternoon of the second day attention is gone, and the part that makes training stick is missing: time to try.

With a week or two between sessions, people come back with their own questions. «I tried it on the minutes and it comes out too long.» «It doesn’t work on my spreadsheet the way it did in the session.» Those questions are the material for the next session, and from that point the course belongs to them.

The risk on the other side is the gap that breaks the thread. Three weeks and the group has cooled off. One or two weeks holds, and it helps to fix every date before the first session.

Going above 24 hours makes sense when the goal is to rebuild a whole workflow, the proposal cycle for example. At that point it is no longer only training, and it is fair to call it something else.

Who do you start with: managers or heavy users?

If managers have to bring AI to their teams, start with them: a manager who doesn’t know what to ask for blocks their team without noticing, and the internal usage rule needs their signature.

If the goal is the workflows, start with a mixed group: two or three people per department, the ones who are in the tools all day. They are also the people colleagues ask for help, so it pays for them to have been in the room.

The pattern I see go wrong is starting with one isolated department, usually marketing, and stopping there. Three months later that team works in a new way and everyone else doesn’t, and every handover turns into a negotiation.

With technical teams, add one thing: an hour on where the tool breaks. Skip it and they will find out on their own, in the worst way, in front of a client.

What if the licences have been there for months and nobody uses them?

This is the situation I find most often, and nobody is to blame for it. The licences arrived without anyone saying what they were for, so people did what people do and worked around it. Some use a personal tool on their phone, some gave up after two attempts.

You start there, and the first half hour goes into hearing it: what you tried, what didn’t work, what you use now. It has to be done without turning it into an inquiry, or nobody says anything and the course starts blind.

What comes out of that half hour is useful material. If half the office drafts email in another tool, that is a habit to build on, and a security question to put on the table.

These groups usually need one session less, not one more. They have already tried things, and what they are missing is a method and permission. The permission is the written usage rule, which is why it belongs inside the course.

What should be left after the 16 hours?

Three written things that someone can open the next morning.

▸ The group’s saved prompts, organised by task rather than by person, somewhere new ones can be added.

▸ The draft usage rule: what can go in, what can’t, what gets read again before it goes to a client, who decides in unclear cases.

▸ A plan for the first weeks: who tries what, and when you meet again to see how it went.

On measurement, the end-of-session survey tells you whether people enjoyed it, which is partial information. What you want is a second pass a month later, half an hour with the team leads: how many use it in a given week, on which tasks, where it jammed.

If usage is flat after a month, the problem is rarely the hours in the room. Usually permission is missing, or nobody owns keeping it alive.