Copilot Adoption Metrics Reference

This page is for analysts and sceptics who want to check exactly how Copilot Adoption works out its figures, and for contributors who change them. It defines every rate, score, band, action, reclaim tier, modelled estimate, reporting-period rule and agent measure, with its default values. An administrator can change many of the defaults on Settings; the report always quotes the values it used. Section numbers follow the specification.

On this page: Headline rates · 3.1 Engagement score · 3.2 Bands · 3.3 Frequency · 3.4 Actions and reclaim tiers · 3.5 Licence opportunity score · 3.6 Time saved · 3.7 Reporting period · 3.8 Managers · 3.9 Agent measures · Agent growth

---

3. What the tool measures

Headline rates

Measure	Numerator ÷ denominator	Read it as
Adoption rate	Active scored seat holders ÷ all scored seat holders	Any observed use in the period, not a habit
Habit rate	Scored seat holders in Established or Champion ÷ all scored seat holders	Crossing the weighted engagement threshold (§3.2), not just opening Copilot often
Average adoption score	Sum of scored seat holders' scores ÷ scored seat holders	A population average: read it with the band mix and coverage
How often people open Copilot	Active people in each frequency bucket ÷ active people, separately for licensed and unlicensed use	Frequency only (§3.3); not the denominator of the habit rate

Active means any band from Trialling up. The rates divide by the people actually scored, not by the seats you bought. Licensed-user detail, unlicensed use and licence candidates are each capped at 50,000 by default, so on a very large tenant a rate can describe a subset: keep the scored count and any cap warning beside it, and don't extrapolate it to the whole organisation.

3.1 Engagement score (0–100)

Each licensed user gets a graded score, because "did they use Copilot?" is almost never a yes/no question — someone who opened it twice and someone who lives in it produce the same "active user" count and need opposite responses.

Component	Default weight	Measures	Default target
Frequency	50%	Distinct days used	60% of available working days (5-day week)
Depth	30%	Interactions per active day, downweighted for a small sample	5 per day; full depth confidence at 3 active days
Breadth	20%	Distinct Copilot surfaces used	3

frequency = min(1, activeDays / expectedActiveDays)
depth     = min(1, (interactions / activeDays) / depthTarget) x min(1, activeDays / depthMinActiveDays)
breadth   = min(1, appsUsed / breadthTarget)

score = (frequency x 0.5 + depth x 0.3 + breadth x 0.2) / (0.5 + 0.3 + 0.2) x 100

When there are no active days, depth is zero and division is not evaluated. depthMinActiveDays defaults to 3: below it the capped component is reduced proportionally, at/above it confidence is one. This does not make three days the habitual-user threshold: weighted score/bands still decide that. An administrator can change these targets on Settings. Formulas here show defaults; always read the effective settings before comparing scores.

The frequency target (expectedActiveDays) is the period's working days × the target ratio (28 × 5/7 × 0.6 = 12 days at the defaults), and at least one day. It is scaled down for an account created part-way through the period and, for a past date range, for someone who held a seat for only part of it (§3.7).

Where the evidence comes from. The audit log is preferred. Microsoft's Copilot usage report supplies fallback evidence for a seat holder the audit log has no signal for; its period can differ, and the source is recorded. Fallback prompt counts are never added to audit interaction totals. A last-activity date can establish use even when counters are missing; it can't establish detailed intensity.

Design decisions worth preserving:

• Working days, not calendar days. Against calendar days, someone using Copilot every single working day caps out at ~71% and looks like a partial adopter.
• Depth is per active day. Otherwise an intermittent-but-intensive user is penalised twice for the same low frequency.
• Every component is capped at 1 before weighting. Nothing above target buys extra credit, and no single component can carry a user on its own.
• The weights are tenant-configurable: an administrator sets whole percentages totalling 100 on Administration → Copilot & reporting → Copilot Adoption settings, stored in the CopilotAdoptionSettings partition of the AnalyticsState table. The defaults above are unchanged unless someone saves different values. See Settings.
• The weighted sum is divided by the total of the weights. That is what keeps the result on a 0–100 scale whatever the weights are tuned to — and it is why the UI must quote each weight's share of the total rather than the raw weight. Quoting the raw weight is only correct while they happen to add up to 1.
• "Last N days" means exactly N distinct calendar dates, ending today. The window starts at midnight N−1 days ago, not N — starting N days back spans N+1 dates, so a user active every single day would record 29 active days in a "28-day" window while expectedActiveDays is derived from 28. The numerator and the denominator have to measure the same window, or the score is inflated for precisely the most engaged users and the dates shown on screen are a day wider than their own label. One definition, CopilotAdoptionScoring.WindowStartUtc, sits beside TargetActiveDays so the two cannot drift apart. An explicit date range (§3.7) is its own inclusive dates, from midnight UTC on the first to the end of the last.

3.2 Engagement bands

Band	Rule	Meaning
Champion	score ≥ 75	Among the deepest users
Established	score ≥ 50	Habit formed — this is the "habitual users" line
Developing	score ≥ 25	Habit forming
Trialling	score < 25, some activity	Occasional use only
Dormant	no activity this period, but some in the last 365 days	Tried it and stopped
Never used	no activity at all in the history window	Never started

The Champion, Established and Developing thresholds (default 75 / 50 / 25) are tenant-configurable by an administrator, with 1 ≤ Developing < Established < Champion ≤ 100. The report, the method text and the Excel export always quote the thresholds actually used.

Users with no activity in the period are never scored, because a zero score would put two completely different problems in the same bucket. Dormant + Never used = idle seats. The reclaimable licences figure is narrower: only the Certain and Probable reclaim tiers.

3.3 How often people open Copilot (unweighted frequency)

The unweighted counterpart to the bands, and the number a sceptical reader trusts first: how many days a month does this person actually open Copilot?

Deliberately not labelled "habit" on screen. "Habitual users" in the headline is the weighted engagement score — frequency plus depth plus breadth — whereas this card is frequency and nothing else. Using one word for both would put two different methodologies behind the same label, which is exactly the ambiguity the tool exists to remove. The two are meant to be read against each other: a large "Daily" tile with a low habit rate means people open Copilot constantly and do very little with it.

Bucket	Default range
Infrequent	1–5 active days a month
Moderate	6–10
Frequent	11–19
Daily	20+

Because the reporting period is adjustable, active days are normalised — and rounded to whole days — before bucketing:

daysPerMonth = round(activeDays x 28 / windowDays)

Without the normalisation, "11+ active days" would mean a near-daily user over a 28-day period and a once-a-fortnight user over a 180-day one — the same tile silently changing meaning when the reader changed the period drop-down. The rounding is what makes the printed captions ("1–5 active days a month") describe the comparison exactly rather than approximately. Any activity at all rounds up to at least one day, so a single interaction in a 180-day window is Infrequent rather than unbucketed.

Habit percentages are a share of active users, not of all licences: someone who never opened Copilot is not an "infrequent" user, they are an idle seat, assessed by the reclaim tiers, and merging the two hides the more expensive problem.

3.4 Recommended actions

Every licensed user who holds a seat today gets exactly one action, so the counts sum to that licensed population. In a past date range, someone who held a seat during the range but no longer holds one gets no action; the CSV says "No reclaim action - this person no longer holds a Copilot licence."

Each label names the step to take, not the state the user is in. Earlier drafts used "Coach" and "Grow", which read as synonyms unless the reader had memorised the band thresholds — two rows needing genuinely different interventions looked like the same instruction. CopilotAdoptionTests.EveryActionLabel_IsDistinctAndNamesTheStepToTake pins this: labels must be unique, multi-word, and never a substring of one another.

There are nine actions, listed in the order the enablement plan works through them:

Action	Applies to	Meaning
Reclaim or onboard	A disabled account that still holds a seat, whatever its band; or Never used, with an enabled account created longer ago than the reclaim grace period	The disabled account is the clearest reclaim there is. For the rest, the licence has produced nothing in the history the tool reads; confirm it is needed before renewal
Win back	Dormant	Ask what stopped; refresh or reassign. For reclaim the seat is review-only: talk to the person or their manager first
Build a first habit	Trialling	One repeatable habit in the app they already live in
Add a second app	Developing/Established with low breadth (in practice, one Copilot surface)	Habit confined to one surface — cheapest remaining gain
Deepen to daily use	Developing with adequate breadth	Scenario-based session aimed at their actual job
No action needed	Established with adequate breadth	Paying for itself
Recruit as advocate	Champion	Run a peer session for their department. A Champion who uses only one surface gets "Recruit as an advocate, and broaden" in the CSV
Review before reclaim	Never used, but the account is younger than the reclaim grace period, or its account status or creation date is unknown	Don't reclaim yet. A person must check first: leave, part-time work, service accounts and shared mailboxes are not visible in usage data
Excluded from reclaim	An administrator has excluded the person from reclaim	Already reviewed. The seat stays in the licensed population but out of the reclaimable figure. The CSV gives the reason and the review date

Since Stable 1859 (PR #821): Add a second app is renamed Add another app, on the page and in the CSV and workbook, and it follows the configured breadth target. It goes to Developing and Established users whose breadth score is 50 or less: people who use no more than half the apps the target asks for. At the default target of 3 that is still one app, so the same people get it. With another target the enablement plan's counts and the CSV change: at a target of 5, for example, it goes to people in two apps, and at a target of 2 to people in one app. A Champion's advice adds and broaden by the same rule, and the action descriptions state the configured target.

Every row of the enablement plan is a drill-through for readers with See PII. Clicking one opens the Licensed users tab pre-filtered to exactly the people that number counted, and its CSV export contains exactly that list. The filter is on the action code, not on the band, because an action such as "Add another app" ("Add a second app" before 1859) spans two bands — filtering by band would land the reader on a different set of people from the number they just clicked, which is worse than having no link at all.

Reclaim tiers

The reclaim tier is a seat decision, separate from the action. It is shown in each person's detail on the Licensed users tab, which can be filtered by it (All reclaim tiers, Certain reclaim, Probable reclaim, Review before reclaim, Excluded from reclaim), and it is in the CSV. Only people who hold a Copilot seat today get a tier. The rules are checked in this order:

Tier	Rule	Safe to act on?
Excluded from reclaim	An administrator has an active exclusion for the person	No: an administrator has already decided to keep the seat
Certain reclaim	The Entra account is disabled but still holds a Copilot licence, whatever it did before it was disabled	Yes
Probable reclaim	Never used (no Copilot use observed in the imported history), with an enabled account created longer ago than the reclaim grace period (30 days by default)	Yes, after confirming the imports cover the period: no observed use is not proof of no use
Review before reclaim	Never used, but the account is inside the grace period or its account status or creation date is unknown; or Dormant	Talk to the person or their manager first
(no tier)	Everyone else: people who used Copilot in the period, unless their account is disabled	Not a reclaim candidate

Reclaimable licences on the headline card is Certain + Probable only. Review and Excluded seats stay in the licensed population. When Microsoft's usage-report period doesn't match the selected period, a Probable seat that was scored from that report (rather than from the audit log) is also held back. The ⓘ on the card reconciles the figure with the bands: never used + dormant + disabled-but-active = reclaimable + held back.

The grace period counts from when the Entra account was created, not from when the Copilot licence was assigned. The tenure signal is the account's age; licence assignment history isn't used for it. Giving an existing employee a Copilot licence doesn't restart the grace period: a long-standing employee who received a licence last week and hasn't used Copilot yet can already be Probable. Check when the licence was assigned before acting, and use an administrator exclusion to protect a recently assigned seat.

3.5 Licence opportunity ("business case") score

Unlicensed users are scored 0–100 so that evidence beats inference:

Signal	Default weight	Default target	Why
Already using Copilot Chat with no licence	35	20 interactions	The only signal that proves demand for Copilot itself
Teams collaboration	25	60 messages + meetings	Heavy collaborator
Email volume	20	80 sent + read	Heavy correspondent
Document work	20	40 files viewed/edited	Heavy document worker

score = copilot x 35 + collab x 25 + email x 20 + documents x 20   (each component capped at 1)
recommended when score >= 50

The cap matters: without it a single extremely noisy mailbox would clear the threshold on email alone. Disabled accounts are excluded from candidates — but kept in the licensed-user list, because a disabled account still holding a Copilot licence is the clearest reclaim there is.

3.6 Time already saved by seat holders (modelled)

This is the model about people who already hold a licence, following §2.11: hours only, a range, never measured productivity and never added to the licence or Cowork estimate.

It counts the Copilot actions that seat holders took in the period, from the Copilot audit log, and multiplies each by a visible time credit:

monthly actions = actions in the period x 28 / days in the period        (for each kind of action)
high (hours a month) = (Outlook x 6 + Word/PowerPoint/Excel x 6 + Teams meetings x 30 + other x 0) / 60
low  (hours a month) = high x 50%

Kind of action	What counts	Default credit	Basis
Outlook	Actions whose app host is exactly Outlook	6 minutes per action	Microsoft's Copilot assisted-hours credit for email actions (Viva Insights metrics)
Word, PowerPoint and Excel	Actions whose app host is exactly Word, PowerPoint or Excel	6 minutes per action	Microsoft's assisted-hours credit for document actions (Copilot Dashboard)
Teams meetings	Each distinct meeting a seat holder used Copilot in, once per person, however many prompts	30 minutes per meeting	Microsoft credits meeting summaries by the meeting's length. The import doesn't reliably carry that, so this is a fixed, visible fallback
Copilot Chat and other surfaces	Everything else	0 minutes	Microsoft has published no per-prompt credit. They are counted and shown as uncredited actions, so the omission is visible

After an upgrade from a build before 1856, the Teams-meetings figure can fall. Meetings are counted as distinct meeting rows, and builds before 1856 could store one Teams meeting several times. A seat holder whose interactions in one meeting were linked to different copies was credited for that meeting once per copy. Migration 202610221500003_UniqueOnlineMeetingIds merges the copies, so after upgrading to 1856 the Teams-meetings figure, and the hours it adds, can fall. That's a correction, not lost data: no interaction is deleted, and each one stays linked to its meeting. See Upgrade to Build 1856 → Migration 003.

Rules worth preserving:

• Meetings take precedence. An action linked to a meeting is credited only as that meeting, never also as an Outlook, Office or uncredited action.
• Agents and Cowork are left out entirely. Cowork has its own estimate.
• Seat holders scored only from Microsoft's Copilot usage report are left out. That report has prompt counts but no per-action detail, so they are counted separately as Excluded users.
• Aggregate only. The estimate is given for the tenant, by engagement band and by department, never per person. Departments with fewer than MinSeatsPerSegment (5) seat holders are omitted, and at most TopSegments (10) departments are listed, those with the most hours first.
• The credits are options, CopilotSeatOutlookMinutesPerAction, CopilotSeatOfficeMinutesPerAction, CopilotSeatMeetingMinutesPerAction and CopilotSeatUncreditedMinutesPerAction, returned with the results like every other option (§2.7). The low end uses the shared conservative share (§2.11).
• Withheld, never guessed. With no Copilot audit data for the period, the estimate is not assessed. If its query fails or times out, the estimate is not assessed and the analysis is marked incomplete (FiguresIncomplete), naming the dataset seat-holder Copilot time-saved inputs in the page's incomplete-figures banner. Either way there is no card, no section and no workbook sheet: an empty estimate is never shown as zero hours. A query that succeeds and finds no credited actions is a real zero, and shows 0 hours.

Where it appears. A headline card, Time already saved by seat holders. For holders of See PII it links to Review on Licensed users; for other readers it has no link, because that tab needs See PII. There, the Seat holders' time saved (modelled) section shows the range, how many people it covers, the excluded users, the observed actions a month with the credit applied to each, and the department table. Like the rest of that tab, the section needs See PII. The server picks the departments with the default credits, but each department's hours are recomputed from the reader's credits, as the headline and the workbook are. The workbook's Seat holders time saved sheet carries the same figures plus the band breakdown, and is included in every workbook, because it is aggregate.

Reader overrides. A reader can change any of the four credits for their own browser tab (§2.11). The Excel export then sends only the changed credits as copilotSeatOutlookMinutesPerAction, copilotSeatOfficeMinutesPerAction, copilotSeatMeetingMinutesPerAction and copilotSeatUncreditedMinutesPerAction. These are page options, not configuration. The portal and the server both limit them: Outlook to 0–60 minutes, Word/PowerPoint/Excel and meetings to 0–120, and other surfaces to 0–240.

Cost. One more query in each analysis, named SeatHolderTimeSaved (§9). It lengthens the first, uncached load of a long period on a large tenant; the measurements are in design notes.

Past date ranges. For a past range (§3.7) it counts the actions taken in that range by that range's seat holders, the same population as every other seat figure.

Read it as an assumption range. The low end is the conservative share of every credit, not a statistical confidence interval. A surface credited at 0 minutes, such as Copilot Chat, is uncredited by this model, not worthless.

The licence and Cowork estimates: defaults

The other two modelled estimates have their own visible assumptions. Both are ranges in hours a month: the high end applies each assumption in full, and the low end applies the conservative share, 50% by default (CoworkEstimateLowerBoundRatio, shared by both). A reader can change any of them for their own browser tab, on the Time saved sub-tab of Licence opportunities and on the Cowork tab; they are page options, not tenant settings. The three estimates are never added together.

Licence estimate: the time Microsoft 365 Copilot might give back to people who don't hold a licence (the people recommended for one, or all candidates), from their monthly volumes in the Microsoft 365 usage reports:

Work counted	Default minutes saved per item	Option
Meetings	5	CopilotMinutesSavedPerMeeting
Emails sent or read	0.5	CopilotMinutesSavedPerMailThread
Files viewed or edited	1	CopilotMinutesSavedPerDocument

Each default is Microsoft's published Copilot assisted-hours credit spread over every item observed, because the usage reports count every meeting, email and file, not only the ones Copilot helped with.

Cowork estimate: the time Cowork might save on top of Microsoft 365 Copilot, by taking on a share of each person's work:

Work Cowork takes on	Default share	Default minutes saved per item
Organising the meetings they organise	25%	6
Preparing them for the meetings they attend	10%	6
Sending the emails they send	5%	6
Posting their Teams messages	1%	6
Creating documents, out of the files they work on	2%	6

No study has yet measured Cowork's time savings or how much work people hand to it, so the page labels all of these as assumptions.

3.7 The reporting period: rolling windows and past date ranges

Practical steps and the exact warning texts are in the user guide.

There are two kinds of period:

	Rolling window	Explicit (past) date range
Request	windowDays = 7, 28, 90 or 180. Any other value snaps to the nearest	from and to, both yyyy-MM-dd. When present they replace windowDays
Dates	The last N calendar dates, ending now (§3.1)	from to to inclusive, in UTC: 7 to 180 dates, ending no later than yesterday, starting no earlier than 1753-01-01
Seat holders	Today's (user_license_type_lookups)	From licence history: everyone holding a Copilot-seat licence type at any point in the range
Named lists	Shown to holders of See PII	Never shown

Every endpoint except availability accepts from and to: summary, licence-types, sql, filters, licensed-users, opportunities and cowork with their /exports, and export/workbook. Each period is analysed and cached on its own. A request that breaks a rule is refused with 400, and the error's code (repeated as its message) is the translation key the portal shows:

Code	Refused because
copilotAdoption.error.missingDate	Only one of from and to was sent
copilotAdoption.error.invalidDateFormat	A date is not yyyy-MM-dd
copilotAdoption.error.invalidDateRange	Fewer than 7 or more than 180 dates, or the range ends today or later
copilotAdoption.error.dateTooEarly	The range starts before 1753-01-01

The portal's controls produce both kinds: the Period list is rolling; Last calendar month, Last calendar quarter, the four settled presets and Custom range are explicit. A custom range is checked in the browser by the same rules before it is sent.

One seat population per range. A past range resolves licence-history availability once, as the first completed licence refresh (MIN(completed_utc) of dbo.license_refresh_runs), then uses one definition of "seat holder" in every seat-dependent query: licensed users, usage by app, the unlicensed figures (unlicensed means not in that population), licence opportunities, Cowork readiness and credits, and time saved by seat holders (§3.6). Mixing today's holders in one query with history in another would count the same person as licensed in one chart and unlicensed in the next.

• Overlap. A history row counts when it overlaps [from, to + 1 day).
• Held days are clipped to the range and merged per person across overlapping or consecutive seat licence types, so two SKUs held at once count once. They cap the days a person's expected activity is worked out from: someone who held a seat for 10 days of a 90-day range is expected to be active over those 10 days, not 90.
• Seeded rows (from_source = 0, written at the first refresh) are treated as held from the range start. A range that starts before history began therefore includes everyone who held a seat at the first refresh, which errs in both directions. Warning licenceHistoryPartialForRange carries the history start date.
• No history. If the licence-history tables are missing or no refresh has completed yet, the range falls back to today's seat holders, with warning licenceHistoryUnavailableForRange.

Everything else is as of today. Department, manager, country, office, company, account status and reclaim exclusions are today's values (warning currentOrgDataForPastRange). The agent inventory is computed for the same number of days ending now, not for the range (warning agentInventoryAsOfNow). Since Stable 1859 (PR #821): active agents, agent interactions and interactions per agent user are read for the range itself, with the inventory's own query over the range's dates, when the Copilot audit log holds that period. When it holds nothing for the period they are null, with warning agentPeriodFiguresUnavailable, never the inventory's latest weeks; a read that fails leaves them null with the usual could-not-load warning. The agent list, health verdicts, agent use by department and reach stay as of now. Microsoft 365 usage-report evidence for opportunities and Cowork readiness is read for the range's dates only.

Reclaim acts only on seats that exist today. A past seat holder who no longer holds a seat gets no reclaim tier; their reason reads "No reclaim action - this person no longer holds a Copilot licence." Disabled-account reclaims count only people who still hold a seat. Idle (never used or dormant) former holders are counted in reclaimSeatsNoLongerHeld, a fourth reconciliation term: never used + dormant + disabled-but-active = reclaimable + held back for window mismatch + held back for review or exclusion + no longer hold a seat.

A past range never names people. Its people are described with today's departments, managers and account status, and reclaim and recommendations can only be acted on today, so:

• licensed-users, opportunities and cowork, and their CSV exports, answer 400 with code copilotAdoption.error.pastRangeNamedListsHidden, even for See PII;
• the summary drops the manager roll-up, as it does for a reader without See PII;
• the workbook leaves out its per-person sheets, and its cover says "not included (historical range)";
• the portal hides only the person lists (the Licensed users list, Licence opportunities' Candidates and Cowork's People to enable) and keeps every aggregate section of those tabs. In a list's place, a See PII holder sees the past-range note and a reader without See PII the usual See PII note. Every past range carries warning pastRangeNamedListsHidden.

Counts stay.

Exports. The workbook is named copilot-adoption-<from>-to-<to>…-<generated>.xlsx rather than copilot-adoption-<N>d…-<generated>.xlsx, and its method sheet gains a Reporting period row stating the UTC dates. A printed page's header labels the period Custom range and gives its dates.

3.8 Do managers use Copilot themselves? (manager modelling)

The 2026 Work Trend Index discusses manager support for AI use. This tool asks a related, telemetry-based question: do the people who manage Copilot users use it themselves, and how do their teams compare? It measures an association in imported usage, not Microsoft's survey score or a causal effect.

Who counts

• A direct report is a licensed user the analysis scored whose account is enabled and whose recorded manager (users.manager_id, the direct manager only, never the wider hierarchy) is someone else with an enabled account.
• A people manager is anyone who directly manages at least one such report, with or without a Copilot seat. Someone who manages only unlicensed users, or nobody, is not counted, however much they use Copilot.
• Disabled accounts are left out on both sides. A disabled manager's reports are left out too: a departed manager whose team has not been re-parented yet is not a manager who chose not to use Copilot.
• A user recorded as their own manager is not their own report. Because only the direct manager is ever read, a management cycle (A manages B, B manages A) is just two report lines; nothing recurses.

A manager's own status

Status	Rule
Active	Any Copilot use in the period. That means either a seat holder whose band is above Dormant (the same rule as the adoption rate), or someone without a seat who appears in the unlicensed Copilot Chat usage
Not active	The data shows no use: a seat holder at Dormant or Never used, or someone without a seat who is absent from a complete unlicensed list
Unknown	The data cannot say. This covers three cases: a seat holder beyond maxLicensedUsersScored; someone without a seat when the unlicensed usage stopped at maxUnlicensedUsersScored, failed, or could not run (it needs the Copilot audit import); or an external guest, because the unlicensed usage leaves guests out

Unknown is never counted as not active. Those managers are counted in managersStatusUnknown, and their reports in reportsManagerUnknown. Both are left out of every rate. Absence from a truncated list proves nothing; presence on one still proves use.

The figures

Snapshot facts key	Meaning
managersActivePct	Active people managers ÷ people managers whose own use is known (managersStatusKnown), × 100. managersActive is the numerator
managersStatusUnknown	People managers whose own use could not be determined
reportsActiveRatePctManagerActive / reportsActiveRatePctManagerInactive	Share of direct reports active in the period, by whether their manager used Copilot. The denominators are reportsManagerActive / reportsManagerInactive
reportsHabitRatePctManagerActive / reportsHabitRatePctManagerInactive	The same split for the habit rate: reports in the Established band or above, the existing "habit formed" definition
reports…RatePctManager{Active,Inactive}{Licensed,Unlicensed}	The same comparison within managers who hold a Copilot seat, and within managers who do not. Denominators are reportsManager{Active,Inactive}{Licensed,Unlicensed}
reportsWithManager	All direct reports, including those whose manager is unknown

The split by seat exists because a manager with a seat is more likely both to use Copilot and to lead a team that was given seats. On its own, that would widen the gap. Compare like with like (managers with a seat against managers with a seat) before reading anything into the headline gap.

Per department, the same figures are shown for each department in Adoption by department, in the same order, so the seat minimum and the top-N cap are inherited. The department is the report's own; a manager who leads people in two departments counts in both.

Aggregates only. No manager is named anywhere, and the accountability roll-up by direct manager deliberately carries none of this: one row per manager with that manager's own status would disclose one person's use. Small groups are withheld at both levels:

• A figure that depends on managers' own use (including the split counts) needs at least minSeatsPerSegment people managers whose use is known.
• Every rate needs at least minSeatsPerSegment reports behind it.
• Since Stable 1859 (PR #806): the comparison by whether the manager uses Copilot, and its split by seat, is shown only when every group in it holds at least minSeatsPerSegment managers or none. Otherwise the whole comparison is withheld, because its groups add up to totals that are always shown.

A withheld figure is blank, never 0%. The figures are open to every signed-in reader, like every other aggregate on the page.

An association, not a cause. Teams whose manager uses Copilot may differ in function, seniority or seat coverage. The report says the same of its own drivers. This caveat is printed next to the figure on screen and on the workbook's method sheet.

Where it appears:

• Executive view: one line, with an "i" tip.
• Analyst view: the same line plus the seat split, above Adoption by department, whose rows gain five columns: managers using Copilot, plus the active and habit rates of reports whose manager does and does not use Copilot.
• Workbook: two tables on Departments and apps, each headed by the whole population, plus the definitions on How this is calculated.
• Snapshot facts: the tenant-level keys above. The department list appears there only as managerModellingByDepartment.count, because a department name is tenant data and never a key.

Filtered views. A filtered view resolves managers against the whole tenant's rows, so a report inside the filter whose manager is outside it is still resolved. None of this adds a query; see design notes.

3.9 Agent breadth and depth, builders and reach

Paired audit records count as one turn, and Copilot Studio maker testing is excluded from the agent-use grain. This applies to breadth, depth, reach and the growth series, not just the agent inventory.

Agent adoption grows in two different shapes: breadth (agents used in many departments) and depth (people relying on many agents in a few). The two call for different programmes — breadth needs reach, depth needs more agents on the workflows people already use — so the tool reports both, tenant-wide and per department, beside who builds agents and how far each agent has spread. Figures, not charts: they are columns of the existing department and agent tables, and tenant-level values on Snapshot facts.

Which agents count. Customer-built agents only — the agents the organisation built itself, which is what the 2026 Work Trend Index counts. Microsoft's own agents are left out by design. Each agent's origin comes from its stored id through the same classifier as the Agents tab's Type column, so an agent past the inventory's row cap, or one that has gone quiet since a past period, is still placed. An agent of unknown origin is not counted either — the classifier never guesses — and the page and workbook say how many were left out (agentUnknownOriginAgents, agentsInThreeOrMoreDepartmentsUnknownOrigin), so a reader knows the figures are a floor. The scope is named next to every figure (Agents counted: customer-built agents only…) and carried in agentFiguresScope. Per-agent reach is shown for every agent in the inventory; only the tenant counts are scoped. If the origins cannot be read, breadth and depth are left blank rather than counted over no agents.

The population. Every per-person figure is over the active Copilot users the audit log can see: seat holders whose Copilot activity comes from the audit log, plus every unlicensed Copilot Chat user. Seat holders scored from Microsoft's usage report are left out of both sides of every ratio, because that report does not say which agents anyone used — counting them would read as "active, and never used an agent".

Figure	Definition	Where it appears (Snapshot facts key)
Departments with an agent user	Departments with at least one person who used an agent in the period ÷ departments counted. A department is counted when it has at least minSeatsPerSegment Copilot seat holders or that many active unlicensed users — the rule that gives it a row in the department table. People with no department are not a department	Department card, workbook (agentBreadthDepartmentsWithAgentUsers ÷ agentBreadthDepartments = agentBreadthDepartmentPct)
Active users who used an agent	People who used at least one customer-built agent ÷ active users, as defined above	Department card and the table's Using customer-built agents column (agentBreadthAgentUsers ÷ agentActiveUsers = agentBreadthUserPct)
Distinct agents per 100 active users	Distinct customer-built agents those people used × 100 ÷ active users	Department card and table (agentDepthDistinctAgents, agentDepthAgentsPer100ActiveUsers)
Interactions per active agent	Their interactions with those agents ÷ distinct agents	Department card and table (agentDepthInteractions, agentDepthInteractionsPerActiveAgent)
Agent builders	People who created, published or shared a Copilot Studio agent in the period — Microsoft's authoring operations BotCreate, BotUpdateOperation-BotPublish and BotUpdateOperation-BotShare from the Power Platform audit feed. Editing a topic, component or setting does not count	Department card and table's Agent builders column (agentBuilders)
Reach (per agent)	Departments with at least one of its users in the period; its home department — the one most of its users are in (ties go to more interactions, then alphabetical order); and its home share — the share of its users in that department. A low home share means a local win that has spread	Agents tab inventory, workbook Agents sheet
Agents used in 3 or more departments	Customer-built inventory agents with reach of three departments or more; agents of unknown origin with that reach are counted separately	Department card, workbook (agentsInThreeOrMoreDepartments, agentsInThreeOrMoreDepartmentsUnknownOrigin)

Read them carefully. Distinct agents per 100 active users measures how varied the agent estate is relative to active people, not how many agents each person used. Department lists show the top ten departments by default, not every department. The inventory holds at most 5,000 agents by default, so reach totals can be a floor.

Privacy. Department rows below minSeatsPerSegment are suppressed as everywhere else, but their people still count in the tenant totals. An agent's home department is named only when at least minSeatsPerSegment of its users are in it; below that the share is still shown, because a share names nobody. Builders are only ever a count — no endpoint, export or telemetry event names one. Department names are tenant data: shown as stored, never translated, never a Snapshot facts key.

Builders are not matched to the agents they built. Copilot Studio identifies an agent by its bot id; the Copilot interaction log identifies it differently, and nothing proves the two identifiers equal (the same reason the agent-cost import keeps the licensing API's agent id unjoined). So builders are shown beside agent use, and the report does not say who built which agent.

A quiet selected period does not hide builders. Their authoring feed is checked independently of Copilot interaction activity. Available create/publish/share evidence can still produce a builder count when there are no selected-period Copilot interactions. That does not make unavailable selected-period reach or depth a measured zero.

"Not measured" is not zero. Each figure is blank when it could not be measured: the query failed, the agents' origins could not be read, the period has more than 1,000,000 agent–person combinations (a warning says the figures were withheld rather than computed from part of the data), or — for builders — no Copilot Studio authoring event has ever been imported, so a tenant without the Power Platform audit feed does not read as "nobody builds agents".

Filtered views and past periods. Breadth, depth and builders are narrowed to the people a filtered view selects, like every other per-person figure. Reach belongs to the agent inventory, so — like the inventory — it stays tenant-wide in a filtered view and, for a past period, describes the latest period.

Agent growth, year on year

One line under the agent headline figures compares use in the most recent closed 28-day window with the window 364 days earlier, with a sparkline of the windows between. This compares the organisation with itself, not with a Microsoft growth target.

Coverage is not identical to the Work Trend Index: this tool counts recognised customer-built agents in its audit evidence, leaves unknown origins out, and keeps billed-agent evidence separate. Microsoft's telemetry includes platforms and autonomous runs this importer cannot fully observe.

The series checks settled audit history independently of the selected reporting period. A quiet selected window does not hide growth evidence in its own fixed horizon. A never-imported feed, an uncovered window or a failed source read still leaves the relevant figures blank or incomplete, not measured zero; the existing inventory scope is unchanged.

Windows	14 consecutive, closed windows of 28 whole UTC days, most recent first. They end on the last settled day: today less usageReportLagDays (default 3), the margin the report already gives Microsoft's usage reports, because Copilot audit events arrive 2–3 days in arrears and Copilot Studio billing is re-read by the importer for a week. Window 13 starts exactly 364 days before window 0, so the two cover the same weekdays a year apart, and window 0 against window 13 is the year-on-year change. The series always ends at the last settled day before the analysis ran, whatever reporting period is selected, like the agent inventory
Per window	Active agents: agents with at least one day of user-initiated use in the window, the report's definition. Agent users: distinct people. Agent interactions. Interactions per agent user. Beside them, agents of unknown origin, not counted (see below)
Which agents	Customer-built agents only, the report's scope, as the agent-origin classifier decides it: the same classifier behind the Type column of the agent inventory. Agents Microsoft ships, such as Cowork, are left out. Agents whose origin the audit log does not reveal (SharePoint agents, BuiltIn_* ids and other shapes the classifier will not guess at) are left out too, and counted separately in each window as agents of unknown origin, not counted, so the gap is visible: the figures are a floor by that much. An interaction counts when the Copilot audit log attributes it to a counted agent and to a person, licensed and unlicensed users alike. The page, the workbook and Snapshot facts (agentGrowthScope) all name the scope
Not measured is not zero	A window is measured only when the Copilot audit log holds an interaction inside it and its history reaches back to the window's first day. Otherwise every figure is blank: a dash on screen, an empty cell in Excel. A window the import did not cover would otherwise read as "nobody used an agent", and in the year-ago window that is the denominator of any growth ratio. On a tenant whose Copilot audit history is younger than 392 days, the year-ago window stays blank until the history is long enough
Autonomous runs	A separate, labelled figure that is never added to active agents: agents billed in Copilot Studio, the Copilot Studio agents with billed consumption in the window, from the agent-cost billing import (copilot_studio_credit_daily; see Agent costs). The audit log records user-initiated use only, so an agent that runs on its own shows up in billing and not in the audit log. Billing also covers conversations, so this is evidence that agents ran, not a count of autonomous runs, and its agent ids are the licensing API's, so the two figures cannot be matched agent for agent. A window the billing import holds no rows for is blank
Cowork scheduled tasks	Not counted. They would be the other evidence of autonomous runs, but the table meant to hold them (cowork_usage_user_activity_log) has never been written: Microsoft reports Cowork tasks only in its Cowork usage report in the Microsoft 365 admin centre (Copilot > Cowork > Usage), which this product does not import
The caveat, on screen	This compares the organisation with itself. The report's 15x is year-on-year growth in active agents across Microsoft's whole customer base. It is not a target, and not a benchmark for one organisation

Quoting growth. Divide window 0's active agents by window 13's, only when both windows are measured and the earlier count is above zero; the percentage change is (ratio − 1) × 100. A synthetic example of 20 against 10 agents is 2×, or +100%. A zero in the earlier window gives no growth figure, not an infinite one. A covered window can show zero active agents as a real result, when Copilot was used but no customer-built agent was.

Where it lands. The Agents tab (one line, with the SQL behind both figures); an Agent growth sheet in the Excel export (all fourteen windows, oldest first, with a live line chart, the sources and the caveat); the definitions on How this is calculated; and fixed keys for windows 0 and 13 on Snapshot facts: agentGrowthActiveAgentsWindow0 and agentGrowthActiveAgentsWindow13, the same pair for UnknownOriginAgents, AgentUsers, Interactions, InteractionsPerAgentUser and CopilotStudioBilledAgents, plus agentGrowthScope and agentGrowthSettledThroughUtc. Each is blank, never zero, when its window was not measured.

⚠️ Keep a year of Copilot interactions, or the series goes blank. Nothing about the series is stored. Every run recomputes it from the raw Copilot interactions (dbo.copilot_chats) and Copilot Studio billing rows (dbo.copilot_studio_credit_daily), so it reaches back only as far as the database keeps those rows. Clean Old Data Data.sql keeps one month: applied to Copilot interactions, it destroys the series, leaving windows 1–13 blank and year-on-year comparison impossible until a year of data has built up again. As shipped, the script cleans the audit metadata tables (event_meta_*) and the usage-report tables, but not copilot_chats or copilot_studio_credit_daily, so it leaves this series intact. Keep it that way. If you extend the script, or shorten retention of Copilot data any other way, keep at least 392 days (14 × 28) of both tables, and export the workbook first: its Snapshot facts sheet is the only baseline that survives.

---

Previous: Copilot Adoption Specification · Next: Copilot Adoption Sources and Outputs Reference

Reference set: Specification → Metrics reference → Sources and outputs reference → Design notes