What is confirmed, what is assumed, and how to plan a tier strategy without betting a three year commitment on a roadmap. 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 fourteen of forty, and this is the session people ask about before they get to it. E7. The top of the stack. I am going to give you the answer in the first minute rather than build to it, because the answer is factual and you should be able to act on it immediately. There is no Microsoft 365 E7. Microsoft does not publish or sell a plan by that name, no price list contains it, and the enterprise line up runs E3 and E5 with F1 and F3 for frontline staff. That is checkable in about thirty seconds against the published plans page, and I would like you to check it rather than take my word for it. So this session is not about a tier. It is about what people are actually asking for when they use that word, why the word persists, and how to plan the top of your stack deliberately when the thing above your current tier is something you assemble rather than something you select.
Five takeaways. One, the confirmed position: no E7 plan exists, E5 is the genuine top enterprise tier, and F1 and F3 sit below for frontline staff. Two, what people mean: across the conversations behind this course, every single E7 request resolved to E5 plus something specific, and in sixty to seventy percent of cases that something was Copilot. Three, how the top is built: anything above E5 is assembled from add ons rather than ascended to, so each addition is a separate decision carrying its own evidence. Four, the naming risk: budgeting around a plan that does not exist invites the vendor to define it for you, which is a poor place from which to start a three year commitment. Five, planning without a roadmap: how to hold a tier strategy that survives whatever ships next, by committing to capability you have tested rather than to names you have heard in meetings.
What is actually confirmed, three statements, all true at the time of recording and all checkable. First, there is no E7 plan. Microsoft does not publish or sell it, no price list contains it, and the current set is confirmable on the published enterprise plans and pricing page before you model anything. Second, E5 is the top of the published stack. Anything above it is assembled from add ons rather than bought as a single higher tier, which means the top of your stack is something you design rather than something you choose off a menu. Third, Copilot is separate, always. It is a per user add on requiring a qualifying base plan, priced apart from E3 and E5 and bundled into neither, so any proposal treating AI as a property of a tier has made a claim the price list does not support. And where does the term come from? Three places: sequence logic, because people assume E7 follows E5 the way E5 follows E3; vendor shorthand for the fullest stack; and old roadmap chatter that never shipped.
What buyers mean when they say E7, and the real SKU that covers it. AI productivity: E5 plus Copilot, and this is the most common case by a wide margin. Top security: E5, already, so buying it again is precisely the duplication from last session. Advanced compliance: also E5, because Purview is bundled, which is the same duplication in a different family. Premium support: unified support, priced apart from seats entirely and not a plan tier at all, which surprises people. And everything, future proofed, which is the request that most needs converting into specifics before anybody prices it. Here are the numbers behind this slide. Across roughly twenty to thirty conversations where a buyer asked about E7, the request always resolved to E5 plus something specific. In sixty to seventy percent of them the real need was Copilot. None of them needed a higher tier. And several had already been quoted bundles they did not need, which is the cost of asking the question in the wrong direction.
First check. Your CIO asks you to budget for moving three thousand users to E7 next year. What is your first move? A, ask the account team for E7 pricing. B, ask the CIO which capability they want, because there is no E7 plan on any price list and the request will resolve to E5 plus something specific, most often Copilot. C, budget E5 plus thirty percent as a placeholder. D, tell the CIO the request is wrong and close it. Pause it, and as you think, notice that one of these answers hands the definition of your own budget line to somebody else.
The answer is B. A is the expensive answer and it is also the natural one, which is a bad combination. Asking a vendor to price a plan that does not exist invites them to define it, and what comes back is a bundle assembled to their preference rather than to your requirement. Define it yourself from real SKUs. C looks prudent and is worse than it appears, because a placeholder in a budget becomes a target for a proposal to fill, and thirty percent above E5 across three thousand seats is a very large target to leave lying around where an account team can see it. D is right on the facts and wrong in the room, and I want to be clear about why. The CIO is not confused about what the business needs. They are using a shorthand they heard somewhere. The useful response is to convert the name into a capability list, and nine times out of ten that conversation takes five minutes and ends at Copilot, which is a real product with a real price and a real evidence requirement.
Assembling the top of the stack, five rules. Start from E5 as the base, then add only what the business has asked for by capability, so each addition is a deliberate choice rather than a tier you ascend to. Separate the lines: E5, Copilot, and support are three negotiations, and a single uplift across all three hides which parts you are paying for and which you will never use. Anchor every line to something published: list price for the SKU, use rights from the Product Terms, because a line you cannot anchor is a line somebody else is defining. Stage the adoption: ramp to proven users rather than committing across the estate on day one, which applies most sharply to Copilot and to every premium component. And keep the assembled stack named: write down what your top tier consists of, per persona, in SKUs. If your own internal document says E7 anywhere, you have inherited somebody else's shorthand straight into your budget. The discipline underneath all five: never let a name do the work of a specification.
Guest analyst I had a call a while back that I still use as a teaching example, because of how ordinary it was. A large retailer, and the head of IT procurement opened with, we have got E7 in next year's budget, can you help us benchmark it. And she said it completely matter of factly, the way you would name any product, because by that point it had been in three internal documents and a board paper. So I asked the question I always ask, which is, what does it do that E5 does not. There was a pause, and then she said, honestly, I do not know, it came from the account team as the next step up. We traced it back. Somebody in a meeting eight months earlier had used E7 as loose shorthand for the fullest possible stack. A note taker wrote it down as a product. It went into a planning spreadsheet, then into a budget line with a number attached, and by the time it reached the board it had a figure beside it that was about thirty percent above their E5 spend, because that felt like the right size of increment. Nobody invented anything dishonestly. It was a shorthand that hardened. What that budget line actually needed to be was E5 plus Copilot for about six hundred people in merchandising and marketing, on a staged ramp, which was roughly a third of the number in the board paper. And the useful part was not the saving. It was that the conversation with the account team changed completely, because they arrived expecting to price a tier and instead had to price two lines she could evaluate separately.
A shorthand that hardened into a board number in eight months. Search your own documents for it, and that is in the homework. Second check.
Check two. A proposal offers a premium bundle above E5 at a single per user uplift, described as future proofing. What is the risk? A, none, bundling above E5 is standard practice. B, you commit to a composition you cannot inspect, so components already inside E5 can be billed again and capability you never adopt is locked in for the term. C, the risk is only that the discount could be deeper. D, the risk is that E7 might launch later at a lower price. Pause it, and ask yourself what you would be able to cancel in eighteen months, and what you would not.
The answer is B, and two distinct things happen inside an un itemised premium bundle. First, duplication: components already bundled in E5 reappear in the premium layer and get paid for twice, which is exactly last session's pattern arriving one level higher up the stack. Second, lock in without adoption: capability nobody deploys is committed for the term, and unlike a component you attached deliberately, you cannot drop it later because you never had a separate line to drop. That asymmetry is the real cost. A treats a common practice as a justification, which it never is. C negotiates the size of an unknown, and that has now been the recurring error across three sessions of this module. D invents a specific future and plans against it, which is the exact habit this session exists to break. So ask for the itemisation, and if the composition cannot be shown to you, that refusal is itself the answer, and the right response is to buy the components you can name.
Planning without a roadmap, three moves, because you will be asked to plan around things that have not shipped and refusing to engage is not a strategy. Commit to capability, not to names: write the strategy as capabilities per persona with the SKUs that deliver them today, so that when something new ships you compare it against requirements you already hold rather than rewriting the plan around a name. Buy the option, not the outcome: where a future tier is genuinely plausible, negotiate the right to move into it at a known rate rather than a commitment made in advance, because an option costs less than a purchase and it expires harmlessly if nothing ships. And date every assumption: any planning statement about a product that has not shipped gets a date and a source in your own document, because assumptions with dates get reviewed and assumptions without dates quietly become facts inside about six months. This is also how you stay credible internally, and that credibility is worth real money at the next renewal.
Three negotiations, not one, and look at the last column because it is the argument. The E5 base is decided by the retirement test from session twelve, per persona, and the evidence belongs to the security and compliance owners with procurement pricing it. Copilot is decided by measured adoption on a staged ramp rather than a blanket rollout, and the evidence belongs to the business units running it, with usage telemetry. Premium support is decided by service requirement and incident history, priced entirely apart from seats, and the evidence belongs to IT operations against actual support consumption. Named components are decided by the crossover arithmetic from last session, owned by whoever asked for the capability, by name. And the combined uplift is decided by nothing at all, because it is a packaging choice, and it is owned by nobody, which is exactly the problem with it. Three lines can be approved, deferred, or refused independently. A single uplift can only be swallowed or rejected whole.
Last check. You are asked to sign a three year commitment on the basis that a premium tier is expected during the term. What is the buyer side position? A, sign, being early usually secures better pricing. B, negotiate the right to move to whatever ships at a known rate, and commit today only to capability you have tested, because an expectation is not a product and cannot be evaluated. C, refuse to discuss anything unreleased. D, sign for one year instead of three. Pause it. And notice as you think that there is a version of this where the roadmap conversation is genuinely useful to you.
The answer is B. The roadmap conversation is useful, just not in the direction it is normally pointed. What it should produce is an option: a named right to move to a future offering at a known rate, at your election, with no obligation if it never ships or ships badly. That costs you nothing today and it converts uncertainty into a contractual position, which is the only form uncertainty is worth holding in. A pays now for an outcome you cannot inspect, and early pricing on an unreleased product is a discount against a list price that does not yet exist, which should tell you what the discount is worth. C throws away the option along with the risk, and it makes you the person who cannot have a forward looking conversation, which costs credibility you will want later in the term. D shortens the exposure without addressing it, and in most cases a one year term prices worse per seat than a three year one, so you end up paying for the flexibility twice.
The tier strategy method, three steps, producing one page per persona written in capabilities and SKUs. One, write the capability list: per persona, what the business actually needs, in plain language, with no product names in the first draft. That is harder than it sounds and it is where most of the value sits, because it forces the requirement to exist independently of the catalogue. Two, map it to today's SKUs: base plan plus named components plus Copilot where the evidence supports it, every line anchored to a published price and a use right you have personally read, and whatever you cannot map gets written down as unmet. Three, hold the options separately: anything roadmap dependent goes into a short options section with a date, a source, and the rate you would want if it ships, reviewed each quarter and never mixed into the committed plan. That document is also the honest answer to the E7 question when it comes back, and it will come back.
Session fourteen, three sentences. One: there is no E7 plan on any Microsoft price list, E5 is the top of the published enterprise stack, and anything above it is assembled from add ons rather than ascended to. Two: every E7 request resolves to E5 plus something specific, most often Copilot, so the first move is always to convert the name into a capability list before anybody prices it. Three: commit to capability you have tested and negotiate options rather than outcomes on anything unreleased, because a strategy written in capabilities survives a rename and a strategy written in tier names does not survive contact with a proposal. And one honest caveat on this session: it is built on what is verifiable now. If a genuine premium tier ships later, the method still holds, because the method was never about the name.
Homework, about an hour, and this week you name your own top tier. One, search your documents: look for E7 in your budget lines, planning decks, and board papers, and if it appears anywhere, find out who put it there and what they actually meant. That single search is worth the hour on its own in a surprising number of organisations. Two, write the capability list for your most demanding persona, in plain language, before you open any catalogue. Three, map it to SKUs: base plus named components plus Copilot if the evidence supports it, each anchored to a published price. Four, mark the unmet: anything the current catalogue genuinely does not cover, which is a short list in most estates and is the only legitimate input to a roadmap conversation. Five, write the options section, with a date, a source, and the rate you would want, reviewed quarterly and kept firmly out of the committed plan.
Five reads before next session, all free on redress compliance dot com. First, the Microsoft 365 E7 complete guide, which sets out what the term really means, where it came from, and how to build the stack from real SKUs. Second, E7 pricing and negotiation strategy, on pricing the layers above E5 as separate negotiations rather than one uplift. Third, Microsoft 365 Copilot licensing for enterprise, which is the add on most E7 requests actually resolve to, and which module four covers properly. Fourth, every Microsoft 365 add on explained, for the components you assemble the top of the stack from. And fifth, the Microsoft licensing guide, for the current programme picture including where the pressure to standardise on security bundles is coming from. Next session closes module three with the licence mix model: personas over averages, built from real role data, and the full cost of licensing everybody at the highest tier. See you there.