Licenses went out. Training happened. Six months later, usage is back where it started. Here's what actually stalls a rollout, and the 30-day plan that restarts it.
Say a rollout owner opens the Copilot usage report six months after go-live. Licenses: 1,200, assigned back in March. Active users this week: a few hundred, mostly the same people who showed up to the first training session. Everyone else quietly went back to typing the email themselves. Nobody announced they’d stopped. They just did.
This is the moment almost every leadership team eventually reaches, whether the rollout covered 50 seats or 5,000: the launch went fine, the training scored well, and six months later the usage graph looks almost exactly like it did in week one, a spike, then a slow settle back toward flat. The question that follows is always some version of the same thing. Did we buy the wrong tool, or did we roll it out wrong?
Honestly, it’s rarely the tool. Gartner’s own research on generative AI projects found that at least half of them were abandoned after the proof-of-concept stage by the end of 2025, and the reasons it names most often, unclear business value and weak change management, are organizational, not technical.[1] That figure covers generative AI projects broadly, not Copilot rollouts specifically, so treat it as evidence of the shape of the problem rather than a Copilot-specific number. Still, the shape matches what shows up in stalled Copilot rollouts constantly: a tool that clearly works, sitting mostly unused six months later. This isn’t about redesigning the training itself either, that’s the territory our guide to why most Copilot rollouts stumble at the training stage already covers. This is about what to do once a rollout that already launched has gone quiet.
Worth saying plainly before going further: a stalled rollout is closer to the default outcome of doing nothing differently after launch than a rare failure. Treating it that way, as a normal, fixable stage rather than a verdict on the tool or the team, changes how the next month actually gets spent.
The instinct when usage drops is to look at the tool again. More features, a better onboarding video, a refreshed cheat sheet. None of that is wrong exactly, it’s just aimed at the wrong layer of the problem. Six months in, Copilot is rarely struggling because it can’t do the work. What’s missing is that using it never became the automatic move for any specific, recurring task.
Think about how any other habit actually forms. Nobody adopts a gym routine because the equipment is good. They adopt it because a specific action got attached to a specific moment: shoes by the door, gym bag in the car, same time every Tuesday. Copilot adoption works the same way, and most rollouts skip that step entirely. They teach the tool in the abstract, here’s what Copilot can do, and leave it to each employee to figure out where, exactly, it fits into a Tuesday that’s already full.
A few signs the actual problem is workflow fit, not the technology itself:
Training builds the capability to use Copilot. What’s usually missing after that is workflow design, a specific recurring task to attach it to, and reinforcement, something that turns a one-time try into an actual habit. Skip either one and training doesn’t turn into adoption on its own, no matter how good the session was.
Strip away the specifics and most stalled rollouts trace back to a small number of repeatable causes. None of them are exotic, and most leadership teams can spot their own rollout somewhere on this list without much digging.
| What it looks like | The real cause | What doesn’t fix it |
|---|---|---|
| Usage spiked at launch, then flattened within a month | Curiosity, not habit. Nothing recurring anchored the tool to a task. | A reminder email. It works for a day. |
| A few power users, everyone else silent | Training was generic, not role-specific. Only people who could self-translate “what Copilot can do” into “what I do on Tuesdays” stuck with it. | Another all-hands demo. They already saw the first one. |
| Managers never mention it | Nobody senior visibly uses it, so it reads as optional. | A memo saying it’s a priority. Words don’t model behavior. |
| Nobody can say if it’s working | The only number being tracked is licenses, which never drops even when usage does. | Buying more licenses. That makes the wrong number bigger. |
Built from how these rollouts typically play out in practice, not a scored diagnostic. Treat it as a starting point for figuring out which cause is closest to yours, not an exhaustive list.
A fifth cause worth naming separately, because it’s less visible on any dashboard: unclear ownership. Plenty of rollouts launch with an executive sponsor and no single person actually responsible for what happens after go-live. When usage drops, nobody’s job is to notice, so nobody does until someone asks about it in a budget meeting six months later.
The pattern worth sitting with is that every one of these causes, the four in the table and the ownership gap, is about people and process, not product. That matters because it changes what’s worth spending the next month fixing. More Copilot training rarely helps a rollout stuck at any of these four points. Different training, aimed at the actual cause, sometimes does, and our guide to the five mistakes almost every Copilot training makes is the right next stop if the cause you’ve landed on is specifically about how the original session was designed.
Microsoft ran into this exact pattern in its own sales organization, more than 60,000 employees deep into a Copilot rollout where early curiosity didn’t turn into lasting behavior change. What eventually moved the number wasn’t a new feature. It was five specific, unglamorous changes, documented afterward in Microsoft’s own internal write-up of the rollout.[2]
The first was leadership modeling: hesitation dropped once people watched their own managers actually use the tool, not just endorse it in an email. The second was peer networks over top-down messaging, early adopters running informal workshops built more trust than another company-wide announcement. The third was role-based training tied to specific responsibilities, drafting an account plan, summarizing a call, rather than generic “here’s what Copilot can do” sessions. The fourth was habit formation, small, repeatable actions built into a workflow that already existed, not a new one invented for the rollout. The fifth was combining usage numbers with actual listening, surveys and direct feedback caught friction the dashboard alone missed. Chief AI Transformation Officer Pam Maynard put the leadership piece bluntly: “In the era of AI, ‘do as I say, not as I do’ won’t cut it.”[2]
Adoption is a habit that has to survive week three, not a single training event.
Worth naming for whom this actually differs, because “employees” isn’t one group. A frontline manager needs Copilot attached to something that happens every day, meeting notes, a status update, a first-draft email. An individual contributor in a specialist role, finance, legal, engineering, needs it attached to a task specific enough that the output is genuinely useful without heavy editing. And the person actually running the rollout, usually someone in IT or a change function, needs a different kind of attention entirely: not more features to demo, but a short list of which teams have stalled and why, updated monthly rather than reviewed once at launch and forgotten.
Peer proof moves people that a company-wide announcement never does.
Measuring whether any of this actually worked means going past a login count. The stronger lens has three stages: use, are people doing it at all; persistence, are they still doing it a month later without a reminder; and impact, is the actual work, the draft, the summary, the plan, measurably better or faster because of it. A rollout that only ever tracks usage has measured access, not adoption.
| Stage | The question | Where a raw usage number falls short |
|---|---|---|
| Use | Did people try it on a real task this week? | Enabled and active are different things. A license alone tells you nothing. |
| Persistence | Are they still doing it a month later, without a reminder? | A one-week spike after launch looks identical to real adoption on a dashboard. |
| Impact | Is the actual output better or faster because of it? | Prompt counts say nothing about whether the output was any good. |
Adapted from Future Factors’ standard adoption lens to a rollout specifically. Microsoft’s own Copilot usage report tracks an “Active Users Rate,” enabled users who took an intentional action inside an app, which is a real improvement on raw license counts but still only covers the first stage.[3]
Don’t grade a rollout on logins. Grade it on whether the habit survived a month with no reminder.
None of the fixes above require re-running the original rollout. They require a focused month aimed at the specific cause identified in the diagnostic table above, not a repeat of the launch. Before starting, it’s worth checking the original rollout plan against our AI adoption checklist to see what was skipped the first time around.
Pull the real usage data, not license counts, and name the specific cause from the diagnostic table above. Line up three managers willing to visibly use Copilot on their own real work this month, not just approve the rollout.
Recruit five to eight peer champions from teams with the highest natural interest, not the org chart. Give each one real task to demo to their own team, not a slide deck.
Replace one generic training session with a role-specific one for the team furthest behind. Anchor it to a single recurring task that team already does every week.
Check use, persistence, and impact for the teams touched this month, not the whole rollout. Send a short survey alongside the usage numbers, not instead of them. Decide what gets repeated for the next team next month.
A restart, not a relaunch: four weeks aimed at the specific stall point, not another version of the training everyone already sat through.
A restart is worth running when a few things are true:
One thing worth being direct about: none of this works as a one-time fix. A rollout that gets a good 30 days and then reverts to silence from leadership and no measurement will drift right back to where it started. The teams that keep the gains treat this as a monthly rhythm, checking a handful of teams’ use, persistence, and impact every month, not a single sprint reviewed once and filed away.
Structured training still has a real place here, and it’s worth saying plainly. Role-specific training from someone who’s run this pattern before shortens the month above considerably, and it builds shared capability across a whole team rather than depending on whichever manager happens to already be a natural champion. Training on its own was never going to be the whole fix, not because it’s the wrong move, but because a session disconnected from a specific recurring task, with nobody senior modeling the behavior afterward, fades within a week. If you’re the executive being asked to greenlight next quarter’s budget for exactly this kind of restart, our guide to the five questions executives ask about Copilot covers that conversation directly.
Because the curiosity that got them through week one doesn’t have anywhere to land. Nobody attached the tool to a specific, recurring task on their own calendar, so once the novelty fades, going back to the old way is just easier. The fix usually isn’t more training. It’s picking one task per role and making Copilot the default way that task gets done, not an optional extra sitting alongside the old habit.
Usually neither, at least not primarily. Gartner’s research on generative AI projects points to unclear business value and weak change management as the leading causes of abandonment, ahead of the underlying technology. Training is often fine on its own terms. What’s typically missing is a specific workflow to attach it to and someone senior visibly using it, which is a change-management gap, not a curriculum gap.
Use, persistence, and impact, in that order, and specifically whether the same person who tried Copilot in week one is still using it in week eight without being reminded. Persistence is the number most rollouts skip entirely, because it takes a month to know the answer and most reviews happen once, right after launch, before anyone could possibly know it yet.
A small group, roughly five to eight people per few hundred employees, drawn from wherever genuine curiosity already exists rather than assigned by org chart, who demo one real task to their own teams instead of sitting through a company-wide session. It works because peer proof lands differently than a mandate. Someone watching a colleague use a tool on real work is more convincing than any announcement from leadership.
A focused month can genuinely restart momentum for one team, using the 30-day plan above. Fixing an entire stalled rollout across many teams takes longer, usually a full quarter of repeating that same focused month for one team at a time rather than trying to relaunch everyone simultaneously, which is close to what stalled the rollout the first time.
The generative AI abandonment figure in this guide comes from Gartner’s own January 2026 article, fetched directly, and is explicitly flagged as covering generative AI projects broadly rather than Copilot rollouts specifically, since no Copilot-specific figure could be independently verified at write time. The five-lesson rollout account and the Pam Maynard quote come from Microsoft’s own Inside Track blog post about its internal sales-organization rollout, fetched directly, not a secondary summary of it. The Active Users Rate definition comes from Microsoft’s own Copilot usage report documentation.
Weekly tips. Real examples. Practical help for busy professionals.
We care about your data, check out our privacy policy.