“Adoption” can mean five different things inside one rollout. Here are the stages worth measuring, how Microsoft defines them, and what good looks like at each.
After a Copilot rollout, the question that tends to come up first is “What’s a good adoption rate?” The person asking usually wants a number to put on a slide. Sixty percent? Seventy-five? Eighty?
The trouble is that “Copilot adoption” can mean five different things. Having a license. Using Copilot once this month. Coming back the month after. Using it often enough that it has become part of the week. Or being able to name a recurring task where Copilot changed how the work gets done. Inside one organization, those five numbers can sit far apart.
So before I give anyone a benchmark, I ask which stage they mean. Microsoft’s own reporting has moved in the same direction. The Copilot Dashboard separates active use, returning users, usage consistency, app adoption, agent adoption and impact, and it sorts licensed users into Novice, Habitual and Power groups over a rolling 12 weeks.[2]
A Copilot adoption number means something only once it names the stage it measures.
A Future Factors framework. Microsoft reports the first four stages and an impact estimate. The workflow stage comes from asking people. In our Use, Persistence, Impact lens, stages 2 and 3 are use, stage 4 is persistence, and stage 6 is impact.
A rollout update often leads with “2,400 licenses deployed.” It sounds impressive and says almost nothing about use. A license answers one question: who has access.
Microsoft draws that line itself in the Copilot usage documentation. Enabled users are people with Copilot licenses. Active users are enabled users who tried a user-initiated Copilot feature in the selected period, and opening the Copilot pane does not count, while submitting a prompt does.[1] That gives you the first useful number: the Active Users Rate, which is active users divided by enabled users. You can view it over 7, 28, 90 or 180 days.
Say 1,000 people hold a license and 620 took a qualifying action in the last 28 days. Your active users rate is 62 out of 100. That is worth knowing, and it still doesn’t prove adoption, because someone who tried Copilot once after a training session counts as active. So the next question is who came back.
Microsoft’s Copilot Dashboard tracks returning users: people who took at least one Copilot action in both the current period and the preceding one.[2] The metric reference defines it on 28-day periods, and it also reports what share of this week’s active users used Copilot the week before.
Picture a rollout where week one after training shows 800 active users and week four shows 790. That looks steady. Then you check who those 790 are and find that a large share are different people from week one. Plenty of employees tried Copilot once, and far fewer built a habit. Active users tells you people are touching the tool. Returning users tells you whether the same people found enough value to come back.
If I were the executive sponsor, I would ask for the returning-user number by name. Retention alone doesn’t prove value. It does help separate launch curiosity from behavior that is starting to stick.
The part of Microsoft’s current reporting I would put at the center is the usage levels. The Copilot Dashboard classifies licensed users into four groups over a rolling 12-week window.[2]
| Group | Microsoft’s definition (rolling 12 weeks) | How I’d read it |
|---|---|---|
| Power | Averages 15 or more Copilot actions per week and used Copilot in at least 9 of the past 12 weeks | Heavy, regular use. Check whether it sits in a few teams. |
| Habitual | Averages 1 to 14 actions per week and used Copilot in at least 9 of the past 12 weeks | Regular use that has become routine for that person. |
| Novice | Averaged at least 1 action over the 12 weeks but did not use Copilot in at least 9 of them | Has tried it. Use is irregular. |
| Other | Licensed users who don’t meet the Power, Habitual or Novice criteria | Licensed, with no qualifying pattern of use. |
Definitions are Microsoft’s, from Microsoft Learn. The right-hand column is our reading. The analyst Adoption report labels the last group “Non-user.”[4]
This is more useful than a table of my own that says 40% adoption is weak and 70% is strong, because it measures consistency. Someone who uses Copilot twenty times the day after training and then leaves it alone for two months is a different kind of adopter from someone who uses it twice a week. Frequency matters, and so does regularity.
There is no universal number, and Microsoft doesn’t publish one global target either. It benchmarks relatively. The Copilot Dashboard offers an internal benchmark, built from a comparison cohort inside your company that shares job function, region or manager attributes. It also offers an external benchmark against other companies using Copilot, or against “companies like yours” by industry, size tier or headquarters region, with at least 20 companies in each group.[2] The analyst Adoption report lets you compare against the top 25 percent of similar companies, but only for the percentage of active Copilot users and with up to six months of history. The Dashboard’s full feature set, benchmarks included, needs 50 or more assigned Copilot licenses.
Peer benchmarks are useful context. Before you read one, ask what you’re comparing:
A new rollout shouldn’t compare itself with a mature one and conclude it failed. A company that licensed only its most motivated knowledge workers shouldn’t compare its rate with an enterprise-wide deployment either.
The benchmark I care about most is your own trend. Say one company sits below its peer benchmark, but its active users rate has climbed for four straight months, returning users and the Habitual group are growing, and more departments use Copilot consistently. Say another sits slightly above its benchmark, but its rate has slid for four straight months, its Power users are concentrated in one early-adopter group, and returning use is slipping. I would rather own the first rollout. A benchmark tells you where you stand against someone else. A trend tells you whether the rollout is getting healthier.
When someone asks whether a rollout is good, this is the order I would look at the evidence:
Until you reach the fourth step, you know Copilot is being adopted. You don’t yet know what the adoption is worth.
If I were building a Copilot dashboard for leadership, I would not hand over twenty-five metrics. I would give them five signals that each answer a different question.
| Signal | Question it answers | Where it comes from | What it doesn’t prove |
|---|---|---|---|
| Active users rate | Did enabled users deliberately use Copilot? | Usage report[1] | That they came back |
| Returning users | Did they find enough value to return? | Copilot Dashboard[2] | That Copilot is part of a real workflow |
| Habitual and Power share | Is use consistent? | Dashboard usage levels[3] | That the work improved |
| Named-workflow adoption | What does each person use it for? | Asking people directly | That the workflow is a good one |
| Workflow impact | Is the work any better? | Your own measures, plus Microsoft’s assisted-hours estimate[2] | That the result holds in every role |
Put one stage name next to each number you report, so nobody reads a license count as adoption.
Named-workflow adoption is the one a dashboard can’t give you, because the answer lives in how people work rather than in a usage log. So I ask directly: “What is one recurring task you use Copilot for every week?” Someone who has a workflow answers immediately. “I use it every Monday to pull my unresolved commitments from last week’s meetings and email into my leadership briefing.” Someone whose use is scattered says, “Mostly brainstorming, emails, little things.” Both could show up as active users in the dashboard, and only one can point to changed work.
Impact is where measurement should eventually land. Microsoft’s Dashboard reports Copilot assisted hours, an estimate of time employees were assisted over the past 28 days. It is built from assumptions: meeting summaries count by meeting duration, and each search or summary action and each creation action counts as 6 minutes.[2] That is useful for a sense of scale, and it is a modeled estimate, so I would not present it as time saved. Ask about the workflow itself: did cycle time fall, did effort drop, did quality hold, did the approval bottleneck move?
For the monthly update to an executive sponsor, I would use one page and finish it with one line: what we’re doing next.
| Section | What goes in it |
|---|---|
| Activation | Share of enabled employees active in the past 28 days |
| Retention | Share returning from the prior period |
| Habit | Split of Novice, Habitual and Power users |
| Breadth | Functions with the strongest and weakest adoption |
| Workflows | The top five recurring Copilot workflows people report |
| Impact | Two or three workflows with demonstrated improvement |
| Next step | “Finance adoption is strong and stable. Operations has high first-time use but weak return. Next month we’re replacing generic refresher training with two Operations-specific workflows and manager-led reinforcement.” |
A Future Factors template. The Next step row is an example of the level of detail to aim for.
Say your company-wide active users rate is two in three. That looks healthy. Split it by function and marketing is almost everyone, finance and HR are well above average, and operations and legal are around one in four or one in three. Now the conversation changes. Operations may lack relevant information to work with. Legal may have legitimate governance concerns. Marketing may have had workflow-specific training. One department head may encourage Copilot while another barely mentions it. The Dashboard supports this kind of split by organization and, when an admin has uploaded the attributes, by job function.[2]
That is where I would spend the time. “How do we raise adoption by seven points?” is a weaker question than “Why does this team use Copilot differently from that team?”
Power-user concentration can fool you too. Say 500 people hold licenses and thirty of them love Copilot. They build agents, use it across Outlook, Teams, Word, Excel and PowerPoint, and share tips constantly. Your total action count looks fantastic, and adoption is still narrow. Ask what share of Copilot activity comes from a small group of Power users. They are valuable as champions and sources of workflow ideas. One person using Copilot 100 times is a different outcome from 20 people using it five useful times each.
Prompt count is a weak success metric for a similar reason. The usage documentation lists total prompts and average prompts per active user for Copilot Chat.[1] More prompts can mean deep integration. They can also mean someone is struggling to get a usable answer and is prompting 14 times. Volume doesn’t tell you value, and it is also why I wouldn’t push every employee toward the Power threshold. Some roles have several daily Copilot workflows. Others get real value from one weekly workflow. The better question is what level of use makes sense for this role and whether it produces something valuable.
Different people need different slices of the same data:
When Copilot usage flattens, I wouldn’t jump to another launch campaign. I would find the stage where people are dropping out, because each stage points to a different problem.
| Where it drops | What it usually points to | First thing to try |
|---|---|---|
| Enabled to active | Activation problem: people don’t know what it does, can’t find it, see no use case, or the role fits poorly | Show each role one first task that fits its work |
| Active to returning | Value or habit problem: people tried it and found no reason to return | Pair the first task with a weekly routine and a manager who asks about it |
| Returning to habitual | Workflow-depth problem: useful occasionally, not embedded in recurring work | Design one recurring workflow per role |
| Habitual to broad | Scaling problem: some teams have cracked it, others haven’t | Borrow the strong team’s workflows for the weak team’s work |
| Broad to impact | Measurement or workflow-design problem | Pick two or three workflows and measure cycle time and quality |
A Future Factors diagnostic, and our judgment about what each pattern points to. Test it with a few conversations before acting on it.
Pilots are where many comparisons go wrong. A pilot of 50 people draws volunteers, usually people already curious about AI. They attend the training, join the channel, share prompts and try new workflows, so usage looks excellent. Then leadership expects the same curve from the other 2,000 employees.
A pilot proves the tool can work for people who already wanted to try it. It says little about everyone else.
The pilot-to-production problem isn’t unique to Copilot. Gartner reported in January 2026 that at least 50% of generative AI projects were abandoned after proof of concept by the end of 2025, citing poor data quality, inadequate risk controls, escalating costs or unclear business value.[7] That finding covers generative AI projects broadly, so I wouldn’t turn it into a Copilot failure rate.
Managers matter more than another email campaign. Gallup’s May 2026 data found 30% of U.S. employees using AI a few times a week or more, and employees whose managers actively support AI use were 1.7 times as likely to use it at that frequency.[5] Microsoft’s 2026 Work Trend Index surveyed 20,000 AI users across ten markets and reported that organizational factors such as culture, manager support and talent practices accounted for more than twice the reported AI impact of individual factors. It also found only 19% of users in the “Frontier” group where individual capability and organizational readiness are both high. Both are surveys that show association, and neither proves that manager support causes adoption. They do fit what I’d expect: a manager who shows how they use Copilot to prepare for Monday’s meeting, and what they check before trusting the output, does more than a poster announcing that AI is here.
Training can build the capability, and it can’t create adoption alone. Workflow design gives the skill a recurring task, and reinforcement from managers turns it into behavior. That is the same Tool x Workflows x Behavior thinking behind what makes an AI-powered professional different, applied to one tool.
If your numbers are weak, don’t relaunch Copilot to the whole company. Pull the data first: the active users rate, then returning users, then the split of Novice, Habitual and Power users, then all of it by team. Pick one team with a clear problem and talk to them. Ask ten people, “What is one recurring task you use Copilot for?”
If most answers are vague, you probably don’t need more awareness. You need workflow design. If people can name good workflows and still aren’t coming back, ask what is in the way: output quality, manager support, poor integration, a workflow that takes longer than the old way, or uncertainty about governance. Low adoption is a symptom, and the stage where it shows up tells you where to look. Our guide to why Copilot adoption fails and what fixes it covers a 30-day restart plan.
I would also retire “target adoption rate” as a standalone goal. Targets that name a stage and a group are easier to act on:
A target of “get adoption to three quarters” works only if everyone knows which behavior that describes.
A license shows who has access. A returning, consistent user shows who found a reason to stay.
If I had no dashboard and could ask one question, it would be: “What is one thing you now use Copilot for every week that you used to do another way?” People who have changed their work usually answer fast. “I use it after every customer meeting to draft my follow-up and update my actions.” Or: “Every month I use it to question the variance numbers before I write the commentary.” That sounds different from “I use it for emails sometimes.” I wouldn’t replace dashboards with workflow evidence, and I wouldn’t replace workflow evidence with dashboards. You need both.
So what does good Copilot adoption look like? Most of the people who should be using Copilot activate it. A growing share come back. More users move from occasional experiments to consistent use, and usage spreads beyond the original enthusiasts. People can name recurring workflows, managers reinforce them, and over time the organization can point to work that is measurably better. A benchmark should tell you which of those stages you have reached.
There’s no single percentage that marks successful adoption. Microsoft’s reporting supports comparison against internal groups and against external peer groups, and it doesn’t publish one fixed target. I would look at the active users rate, returning users, usage consistency, workflow adoption and business impact together, and watch your own trend over time.
In Microsoft’s usage report, an active user is an enabled user who tried a user-initiated Copilot feature in the selected period. Opening the Copilot pane doesn’t count, and submitting a prompt does. In the Copilot Dashboard, returning users are people who took at least one Copilot action in both the current and the preceding period.
Over a rolling 12 weeks, Microsoft classifies a Power user as averaging 15 or more actions per week and using Copilot in at least 9 of the 12 weeks, and a Habitual user as averaging 1 to 14 actions per week with the same 9-of-12 pattern. A Novice user averaged at least one action but used Copilot in fewer than 9 of the weeks. Not everyone needs to reach Power, because the right frequency depends on the role and the workflow.
Yes. The Copilot Dashboard offers an internal benchmark based on similar job functions, regions or managers inside your company, and an external benchmark against other companies or companies like yours by industry, size and region. The analyst Adoption report compares the percentage of active users against the top 25 percent of similar companies. Check the current requirements, since the full Dashboard feature set needs 50 or more assigned Copilot licenses.
Check the active users rate after the post-training spike has settled, then returning users and movement from Novice toward Habitual use. Pair that data with one question, which is what recurring task each person now uses Copilot for, and then measure whether a few chosen workflows improved. Training builds capability, so the measures that matter most come from what happens in the weeks after it.
This guide uses Microsoft’s own definitions. The enabled, active and returning user definitions, the Novice, Habitual and Power thresholds, the benchmark options and the assisted-hours method come from Microsoft Learn pages that I checked on October 4, 2026, and Microsoft updates them regularly, so confirm the current wording before you build a dashboard on it. The Copilot Adoption Ladder, the Stage Rule, the drop-off diagnosis and the Adoption Pulse are Future Factors working frameworks, not Microsoft’s and not validated research scales. An earlier version of this article carried weak, typical and strong percentage bands of our own, and I removed them because the evidence doesn’t support calling one percentage weak or strong across different companies, roles and rollout stages. It also described Dashboard benchmarks against the top 10% and top 25% of companies. I could confirm the top 25 percent comparison in Microsoft’s Adoption report documentation and could not confirm a top 10 percent view in Microsoft’s documentation, so it is no longer cited. The Gallup and Work Trend Index figures are survey results about association, with Gallup covering U.S. employees, and neither shows that manager support causes adoption. Gartner’s figure covers generative AI projects broadly and is not a Copilot failure rate.
Weekly tips. Real examples. Practical help for busy professionals.
We care about your data, check out our privacy policy.