I’ve lost count of how many Microsoft 365 Copilot conversations I’ve had with UK IT leaders in the last year. Most of them start the same way. Someone on the exec has decided Copilot is happening. Licences have been bought, or are about to be. The question being asked is no longer “should we?” but “how do we not mess this up?”
Which is the right question, in fairness, because a lot of rollouts are being messed up.
Copilot is a strange product to deploy. It isn’t really software in the traditional sense. You don’t install it, configure it, and move on. It’s more like hiring three hundred new members of staff on the same day, all of whom are eager but a bit unpredictable, and then watching what happens when they get access to your SharePoint. The variable that determines success isn’t the tech. It’s whether your organisation was ready for what Copilot was going to reveal.
The first four weeks are where it goes wrong
Here’s what I’ve seen happen repeatedly. An organisation buys, say, 200 Copilot licences. They’re distributed to “pilot” users, which in practice means senior leadership plus whoever shouted loudest. Week one, everyone is excited. Week two, the novelty fades and a fair chunk of users stop opening it. Week three, someone in finance notices Copilot has summarised something it shouldn’t have had access to. Week four, IT gets a panicked email from legal.
By month two, licence utilisation is somewhere around 30 percent, nobody wants to be the one to tell the CFO that the £400,000 they signed off on isn’t delivering, and the whole thing has become politically awkward to talk about.
This isn’t a Copilot problem. Copilot is doing exactly what it’s supposed to do. The problem is that most organisations rolled it out as a procurement exercise when it should have been a change programme.
What readiness actually means
The phrase “Copilot readiness” gets thrown around a lot and I think it’s often used badly. It tends to mean “we’ve checked the technical prerequisites,” which is the least interesting part of the equation. The technical side is genuinely not that hard. Your tenant needs to be on the right plan, your users need the right licences, your data needs to be in Microsoft 365 rather than scattered across file shares. Fine. Any competent IT team can tick those boxes in a fortnight.
The hard bit is everything else.
Are your SharePoint permissions sensible? I don’t mean “technically configured.” I mean: if Copilot summarises across every document a user can access, is the output going to contain anything that shouldn’t be in front of them? For most organisations, the honest answer is yes, and nobody has audited it in years.
Do you have sensitivity labels applied consistently? Because Copilot respects them, but only if they’re actually there. If half your sensitive documents are unlabelled, Copilot will cheerfully include them in a summary for the junior who asked about quarterly performance.
Do your users actually know what Copilot is for? Most early rollouts skip training entirely, on the assumption that it’s “intuitive.” It is intuitive, in the sense that typing a question is intuitive. But knowing what to ask, when to trust the output, and when to treat it with suspicion: that’s a skill, and it has to be taught.
Where consultants earn their money
There’s a lot of variation in the UK market right now in terms of what a Copilot engagement actually looks like. At the low-rent end, it’s someone walking you through the admin centre and then invoicing. At the better end, it’s a structured piece of work that looks something like: assess the data estate, clean up what’s broken, identify high-value use cases for your specific business, run a proper pilot with measurement, then scale with ongoing adoption support.
One UK partner has published a detailed breakdown of its Microsoft 365 Copilot consultancy, covering readiness through to adoption and success metrics, which is worth a read if only to pressure-test whatever proposal is currently sitting in your inbox. The useful bit is that it makes the non-technical stages explicit, which is where most rollouts fail.
A cheaper way to think about it
If you’re weighing up Copilot right now, my unsolicited advice is this: treat the licence cost as roughly a third of what the project actually costs. Budget for the readiness work. Budget for the change management. Budget for the training, the comms, the centre of enablement, the quarterly review of what’s being used and what isn’t.
The organisations getting real value from Copilot in 2026 aren’t the ones with the biggest licence deployments. They’re the ones that did the unglamorous preparatory work, chose a small number of use cases to really commit to, and measured what came out the other end. It’s slower and less exciting than the vendor pitch makes it sound. It also works.
