Category: AI

The Quiet Productivity Cost of Watching AI Work

image

I noticed something a few weeks back during a busy Friday afternoon. I’d asked Copilot in Word to pull together a draft summary of a long client document, and instead of moving on to the next thing on my list, I just sat there. Watching. Cursor blinking. Sentences slowly stitching themselves across the screen like I was waiting for a kettle to boil. It took me a good thirty seconds to realise I was, in effect, staring at a digital pot — and getting absolutely nothing else done while I did it.

That small moment has stuck with me. Because I don’t think I’m the only one doing it.

The watching trap

There’s a quiet productivity tax that nobody really warned us about with generative AI inside Microsoft 365. We’ve been told these tools save us hours. And they will — but only if we actually use those hours. The moment we anchor ourselves to the screen and watch Copilot draft a reply in Outlook, summarise a meeting recording in Teams, or build out a deck slide by slide in PowerPoint, we hand back every minute of the gain.

I think this happens because the output feels unfinished until it’s done. The brain treats it a bit like a conversation — and you don’t walk away from someone mid-sentence. But Copilot isn’t speaking to you. It’s working for you. And it doesn’t care whether you’re in the room.

The result is a strange new flavour of busywork. You look productive. You’re sitting at your desk, focused, eyes on the screen. But the actual output of your time is whatever Copilot was going to produce anyway. You’ve added nothing. You’ve just supervised a process that didn’t need supervising.

Why staring at it doesn’t help

The other problem with the watching habit is that it isn’t even useful. You can’t speed Copilot up by looking at it harder. You’re not catching errors in real time, because most of us don’t read carefully enough mid-generation to spot a problem — and you’ll review the final output once it’s done anyway. The watching is pure overhead.

Worse, it primes a passive mindset. When you sit and observe the machine doing the work, you start to mentally check out. The next task on your list feels heavier than it should. You lose the rhythm of context-switching that real knowledge work depends on. By the time the draft email or summary lands, you’ve already half-disengaged. So instead of pouncing on it, reviewing it sharply, and sending it on its way, you take another minute or two to gather yourself.

That’s two layers of cost. The time you spent watching, and the time it takes to mentally re-enter the work.

Treat Copilot like a colleague, not a performance

The shift I’ve had to make is treating Copilot the same way I’d treat anyone I’ve delegated something to. You don’t stand over a colleague’s shoulder while they write a document. You hand it off, you go do something else, and you come back to review when it’s ready.

So when I ask Copilot in Excel to analyse a dataset, I switch to my inbox and clear a few replies. When I have Copilot in Word drafting something substantial, I move into Teams and respond to chats. When a deck is being assembled in PowerPoint, I’m reviewing tomorrow’s calendar or skimming a SharePoint document I’d been putting off. The five or ten seconds of context-switch cost is well worth the two or three minutes I would have otherwise stared away.

The deeper habit, though, is queueing the work. I now line up several AI-assisted tasks at once. A summary running here, a draft being produced there, an analysis underway in another window. Copilot is happy to run in parallel across Microsoft 365. There’s no good reason to make those tasks sequential by tying each one to your eyeballs.

What I’m watching next

The thing I’m paying attention to from here is how teams handle this collectively. Because once AI is doing more of the small tasks across an organisation, the productivity ceiling stops being defined by what the tools can do and starts being defined by what their humans do while the tools work. The businesses that win the Copilot game won’t be the ones with the best prompts. They’ll be the ones whose people have stopped sitting and watching, and started filling that reclaimed time with thinking, deciding, and acting.

The technology is doing its part. The next move is ours.

Where Do Your Uploaded Documents Actually Go in Copilot Notebooks?

image

One of the questions I get asked most often about Microsoft 365 Copilot Notebooks is deceptively simple: when I upload a document into a notebook, where does it actually live? It’s a fair question. If you’re an MSP, an administrator, or anyone responsible for governance, “it’s in the cloud somewhere” isn’t a good enough answer. You need to know exactly where that data sits, who can reach it, and what compliance controls apply. The answer turns out to be more interesting than most people expect, and it hinges on a relatively new piece of the Microsoft 365 storage platform called SharePoint Embedded.

The short answer: SharePoint Embedded

When you upload a document into a Copilot Notebook, it does not land in your OneDrive, and it doesn’t go into a regular SharePoint site or document library that you can browse to. Instead, it’s stored in SharePoint Embedded — specifically inside a user-owned container.

Here’s the part that surprises people. Copilot Notebooks, Copilot Pages, and Loop’s “My workspace” all share the same single user-owned container per user. You don’t get a separate container for each. The first time you need any one of those experiences, Microsoft provisions one container and reuses it for all three. Even the container’s name depends on which app you opened first: it’s called “Pages” if you visited the Microsoft 365 Copilot app first, or “My workspace” (localised to your Loop language) if you opened Loop first.

There’s a governance wrinkle worth committing to memory: in the SharePoint admin center, in PowerShell, and in Purview audit data, this container’s application name always shows as “Loop” — even when it only holds Copilot Notebooks. There is no separate “Copilot Notebooks” application filter. So if you go hunting for Copilot content in your audit logs and only search for “Copilot”, you’ll come up empty. Look for Loop.

So what is SharePoint Embedded?

SharePoint Embedded is an API-only file and document management system built on the same proven Microsoft 365 storage platform that powers SharePoint and OneDrive. The key word is API-only. Unlike a normal SharePoint site, there’s no friendly web UI you can navigate to. When an application uses SharePoint Embedded, it creates a separate storage partition inside your Microsoft 365 tenant, and the documents in that partition are only accessible through Microsoft Graph APIs — and only to the owning application.

Within that partition, the application stores content in entities called File Storage Containers. Think of a container as an API-only document library: it can hold any file type, supports folders, versioning, search, and co-authoring, but it’s dedicated to and reachable by just the one app that owns it. That isolation is the whole point. The files your Copilot Notebook depends on are walled off from other applications, yet they still benefit from the full richness of the Office stack — you can open an uploaded Word or Excel file in Office for the web straight from the experience.

This is the same architecture Microsoft uses under the hood for Loop and Designer. Copilot Notebooks is simply another first-party consumer of the platform.

The detail that matters most: your data stays in your tenant

This is the line I always emphasise with clients. The storage partition that SharePoint Embedded creates lives inside your own Microsoft 365 tenant. Your uploaded documents do not leave your tenant boundary. That means everything your existing Microsoft Purview controls already do, they continue to do here:

  • eDiscovery — content is discoverable

  • Auditing — actions are logged (remember: under the “Loop” application name)

  • Data Loss Prevention (DLP)
  • Retention policies and sensitivity labels
  • Conditional access

So while the storage mechanism is new, the compliance posture is reassuringly familiar. The data is yours, it’s in your tenant, and your governance tooling applies.

Quotas, limits, and a billing nuance

Here’s a distinction that trips people up. The general, developer-facing SharePoint Embedded model bills storage separately through an Azure pay-as-you-go subscription, and that storage does not count against your SharePoint quota. But Microsoft’s first-party use of it for Copilot Pages and Copilot Notebooks works differently. Copilot Pages and Copilot Notebooks content counts against your organisation’s existing SharePoint storage quota — there’s no separate Azure bill for it. The user-owned container has a hard ceiling of 25 TB, which can’t be raised or lowered.

Lifecycle: tied to the user, with sharp edges

The container’s lifecycle is bound to its owner. Content is private by default, much like OneDrive — there’s no forced sharing. When the owning user’s account is deleted, the container is scheduled for deletion and follows the same lifecycle as OneDrive, including a manual handoff step at departure and the option to permanently reassign the container to a new owner.

One critical warning for anyone planning their data protection strategy: there is no end-user recycle bin for Copilot Notebooks. If a notebook is deleted, neither the user nor an administrator can recover it. That’s a meaningful gap compared to the recycle-bin safety net we take for granted in SharePoint and OneDrive, and it’s worth flagging to end users before they start relying on Notebooks for anything important.

Why this matters

Copilot Notebooks feel lightweight and personal, but underneath sits real enterprise-grade storage that you already know how to govern — just wearing a new name. Knowing it’s SharePoint Embedded, that it surfaces as “Loop” in your admin tools, that it counts against SharePoint quota, and that it has no recycle bin turns “somewhere in the cloud” into something you can actually manage.

Copilot Notebooks storage & governance

SharePoint Embedded platform

The MSP Skills Gap Nobody Is Talking About Yet

image

I had a conversation with an MSP owner last week that has been rattling around in my head ever since. He was telling me, proudly, about how his team had just finished a big project hardening a client’s endpoint stack. Patching, EDR, conditional access, the lot. Then almost as an afterthought he mentioned the same client had quietly turned on Copilot for sixty users and was already building their first agent in Copilot Studio. He had no plan for any of it. No policy, no review process, no clear idea who in his team would actually own it. And here is the uncomfortable part. He is not unusual. He is the rule.

The growth in AI agents inside SMB environments is going to be the steepest curve we have seen in years, and most MSPs are walking into it carrying the wrong toolkit. The skills that built a successful managed services business over the last decade are not the skills that will keep customers safe and productive over the next one. That gap is widening every week, and very few MSP owners I speak to have noticed.

Agents are not endpoints

For twenty years MSPs have been organised around things. Devices, servers, mailboxes, firewalls. You patch them, monitor them, back them up, replace them. The whole MSP operating model — RMM, PSA, ticketing, SLAs — assumes a world of static assets that misbehave in fairly predictable ways.

An AI agent is none of those things. It is not an endpoint. It does not sit still. It reads documents in SharePoint, drafts replies in Outlook, pulls data from line-of-business systems, and acts on behalf of a user across surfaces the MSP has never had to think about as a single connected thing. When a Copilot agent fetches the wrong document and pastes confidential numbers into an external chat, no RMM alert is going to fire. The questions are different too. Not “is it patched?” but “what did it do today, and why?” That is a governance and behaviour problem, not an infrastructure one.

The new skill set is governance, data and prompts

Managing agents well leans on a set of muscles most MSPs have never had to build. Understanding identity scope in Entra so an agent cannot reach data it has no business touching. Configuring sensitivity labels and DLP in Purview so a chatty agent does not quietly become a leak. Reviewing prompt design and grounding sources in Copilot Studio before an agent is let near real users. Watching audit logs in the Microsoft 365 admin centre for patterns of agent behaviour that look off.

This is closer to the work of a data steward or a security analyst than a traditional systems engineer. It is slower, more interpretive, and more about judgement than ticket throughput. It rewards curiosity and writing skills as much as PowerShell. The MSP business model has not been built for that kind of work, and the hiring pipeline certainly has not.

The retraining window is now

Here is the bit that worries me. Customers are going to assume their MSP has this covered. They will turn on Copilot, build agents in Copilot Studio, plug them into their CRM, and look across the table expecting the same calm competence they get for backups. When something goes wrong — a leaked document, an agent that quietly emails the wrong list, a workflow that has drifted off purpose — they will ring their MSP. And most will not be able to help.

The MSPs that get ahead of this will start small and start now. Pick one client, one agent, and learn it end to end. Read the audit logs. Write the policy. Build the review cadence. The technical hardening skills will still matter. They are just no longer enough on their own.

Your clients are building AI agents right now. Nobody’s watching.

image

A client rings you. “One of the team built a little AI helper that answers questions from our SharePoint. It’s started giving odd answers. Can you take a look?”

So you go looking. There’s no record of it. No owner listed. No idea what data it reaches into. And while you’re in there, you find eleven more — built by people who left months ago, quietly wired up to who-knows-what.

That’s not innovation. That’s debt.

Here’s what nobody mentions when an SMB switches Copilot on: everyone in that tenant can already build agents. Not eventually. Today. The moment Copilot Studio and Agent Builder light up, every staff member can spin up an AI agent, point it at company data, and share it around.

And by default, all of it lands in one place — the default Power Platform environment — which you can’t delete and can’t fully lock down.

Notice what’s missing? Any decision about who’s allowed, what they can touch, or who cleans up afterwards.

What is agent lifecycle governance, really?

Strip the jargon and it’s three decisions you make before the agents arrive: where they’re allowed to live, what data they’re allowed to touch, and who’s on the hook when one misbehaves.

Microsoft hands you three levers for exactly that.

Environments are the containers agents live in. Data policies decide which connectors an agent can talk to. Maker controls decide who’s even allowed to build in the first place.

Get those three right and the eleven mystery agents never happen. Get them wrong and you’re the one explaining to a client why their customer list ended up somewhere it shouldn’t.

This isn’t about saying no to AI. It’s about drawing the lines once, so everyone can say yes safely.

Step-by-Step: putting guardrails up before the sprawl

You don’t need a six-month project. You need an afternoon in the Power Platform admin centre.

Lock down who can create environments

Tenant settings first. Stop every user being able to spin up new environments on a whim. Restrict environment creation to admins, so a new space is a decision — not an accident.

Treat the default environment as hostile

You can’t delete it, so assume the worst will land there. This is where ungoverned agents breed. Keep nothing sensitive in it, and route anything serious somewhere else.

Give real agents a real home

For anything a client actually depends on, follow the dev-test-prod pattern Microsoft recommends: build in a development environment, validate in test, publish to production. Lock each one to an Entra security group so only the right people get in. Build in production and you’re editing live, in front of users, with no safety net.

Set a data loss prevention policy

This is the big one. In the admin centre, create a data policy and sort your connectors into groups:

Business     — SharePoint, Dataverse, Outlook, Teams
Non-Business — everything else, by default
Blocked      — public HTTP, personal email, social, FTP

An agent can’t combine data across the Business and Non-Business groups. So a bot reading your client’s SharePoint physically cannot also push that data to some random web endpoint.

Notice what’s missing? You didn’t write a line of code. You drew a line, and the platform enforces it for every agent, forever.

Turn on Managed Environments where it counts

For your production spaces, switch on Managed Environments. That gets you sharing limits, weekly usage insights, and an actual record of what’s being built — the visibility that turns “eleven mystery agents” into a list you can read on a Monday morning.

Why this actually changes behaviour

Most MSPs treat this as a clean-up job. Something you’ll get to after the agents pile up.

Wrong order. Governance is cheap before the sprawl and brutal afterwards. Every agent you let breed in the default environment is one you’ll eventually have to find, decode, and either rescue or retire — usually under pressure, usually after the person who built it has gone.

“But my clients are tiny — three agents, not three hundred.” Sure. Govern the three now and the thirtieth looks after itself. Skip it, and you’ll meet the thirtieth as an incident.

Here’s the real win. When the guardrails go up first, makers still build. They just build inside lines you drew. Innovation doesn’t stop — it stops being a liability.

And for you as the MSP, that’s a conversation worth having. “We make sure your team’s AI agents are governed, owned and safe” is a service. A monthly line item. Not a favour you do at 11pm when one breaks.

Copilot agents don’t get tired, and they don’t ask permission. Govern them like staff, not like features.

My recommendation? Do the afternoon in the admin centre before your client’s first agent — not after their twelfth.

Agent governance isn’t there to slow your clients down. It’s there to make sure the thing someone built on Tuesday isn’t the thing you’re explaining to their lawyer on Friday.

CIA Brief 20260627

image

Security & Threat Intelligence
Microsoft Product Updates & Announcements
Cloud & AI
Sustainability

After hours

When a cyber attack took 100 hospitals offline – https://www.youtube.com/watch?v=WxY6aLRVgcI

Editorial

If you found this valuable, the I’d appreciate a ‘like’ or perhaps a donation at https://ko-fi.com/ciaops. This helps me know that people enjoy what I have created and provides resources to allow me to create more content. If you have any feedback or suggestions around this, I’m all ears. You can also find me via email director@ciaops.com and on X (Twitter) at https://www.twitter.com/directorcia.

If you want to be part of a dedicated Microsoft Cloud community with information and interactions daily, then consider becoming a CIAOPS Patron – www.ciaopspatron.com.

Watch out for the next CIA Brief next week

Before You Buy the Copilot Licence, Do This First

MAI_a705418914201c07

Everyone wants to know what Copilot can do. Almost nobody asks what Copilot will find.

That’s the question that actually matters. Copilot doesn’t create new access — it works entirely within your existing Microsoft 365 permissions. It can only surface what a user is already allowed to see.

Sounds safe. It’s not. Not if your SharePoint environment looks like most tenants I’ve walked through.

Sites shared with “Anyone with the link” since 2021. Files in folders with permissions no one’s reviewed in years. Ownerless sites stuffed with content nobody knows exists. When your finance manager asks Copilot to “summarise what we know about Project X,” it’ll pull from everything she can already access — including documents she’d have had to know to search for directly.

That’s not a Copilot problem. That’s the data governance problem you already had, just made visible.

My recommendation? Run the readiness assessment before you assign a single licence.

What is the Copilot Readiness Assessment, really?

Most people think readiness means “do you have the right licence and update channel.” The Copilot Readiness Report in the Microsoft 365 admin centre does tell you that — which users are technically eligible, which devices are on the right update channel, who your best pilot candidates are.

That’s the easy half.

The hard half is whether your data is in a state that Copilot should be let near. That check lives in a completely different place, and most readiness guides skip it entirely.

Notice what’s missing? Almost every “Copilot readiness checklist” you’ll find online focuses on licence eligibility. The data side is where the actual risk sits.

Step-by-Step: Running a Proper Readiness Check
Open the M365 Copilot Readiness Report

Go to the Microsoft 365 admin centre. In the left nav, select Reports > Usage, then choose Microsoft 365 Copilot and open the Copilot report. Click the Readiness tab.

You’ll see prerequisite licence counts, update channel eligibility, and a user table flagging suggested Copilot candidates. Export the list. It gives you a concrete starting point for a pilot conversation with your client.

Check for Oversharing in SharePoint

Open the SharePoint admin centre. Go to Reports > Data Access Governance. This is where you find the oversharing risk — sites with “Anyone” sharing links active, files broadly accessible across the tenant, high-member-count sites with no clear owner.

Work through the data access governance reports. Anything flagged here is content Copilot can reach on behalf of any user who has permission.

By default, SharePoint sharing is set to the most permissive option. Most tenants have never changed it.

Run the Content Management Assessment

Still in the SharePoint admin centre, go to Advanced Management > Content Management Assessment and select Start assessment. This surfaces inactive sites, ownerless sites, and sites that haven’t been attested by anyone recently.

SharePoint admin centre
  > Advanced Management
    > Content Management Assessment
      > Start assessment

Rerun it every 30 days. This isn’t a one-time exercise. It’s a recurring conversation starter with every client who has Copilot.

Review Your Sensitivity Labels

Open the Microsoft Purview compliance portal > Information protection > Labels. Check whether labels are deployed and whether content users will ask Copilot about is actually labelled.

Sensitivity labels travel with content. Copilot honours them at response time — it won’t surface content a user doesn’t have decrypt rights for. No labels means no enforceable control over what ends up in a Copilot response.

They’re not a Copilot feature. They’re the floor you build on.

Why This Actually Changes Behaviour

Here’s the real win.

Running this before you sell the licence gives you a different kind of client conversation. Not “here’s what Copilot can do” — but “here’s what your data looks like right now, and here’s what we need to fix before Copilot is safe to use.” That’s a trusted adviser conversation, not a licence upsell.

Microsoft’s Secure & Governed Data Foundation blueprint organises this into three pillars: remediate oversharing, set up guardrails, meet regulations. It’s worth reading before your next client review. Print it. Take it in.

If you’re not showing clients this work before you enable Copilot, you’re not protecting them — you’re just adding a powerful AI to a mess.

Copilot doesn’t create oversharing. It reveals it. Fix the foundation first, then turn on the power.

Copilot Cowork Just Hit GA — and CSP-Managed Tenants Are Hitting a Billing Wall

copilot-cowork-csp-billing-header

Why “Your organization is managed by your solution provider” appears, why the customer’s own Azure subscription won’t save you, and the exact partner-side fix.

The symptom

Here’s a scenario that is going to land on a lot of MSP desks over the coming weeks. You have a client who has been happily using Microsoft 365 Copilot Cowork while it was in preview. They love it. They want to roll it out to more people. Then Cowork moves into General Availability, and suddenly they can’t add any new users to it. When they go digging in the Microsoft 365 admin centre, into the Copilot section to sort out billing, they are met with this brick wall:

The exact message

“Your organization is managed by your solution provider. Copilot credit setup for organizations managed by a solution provider must be set up by your provider. Contact your provider to enable consumption-based AI services for your organization.” The kicker is that this particular client already has a perfectly good pay-as-you-go Azure subscription sitting in their tenant. So the natural reaction is: I have an Azure subscription, I have billing, why is Microsoft telling me to phone a friend? The short version is that this is not a bug, it is not a permissions problem, and it is not something the client can click their way out of. It is a commerce-channel issue, and the resolution lives with whoever holds the CSP relationship — which, for most of us reading this, means it lives with us.

What actually changed at GA

When Cowork was in preview, the gloves were off — people could use it without the full commercial billing plumbing being in place. At GA, Microsoft moved Cowork behind what they call usage-based billing, powered by Copilot Credits. This is the same consumption model that sits alongside fixed per-user Copilot licensing. Worth noting precisely: as it stands today, this usage-based billing method only applies to Copilot Cowork and the Work IQ API — it is not the whole Copilot estate. Microsoft has said more agents and services will be folded into this model over time, but right now Cowork is the headline reason an MSP will trip over this.

How the new billing model is wired up

Usage-based billing is managed from a new node in the Microsoft 365 admin centre: Copilot, then Cost Management. That is where an admin activates a default spending policy, sets monthly and per-user spending limits, configures alert thresholds, and — critically — chooses a billing method. The billing method is an Azure subscription. Copilot Credits are drawn against that subscription on a pay-as-you-go basis (with optional pre-purchase plans layered on top for discounting, but ignore that for now). So the whole thing hinges on one question: which Azure subscription is allowed to be the billing method? And that is exactly where a CSP-managed tenant comes unstuck.

Why the client’s existing Azure subscription doesn’t help

This is the bit that catches people out, so it is worth being precise. The client genuinely has an Azure subscription. But the Copilot Cost Management setup, in a CSP-managed tenant, will not let them attach it — because that subscription is almost certainly on the wrong commerce channel. When a tenant is managed under the Cloud Solution Provider program, Microsoft routes all consumption commerce — Azure, marketplace, and now these AI services — through the partner’s Microsoft Partner Agreement billing account. A subscription the customer signed up for directly (a credit-card MOSP or direct Microsoft Customer Agreement Azure sub) is a completely separate billing relationship that the partner does not own. The commerce platform sees the tenant flag that says “this org is CSP-managed”, looks for a billing source on the partner channel, doesn’t find one, and throws up the “managed by your solution provider” gate. The presence of some other Azure subscription in the tenant is irrelevant to that check.

The mental model: who owns the commerce channel

If you keep one diagram in your head, make it this one. A CSP-managed customer’s consumption billing has to originate from an Azure plan that the partner provisions under their Microsoft Partner Agreement. The Azure plan gives the customer access to Azure services at pay-as-you-go rates under a Microsoft Customer Agreement, and the resulting Azure subscription lives in the customer tenant but invoices back to the partner. That partner-channel subscription is the only thing the Copilot Cost Management billing-method picker will accept for a CSP tenant. Here is how the three channels compare:

– Billing channel
– Who owns it
– Works as Cowork billing method in a CSP tenant?

Direct / MOSP Azure (customer’s own credit card)
The customer
No — wrong channel, not visible to the CSP gate

Direct Microsoft Customer Agreement (Azure direct)
The customer
No — tenant is flagged CSP-managed, so this is bypassed

Azure plan under Microsoft Partner Agreement (CSP)
The partner (you)
Yes — this is the channel the gate is looking for

The fix, step by step (partner side)

Assuming you are the CSP for this client, the resolution is to provision an Azure plan and an Azure subscription for them through the partner channel, then point Copilot Cost Management at it. Work through these in order:

  • Confirm the Microsoft Customer Agreement is accepted. In Partner Center, open Customers, select the customer, and check the Microsoft Customer Agreement status on their Account page. You cannot purchase an Azure plan until the MCA is in place — invite them to sign it directly with Microsoft if it isn’t.

  • Purchase the Azure plan. In Partner Center, with the customer selected, choose Add products, set Segment to Commercial, find Azure plan, add to cart, Review and Buy. If the customer already has an active Azure plan, skip to the next step.

  • Create an Azure subscription under that Azure plan. Sign in to the Azure portal with your Partner Center (Admin agent) credentials, making sure you are in your partner directory, not the customer’s. Go to Cost Management + Billing, pick the billing scope for the account where the customer sits, open Customers, select the customer, then All billing subscriptions, and choose Add. Pick a Usage based / Azure subscription with the plan set to Microsoft Azure Plan, then Review and create.

  • Lean on AOBO for the Azure rights. Subscriptions you create through CSP grant Admin-on-Behalf-of, which gives any Admin agent in your partner tenant Owner rights on that subscription automatically. That satisfies the setup wizard’s requirement for Owner or Contributor on the Azure subscription and resource group — no extra role assignment needed.

  • Configure usage-based billing in the customer’s M365 admin centre. Go to Copilot, then Cost Management, and select Get Started. In the Billing method section choose the new CSP Azure subscription. Set a sensible monthly spending limit, a per-user spending limit, and alert recipients and thresholds, then Activate. The Cowork block clears and you can add users again.

Prerequisites worth double-checking before you start

Setup will fail at the last hurdle if any of these are missing, so confirm them up front:

  • On the Microsoft 365 side, the person running the Cost Management setup needs Global administrator or Billing administrator. AI administrator and License administrator can create spending policies and manage limits, but they cannot set or change the billing method.

  • The tenant must have at least one SharePoint licence, or a licence that includes SharePoint. This is a real prerequisite for the Copilot billing node, and easy to overlook on a lean tenant.

  • You need Owner or Contributor on both the Azure subscription and a resource group in it. Via CSP and AOBO this is automatic, but if you have deliberately stripped AOBO and are using Lighthouse or directory accounts instead, make sure the identity doing the setup actually has those rights.

  • An Azure resource group must exist in the subscription — the wizard can create one for you during setup if needed.

Direct CSP vs indirect reseller — know which one you are

There is an important fork here. If you are a direct-bill CSP partner, you hold the Microsoft Partner Agreement billing account yourself and you run every step above in your own Partner Center. If you are an indirect reseller sitting underneath a distributor or indirect provider, you do not own that billing account — the Azure plan purchase is initiated through your indirect provider’s flow, not your own Partner Center billing scope. In that case you coordinate with your distributor to get the Azure plan provisioned, and then you can still handle the Azure subscription creation and the customer-side Cost Management configuration. And if it turns out a completely different provider holds the CSP relationship for this client, then none of this is yours to fix directly — that provider has to provision the Azure plan, or the CSP relationship needs to be transferred to you first.

Gotchas and things I’d watch

A few practical landmines that are easy to step on with this new model:

  • Budgets notify, they don’t stop. A budget on a billing policy triggers email alerts at the thresholds you set, but by default it does not enforce a hard cap or interrupt service. If you want a genuine ceiling, use the monthly spending limit and per-user limits in the Cost Management spending policy, which can actually cut access when hit.

  • Set a per-user limit on day one. The whole point of consumption billing is that a single enthusiastic user can run up real spend. The per-user monthly limit is optional in the wizard, but for an MSP managing someone else’s bill, treat it as mandatory.

  • Region selection is sticky. When you create the billing policy you choose a region that determines where tenant ID and usage data are stored, and you cannot edit the subscription or resource group tied to a policy afterwards. Get it right the first time.

  • Turning pay-as-you-go off is not instant. Disconnecting a service from a billing policy can take up to two hours to actually stop users, so don’t panic if access lingers briefly after you flip it off.

  • Pre-purchase plans layer on top, they are not an either/or. If cost predictability matters, a Copilot Credit pre-purchase plan gives discounted credits that are consumed first, with pay-as-you-go catching any overage. You don’t have to choose one or the other.

The takeaway

This is going to be a recurring support ticket. Cowork going GA is good news, but the GA billing model assumes the customer can attach their own Azure subscription — and for CSP-managed tenants that assumption simply doesn’t hold, no matter how many Azure subscriptions are already sitting in the tenant. The fix is entirely on the partner side: provision an Azure plan and subscription through the CSP channel, then point Copilot Cost Management at it. If you manage Microsoft 365 customers through CSP and any of them are using Cowork, get ahead of this now, because the moment GA flips the billing requirement on, their ability to add users stops until you’ve done the plumbing. As always, plan it, test it on one tenant, and document the steps so your L1 team can repeat them.

Can MSPs Actually Bill for Copilot Cowork?

image

I’ve been mulling over a question that doesn’t get asked enough, and I think it deserves a hard look: when Copilot Cowork lands with pay-as-you-go billing, do small and midsize MSPs actually have the skills to handle it? Not the product. The billing. Because from where I sit, that’s the part most of us are least prepared for.

For years, the SMB MSP model has run on something beautifully predictable: per-seat licensing. A client has thirty users, you sell thirty licences, you mark them up, and everyone knows what next month’s invoice looks like before it arrives. That predictability is the whole foundation. It’s what lets you quote a managed services agreement with a straight face. Consumption billing pulls that foundation out from under you.

We’ve Never Had to Read This Kind of Meter

PAYG is a different animal. Usage goes up and down. Costs follow. Suddenly you’re not selling a fixed thing, you’re selling access to a meter that ticks based on what people actually do inside Copilot. And here’s the uncomfortable truth — most of us have never had to read a meter like this before. We don’t have the muscle for it.

Think about the questions a client will ask the moment their first variable bill arrives. Why was it higher this month? Which users drove that? Was it worth it? If your answer is a shrug and a forwarded Microsoft invoice, you’ve got a problem. You need to pull the usage data, make sense of it, and explain it in plain English. That’s not a skill most SMB MSPs have built, because we’ve never needed it.

Configuring It Is the Easy Part

Turning Copilot Cowork on through the admin centre isn’t the hard bit. Microsoft will make that straightforward enough. The hard bit is everything that wraps around it — setting spending limits so a client doesn’t get a nasty surprise, deciding who gets access, and putting guardrails in place before usage runs away from you.

Then comes reporting, which is where I think the real gap shows. Can you stand in front of a client at the monthly meeting and show them, clearly, what they consumed and what they got for it? You’ll be living in the Microsoft 365 admin centre and the usage reports, and you may well end up pulling that data into Excel — perhaps asking Copilot itself to summarise the month’s consumption into something a business owner can read in thirty seconds. If you can’t produce that story, the client will assume the worst.

This Is a Discipline We Have to Learn

What worries me isn’t the technology. It’s that consumption billing is a genuine discipline, and it’s one the SMB MSP world has largely skipped. The cloud providers have been doing variable billing for years. Most of us serving small business have not. We’ve been comfortable in fixed-price land, and Cowork is going to ask us to grow up fast.

So I’d put the question back to you honestly. Could your business take on a client with Copilot Cowork tomorrow, configure it sensibly, manage the spend, and report on it with confidence? If there’s hesitation in that answer, you’re not behind — you’re normal. But the MSPs who close that gap early, who learn to read the meter and tell the story, are the ones who’ll own this conversation. The rest will be forwarding invoices and hoping nobody asks why.