Team Briefing

What a team briefing is

A team briefing is a one-hour meeting about a week before AI training, run by the manager rather than the trainer. It names the tasks in scope, asks each person to bring one real example and says what is not allowed near the tools.

The site’s briefing article calls it the first thing put in a client’s calendar before any training session runs. Its claim is a plain one: the difference between a session that changes how people work and one that does not is set a week before anyone opens a laptop.

This page uses that meaning. It does not teach you to run a training session. It explains what the briefing is, what it covers, who should give it, and why it is the cheapest part of the whole programme. It is also easy to confuse with other briefings, so the page ends by separating them.

Why brief the team before AI Training

People arrive at AI training with nothing to try it on, and the briefing article says that is a decision somebody made by not making it. Skip the briefing and a training day defaults to generic examples nobody in the room needed. The article calls this the single biggest reason a training budget produces enthusiasm on the day and nothing measurable a month later.

The article explains the difference between a session that works and one that goes flat. A session works when somebody in it has a task they already resent. They know how long it takes, they know what a right answer looks like, and they can tell within a minute whether the tool did anything. Nobody has to invent a brief for them, and inventing the brief is the hard part.

A session goes flat when the room is full of people who were told to attend. They have no task in mind, so the trainer supplies one, and a supplied example is always easier than real work. Everybody leaves having watched something succeed on a problem they do not have.

The ChatGPT for small businesses article makes a related point about introducing any tool. A team that gets a short briefing, a few shared prompts and a rule about data tends to find real savings in drafting and summarising, while a team left to work it out alone tends to get uneven results, with a few enthusiasts doing well and the rest abandoning it.

The what makes AI trainings stick article reaches the same place from the evidence. Its first principle for durable training is to make it relevant. The briefing is how relevance gets into the room before the day.

Who should run the briefing

The manager, not the trainer. The briefing article says a trainer explaining what training will cover is a sales pitch. A manager saying which parts of their team’s own work are in scope is an instruction, and people prepare differently for the two.

The manager does not need to understand AI. The article says the manager is not explaining how the tools work, only naming which parts of the team’s existing work are in scope and asking people to bring a real example. Both require knowing the team’s work, not knowing the technology, so a manager who has never used the tools can still run it well.

The article also says a call is enough. It does not need a room or a presentation.

What the hour has to cover

The article names three things, and the rest of the hour is those three, taken in turn: which parts of this team’s work are in scope, an instruction to bring one real example each, and what is not allowed near the tools.

It keeps the briefing to an hour and puts it about a week before training. A week is long enough for people to notice the tasks they want to bring and short enough that they have not forgotten the briefing happened. A day before is too late to change what anyone brings.

Why name tasks, not Tools

The article is clear about how to name the scope. Name it as tasks, not tools. “You can use AI for the client update” is something a person can act on in the next week. “You now have access to an AI assistant” is not, because it names a capability and not a task, and a capability with no task attached is exactly what produces a room full of people with nothing to bring.

The method is to go round the team and ask each person which one thing on their plate this week is worth trying it on, and write the answers down. Six named tasks from a team of eight is a good briefing. Zero is the result worth knowing about before the training is booked.

Why ask for a Real Document

The instruction has to be concrete. The article says to ask for the real document, not a description of it. “Bring your worst client email” produces the email. “Think about a task this might apply to” produces nothing, because thinking about it later is exactly what does not happen once the meeting ends.

It should be concrete enough that someone can act on it that afternoon: export the spreadsheet, save the transcript, print the contract clause. A task without the actual document attached is a task that gets forgotten by the time training starts. A real document also gives the trainer something to write a real prompt around, instead of an invented one.

What to say is out of bounds

Say what is out of bounds, even though nobody has asked yet. The article’s examples are client data and anything covered by data protection rules, anything under an NDA, and anything that would need sign-off before it left the building.

The reason is practical. If it is not said in the briefing, it gets decided informally in the training room, by whoever is loudest, and a vague answer in that moment gets remembered as permission long after the meeting is forgotten. The article says that is how shadow AI starts. It adds that this is a one-sentence addition to the briefing, and cheaper to say once here than to correct once it has already happened.

If the organisation already has an AI governance policy or an AI tool inventory, the article says to say where each lives and who to ask, and to say that a human in the loop signs off anything that reaches a client. The AI governance page covers what a policy is for, and the AI use policy article covers how to write one.

What if the team cannot name a task

That is a result, not a failure. The article says anyone who cannot name a task to bring is telling you something useful before the money is spent, and that if a team cannot come up with six tasks between them, it may need a grounding in AI literacy before anything more specific.

It is also a reason to stop and look at the team’s work before booking anything. The briefing costs one meeting. Finding out on the day of the training that nobody had a task costs the whole day.

Does it matter for a Core Course or a Bespoke Programme

The briefing is the same hour in both cases. The article says that whether you are running a core AI course, a bespoke programme built from your own processes, or picking something from the full catalogue, the briefing is the same hour and the cheapest part of the whole thing.

It matters more for bespoke work. A core course arrives with its own examples if a team turns up empty-handed. A bespoke programme is built from what a team brings, so a session run without a briefing has nothing of its own to build from, and the trainer ends up improvising a generic session anyway, at bespoke cost.

How it fits a 30-day Training plan

The site’s 30-day training plan article describes a related but shorter briefing. Before the first session, it says to brief the team in person for fifteen minutes: say what the 30 days are for, what is expected each week, and that nobody is being tested or replaced.

That is a different meeting from the one-hour briefing above, with a different aim. The hour names tasks and collects real documents. The fifteen minutes sets expectations for a month. The two can sit side by side, and the plan article itself points readers to the briefing article before they send the calendar invitation.

The plan then runs in weeks. The first week covers the rules and first tasks, with one real task done and kept, and the article’s principle throughout is to train on each person’s own work. The upskilling page covers the longer view, and the AI adoption page covers what happens when a team has been trained but nothing sticks.

The AI use policy article adds a third, shorter form. It says to brief people in person: fifteen minutes in a team meeting with two real examples does more than a signed form.

A worked example

An illustration, not a case study. A manager has a team of eight and a training session booked for the following week.

The manager sets aside an hour, by call. They explain that they, not the trainer, are deciding which parts of the team’s work are in scope. They go round the team and ask each person for one thing on their plate this week that is worth trying AI on, and write the answers down. Six people name a task. One names a client update that takes too long. Another names a weekly report. Two say they cannot think of one.

The manager asks each person to bring the real document: the client update, the spreadsheet behind the report. They say what is out of bounds: client data, anything under an NDA, anything that would need sign-off before it leaves the building. They say where the AI policy and the list of approved tools live and who to ask, and that a person signs off anything that reaches a client.

The two who could not name a task are not a problem. The manager notes it, and talks to them afterwards about what they do in a week. The training is built on six real documents, not on examples invented for the day.

Mix-ups worth avoiding

Four confusions come up often enough to name. The first is treating it as the trainer’s introduction, when the article says a trainer explaining the training is a sales pitch and the manager’s version is an instruction. The second is naming tools instead of tasks, which gives people a capability with nothing to do with it. The third is leaving out what is out of bounds, so it is decided in the training room. The fourth is confusing it with other briefings: the AI brief is how you instruct an AI tool, and the leadership briefing that the set courses against bespoke review puts first in bespoke work is a different meeting, for leaders, with a different job.

How we use it

The briefing article says it is the first thing put in a client’s calendar before a single training session runs. The task and decision article points to the briefing as what a team needs before its steps are sorted onto the delegation ladder.

If you would like to talk through what your own briefing needs to cover before anything else is booked, a discovery call is a quick way to start.

Sources

• How to brief a team on AI before you train them: the hour, the week before, the manager and not the trainer, tasks not tools, the real document, what is out of bounds, the zero-tasks result, and why it matters more for bespoke work.
• The difference between automating a task and automating a decision: the briefing as what a team needs before its steps are sorted onto the ladder.
• How to train your team to use AI: the fifteen-minute briefing before a 30-day plan, the baseline, the first week and training on each person’s own work.
• How to write an AI use policy for your team: briefing people in person with two real examples, and a policy and a short briefing as practical evidence of AI literacy.
• What makes AI trainings stick: making training relevant to the work.
• Set courses vs bespoke training: the leadership briefing that comes first in bespoke work.
• ChatGPT for small businesses: a team with a short briefing, shared prompts and a rule about data finding real savings.
• Core AI course, Bespoke in-house training, AI literacy, Shadow AI, Delegation ladder, Upskilling, AI adoption, AI governance and AI brief: the neighbouring terms this page links to.