Why Copilot rollouts stall before they pay back

The pilots that stall almost always share three traits. The first is messy permissions in SharePoint and OneDrive. The second is no honest measurement of value beyond 'people seem to be using it'. The third is no nominated owner once the rollout project closes and the IT team moves on.

Permissions get exposed the moment Copilot starts summarising. Documents that were technically accessible to everyone now actually surface to everyone, because the AI is helpful enough to find them. A board pack that nobody could be bothered to navigate to is suddenly being quoted back in a one-line summary.

Measurement gets vague because nobody defined what success looked like before go-live. Hours saved, draft quality, meeting prep time, customer reply turnaround - none of it gets baselined, so the renewal conversation comes down to vibes.

Ownership evaporates because Copilot was treated as an IT deployment rather than a working-practice change. IT delivered, the steering group disbanded, and there is no one in the business whose job it is to make the second 90 days better than the first.

The thing Copilot is actually doing is reading your tenant. The model is a commodity. The quality of the answers is set by what it can see and how clean that surface is. If your SharePoint has 14,000 sites, half of them abandoned, and a long history of 'share with Everyone except external users', the experience is going to feel patchy at best and dangerous at worst.

This is why mature rollouts look like data programmes with a Copilot wrapper. Information architecture, sensitivity labels, retention, lifecycle, and access reviews all do more for the experience than any prompt-engineering training.

Successful rollouts pick two or three concrete use cases per function rather than 'general productivity'. Finance gets help drafting variance commentary. Sales gets meeting prep and follow-up emails. Operations gets policy lookups and shift handover summaries. Each one has a baseline and a measurable outcome.

They also tidy up oversharing before turning Copilot on. A short audit of the top sites, a small DLP policy, and a sensitivity label scheme stops the worst leaks before the AI puts a microphone in front of them.

And they run a real 90-day measurement window with named owners. Not the IT director by default. The functional leader who wanted the capability in the first place.

The teams that pay back fastest are knowledge-heavy roles with high written volume: client services, professional services, in-house legal, marketing, internal comms. The drafting and summarising habits map neatly onto the tool.

The teams that struggle are the ones whose work is verbal, transactional, or already automated. There is no point putting Copilot in front of a shift supervisor whose day is radios and walk-rounds. Pretending otherwise just burns goodwill and licence cost.

If you're sponsoring a Copilot programme, the most useful question to ask your partner isn't 'how do we deploy it'. It's 'how will we know in 90 days whether it earned its keep, and what's the plan if it didn't?'

If the answer is a project plan, you're going to stall. If the answer is a named business owner per use case, a measurement plan, and a tidy-up of the data underneath, you're probably going to renew with confidence.

Copilot licences are deceptively cheap per user, which is why programmes are often approved without a business case. The real cost is the data and adoption work underneath: SharePoint hygiene, sensitivity labels, change management, and the time of named owners in each function. Budget for that work explicitly rather than discovering it halfway through.

Firms that treat the licence as the cost end up paying twice: once for the licence, and again for the remediation when the rollout stalls. Firms that budget for the underlying work upfront tend to renew without a second conversation, because the value is visible by the time the question comes up.