In the Microsoft 365 tenants I work with, the question of what Microsoft 365 Copilot is actually worth used to be a vague hope. Now it's a concrete discussion about business value and adoption. Copilot Analytics is built into Viva Insights, so there is finally an official source for usage figures and the familiar "hours saved" claims. That still leaves open questions: how reliable are these metrics, what do the privacy controls mean for reporting, and where do works council requirements set the boundaries? Below is what I've seen in practice, including where the numbers help and where they mislead.
Access to the Copilot Dashboard depends on Viva Insights roles
Once Copilot licences are assigned, a new Copilot Dashboard menu appears in the Viva Insights portal. Not every Copilot admin gets access automatically, though. You need the right Viva Insights roles or permissions, and that trips up even experienced IT teams. The dashboard shows aggregated usage: active Copilot users, breakdowns by Word, Outlook, Teams and other apps, usage trends and, most prominently, Microsoft's estimate of "assisted hours", meaning the work hours Copilot is supposed to save. For metric details and access control, the Microsoft documentation on the Copilot Dashboard is a good reference.
One point matters a lot here. The dashboard only displays aggregated group data, never the activity of individual users, and usually only when a group has at least 10 members. This privacy threshold follows the general Viva Insights approach and is essential for works council compliance. Without it, the feature would never get approved in many German and European companies. The downside is that small teams often see nothing at all, just empty screens, and managers who want granular insight find that frustrating.
Assisted hours are an estimate, while active user counts are measurable
Most debates start with the "assisted hours" metric. In theory it adds up the time Copilot "saves" users, based on Microsoft's research into typical Copilot interactions. Whether those estimates match real working habits is another matter, particularly in Germany, where meetings take up a lot of the day and Copilot adoption is cautious. I regularly see management treat the figure as hard ROI, while the business units ask the obvious question: is a Copilot-generated summary really an hour of work avoided? Anyone who has used Copilot day to day knows how much rework and human checking it still needs.
Active user counts are more tangible, because they track who actually used Copilot features in supported apps. It makes sense to compare them with the Copilot usage report in the Microsoft 365 Admin Center, which gives admins more filtering options and time ranges. Putting both sources together shows you who holds licences, who really uses Copilot and how adoption develops over time. I've written up practical advice and pitfalls in /blog/copilot-usage-reports-licence-assignment and /blog/copilot-licences-review-reassign.
Practical tip: Never show the "assisted hours" figure on its own. Executives often don't realise it's a rough estimate rather than a direct measurement. I always link to the definitions in the dashboard and present the number as an indicative trend, not a precise productivity gain.
Viva Insights reporting allows deeper Copilot analysis within privacy limits
With a Viva Insights licence, the advanced analytics module lets you break Copilot usage down further, by department, role or other attributes, as long as the privacy thresholds are met. The relevant documentation lists which dimensions you can analyse. In real projects, though, IT, HR and the works council have to check which groupings are big enough to show data without making individuals identifiable. If a unit is too small, fields are masked or stay empty, and you have to move up a level or combine several teams to get meaningful trends.
In larger organisations with complex works council oversight, you should clarify early on which data the analytics modules expose and whether the existing privacy thresholds are sufficient. Sometimes additional works council agreements are required before Insights data can be used at all. I also like to pair these analytics with conventional business surveys (for example on perceived Copilot value or satisfaction). That helps calibrate the dashboard figures against how users actually feel about the tool.
The diagram shows how usage data and privacy controls interact
This Mermaid diagram shows how Copilot usage data reaches the dashboard, where privacy and access controls apply, and where the admin fits in:
flowchart TD
CopilotUsage["Copilot usage in apps"] --> InsightsCapture["Viva Insights data capture"]
InsightsCapture -->|"min. group size"| Aggregation["Aggregation & privacy"]
Aggregation --> Dashboard["Copilot Dashboard"]
Dashboard --> Admin["Admin/role-based access"]
Dashboard --> WorksCouncil["Works council reviews privacy"]
Figure: Typical data flow and privacy controls in Copilot Analytics.
Copilot Analytics has limits, and context decides what the numbers mean
Good-looking dashboards don't change the fact that measuring Copilot's impact is still an approximation. "Assisted hours" points in a direction at best and is not a certified productivity gain. You get a realistic picture by combining these analytics with licence and usage reports, user feedback and, if you're lucky, real business KPIs. I get especially uneasy when rough estimates turn into hard budget arguments. If you take Copilot Analytics seriously, you need to understand its limits, communicate openly with management and the works council, and ideally run a structured adoption programme that puts numbers and user stories side by side. Managing expectations and privacy is still as much a part of this as the technology.


