Copilot adoption never stalls everywhere at once

A single adoption percentage hides the only thing you can act on. How per-app usage tells you whether the problem is habit, data or the work itself.

LogiSam · 6 October 2026 · 4 min read
Microsoft 365 Copilot adoption broken down per app, with one app clearly lagging

Say your tenant's Copilot adoption number comes back at 54%. Now what?

That number is the most quoted and least useful figure in a Copilot programme. It averages together apps where adoption is near-universal and apps where it is close to zero, and the average is the one state the tenant is definitely not in.

Adoption does not stall evenly. It stalls in one or two apps while the rest look fine, and which ones tells you what is actually wrong.

Read it as a diagnostic, not a score

Break usage down per app — Microsoft's own Copilot usage report gives you the raw signal — and the shape of the result is the finding.

High in Teams and chat, low everywhere else. People have adopted the obvious thing, which is a meeting recap, and stopped. The value is real but shallow, and it is the easiest pattern to mistake for success because the headline number looks healthy. What is missing is the harder habit: using it inside the document you are already writing.

Low in one document app specifically. This is almost never a training problem. It is usually the content. Copilot in Excel wants a proper table with headers; it does not do much with a sheet of merged cells and colour-coded conventions. Copilot in Word does well with documents that have structure and badly with a scanned PDF someone pasted in. If one app is flat while its neighbours are fine, look at what your organisation keeps in that app before booking anyone a session.

Flat across the board for one department. Not an app problem at all. Either the work genuinely is not Copilot-shaped, or nobody in that department has seen a peer use it. Both are findings, and they have opposite responses.

High everywhere except for a cohort of individuals. That is a licence allocation question, not an adoption one — see setting a dormancy threshold.

Three reasons an app goes flat

Nearly every stalled app comes down to one of these, and they do not respond to the same intervention.

The habit is not obvious

People know Copilot exists in the app. They do not have a moment where reaching for it is the natural move, because nobody has shown them one in their own work. This is the only one of the three that training fixes — and specifically peer training, in-role, on a real document, rather than a generic session.

The data is not in a usable shape

The app is fine; what you keep in it is not. Spreadsheets built as layout rather than as data, documents with no headings, content scattered across sites with inconsistent structure. Here, more training actively hurts: it teaches people to try something that will disappoint them, and a disappointed user does not come back for a second attempt.

The work is not Copilot-shaped

Some roles do not produce much long-form text or do much synthesis. This is a legitimate outcome, and recognising it early is how you avoid spending a year trying to fix it. The right answer is to move the licence to someone whose work is a better fit.

Why the blanket answer fails

"Adoption is low, let us run more training" is the default response, and in two of those three cases it makes things worse — once by wasting effort, once by burning the user's willingness to try again.

The per-app view is what lets you tell them apart. It is a cheaper diagnosis than any of the remedies, and it is available from data you are already generating.

What to do with the diagnosis

  • Habit problem — find somebody in the same role who already uses it and let them run twenty minutes. In-role beats expert every time.
  • Data problem — fix one representative dataset, show the difference, and let that make the argument for the rest. Do not announce a content programme first.
  • Fit problem — move the licence, and say plainly why. A seat released for a good reason is much easier to release next time.

Then re-measure the same app, with the same definition, a quarter later. The per-app numbers are far more responsive to a targeted intervention than the tenant average ever will be — which is the other reason not to manage by the average.

Seeing the pattern

Copilot Insights reports adoption by app across Teams, Word, Excel, Outlook and Chat alongside per-user status, so a flat app is visible as a flat app rather than drag on a tenant-wide percentage. It is read-only and reads activity metadata only, never the content of a prompt or a document.

Related: assigned is not adopted, how many quiet days make a seat reclaimable, and the renewal meeting needs one page.

Copilot InsightsCopilotMicrosoft 365Copilot Adoption

Want to apply this in your tenant?

Book a free call with a LogiSam consultant — we will show you the quickest, safest way to do it on Microsoft 365.

LogiSam Assistant Guided help & instant answers

Answers come from this website. Privacy policy

↑↓ to navigate ↵ to open