Chatbot interface on a company intranet with employees interacting
By · Published April 2025, Updated August 2026 · 8 min read

Your SharePoint news and policy views are down 22 per cent quarter on quarter. Nothing about your editorial output changed. What did change is that Microsoft 365 Copilot went live across the tenant in the same period, and a good share of the organisation now asks a question in Teams instead of navigating to a page. The honest reading of that chart is not that your communication got worse. An assistant moved in front of your intranet and started answering on its behalf, and your measurement was built on the assumption that reading requires arriving. That assumption is the thing that broke.

This is a more interesting problem than it first looks, because the drop is not uniform, and where it lands tells you something useful about your content. It also puts internal communication in the awkward position of having to explain a falling number as evidence of an improving service.

What now sits between the employee and the page

Microsoft 365 Copilot answers using content the signed-in user already has permission to see, retrieved from the tenant through Microsoft Graph and returned inside the chat surface[1]. The grounding is permission-trimmed, so two people asking the same question can legitimately get different answers[2]. Alongside it, many organisations run a purpose-built intranet assistant, built in Copilot Studio or bought from an HR service vendor, pinned in Teams or embedded in the portal.

The mechanic is the same in every case. The assistant reads your content, extracts the part that answers the question, and returns it with a citation link most people never click. Your content was consumed. Your page was not visited. Every metric downstream of a page load is now measuring something narrower than it used to.

Why reach falls while delivery improves

Take a concrete example. A 4,000-word remote working policy page had 310 views in the quarter before the rollout, with an average time on page of 41 seconds. That 41 seconds was never a good sign: it meant most people arrived, scanned, failed to find the clause about eligibility after 12 months, and left. In the quarter after, the same page had 62 views, and the assistant answered roughly 900 questions grounded on it.

More people got the answer. Far fewer people arrived. Both facts are true and only one of them is in your report.

The drop also lands unevenly, which is the part worth studying. Reference content loses the most: policies, procedures, benefits, IT how-to, anything an employee arrives at with a specific question already formed. Editorial content loses far less, because nobody asks an assistant to summarise a story they did not know existed. A CEO message about a plant closure does not generate a query, it generates a reaction. If your reference pages have collapsed and your news pages have held, that is not a communication failure. It is the assistant absorbing the traffic it is genuinely better at serving, and leaving you with the traffic that was actually yours.

The four numbers that break first

Metric What it meant before What it means once an assistant intermediates What to do
Page views Rough proxy for how many people consumed the content How many people needed the full page rather than an extract Keep it, rename it, stop calling it reach
Unique viewers as reach How much of the population the content touched A systematic undercount, worst on your most useful reference pages Rebuild reach on delivery events, not page loads
Average time on page Weak engagement signal Now measures the people who failed to get an answer elsewhere Treat a rise as a possible content problem, not a win
Intranet search queries Your best free signal of unmet demand Progressively empty, because the demand moved into chat Recover the demand signal from assistant usage, not site search

The fourth row is the one teams underestimate. Intranet search logs were the cheapest content-strategy input most communication teams had. Watching them fall to a trickle removes an editorial signal, not just a metric, and nothing native replaces it automatically.

What to measure instead

The shift is from arrival to delivery. Four changes cover most of it.

  • Reach as a delivery event against a defined population. Count the number of people in the intended audience who received the content on any surface, expressed against a stated denominator. Our note on which intranet metrics matter covers how to construct that base without flattering it.
  • Source attribution on every arrival. Feed, search, newsletter, manager cascade, assistant citation. Once assistants are in play, knowing that 15 per cent of arrivals came from a Copilot citation changes what you optimise.
  • Demand by topic as an editorial signal. The questions employees put to an assistant are the clearest statement of what your content estate is failing to make obvious. That is a content plan, not a dashboard tile.
  • One continuous series across the cutover. Annotate the rollout date on the chart and keep both the old and the new definition running in parallel for two quarters. A team that silently changes definition in the same quarter as a rollout will not be believed, and should not be.

Push metrics survive all of this intact. An assistant does not deliver news nobody asked for, so for the announcement, the campaign and the leadership message, reach and read-through remain yours to defend. That distinction between what an assistant can pull and what only you can push is the subject of our companion piece on whether chatbots will replace the intranet.

What native tooling gives you here, and what it does not

Be fair to Microsoft first. Copilot adoption and usage reporting exists in the Microsoft 365 admin centre, SharePoint site usage still reports views and unique viewers per site[3], and for a single site owner asking whether their pages are being read, that combination is free, already switched on and adequate. If that is your question, build nothing.

The gap is the join. Copilot usage reporting tells you about assistant adoption. SharePoint usage tells you about pages. Neither connects assistant demand to the specific content that answered it, and neither connects either one to organisational attributes, so the question your CCO will ask, whether the German plants received the safety update by page, feed or assistant, has no native answer. Gallagher’s State of the Sector research has found measurement sitting at the top of the capability gaps internal communicators report[4], and an assistant layer widens it rather than closing it.

Power BI is the usual next move, built on the Microsoft Graph reporting API[5]. It can be made to work. Know what you are signing up for: the reporting API is not consistently reliable and produces days with missing data, customers have shown us Power BI dashboards whose KPI values do not reconcile with the native SharePoint reports for the same period, and a dependable build needs a robust ingestion process, scheduled reconciliation against the native figures and a named owner. Budget for the pipeline rather than the dashboard.

Tryane sits in that join. It reads SharePoint alongside Viva Engage, Teams and your newsletter platform, connects that activity to your organisational structure through Entra ID or an HR file, and holds history across product transitions so a Copilot rollout does not reset your trend line. For the Copilot-specific detail, including what the usage data does and does not expose, see our dedicated analysis of Microsoft Copilot and internal communications measurement. Tryane is SOC 2 Type 2 certified and GDPR compliant by design, hosts in the EU by default with US data residency on request, deploys in a couple of hours over single sign-on with Azure AD or Entra ID, and installs no agent.

What this changes about how you write

Assistants reward structure and punish sprawl. One topic per page, with the answer near the top and real headings rather than styled bold text. Explicit effective dates and a named owner, because a retrieval system will cite a superseded policy with exactly the same confidence as the current one. Answers in the page body rather than inside an attached PDF. And a genuine deletion policy: the 2021 travel guidance you left published because deleting felt risky is now an active source of wrong answers, not a harmless archive. Content pruning has quietly become a communication task.

Frequently asked questions

Why did our SharePoint page views fall after the Copilot rollout?

Because a page view requires someone to arrive, and an assistant answers without sending them. The fall concentrates on reference content, where employees arrive with a formed question, and is much smaller on editorial and news content, where they do not. Check whether the decline is uniform across content types before treating it as a communication problem: if reference pages dropped and news held, the assistant is doing its job.

Can we measure what an assistant answers from our intranet?

Partially. Microsoft reports Copilot adoption and usage at tenant level, which tells you how much the assistant is being used but not which of your pages it grounded an answer on, nor by whom in organisational terms. A purpose-built assistant you own can log its own queries. Joining assistant demand to specific content and to segments is the part no native report currently does.

Does an assistant make the intranet less important?

It makes the intranet less visited and more load-bearing. Everything the assistant says about a policy comes from a page somebody in your organisation wrote, and permission-trimmed retrieval means content quality and permissions now determine answer quality. A neglected intranet used to produce frustration. Behind an assistant, it produces confident wrong answers, which is worse.

Should we stop reporting page views?

No, but stop presenting them as reach. Page views remain a useful measure of how often content needed to be read in full. Report them under a name that says that, keep the assistant rollout annotated on the chart, and move your reach claim onto a delivery-based measure with a stated population underneath it.

How do we keep a trend line across the cutover?

Run both definitions in parallel for two quarters and publish both, then retire the old one on a stated date. Native retention windows make this harder than it sounds, because the history you need may age out before the comparison is finished, which is the main practical reason teams keep an independent measurement layer.

Sources

Microsoft Learn, Microsoft 365 Copilot overview

Microsoft Learn, data, privacy and security for Microsoft 365 Copilot

Microsoft Learn, portal health and site usage

Gallagher, State of the Sector

Further reading

Microsoft Copilot and internal communications measurement

Will chatbots replace the intranet?

Can Copilot be used for internal communication?

Measuring cross-channel internal communications

A guide to SharePoint native analytics

Tryane runs a 15-minute working session with Heads of Internal Communication on exactly this problem: what your intranet numbers looked like before the assistant arrived, what they mean now, and which measure you should be defending instead. Book a slot with Jérémy.