White paper vii · Microsoft · Full text

The M365 Copilot at the seat-sizing window.

Twenty-two pages on the Copilot seat construct, the E3 versus E5 prerequisite question, the SharePoint and Graph readiness debt, Copilot Studio and the Pay-As-You-Go meter, the role-based rollout matrix, the proof-of-value position and the renewal posture inside the EA cycle.

AuthorMarcus T. Bennett
Pages22
PublishedDecember 2025
UpdatedApril 2026
Reading time34 minutes
Read in browser. Independent. Buyer-side. Not a partner, reseller, or affiliate of Microsoft or any other software vendor.

Inside the paper

  1. Why this paper exists
  2. The Copilot seat
  3. The prerequisite stack
  4. SharePoint and Graph readiness
  5. Copilot Studio and Pay-As-You-Go
  6. Seat rollout sizing
  7. The proof-of-value position
  8. The renewal posture
  9. Reading list and references
Section i

Why this paper exists.

Microsoft 365 Copilot is the most visible enterprise AI deployment of the current cycle. The seat construct is simple to procure and difficult to size correctly, and the procurement decision lands on the buyer at three contested points at once: the Copilot seat itself, the M365 prerequisite stack underneath it and the Copilot Studio Pay-As-You-Go meter alongside it.

The Microsoft sales motion will frame the Copilot expansion as a productivity decision. The buyer-side question is a procurement decision. The decision turns on whether the marginal seat cost will be recovered by deployed-use evidence inside the contract term, and on whether the prerequisite uplift Microsoft proposes alongside Copilot belongs to the Copilot business case or to a separate M365 decision that should be evaluated independently.

This paper is the reading we run inside the Microsoft practice for clients evaluating Copilot inside their Enterprise Agreement renewal cycle. The methodology runs in the Renewal Programme and the Benchmarking Programme, on a fixed fee, contingency or annual retainer basis.

Section ii

The Copilot seat.

The M365 Copilot SKU is sold as a per-user, per-month add-on to a qualifying M365 base licence. The seat carries published-list pricing and is offered through the EA, the MCA-E and the CSP channel under the same broad construct. The activation mechanic inside the tenant assigns the seat to a named user account; the seat is not pooled, not transferable mid-period and not metered by use.

The seat economic logic is therefore the per-seat cost multiplied by the seat count multiplied by twelve, with no discount available against the headline number for unused seats. The annual exposure for an enterprise rollout at published list is a number large enough to matter to the CFO, and the buyer side is therefore the seat count, not the seat price.

Volume discount construct

Discounts on the Copilot seat are available inside the EA negotiation and inside a sufficiently large MCA-E commitment. The discount construct is broadly volume-based and rises with the committed seat count across the term. The construct is reset at each EA renewal; the buyer's discount position is therefore a function of the seat-band the buyer commits to inside the agreement, not a function of the actual deployed-seat count.

The Microsoft commercial posture on Copilot discount is materially tighter than the historical discount posture on M365 base SKUs. Buyers should expect a smaller discount band on Copilot and should not anchor the Copilot negotiation to the M365 E3 or E5 discount they have previously achieved.

The activation question

Activation is the trigger that converts a purchased seat into a billed seat. Inside the EA, the seat is billed from the day it is assigned in the admin centre. The buyer's deployment plan must reconcile the procurement quantity to the assignment cadence, so the billed seat count does not race ahead of the actual rollout.

Section iii

The prerequisite stack.

M365 Copilot does not run on its own. The seat requires an M365 base licence in the qualifying set, which in practice means E3, E5, Business Standard or Business Premium across the enterprise SKU range. The prerequisite stack is the second contested point of the procurement decision.

For an estate on M365 E3, the Copilot seat sits on top of the existing licence at no additional prerequisite cost. For an estate on M365 E5, the Copilot seat sits on top of the more expensive E5 licence and the buyer is paying the higher prerequisite cost regardless of Copilot. For an estate on a mixed E3-and-E5 footprint, the procurement decision turns on which population of users will receive Copilot and whether the population is on the qualifying SKU.

The E5 uplift question

Microsoft will sometimes propose an E5 uplift alongside the Copilot purchase. The framing is that E5 enables Defender, Power BI Pro and the rest of the E5 capability stack, and that the combined uplift is favourable inside the Copilot business case. The buyer-side reading is that the E5 uplift is a separate procurement decision and should be evaluated independently. The Copilot seat does not require E5; it requires a qualifying base licence. Buyers should resist the bundling of the E5 decision into the Copilot decision unless the E5 capability stack is independently justified.

The Copilot prerequisite is a qualifying base. Microsoft will sometimes propose the most expensive qualifying base.

Where Defender for Endpoint, Defender for Office, Defender for Cloud Apps or the rest of the EMS overlay are independently justified, the E5 uplift may be the right answer. But the right answer is rarely arrived at by bundling the security decision and the Copilot decision in the same procurement window. The two decisions should be made on their own evidence.

Section iv

SharePoint and Graph readiness.

M365 Copilot retrieves and reasons over the tenant's own data. The retrieval path runs through Microsoft Graph, which in turn reads SharePoint, OneDrive, Exchange Online, Teams and the rest of the M365 surface. The data plane underneath Copilot is therefore the most consequential readiness work that precedes a meaningful seat rollout.

The principal readiness risks are three. The first is over-shared content: documents that are accessible to a broader population than intended because permissions have decayed across the SharePoint estate. Copilot will surface that content to any user with retrieval access, which can convert a long-standing permission-decay problem into an immediate compliance incident. The second is missing sensitivity labels: documents are not tagged, and Copilot will return content that would otherwise be protected by a label-aware control. The third is residual content in archived SharePoint sites that should have been retired but remains addressable.

Restricted search content and Microsoft Purview

The standard remediation programme for the readiness risk uses Microsoft Purview to apply sensitivity labels at the site, library and document level, applies restricted SharePoint search to limit Copilot retrieval to a curated set of sources during the early rollout, and reviews permission inheritance across the highest-risk sites. The work is meaningful and should be sized into the Copilot business case, not treated as an external cost.

The Admodum readiness audit sizes the remediation cost against the deployed-seat plan. Where the readiness debt is large, the seat rollout cadence is paced to match the remediation rate, not to match the Microsoft commercial pressure. The seat-band negotiated inside the EA must accommodate the readiness work, not anchor against it.

Section v

Copilot Studio and Pay-As-You-Go.

Underneath the Copilot seat sits the Copilot Studio agent construction layer and the Copilot Pay-As-You-Go message meter. The Pay-As-You-Go construct is the consumption tier on which custom Copilot agents bill, with consumption priced per message and charged against the Azure relationship.

The economic significance of the Pay-As-You-Go tier is that it removes the seat ceiling on Copilot economics. The seat-priced construct is bounded by the seat count; the Pay-As-You-Go construct is bounded by the message volume across all custom agents. For estates with significant Copilot Studio activity, the Pay-As-You-Go bill can rapidly become the larger component of the Copilot programme cost.

The Azure relationship

Pay-As-You-Go consumption charges against the Azure billing relationship. Where the buyer holds an Azure MACC commitment, the Copilot Pay-As-You-Go spend reduces the MACC drawdown at one hundred percent of the transaction value. The MACC interaction is favourable; it converts unspent commitment into productive AI consumption, and it places the Copilot Pay-As-You-Go meter inside the existing Azure commercial envelope rather than alongside it.

The buyer-side discipline for Copilot Studio is the same as for any other consumption-priced workload: forecast the message volume across the agent population, monitor the consumption quarterly, set a Pay-As-You-Go budget at the agent level and review the budget against the FinOps telemetry. The discipline is not optional; the meter is fully variable.

Section vi

Seat rollout sizing.

The role-based prioritisation matrix is the central buyer-side tool inside the Copilot seat-sizing engagement. The matrix sorts the headcount into role-types where Copilot use is high, role-types where Copilot use is contested and role-types where Copilot use is low. The seat rollout follows the matrix, not the headcount.

The high-use role-types in the Admodum engagement experience are knowledge-work roles with heavy email volume, document creation, meeting cadence and information synthesis tasks: marketing leads, programme managers, sales operations, finance business partners, HR business partners, legal contract managers, certain consulting and account-management roles. The deployed-use evidence in these populations supports the Copilot seat at the published list price net of negotiated discount.

The contested role-types are operational, administrative and field roles where the Copilot value capture is uneven across the population and depends heavily on the individual user's task mix. Examples include first-line managers, customer-service supervisors, project coordinators, lab and operations staff. The deployed-use evidence in these populations is mixed and the Copilot seat is justified only for a sub-population of high-task-mix users, not for the role-type as a whole.

The low-use role-types are roles where the day-to-day work is not principally information work: production-floor staff, retail-floor staff, drivers, technicians, clinicians on rotation, frontline support staff. The deployed-use evidence in these populations does not support the Copilot seat at the published list price; for those role-types, Copilot is a future-cycle decision, not a current-cycle decision.

Seat sizing follows deployed-use evidence. Seat sizing does not follow enterprise-rollout marketing.

Seat reclamation

The Copilot seat reclamation discipline inside the EA term recovers the seat from users who are not capturing the value. The mechanic monitors per-user Copilot activity inside the tenant, identifies users with sustained low activity over a defined window, runs a confirmation conversation with the user's manager and then reassigns the seat to a user inside a high-use role-type who is currently on a waitlist. The reclamation discipline tightens the seat-band over the term and avoids the licence-creep that historically affects the M365 estate.

Section vii

The proof-of-value position.

The Microsoft-published Copilot productivity claim sets the marketing context for the procurement decision but is not the basis on which the procurement decision should be made. The buyer side is the deployed-use evidence inside the buyer's own estate, captured over a sufficient evaluation window, against a defined user population.

The Admodum proof-of-value methodology runs a structured pilot of six-to-twelve weeks across the high-use role-types identified in the prioritisation matrix. The pilot captures per-user activity telemetry inside the tenant, captures user-reported value at week six and week twelve, and captures a small set of objective measures (time-to-output on defined tasks, meeting-summary quality, email-draft acceptance rate). The pilot deliverable is a memo to the CFO and CIO that scores the value capture by role-type and recommends the production seat-band, the rollout cadence and the reclamation discipline.

The memo is the load-bearing document inside the production rollout decision. The procurement window opens on the memo's recommendation, not on the Microsoft proposal. Where the memo's recommendation is a tighter seat-band than the Microsoft proposal, the buyer carries the memo into the negotiation; where the memo's recommendation is a broader band, the buyer carries the memo into the procurement decision with confidence the production cost will be recovered.

Section viii

The renewal posture.

M365 Copilot sits inside the EA renewal cycle. The seat-add timing, the multi-year ramp design, the volume-discount construct and the relationship to the underlying M365 base SKU negotiation are all anchored to the renewal window.

The buyer-side posture at the renewal window is the seat-band negotiated against the role-based prioritisation matrix, with a multi-year ramp design that paces the rollout against the readiness work and the proof-of-value evidence. The ramp posture is rarely a flat commitment; the better posture is a stepped ramp that opens at the high-use role-type count, steps to the contested role-type count at year two and reviews the low-use role-type question at year three.

The interaction with the underlying M365 base SKU negotiation is material. The buyer should negotiate the Copilot seat construct and the M365 base SKU construct in the same procurement window, with the discount taper across the two constructs reviewed together. Microsoft will sometimes propose a coupling: a tighter Copilot discount in exchange for a more favourable M365 base discount, or the reverse. The coupling is a legitimate negotiation lever for the buyer, provided the underlying seat-band on each construct is independently defensible.

The closing posture protocol is built around the EA renewal preparation methodology set out in the EA Renewal Preparation paper, the Azure interaction set out in the Azure MACC paper, the audit-defence posture set out in the Microsoft SAM Audit Defence paper, and the AI vendor portfolio question set out across the AI Vendors practice. The four readings are the cycle-level package the Microsoft practice runs inside the renewal.

Section ix

Reading list and references.

The M365 Copilot paper sits inside the Microsoft cluster of the Admodum white paper library. The companion papers extend the methodology to adjacent commercial mechanics:

The methodology in this paper is the methodology Admodum has applied across the Copilot rollouts of the last eighteen months. Each engagement is structured as fixed fee, contingency / gainshare or annual retainer, depending on the buyer's posture at the renewal window. The full case studies library carries Copilot engagement summaries; the blog publishes the practice's running analysis.

Next in the series

Paper viii. Microsoft SAM audit defence.

The Microsoft Software Asset Management engagement notification, scope contestation, MAP toolkit treatment, the evidence-gathering protocol and the settlement framing that closes the audit without converting the closing memorandum into a commercial uplift.

Companion programme

Bring an advisor. Renewal Programme.

The methodology in this paper runs inside the Renewal Programme on a fixed-fee, contingency or annual-retainer basis. The seat-sizing window is the moment the multi-year envelope is fixed; the Programme is the operational envelope inside which the rollout is built.

Independence
Admodum is not a partner, reseller, or affiliate of Microsoft, or of any other software vendor. No reseller margin, no Cloud Solution Provider commission, no certified-implementer subcontract.
Software licensing white paper

Run the methodology with a senior advisor.

A senior Admodum advisor will walk the methodology through with your CIO, CFO, sourcing, productivity or HR team on a private call. Engagements run as fixed fee, contingency or annual retainer.