Rolling AI Out to Your Team — Learn AI

By the end of this lesson you will be able to

Diagnose why a rollout stalled, or prevent it stalling
Run a pilot that produces evidence rather than enthusiasm
Answer the two objections that come up in every organisation

The tool works. That was never the hard part. The hard part is whether thirty people will use it consistently, safely, and for the right things — and that is a change management problem wearing a technology costume.

The failure mode, in detail

It goes like this. Access is granted. An email goes out saying everyone now has AI. Usage spikes for two weeks. Then it collapses back to the three people who were already using it on their own accounts, and everyone else quietly returns to how they worked before.

Every time, it is some combination of these five:

People do not know what to use it for in their specific role. "Use AI" is not a task.
No time was carved out to learn. Nobody experiments with a new tool during a busy week.
The sceptical and the anxious were ignored rather than answered.
Nobody is tracking whether it is working, so nobody notices when it stops.
The existing workflow was never redesigned. AI was bolted onto a process that assumes it does not exist.

The one that surprises people

Generic training is close to worthless. A session explaining what the tool can do, in the abstract, produces a fraction of the adoption that showing five concrete things a specific team can do tomorrow does. Abstract capability does not transfer into a Tuesday.

Three things to settle before anyone gets access

Name the problem you are solving
Not "adopt AI". Ask the team: what do you do repeatedly that feels like it should not take this long? Where does time go on writing, summarising, or formatting that is not really the work? Their answers are your starting list, and they are usually better than yours.
Buy the right plan
Consumer tiers are not appropriate for client data, internal financials, or HR material. If the work touches any of that, you need a business tier with a confirmed no-training policy before anyone starts, not after.
Write the policy first
Which tools are approved, what data may go in each, what needs human judgement, who reviews output before it leaves, and who to ask when unsure. One page. A twenty-page policy is the same as no policy.

Three phases over twelve weeks

Phase	Weeks	Who	What you are producing
Pilot	1–4	5–15 willing people across roles	Evidence about which use cases actually pay off
Early adopters	5–8	A wider group, guided by pilot champions	Documented use cases and tested prompts
Everyone	9–12	The organisation	Access, communication, and guardrails people have already seen

The shape that works. Compressing it is the most common mistake after skipping the policy.

Getting the pilot right

Pick people who are curious and open — not necessarily your most technical staff. A sceptical bookkeeper who becomes convinced is worth more to the rollout than an engineer who was always going to use it.

Pilot that works

Each person gets one or two specific use cases
A 30-minute demo using their own work
Weekly check-in to collect what is failing
Time saved measured on the targeted tasks

Pilot that fizzles

"Try it for whatever you like"
A generic tour of the interface
No check-ins; assume no news is good news
Nothing measured, so nothing to show

The goal of the pilot is not enthusiasm. It is three documented use cases you can hand to the next group with a straight face.

The two objections

Resistance is normal and usually reasonable. It reliably takes one of two forms, and each needs a different answer.

"It might replace my job."

Answer it directly and specifically. Vague reassurance makes it worse, because it sounds like exactly what you would say if the answer were yes. Name what AI is taking off their plate and what it is not touching — the judgement, the relationships, the context nobody wrote down.

"I am worried I will do something wrong."

Usually the bigger blocker, and much easier to solve. Make the policy simple and explicit, and say plainly that a mistake made while following the guidance is an organisational problem, not a personal one. People experiment when the downside is clear and survivable.

Training that survives contact with a Tuesday

Role-specific examples. Show sales how to prep for a call. Show finance how to write a variance narrative. Not "here is how the tool works".
Hands-on during the session, on a real task. Not a demo — practice. Everyone leaves having produced one thing that worked.
Start embarrassingly simple. The first goal is that everyone succeeds once, at something real.
Normalise iteration out loud. The first output is usually not right, and people who do not know that conclude the tool is bad.

What to watch at 30, 60, and 90 days

Weekly active use as a share of intended users — the single best early warning.
Time on the specific tasks you targeted, against your pre-launch baseline.
Output quality: are the drafts as good or better than before?
Whether people say it helps or say it is one more thing to do.

If usage is not sticking

It is almost always fixable, and the reason is almost never the technology. Ask the people who stopped. Nine times in ten the answer is that they did not know what to use it for in their job — which is a training problem with a cheap fix.

Can we compress this into a month?

You can, and the usual result is the two-week spike. The twelve weeks are not about the software; they are about the pilot producing real evidence before you ask the sceptics to change how they work. Skipping to organisation-wide is the most common rollout mistake.

Should we mandate it?

Mandate the policy, not the usage. Compliance with a tool people resent produces box-ticking. Adoption follows visible time saved and a colleague they trust showing them how — which is what the champions in phase two are for.

What if leadership wants it everywhere immediately?

Offer the pilot as the fastest route to the thing they actually want, which is evidence. Four weeks of measured results from fifteen people is a far stronger case for expansion than a company-wide launch nobody can evaluate.

Key takeaways

Rollouts fail on people and process, not technology. Budget your attention accordingly.
Settle the problem, the plan, and the one-page policy before anyone gets access.
Pilot with 5–15 willing people and one or two specific use cases each.
Answer both objections directly — the "I will do something wrong" one is the bigger blocker.
Role-specific, hands-on training. Generic sessions produce generic results.
Track weekly active use at 30, 60, and 90 days. If it slips, ask the people who stopped.