This is not a Copilot problem. Copilot works. The problem is almost always what happened — or didn't happen — before anyone pressed enable.

Here are the five things that separate a Copilot deployment that delivers from one that quietly becomes expensive shelfware.

Think of Copilot as an amplifier. It takes what's in your Microsoft 365 environment and makes it faster to find, easier to use, and more accessible.

If your data is well-organised and current, that amplification is genuinely powerful.

If your SharePoint looks like a digital filing cabinet that hasn't been touched since 2018 — inconsistent folder structures, outdated documents, no metadata, no content types — Copilot will amplify that too.

Garbage in. Garbage out. Except now it happens at AI speed.

The data hygiene work — archiving what's obsolete, applying sensitivity labels, enforcing consistent content types — is unglamorous. It's also the single thing that most determines whether your Copilot deployment succeeds.

Enabling Copilot for 500 people on day one is the fastest way to ensure that 500 people try it once, get inconsistent results, and decide it's not worth the effort.

The organisations that see strong Copilot adoption do it differently. They pick one team with a specific, measurable workflow. A finance team that produces a weekly report. A procurement team that reviews the same document types every month. An HR team with a predictable onboarding process.

Deploy to that team. Train them on that specific workflow. Measure whether it saves time. Document what worked. Then use that as the blueprint for everyone else.

This sounds obvious. Most organisations skip it.

If you don't define what success looks like before a Copilot deployment, you can't tell whether it's working three months in. You can't identify problems early. You can't justify the investment to leadership when they ask.

Your success metrics don't need to be complicated. Weekly active usage versus licences assigned. Time saved on a specific recurring task. User satisfaction score from the pilot team. The Microsoft 365 admin centre has a Copilot Dashboard that gives you adoption data across every application. Use it from day one, not after things start going wrong.

The pattern is consistent enough that it has a name in the industry: "shelfware." Licences that are paid for, assigned, and barely used.

It usually unfolds the same way: licences purchased, announcement made, training session held, adoption flatlines, leadership asks why ROI is low, nobody has a good answer because nobody measured anything, the investment is hard to justify at the next renewal.

None of that is inevitable. It's the result of skipping the preparation that sits between procurement and deployment.

The good news: all of it is fixable. Even if you've already deployed.

If your Copilot adoption is lower than you'd hoped, start with the Copilot Dashboard in the admin centre. It will show you exactly where usage is and where it's not. That data tells you which of the five steps above to address first.

GTconsult works with organisations across South Africa, the UK, and the US on Microsoft 365 planning, deployment, governance, and adoption. Get in touch for a free consultation.

In July 2026, Microsoft launched the Agent Store's governed publishing flow. Teams can now build agents in Copilot Studio, submit them for admin review, and publish them under a 'Built by your org' section that anyone in the organisation can find and use.

This is genuinely useful. Internal tools that were previously invisible are now discoverable.

But here's the governance implication: an agent built by one team — with permissions that made sense for that team's specific use case — is now accessible to everyone in the business. An agent with broader data access than it needs, that was previously used by three people, can now be triggered by anyone who finds it in the Agent Store.

Agent 365 is the control layer that lets IT see, govern, and apply policies to everything in that Agent Store catalogue. Without it, you're publishing without visibility.

If you haven't opened Agent 365 yet, here's the sequence that makes sense:

1.  Open the Microsoft 365 admin centre and navigate to Agent 365. Review the registry. Most organisations find agents they weren't aware of — including some deployed by teams without IT involvement. That discovery alone is worth the five minutes it takes.

2.  Check the Agent Store under 'Built by your org.' These agents are now discoverable org-wide. Verify that everything published has been through a proper review and is appropriately scoped.

3.  Use Defender's asset context mapping to go beyond a list of agent names. Understand what identities and cloud resources each agent can actually reach. That's the question that matters for a real security posture assessment.

4.  Set a governance baseline — before the list of agents grows any longer. Decide what data access is permitted by default for new agents, when admin approval is required for publishing, and how permissions will be reviewed over time.

The last step is the important one. It's much easier to establish governance standards before there are 50 agents to manage than after.

AI agents are no longer a future consideration for enterprise IT. They're running now, in your environment, whether IT knows about them or not.

Agent 365 gives you the visibility to see what's there, the controls to govern how agents behave, and the security integration to respond when something goes wrong.

The organisations that will manage AI agents well are the ones that set up the governance layer before the list of agents gets unmanageable. That moment is now.

GTconsult works with organisations across South Africa, the UK, and the US on Microsoft 365 planning, deployment, governance, and adoption. Whether you’re just getting started or trying to unlock value from licences you’ve already bought, we can help.