Copilot Adoption Sources and Outputs Reference

This page is for analysts and contributors. It records where each Copilot Adoption figure comes from and the caveats each source carries, what each screen is designed to show, and what the Excel export and its Snapshot facts sheet contain. Section numbers follow the specification.

On this page: 4. Data sources · Cowork use · 4.1 Microsoft's tenant prompt figures · 5. The screens · 5b. The Excel export · Snapshot facts keys

---

4. Data sources and their caveats

Source	Covers	Caveats the UI must state
Copilot audit log (copilot_chats, from Audit.General)	Every user, licensed or not; per-app; matches the selected period exactly	Needs the Copilot audit import. Activity API events arrive 2–3 days in arrears
Microsoft Copilot usage report	Licensed users only	Unusable when the tenant conceals user information. Its window is Microsoft's, not the one selected
Microsoft Copilot usage report — tenant summary (copilot_user_count_log)	Microsoft's own tenant totals: prompts submitted and average prompts per active user	Licensed users only, Copilot as a whole rather than agents alone, Microsoft's own report period and date. Never added to audit figures. See 4.1
Microsoft 365 usage reports (Teams / Outlook / SharePoint / OneDrive)	Workload activity, used to find heavy users without a licence	A dated snapshot, not a period total. Published a few days in arrears
User metadata (licences, department, manager, account status)	The licensed population and all segmentation	Without it there is no denominator and no segmentation. For a past date range the licensed population comes from licence history, but every attribute is today's (§3.7)

Licence classification is listed in full on the page, including the SKUs that were excluded, because Microsoft ships Copilot-branded SKUs that are not a Microsoft 365 Copilot licence (Copilot Studio, Copilot for Sales) and ships new licence SKUs regularly. The licensed population must be checkable rather than taken on trust.

Cowork use comes from the Copilot audit log

Every figure about Cowork use comes from Cowork interactions in the Copilot audit log, labelled as interactions, never tasks. Microsoft's per-user Cowork usage report is a Microsoft 365 admin-centre page (Copilot → Cowork → Usage) with CSV export, not a supported Graph report function in this release. The product does not import it. Where the guide names a manually readable admin-centre figure, it identifies that separate source.

Builds from Stable 1833 to 1846 tried to import the report from a Graph function that doesn't exist (see Known issues). No tenant ever received a row from it, so every figure about Cowork use ever shown was already audit-derived, and no real figure changes. Everything that only the report could have supplied is removed:

• Cowork task counts, the scheduled versus user-initiated split, and the automation ratio;
• 7-day retention, report active days and report last activity;
• credits per Cowork task, the report's snapshot date and period, and the matching CSV columns and workbook rows;
• in the Cowork time-saved model, the "tasks already running" row and the minutes-per-task input. Everyone in the estimate, including people already using Cowork, is modelled from the work they already do by hand.

Observed Cowork use and its regular-use tiers come only from the Copilot audit log. A person has used Cowork when the audit log shows at least one Cowork interaction, and is established when those interactions fall on at least CoworkRegularMinActiveDays (3) active days.

Predicted readiness and the modelled time saved are not audit-only. They also use the ordinary Microsoft 365 usage reports (Teams messages and meetings, email, and files viewed or edited) to measure each person's coordination load, alongside their Copilot fluency from the audit log. They don't use a Cowork-specific report. Without the Microsoft 365 usage-report import, nobody can be identified as a Cowork candidate; see Copilot Adoption Setup.

When the report-only figures were removed, the Copilot Adoption API's JSON lost their properties too; they're listed in Design notes → API changes.

4.1 Microsoft's tenant prompt figures

These are Microsoft's published figures in their own unit and period, not a replacement denominator for audit-derived adoption.

The usage-report import stores the tenant summary of Microsoft's Copilot usage report (getMicrosoft365CopilotUserCountSummary, version 2) in copilot_user_count_log, and the page shows Microsoft's own figures, exactly as the report states them, in Microsoft's own unit:

Figure	Summary / Snapshot facts key	Microsoft's definition
Prompts submitted	microsoftReportPromptsSubmitted	"Total prompts submitted": the prompts users sent to Copilot Chat in the period
Prompts per active user	microsoftReportAveragePromptsPerActiveUser	"Average prompts submitted": the mean per active user, with Microsoft's definition of active
Report date	microsoftReportDate	The last day of the report period (Microsoft's refresh date)
Report period	microsoftReportPeriodDays	The period's real length in days
Report version	microsoftReportVersion	v1 or v2, as the import recorded it

Which report. The importer requests the 28-day summary in version 2 and falls back to the 30-day summary when a tenant only serves version 1 (Graph accepts D28 only in version 2, and D30 only in version 1). The page reads the stored period closest to 28 days, then the most recent report date for it whose row set is complete — its Any App row, where the tenant figures live, exists. It is Microsoft's latest report, as the admin centre shows it, so its period ends on Microsoft's date rather than on the page's. A past date range never reads a report dated after the range.

Where it appears. One line under the headline figures on the Executive and Analyst views, naming Microsoft's report as the source and stating its period and report date (for example 28-day period to 5 Oct 2026). In the workbook: the Headline figures sheet (its own block, after the audit-derived totals), the Report sheet's data sources, Snapshot facts (the keys above) and a paragraph on How this is calculated.

Caveats the surface states:

• Scope differs. Microsoft counts Copilot as its report covers it, not agents alone, so these are not the agent measure charted in Microsoft's 2026 Work Trend Index. No Work Trend Index figure, or any other external benchmark, is shown beside them.
• Population differs. Microsoft's report covers licensed users only; the audit-derived figures on the page also include unlicensed Copilot Chat.
• Never added to audit interaction counts. A prompt and an audit-log interaction are different units, so Total interactions contains no Microsoft prompt count, and nothing on the page sums or averages the two.

Blank, never zero. A figure Microsoft did not report — version 1 of the report has no prompt counts — is a dash on the page with the reason beside it, and blank on Snapshot facts. With no summary imported at all, the line is not shown and every key is blank. A zero that Microsoft actually reported is shown as zero.

Concealed user information does not affect these figures. The import records concealment only against the per-user report (copilot_usage_report_import_log.is_upn_obfuscated); the tenant summary carries no identities, so a concealed per-user run neither blanks nor zeroes it.

No agent figures from this report. Microsoft's published version 2 schema for the tenant summary (Learn) lists Any App, the Office apps, Copilot Chat, Edge, Microsoft 365 Copilot and Copilot Chat (work/web) — no agents surface. The only agent signal in Microsoft's usage reports is the per-user Copilot Agent Last Activity Date. Agent figures on this page come from the audit log.

Filtered views. These are tenant totals with no per-person detail, so a view narrowed to an email domain or a user filter keeps them whole, badges the line Tenant-wide, and names them in the filter banner among the sections that stayed tenant-wide.

Cost. One query in its own analysis step (MicrosoftReportFigures), whose cost doesn't grow with tenant size; see design notes. The SQL is on the Analyst view's line.

5. The screens

For what each tab shows a reader, with screenshots, see Tabs. This section records the design decisions behind each screen.

Executive view and Analyst view

The summary is ordered by the questions a budget owner asks, in the order they ask them, and split into four numbered sections so a long page still reads as an argument rather than a wall of cards. An earlier draft ran seventeen cards in the order they happened to be built, which buried "adoption by department" — the who do I talk to card — near the bottom. Executive view is the concise summary; Analyst view adds the detailed evidence, ⓘ explanations, SQL popovers and breakdowns.

1. Where you stand — the headline position.

Element	Answers
Headline figures	Licences, adoption rate, habitual users, reclaimable licences, average/median engagement, unlicensed use, recommended candidates
Microsoft's usage report line	Microsoft's own tenant prompts submitted and prompts per active user, with the report's period and date — beside the audit figures, never added to them (§4.1)
Gauges	Adoption rate and habit rate against the judgement scale, side by side — the gap between them is the finding
Adoption funnel	Where in licensed → ever used → active → habitual → champion the biggest drop is

The last funnel step is not a loss. Each stage prints the count that did not reach it from the stage immediately above. For the middle steps that is a genuine drop-off and is shown in red. For the final step it is not: everyone who reaches Habitual has, by this tool's own definition, formed a habit — §3.2 calls that "habit formed" and the action catalogue marks it "no action needed / paying for itself". Champion is a top tier, not a target for the whole population, so flagging those users in red as "lost" would contradict the tool's own advice and point enablement budget at the people already succeeding. That step therefore reads "N not yet Champions" in neutral grey and should be read as the size of the advocate pool. Every figure on the right of the funnel carries a hover explanation.

2. What to do next — the work this creates.

Element	Answers
Enablement plan	How many people need each action — the size of each job. Every row drills through to the people in it
Adoption by department	The running order for an enablement plan
Where the unmet demand is	Departments that could be rebalanced rather than bought for

3. How Copilot is being used — the evidence behind those recommendations.

Element	Answers
How often people open Copilot	Unweighted frequency: days a month, no scoring
Engagement mix donut	The whole licensed population in six mutually exclusive bands
Where Copilot is used treemap	Which surfaces carry the traffic, and which are unused
The shape of adoption	Where the typical user differs from the best ones, on frequency/depth/breadth
Usage frequency and intensity bubble chart	Which departments are frequent-but-shallow vs deep-but-occasional
Usage concentration	Whether adoption is broad or carried by a top decile
Who is doing the Copilot work	Licensed against unlicensed share of total volume
What Copilot is working on	Which kinds of tenant content Copilot grounded its answers in

4. Trend and wider reach — direction of travel.

Element	Answers
Weekly active users trend	Whether an enablement programme is working, across all three populations
Weekly Copilot volume trend	Interaction volume, licensed against unlicensed — headcount can flatten while volume climbs
Licensed and unlicensed side by side	Departments with idle licences and heavy unlicensed use — a reallocation, not a purchase. It also carries each department's agent breadth, depth and builders, with the tenant-wide figures above the table (§3.9)
Adoption by country	The same measures for organisations that run enablement regionally

First-run state. When the analysis completes and finds zero Copilot licences, the summary is replaced by a designed empty state rather than seventeen cards each saying "no data" — which reads as a broken page rather than an unfinished import. It names the three usual causes in the order they are worth checking (licence import not run yet; a Copilot SKU this build does not recognise; the tenant genuinely holds no licences) and, when unlicensed Copilot activity was found, says so, because that combination almost always means the licence import is incomplete.

Licensed users

Per-user list with server-side search, band / recommended-action / reclaim-tier / department filters, "Cowork users only", "Disabled accounts only", sorting and CSV export. Carries a short action tag per row with the meanings stated once above the table. The action filter is what the enablement-plan drill-through sets, and it is a normal, visible, reversible filter — arriving here from a click never leaves the reader on a filtered list with no way to see how they got there.

Above the list sits Seat holders' time saved (modelled): see §3.6.

Unlicensed usage

Unlicensed Copilot Chat as a population in its own right — headline users/interactions/habitual count, its own habit strip using identical rules to the licensed one, usage by app, and usage by department. This is the one Copilot population Microsoft's own reporting cannot see at all.

Agents

The Copilot agent estate: active/known/custom counts, most-used and most-versatile agent, an inventory-health donut, a treemap of interactions per agent, agent usage by department, and the full inventory table with a Keep / Review / Retire / New verdict and a stated reason for each agent. It also shows each agent's reach: departments reached and the home department's share of users (§3.9).

The year-on-year agent growth line is defined with the other agent measures, in the metrics reference.

Cowork

Observed Cowork use, from the audit log, is kept apart from predicted readiness, which also uses the Microsoft 365 usage reports (above). The modelled time saved is a separate range of hours, never added to the licence or seat-holder estimates. People to enable is a named list (See PII, rolling periods only); everything else is aggregate. See Tabs → Cowork.

Licence opportunities

Ranked unlicensed candidates with their four component scores and a per-user justification safe to paste into a licence request. Unlike the licensed list, the justification genuinely differs per row — no two candidates reach the same score by the same route — so it stays a per-row column.

How this is calculated

The full methodology: engagement score with a worked example, bands and habit buckets, action selection, the opportunity score, agent verdicts, agent breadth, depth, builders and reach, and usage concentration, data sources with their snapshot dates, and the complete SKU classification table.

5b. Excel export — the point-in-time snapshot

An Excel report button in the page header exports the whole report as a single .xlsx: a sheet for each part of the page, covering every figure, table and chart on it, with native, live Excel charts bound to the cells rather than pasted-in pictures.

This is not "download the data" — the CSV exports already do that per list. It exists for a specific job: comparing before and after an enablement programme. A screenshot of a dashboard cannot be compared with another screenshot six months later — the numbers cannot be subtracted, and nobody can tell what period or thresholds either was run with. The workbook records both. A past date range (§3.7) can also produce the "before" file afterwards, without its per-person sheets.

The sheets, and what each is for, are listed in Reviews and exports → The Excel report. The Report sheet records the run, the period covered, which imports supplied data and any warnings; the Settings sheet records every rule and assumption the run used.

Design decisions worth preserving:

• The workbook records the rules, not just the numbers. Two snapshots are only comparable if both were scored by the same rules — the tuning is adjustable, so without this "adoption went up" could turn out to mean "the bar moved". The Settings sheet records every value used, and the methodology sheet says so explicitly.
• Charts are native and bound to ranges, so a reader can re-plot, re-theme, or copy them into a board deck. Pictures would make the file a dead end.
• Written with zero new dependencies. The .xlsx is produced by Common.Entities.Xlsx, a small hand-rolled OpenXML writer over System.IO.Compression. EPPlus 5+ is commercially licensed, and any third-party library would have meant binding-redirect changes across several projects — see the NuGet rules in the engineering notes.
• Built from the same cached analysis that renders the page, so the workbook can never quietly disagree with the screen it was downloaded from.

A leadership-comparison failure doesn't fail the export. The independently refreshed comparison has one ten-second storage-read deadline. A timeout or unreadable state produces unavailable / stateUnavailable with the comparison's figures withheld, and the workbook still downloads; cancelling the request still cancels it. By contrast, unreadable score settings refuse the whole report with 503 / copilotAdoptionSettingsUnavailable. See leadership availability and score-settings safeguards; neither behaviour changes metric formulas.

Because the writer is hand-rolled, CopilotAdoptionWorkbookTests generates a real workbook from synthetic data on every build and asserts that it is a valid OPC package, that every part is well-formed XML, that no relationship is broken, that the charts reference cell ranges, that Greek text and ampersands survive, and that numbers are written invariantly even under a de-DE culture. A malformed part reaches a customer as "Excel found unreadable content" with no indication of the cause, so this is not optional coverage.

Snapshot facts keys

Snapshot facts carries every scalar figure of the analysis as one key | value row, sorted ordinally by key. The keys are the API's serialised property names, generated by reflection over CopilotAdoptionSummary, so a figure added to the analysis reaches the sheet without anyone listing it.

• A figure inside a section is keyed by the section and the figure, joined by a dot, at any depth: agents.activeAgents, seatHolderTimeSavedEstimate.credits.outlookMinutesPerAction. Workbooks from builds before Stable 1852 skipped nested sections (#640), so their agent figures can't be compared with a later export.
• A list is written as its row count, for example warnings.count or agents.usageByAgent.count. Its rows are on their own sheets.
• A breakdown with a fixed set of values has a row per value, keyed by the value's stable name: bandBreakdown.NeverUsed to bandBreakdown.Champion, agents.healthBreakdown.Retire to agents.healthBreakdown.Keep, and coworkValueEstimate.activities.sendEmail. A key is never a display label, and never tenant data such as a department or agent name.
• The keys come from the product, not the data. A section that wasn't measured still writes all of its keys, blank, so two exports line up row for row.
• A key added in a later build has no value in an earlier export. That is a change in the product, not in adoption.
• options, diagnostics and leadershipComparison are deliberately excluded. Options are on Settings, timings on Run diagnostics, and the independently refreshed leadership comparison has its own Leadership comparison sheet. The comparison script does not compare that sheet.

Key family	What it holds
(no prefix)	The headline figures, Cowork use and readiness, the reclaim tiers, and the period itself (generatedUtc, fromUtc, toUtc, windowDays)
agents.	The agent estate: activeAgents, knownAgents, customAgents, agentUsers, licensedAgentUsers, agentInteractions, interactionsPerAgentUser, historyDays, mostPopularAgent, mostVersatileAgent, a row per health verdict, and the row counts of its lists. These are the baselines for the 2026 Work Trend Index's agent measures
bandBreakdown.	Licensed users in each engagement band
dataSources.	Which imports supplied data, the dates and period of Microsoft's usage reports, and whether the tenant conceals user information
unlicensed.	Unlicensed Copilot Chat: activeUsers, interactions, interactionsPerUserPerMonth, agentUsers, truncated
coworkCreditPosition.	Copilot Studio capacity snapshot, not Cowork usage or credits available to Cowork. The legacy key family remains unchanged: available, entitled, consumed, available_credits, payAsYouGoConsumed, status, snapshotUtc
coworkValueEstimate., coworkFullRolloutEstimate., coworkWithoutLicenceEstimate.	The modelled Cowork estimates: cohortUsers, projectedCoworkTasks, hoursPerMonthLow, hoursPerMonthHigh, and the observed work they rest on, a row per kind of work under activities.
licenceOpportunityEstimate., licenceChatUsersEstimate., licenceAllCandidatesEstimate.	The modelled licence estimates and their observed inputs: addressableMeetings, addressableMailThreads, addressableDocuments, hoursPerMonthLow, hoursPerMonthHigh, candidatesCapped
seatHolderTimeSavedEstimate.	Modelled hours for seat holders, their observed inputs (observedOutlookActions and the other observed* counts), and under credits. the minutes credited per action
userFilter., globalFilter.	The people filters applied: matchedPeople, directoryPeople, and the row counts of their conditions

A change in an observed input is real even when the hours built on it are modelled, and the modelled hours are only comparable when the Settings sheets match.

---

Previous: Copilot Adoption Metrics Reference · Next: Copilot Adoption Design Notes

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