Most rollouts do the announcement, the licences and the training session, then go quiet. The quiet part is where adoption is decided.
A rollout usually gets three things right and one thing wrong. The licences arrive, the announcement goes out, a training session happens, and then nothing else does. Enablement is the everything-else: quick-start materials written for one specific team, realistic examples of their own recurring work, a channel where questions get answered by a person, and champions who are chosen because people already ask them things. This guide covers what belongs in the kit, why the champions model works better than one big session, what support should look like at week one versus week six, and how to measure adoption in a way that counts more than logins.
Say you’re a benefits coordinator in an HR team of nine. Tuesday morning, there’s an all-hands, and the message is that everyone now has an AI assistant. Licences are live. There’s a link. Someone from IT says the words “responsible use.” You go back to your desk, open it, and type the truest thing you can think of: “help me with benefits enrolment.”
What comes back is a competent, generic explanation of how benefits enrolment works in general. Nothing about your plan year, your carrier, the spreadsheet you actually maintain, or the fourteen emails you’ll answer this week about dependants. You close the tab. Nothing was broken. The tool did roughly what you asked. You just had nothing useful to ask it yet.
That gap is the whole subject of this article. The rollout did the visible parts, and the visible parts are the easy ones.
Enablement is the set of things that sit in the space after the announcement. It is not training, though training is part of it. Training builds capability, meaning someone could now do the thing in principle. Enablement is what gives that capability somewhere to land: a specific recurring task, a worked example of it, and someone to ask when the first attempt comes back wrong.
Ship the examples before you ship the announcement.
The order matters more than it sounds. If the examples arrive first, the announcement is an answer to something. If the announcement arrives first, everyone has a week of open-ended access with nothing to point it at, and that week teaches them the tool is vaguely interesting and not for them.
Something worth noticing in the Microsoft data: among the most advanced AI users, 63% say their team gets together to work through which business processes AI could actually improve. Among everyone else, that number is 32%.[1] The advanced group is not doing something exotic. They are having a meeting about their own work.
This piece covers the end-user side specifically. If you need the full planning sequence before you roll anything out, that’s the AI adoption checklist. If your problem is that IT, legal or a sceptical director can stall the whole thing, that’s a different conversation and it needs its own preparation.
The word “kit” makes this sound bigger than it is. Four things, and you can build all of them in a couple of afternoons if you know the receiving team’s work well enough. If you don’t know their work well enough, that’s the real finding, and no amount of material will fix it.
Here’s what belongs in it, filled in for a finance team rather than left as blanks, because a blank template teaches you nothing about the level of detail that makes it work.
| Component | What it actually is | What goes wrong when it’s missing |
|---|---|---|
| One-page quick start | Half a page on getting in and what it can see (your files? your email? nothing?), half a page on the three things this team should try first. One page. Not a 24-slide deck. | People never find out what data it can and cannot reach, so they either overshare or assume it knows nothing and treat it as a search box. |
| Five use-case examples from their work | “Draft the month-end variance commentary from the exported P&L and last month’s version.” Not “summarise documents.” The actual task, named the way the team names it. | Everyone starts from a blank box. The blank box is where good tools go to die. |
| A named place to ask | One channel, named, with two or three people who have agreed to watch it. Not a shared mailbox nobody owns. Not “raise a ticket.” | First bad output goes unexplained, and one person’s private conclusion (“it makes things up”) becomes the team’s position within a fortnight. |
| A written line on what it must never touch | “Do not paste anything with a customer’s name, bank details or a live legal matter in it.” Four categories, in plain words, on the same page as everything else. | Either people quietly avoid it entirely, or somebody pastes something they shouldn’t and the whole rollout gets paused. |
The four components of a minimum enablement kit, with a finance team’s version filled in. Written from Future Factors’ workshop practice, not from a published model.
Before that, one thing worth deciding while you’re writing the examples: who the kit is actually for. “The team” is too broad to be useful, and the five examples change completely depending on the answer.
The two rows that get left blank, in the kits we help teams build, are the last two. The quick start and the examples feel like the deliverable, so they get made. The question channel and the never-touch list feel like admin, so they get postponed, and then the rollout runs into exactly the two problems they would have prevented.
On the examples: five is the number because one looks like a fluke and ten looks like homework. And they have to be recognisably the team’s own tasks. A marketing team’s five and a finance team’s five should share nothing except the format. If you find yourself writing the same five for both, you’ve written the vendor’s examples with new nouns.
The other thing worth putting in the kit, and the thing that gets skipped most often, is an explicit line on who owns what. Not a policy. A table, per use case, that says what the tool prepares and what the person is still answerable for.
| What AI does | What the person still owns | How it gets checked |
|---|---|---|
| Drafts the first pass of the monthly variance commentary from the exported ledger | Why the variance happened, which lives in conversations the model was not in | Every figure traced back to the export before it leaves the team. Every month, no exceptions. |
| Groups 200 open-text engagement survey comments into themes with example quotes | Which themes are signal and which are four loud people, and what the team does about it | Read 20 raw comments yourself first, then compare against the themes it produced. |
| Turns a 40-page policy document into a plain-English summary for a manager briefing | Anything the manager will be quoted on, and every number in it | Two claims picked at random get checked against the source document. Not the ones that look wrong. Two at random. |
A worked example of the ownership split for three common use cases. Add one row per use case in your own kit, before the first run rather than after something goes wrong.
People often read that table as a governance exercise. It isn’t, or not mainly. It’s the fastest way to make a nervous team comfortable, because it answers the question they’re actually holding, which is whether using this thing puts them personally at risk of being wrong in front of someone senior.
One session, everyone in a room, one hour, all questions answered. It’s efficient on paper. And it front-loads all the support into the moment people have the fewest questions, because they haven’t tried anything yet.
The questions arrive later, one at a time, in the middle of real work. Someone gets an output that’s confidently wrong and doesn’t know whether that’s normal. Someone can’t work out why it won’t read the file. Someone wants to know if it’s alright to paste the thing they’re about to paste. None of those happen in the hour you booked.
Champions work because they’re available at the moment of the question rather than the moment of the launch. The mistake is in how they get picked.
Pick the person people already ask, not the person who volunteers.
Those are usually different people. The volunteer is enthusiastic about AI. The person people already ask is the payroll analyst two desks over who worked out how to make the reconciliation stop taking all of Thursday, and who has never once described herself as technical. The second one has social permission that the first one has to earn.
Manager behaviour compounds this. A separate Microsoft study of 1,800 workers found that when managers visibly used AI themselves, the people around them scored 17 points higher on reported value from it.[2] Worth reading that as one signal rather than a law: it’s self-reported, at a single moment, and people who like their manager tend to score most things higher. Directionally it matches what we see in workshops, where the team whose manager has never opened the tool asks noticeably fewer questions.
A champion is only useful if the role is actually defined. “Be a champion” produces nothing. Here’s the version that produces something, written as one person’s remit rather than a job spec.
| Field | Priya, Finance Operations |
|---|---|
| Who she covers | The nine people in finance ops. Not the whole department, not other functions. |
| Time it costs her | Two hours a week for the first six weeks, agreed with her manager in writing, then reviewed. |
| What she actually does | Watches the questions channel. Runs a 20-minute drop-in every Wednesday. Keeps a running note of what people got stuck on. |
| What she is not | Not IT support, not the approver for anything, not accountable for whether the team adopts it. |
| What she gets | Her name on the kit, early access to whatever comes next, and it counts in her development conversation. Say what the recognition is or it isn’t recognition. |
| When it ends | Week twelve, with a decision either way. An open-ended volunteer role quietly becomes an unpaid second job. |
A filled-in champion remit. The two fields teams skip are the time cost and the end date, which are the two that decide whether anyone says yes the second time you ask.
Ratio, roughly: one champion per eight to twelve people, and at least one per function. That’s a rule of thumb from running these, not a researched number. Below about eight the role has too little to do to feel real. Above about fifteen the questions outpace the two hours.
And champions are not a substitute for teaching people properly. They’re the layer that keeps capability alive between sessions. Teams can absolutely build this internally, and plenty do. What structured training buys is speed and coverage: someone who has watched a hundred teams pick their first workflow will stop yours picking a bad one, and a team taught together ends up with shared standards instead of one confident person and eleven onlookers. That second part is the genuinely hard bit to do alone.
Our framework for what makes someone AI-powered is a multiplication: Tool x Workflows x Behavior. It’s explained properly in the piece on what makes an AI-powered professional different, so I won’t rebuild it here. What’s worth saying in an enablement context is narrower.
A rollout only ever ships the first variable. Licences, access, a login. That’s Tool, and it’s the part organisations are good at, because it has a budget line and a completion date.
The other two don’t arrive on their own. Workflows means somebody worked out which recurring task this belongs to, which is exactly what the five use-case examples are for. Behavior means somebody kept doing it into week six when it was still slower than the old way, which is what the champion and the questions channel are for.
So enablement isn’t a supporting activity around the rollout. It’s the only mechanism that produces the two variables the rollout doesn’t.
Which also explains a pattern that otherwise looks strange: organisations that spend heavily on licences and nothing on enablement often end up with worse outcomes than teams who got a cheaper tool and two afternoons of proper setup. Not because the licences were wasted, but because one strong variable and two weak ones is roughly where you started.
Support curves and question curves point in opposite directions. Support is at its highest in week one, when there are almost no questions, and at its lowest by week six, when the real ones arrive.
Week six is where I’d concentrate, and I want to be careful about how strongly I put that. It isn’t a researched number. It’s where we see teams land in the programmes we run: novelty has worn off, the tool is still slower than the old way for at least one task, nobody is watching, and the honest choice between carrying on and quietly stopping gets made.
Put your best support in week six, not week one.
Here’s what the shape looks like when it’s planned rather than improvised. Twelve weeks, one team, deliberately front-light and middle-heavy.
Kit goes out. Quick start, five examples, ownership table, the never-touch list. Channel opens with a champion already posting in it, so it isn’t an empty room.
Short drop-in sessions, 20 minutes, optional. Expect low attendance and don’t read anything into it. The job here is to make the channel visibly alive.
Champions start collecting what people got stuck on. Add the two most common stumbles to the quick start as a second page. The kit should change in month one or it wasn’t built from real use.
The heavy part. A working session per team on one real recurring task, start to finish, with their actual files. This is the week that decides the rollout, and it is the week most plans have nothing scheduled.
Drop back to the channel plus a monthly 30 minutes. Champion role reviewed and either renewed or closed with thanks. First honest look at whether anything stuck.
A worked twelve-week shape for one team, not a methodology. The specific weeks matter less than the weighting: light at launch, heavy in the middle.
Two things to protect in that plan. The week five to seven working session is the one that gets cut when calendars get tight, and it’s the one doing most of the work. And the kit has to actually change in the first month. A quick start that reads identically in week eight to how it read in week zero is a document nobody used.
One more, smaller thing: answer the bad-output questions in public, in the channel, with the reasoning. “It gave me the wrong headcount” answered privately teaches one person. Answered in the channel with why it happened and what to check next time, it teaches nine, and it’s the single cheapest quality-control mechanism you have.
Licence dashboards are seductive. They produce a number, the number goes up, and the number is almost entirely about access rather than adoption. Ninety percent of your team logging in once tells you the rollout email worked.
We look at three things, in order, and only the last one settles anything.
Here’s how to check each one without building anything. All three questions can be answered in a fortnight by asking five people and looking at two artefacts.
| Stage | What you check | What a weak answer tells you |
|---|---|---|
| Use | Ask five people, individually, to name the task they use it for. Not “what do you use it for,” which gets you “writing.” The task. | If they answer with a category rather than a task, the use-case examples didn’t land. Rewrite those five, don’t run more training. |
| Persistence | Pick the one workflow you designed for. Is it in this month’s output? Look at the actual document, not the calendar invite. | Started and stopped means the workflow was wrong for the job, or week six had no support in it. Both are fixable and neither is a people problem. |
| Impact | Ask the person who receives the output, not the person who makes it. Has anything changed about what lands on their desk? | If the receiver can’t tell, you have a faster way of producing the same thing. That’s a real result, just a much smaller one than the business case assumed. |
A two-week adoption check that needs no dashboard. Use, persistence and impact is Future Factors’ standard measurement lens across all our adoption work.
The Microsoft data has one number worth sitting with here. Even among the most advanced AI users, only 26% say their team has documented, repeatable handoffs and quality standards for AI-assisted work. Among everyone else it’s 19%.[1] So the group that’s furthest ahead is mostly not writing any of this down either. Nobody has this solved. If your enablement kit exists at all and gets updated once, you’re doing better than most.
If you’d rather not build the kit from a blank page, that’s roughly what our corporate workshops produce: one real recurring workflow per person, designed in the room, with the ownership split written down before anyone leaves.
Either way, the first move is small. Pick one team. Write their five examples, using tasks you could name out loud to their manager. Send those before you send anything else.
It’s everything that sits around the tool after the licences arrive: quick-start materials written for one specific team, worked examples of that team’s own recurring tasks, a named channel where questions get answered by a person, and champions who are available at the moment the question actually comes up. The useful distinction is against training. Training builds capability, meaning someone could do the thing in principle. Enablement gives that capability somewhere to land and enough support to survive the weeks when the new way is still slower than the old one. A rollout that does training and skips enablement produces a room full of people who can, in theory, and a month later mostly don’t.
One page, and resist the pull to make it four. Half a page on access and scope, meaning how to get in and what the tool can actually see: your files, your calendar, your email, or nothing at all. That scope question is the one people most often guess wrong about in both directions. The other half is the three things this particular team should try first, named as tasks rather than capabilities. Add a short, plain-English line on what must never be pasted into it, with the categories spelled out rather than a link to a policy. The test of a quick start is whether someone can get a useful result from it in ten minutes without asking anyone. If it needs a walkthrough, it’s a deck pretending to be a guide.
It’s a small number of people, roughly one per eight to twelve colleagues, who watch the questions channel and hold a short weekly drop-in for the first six weeks or so. Whether you need one depends on team size rather than enthusiasm. Below about twenty people, one well-supported person usually covers it. Above that, questions arrive faster than any single person can answer them while doing their actual job. The part that decides whether it works isn’t the network, it’s the remit: how many hours, agreed with whose manager, ending on what date. An open-ended champion role with no time allocation and no end date turns into an unpaid second job, and the person who took it on out of goodwill quietly stops answering around week five.
Around twelve weeks for a first rollout, weighted deliberately towards the middle rather than the launch. Week one has the most support scheduled and the fewest real questions, because nobody has tried anything yet. Weeks five to seven are the opposite: the novelty has gone, the new way is often still slower than the old way for at least one task, and there’s usually nothing in the calendar. That’s the window we’d protect. This is a pattern from our own programmes rather than a researched figure, so treat the specific weeks loosely. The principle holds regardless of the exact numbers: support that tapers from launch is pointing away from where the questions are.
Three stages, in order. Use: can five people, asked individually, name the specific task they use it for? An answer like “writing” or “research” means the examples didn’t land. Persistence: is the workflow you designed for visible in this month’s actual output, a month after anyone last mentioned it? Impact: ask whoever receives the work, not whoever produces it, whether anything has changed about what arrives on their desk. Logins and active-user counts only ever answer the first stage, and weakly. They tell you the announcement email worked, which is genuinely useful information about your announcement email and almost nothing about adoption.
The two external figures in this article come from the Microsoft Work Trend Index 2026 annual report itself, read on 27 August 2026, rather than from coverage of it, and from the separate Microsoft People Science manager study that report links to. Both are self-reported survey data collected at a single moment, and the Work Trend Index says plainly in its own methodology that its analysis shows statistical association rather than causation; that caveat is repeated here rather than dropped. Where a number in this piece is our own observation from running adoption programmes rather than published research, it is labelled that way in the text: the week-six timing, the champion ratio, and the recommendation to use five examples are all judgment calls, not findings. Two further figures from the same Microsoft report would have fitted neatly and were left out. One was used in a companion article published the day before this one, and the other only confirms something the reader already believes.
Weekly tips. Real examples. Practical help for busy professionals.
We care about your data, check out our privacy policy.