What the subscription actually licenses, the prerequisites, the per user economics, and the deployment questions that change the count. Three knowledge checks along the way, and 1 clip from a senior cloud advisor.
The presenter in this session is an AI generated avatar. The curriculum and guidance are real, produced by Redress Compliance analysts from our consulting engagements and market network.
This is a taught session, not a talking head. The instructor works through analyst grade slides, and three times the video stops on a question with four options on screen. Pause, commit to an answer, and the next slide explains which option is right and why each of the others is wrong. Once in the session the frame splits and a senior cloud advisor gives the view from inside real Oracle negotiations, and the instructor picks the clip apart when the slides return.
The full narration of this session, section by section, for reading and reference. Guest analyst clips are marked.
Welcome back, session sixteen of forty, and this opens module four. Everything so far has been about the productivity stack: how it is bought, how it is priced, and how the mix is decided. Copilot sits on top of all of it and behaves differently from anything we have covered, which is why it gets five sessions of its own. Here is the framing I would ask you to hold. There are two separate questions about Copilot and they get answered by different people with different evidence. Is it valuable, which is a business question. And what are we committing to, which is ours. This course does not have a position on the first one, and I mean that genuinely, because the answer varies enormously by role and by organisation. What we do have is a very clear picture of how the commitment goes wrong, and it goes wrong in the same two ways almost every time: the prerequisite nobody costed, and the adoption nobody measured.
Five takeaways. One, what it licenses: a per user subscription at thirty dollars list requiring a qualifying Microsoft 365 base, and distinct from the Copilot products sold for Sales, for Service, and Copilot Studio. Two, the prerequisite cost: frontline plans cannot carry Copilot today, so a pilot among frontline staff implies a base plan upgrade, and that gets discovered after the budget is approved with some regularity. Three, the real uplift: Copilot added fifty to ninety percent on top of the base E5 seat in the quotes we reviewed, which makes it the largest single per seat decision in the whole stack. Four, the adoption gap: buyers who took the full bundle for everybody reached only twenty five to forty percent adoption in year one. Five, the phasing premium: phased deals that priced Copilot separately saved fifteen to thirty percent against the all in bundle, which is the largest single saving available in this session.
What the subscription licenses, three things to be precise about. It is a per user add on, not a tier: Microsoft 365 Copilot attaches to a qualifying base plan at roughly thirty dollars per user per month list, and it is never bundled into E3 or E5, which means it can never be legitimately argued for as a property of a tier upgrade. You saw that trap in session thirteen. It rides on the apps you already have: the value proposition is Copilot inside the Microsoft 365 applications working over your own tenant data, which is why the base plan is a prerequisite rather than an option, and why deployment turns out to be as much about data readiness as about licences. And it is not the only Copilot: Copilot for Sales, Copilot for Service, and Copilot Studio are separate products with separate prices and separate cases, and proposals move between them freely. A quote that mixes them without labelling which is which needs correcting before you compare it to anything.
The prerequisites, and what each one costs. A qualifying base plan: an enterprise base such as E3 or E5 on the same user, costing nothing new if that person already holds one. Not a frontline plan: frontline F plans cannot license Copilot today, so the cost is a base plan jump from around eight dollars to around thirty six dollars per person, which is the row that surprises budgets. Same user assignment: the Copilot licence and its base sit on one seat, costing nothing directly but removing any shared pool option, which people do ask about. Tenant data readiness: permissions and sensitivity labels that hold up under a tool which surfaces everything a user can already reach, and that is project cost rather than licence cost, frequently the larger of the two. And an owner for adoption: somebody accountable for use rather than just for deployment, costing time, and the absence of it is exactly what shows up later as the adoption gap.
First check. Operations proposes a five hundred seat Copilot pilot among warehouse supervisors who currently sit on a frontline plan. What is the real cost? A, five hundred times the Copilot rate, as proposed. B, the Copilot rate plus the base plan upgrade for all five hundred, because frontline plans cannot carry Copilot and the base move is the larger line on a frontline population. C, nothing, pilots are usually free. D, five hundred times the Copilot rate, minus a pilot discount. Pause it, and as you think, ask what those five hundred people hold today and whether it qualifies.
The answer is B, and this is the most common budgeting error in Copilot proposals. It is entirely mechanical, which is what makes it avoidable. Frontline plans cannot license Copilot, so every one of those five hundred people needs an enterprise base first, moving them from roughly eight dollars to roughly thirty six before a single Copilot licence is purchased. Two lines, and the one nobody costed is the bigger of the two on this population. A and D price only the visible line, and D is worse than A because it adds a discount conversation on top of an incomplete number, which feels like diligence while being the opposite. C is wrong in a way worth naming carefully: even where licences are provided free for a pilot period, the base plan change is a real purchase, and it does not reverse cleanly, because moving people back down a tier mid term requires the step down right from session eleven. Price both lines, and price the exit as well as the entry.
The per user economics, five numbers that decide the case. The uplift is fifty to ninety percent: in the quotes we reviewed, Copilot added that much on top of the base E5 seat, and nothing else in the stack moves a seat that far in one decision. Estate wide costs ten to twenty percent: Copilot proposals added that to overall seat cost where bought estate wide rather than by role. Year one adoption is twenty five to forty percent for buyers who accepted the full bundle for all users. Six month active use sits at twenty five to forty five percent of assigned seats, which is the number to plan a ramp against. And phasing saves fifteen to thirty percent against the all in bundle. Read those five together and the shape is clear. The product may well be valuable, and the commercial risk is not about the product at all. It is that a per seat commitment gets made across a population where fewer than half will be active, on a timeline running well ahead of the evidence.
Guest analyst The Copilot deployment I learned the most from was one where nothing went wrong technically. Professional services firm, about four thousand people, and they bought Copilot for everybody in the first wave. Good discount, genuinely good, because they committed early and estate wide and the account team rewarded that. Nine months later they asked us to help build the case for the renewal, and we pulled the usage data, and about twenty eight percent of assigned seats had been active in the previous month. Now the interesting part was the meeting. The CIO's first instinct was to treat that as an adoption failure and fund a training programme, and I understand why, but the data did not support it. When we split usage by role, the people drafting and analysing all day were using it constantly and rated it highly. The people who had stopped were the ones whose work was mostly meetings, or systems, or physical. It was not an adoption problem. It was that the seat count had been set by headcount rather than by what people actually do. And here is the part that cost them. Because everybody had been licensed at once, they had no way to demonstrate which roles drove the value, so when the renewal came they could neither defend the full number nor justify a smaller one with evidence. They ended up renewing close to flat on a population they knew was too big, because the alternative was an argument they had no data for. Three years of spend, and they finished it knowing less than a phased rollout would have told them in six months.
Not an adoption failure, a counting failure, and no evidence left to argue with. That is the case for tranches. Second check.
Check two. The business case assumes one hundred percent adoption of six thousand Copilot seats. What should you plan for? A, one hundred percent, the business case was approved. B, a ramp built on twenty five to forty five percent active use at six months, with seats added as usage is proven rather than committed against a forecast. C, fifty percent, splitting the difference. D, buy six thousand and reallocate the unused ones internally. Pause it, and ask yourself what actually happens to the seats that get assigned and never opened.
The answer is B. Measured active use sat between twenty five and forty five percent of assigned seats at six months across the engagements behind this course, and approval of a business case does not change adoption behaviour, it only removes the obligation to check it. D deserves real attention, because it sounds pragmatic and it is where most estates actually end up: unused seats get reassigned to whoever asks for one, which converts a targeted deployment into an estate wide one without anybody deciding to do that, and it destroys the usage signal you would need at renewal, which is exactly what happened in the story a moment ago. C picks a number with no evidence behind it, which is better than a hundred percent and still not a plan. The buyer side position is a ramp with named tranches, each released on measured use of the previous one, and that is a structure you negotiate before signature rather than request afterwards, because afterwards you have nothing to trade.
The questions that change the count, three of them, and each is worth more than the discount. Which roles produce content: the return concentrates in heavy content roles, drafting, summarising, analysis, correspondence at volume, so start there, name them from the persona model in session fifteen, and let the rest of the estate wait for evidence rather than for a rollout schedule. What is the data actually like: Copilot surfaces what a user already has permission to see, which turns over broad permissions and unlabelled sensitive content from a theoretical problem into a live one, and that work has a cost and a timeline that belong in the case. And who owns adoption after go live: deployment ends, adoption does not, and a named owner with a usage target and a quarterly review is the difference between the twenty five percent outcome and something better. Notice that none of those three are licensing questions and all three change the licence count.
Phased against all in, the same product in two commercial shapes. Seats: the whole population from day one, against named tranches released on measured use. Evidence: produced after the commitment if at all, against produced before each tranche by design. Adoption: twenty five to forty percent in year one, against adoption concentrated in roles that were chosen for it. Price: the bundle rate applied to everybody, against fifteen to thirty percent lower in the deals we reviewed. And the renewal position, which is the row that compounds: an all in deployment gives you no usage signal and therefore no argument, while a phased one gives you a measured population and a defensible number. Think about what that means over two cycles. An all in deployment produces three years of spend and no evidence, so the next renewal starts from exactly where this one did. A phased deployment produces a usage record, and a usage record is what a renewal argument is actually made of.
Last check. The account team offers a deep Copilot discount in exchange for an estate wide three year commitment. What is the counter? A, accept, the discount is real and large. B, a phased structure with named tranches released on measured adoption, and the rate held for the term, because phased deals saved fifteen to thirty percent against the all in bundle even before the shelfware is counted. C, counter with a deeper discount on the same shape. D, decline Copilot entirely until the market settles. Pause it. The discount here is genuine, so the question to ask is what it is a discount on.
The answer is B. The discount is real, and it is a discount on a population where fifty five to seventy five percent will not be active in year one, which makes it a large percentage off a number that is itself too big. The move is to take the rate and refuse the volume: negotiate the per seat price as though for the full population, hold it for the term, and then release seats in tranches against measured use. Vendors accept this more often than buyers expect, because it protects their rate card while only deferring their volume, and a deferred sale is a much easier internal conversation for them than a lost one. A pays for adoption that has not happened. C repeats the session ten error, negotiating the ratio rather than the number. D is a defensible position for some organisations and a poor default, because it forfeits the learning that makes the next decision a good one, and the phased structure buys you that learning at a fraction of the exposure.
The Copilot buying method, three steps before any commitment, and the output is a tranche plan with a rate attached rather than a seat number. One, name the first tranche: from the persona model, the roles where content production is the actual work, which is usually a small fraction of the estate and almost never a whole department. Name the people rather than the headcount, because named people can be followed up and a headcount cannot. Two, price both lines: Copilot plus any base plan upgrade the tranche implies, per person, at your own rate, and if the tranche includes frontline staff then the base plan line is probably the larger of the two and it needs to be visible in the paper. Three, negotiate rate now and volume later: hold the per seat rate for the term at full population volume, commit only to the first tranche, and write the usage threshold for subsequent tranches into the agreement. That structure survives both outcomes, which is the point of it.
Session sixteen, three sentences. One: Copilot is a per user add on at around thirty dollars list requiring a qualifying base plan, never bundled into E3 or E5, so it can never legitimately be justified as part of a tier upgrade. Two: frontline plans cannot carry it, which means a Copilot pilot among frontline staff implies a base plan upgrade that is often the larger of the two lines and is usually discovered after approval. Three: adoption runs at twenty five to forty five percent of assigned seats, so hold the rate for the full population and release volume in tranches against measured use, which was worth fifteen to thirty percent in the deals we reviewed. Next session is the half of the Copilot bill that is not per seat, and if you only budget for seats you are budgeting for part of it.
Homework, about an hour, and this week you size your first tranche. One, find the content roles: from your persona model, the roles where drafting, summarising, and analysis are the work rather than an occasional task. Two, check their base plans: which of them hold a qualifying base and which sit on a frontline plan, because that second group carries two lines rather than one. Three, price both lines, per person, at your own rate, and produce a single number for the tranche. Four, write the usage threshold: what measured adoption would justify releasing the next tranche, as a percentage and a window, agreed before anybody buys anything, because agreeing it afterwards is a different and much harder conversation. Five, ask the data question: put one question to your security owner in writing, are our permissions and sensitivity labels ready for a tool that surfaces everything a user can already reach.
Five reads before next session, all free on redress compliance dot com. First, Microsoft 365 Copilot enterprise licensing, which is the buyer side view covering prerequisites, the addressable seat, and the commercial framework. Second, Microsoft 365 Copilot pricing, for current rates and how the uplift lands against a base seat. Third, the CIO playbook on adopting Microsoft 365 Copilot and AI services, which covers the deployment and adoption side that decides the count. Fourth, the Copilot true cost analysis, which covers both layers of the bill including the one that is not per seat, and that is a good primer for next session. And fifth, negotiating Microsoft generative AI contracts, on phasing, ramps, and the specific terms that make a staged commitment actually work. Next session is Copilot Chat, agents, and consumption: the metered layer beside the subscription, credits, pay as you go, and how consumption pricing behaves once agents are in production. See you there.