Personas over averages: building the mix from real role data, and the cost of licensing everyone at the highest tier. 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 fifteen of forty, and this one closes module three. Over the last four sessions we have built up a picture: the map of the stack, the E3 to E5 delta and the retirement test, the component crossover, and what actually sits above E5. All of that is analysis. Today we turn it into an artefact, which is a licence mix model. And I want to manage expectations, because this is not a sophisticated piece of work. It is one table. Every account maps to a persona, every persona maps to a plan, every plan carries your own net rate, and the totals fall out at the bottom. There is no modelling technique to learn here. The reason this session exists is that almost nobody builds it, and the organisations that do walk into renewals with something the other side cannot argue with, because it is made of their own data and anybody in the room can check it.
Five takeaways. One, what the model is: one table mapping every account to a persona, every persona to a plan, and every plan to a price. Small, boring, and the most useful document in the renewal file. Two, the five inputs: assignment, activity, role, risk, and rate, four of which come from systems you already own and the fifth from your last price sheet. Three, building it honestly: personas defined by the work rather than by the department, applied through rules that somebody else could re run and reproduce exactly. Four, the cost of uniformity: licensing everyone at the top tier is a decision with a price, and this session puts the price on it so it can be chosen rather than defaulted into. Five, keeping it alive: a model refreshed at every true up stays true, while a model built once for a renewal is a slide, and it will be out of date before anybody uses it.
What a mix model is, three properties, and none of them are sophisticated. It is reproducible: somebody else, given the same exports and the same persona rules, produces the same answer. That is the property that separates a model from an opinion, and it is why the rules have to be written down rather than applied by judgement in somebody's head. It is per account rather than per average: every account resolves to exactly one persona and one plan, because averages hide the two populations that actually matter, which are the people licensed above their work and the smaller group licensed below it. And it prices, it does not argue: the model produces totals for each scenario at your own rates and stops there. Handing three priced scenarios to a room is considerably more persuasive than handing them one recommendation, because it lets the room reach your conclusion themselves. This artefact is what makes the last four sessions usable.
The five inputs, and where each one comes from. Assignment: an admin centre export, per account, telling you what each person holds today, which is your baseline. Activity: usage telemetry over a ninety day window, telling you whether the plan they hold matches the work they do. Role: HR or directory data joined by account, which decides which persona the account belongs to. Risk: from the security owner, per role rather than per person, deciding whether that persona needs the E5 delta at all. And rate: your own price sheet, net rather than list, which is what makes each scenario cost something real. Now notice the pattern. Four of these five already exist inside your organisation, and they are usually held by four different teams, which is the actual reason the model does not get built. The work is not analytical. It is the joining, and the joining needs one named owner or it does not happen.
First check. Your model shows an average cost of forty one dollars per user per month across the estate. What does that tell you? A, that the estate sits between E3 and E5, which is healthy. B, almost nothing, because an average blends populations that need different plans and hides both the over licensed majority and the under licensed few. C, that you should target thirty six dollars, the E3 rate. D, that the discount is working. Pause it. And as you think, ask yourself which individual person in your building that figure actually describes.
The answer is B, and the reason is that the average describes nobody. It is equally compatible with a well allocated estate and a badly allocated one, which makes it useless for deciding anything. The same forty one dollars could be a sensible spread of E5, E3, and frontline seats, or a heavy E5 default with a handful of frontline seats dragging the mean down, and those two estates need opposite actions taken. A treats a mid range figure as evidence of balance, which is the single most common misreading of a licensing dashboard. C picks a target off the wrong axis entirely: the goal is the right plan per person, and if that genuinely averages forty four dollars because the risk profile demands it, then forty four is the correct answer. D confuses rate with allocation, which is the error this whole module has been dismantling. So report the distribution, not the mean. The histogram is the finding.
Building it from role data, five rules that keep it defensible. Define personas by the work: not by department, not by seniority, not by cost centre, because two people on the same team can belong to different personas and two people in different divisions doing identical work belong to the same one. Write the rule, then apply it: one sentence per persona, precise enough that another analyst applying it to the same export lands on the same allocation, and if the rule needs judgement then the rule is not finished. Let activity break ties: where role data is ambiguous, ninety day usage decides, because somebody with no desktop Office activity in three months is not a desktop persona whatever their job title says. Take risk from the security owner, per role, in writing, with their name against it in the model. And name every exception, because exceptions are fine and unnamed exceptions are not. Forty named exceptions is a governed model. Ten percent unallocated is a model nobody will defend.
Guest analyst The best licence mix model I have seen was built by a licence manager at a pharmaceutical company, and what made it good had nothing to do with the analysis. It was one spreadsheet. Six personas, one sentence defining each, and a rules tab that explained exactly how every account had been allocated, including the ties broken by activity data. About twenty thousand rows. And she did something I had not seen before, which was that before she took it anywhere near procurement or the vendor, she sent the allocation for each division to the person who ran that division and asked one question: which of these look wrong to you. She got about three hundred corrections back. Some of them were people she had allocated too low, which she fixed, and that mattered later. Then the renewal came and the account team pushed the standardisation argument, everyone on the top tier, better rate. And the reason it did not land was not that her numbers were better. It was that when the CIO asked whether the model was trustworthy, four divisional heads in the room had personally reviewed their own section of it. Nobody could dismiss it as a procurement spreadsheet. The mix correction was worth somewhere around one point four million a year across the term. But what she said to me afterwards was that the three hundred corrections were the whole thing, because that was the step that turned her document into everybody's document.
Three hundred corrections, and they were the point. Send the distribution out before you send it up. Second check.
Check two. IT proposes personas by department. Finance proposes them by cost centre. What do you propose? A, department, because IT administers the licences. B, personas defined by the work itself, because the plan a person needs follows what they do rather than where they report, and department groupings mix personas inside one bucket. C, cost centre, because it makes chargeback straightforward. D, both, and reconcile the two afterwards. Pause it, and while you think, picture a single operations department that contains both a security analyst and a shift supervisor.
The answer is B, and the operations department is the reason. A security analyst who genuinely needs the E5 delta and a shift supervisor who belongs on a frontline plan can sit in the same department, so a department bucket forces one plan onto both, and the bucket then gets licensed at whatever its most demanding member needs. Repeat that mechanism across an organisation and you arrive at uniform over licensing without anybody ever deciding on it. That is worth saying explicitly, because it explains a lot of estates that look irrational from outside. A and C both pick an axis for administrative convenience, and both are recoverable, because once accounts are allocated by work you can report totals by department, by cost centre, or by region without touching the allocation. Group by the work, report by whatever the organisation needs. D doubles the effort and produces two answers with no rule for choosing between them, which in practice means the more senior stakeholder's version wins the meeting.
The cost of one tier for everyone, three costs, and only one of them appears on the invoice. The direct cost is the visible one: where a persona aligned mix was priced against a heavy default, the annual list bill moved by roughly twelve to eighteen percent, and on a five million dollar list bill that is in the order of six hundred to nine hundred thousand a year, held for the term. The lock in cost: a uniform commitment removes your ability to correct later, because reducing tier mid term needs a step down right that a standardised deal rarely includes, so you buy the wrong mix and simultaneously give up the mechanism for fixing it. And the evidence cost, which is the subtle one: a uniform estate produces no signal. When everybody holds the same plan, usage data cannot tell you who needed it, so at the next renewal you have three more years of spend and exactly as much evidence as you started with. Say the direct number out loud when the simplicity argument is made, because that argument is usually sincere and almost never priced.
Three scenarios, one page, and this is what you actually take into the room. Current: today's assignments at today's rates, the honest baseline including all the shelfware, and it has to be honest or the rest is worthless. Persona aligned: every account on the plan its work requires, which gives you the achievable position and the gap to today. Vendor proposed: the mix in their proposal, priced at your rates rather than theirs, so you can see what you are being asked to sign in your own terms. Then two rows underneath. Per seat: each scenario divided by users and months, which is the comparison that survives changes in headcount. And assigned against active: each scenario divided by the people actually using it, which is what you pay per person who turns up. Three columns, five rows, one page, at your own net rates. A fortnight of an analyst's time on a large estate, and it is the most reused document in the renewal file.
Last check. Your model is six months old and headcount has moved eight percent. What is its status? A, still valid, eight percent is within tolerance. B, refresh it before it is used again, because allocation drifts faster than headcount as people change roles, and a model quoted from memory in a negotiation is worse than no model at all. C, invalid, rebuild it from scratch. D, adjust the totals by eight percent. Pause it, and ask yourself what changed inside the estate during those six months that a headcount figure does not capture.
The answer is B, and headcount is the least interesting thing that changed. In six months people moved roles, projects ended, a security programme upgraded a population, and licences that were correctly assigned in January are attached to different work by July. Allocation drift runs well ahead of headcount drift, and it drifts in the direction of over licensing, because upgrades are easy and downgrades require somebody to ask for them. D scales a total while leaving the composition wrong, producing a confident number sitting on a stale distribution, and confidence on a stale distribution is precisely how a negotiator gets caught out in front of an account team who refreshed their own data last week. C is disproportionate, because the persona rules survive even when the exports do not, so a refresh is a day rather than a fortnight once the model exists. And A ends with somebody quoting a six month old figure across the table and being corrected, which costs more credibility than the number was ever worth.
Keeping the model alive, three habits. Refresh at every true up: tie it to the anniversary discipline from session seven, because the exports are the same ones the true up already needs, so the marginal cost of keeping the model current is close to zero if you run the two together. One named owner: a person rather than a team, owning the persona rules and the refresh, because the rules will need amending as the business changes and amendments without an owner quietly become undocumented exceptions. And publish the distribution: share the histogram of plans per persona rather than the average, because distribution invites correction from the people who know the work, and those corrections are the most valuable input the model ever receives, as the story earlier showed. That closes module three. You have the stack, the delta, the components, the top, and the model that prices all of it.
Session fifteen, three sentences. One: a mix model is one reproducible table mapping every account to a persona, every persona to a plan, and every plan to your own net rate, and its value is that anybody can check it rather than that it is clever. Two: personas follow the work rather than the department, because a department bucket mixes personas and then gets licensed at whatever its most demanding member needs, which is how uniform over licensing arrives without a decision ever being taken. Three: licensing everybody at the top tier costs the direct twelve to eighteen percent, the ability to correct mid term, and the evidence you would need at the next renewal, so name all three costs when the simplicity argument gets made. Next session opens module four, and the layer we meet there behaves differently from everything in this module.
Homework, about an hour, and this week you build version one. One, join the exports: assignment, activity, and role data matched by account, one table, one row per person. Version one does not need to be complete, it needs to exist. Two, write the persona rules, one sentence each, precise enough for somebody else to reproduce your allocation, and test that claim properly by handing fifty rows and the rules to a colleague. Three, get the risk input: ask the security owner which roles need the E5 delta, in writing, per role, with their name on it. Four, price three scenarios, current, persona aligned, and whatever your last proposal suggested, all at your own net rates with a per seat row underneath each one. Five, publish the distribution: send the plan histogram to the people who run the work, not the average, and ask them what looks wrong. Their corrections are version two, and version two is the one that matters.
Five reads before next session, all free on redress compliance dot com. First, E3, E5, and F3 per persona, which carries the persona archetypes and the worked mix shift this model is designed to produce. Second, auditing your Microsoft licence usage, a step by step guide to producing the activity input, which is the input most estates struggle with. Third, selecting the right Microsoft 365 enterprise plan, for the governance around the allocation and who owns which input. Fourth, Microsoft SAM and licence optimisation, on the practice that keeps the model current between renewals rather than letting it go stale. And fifth, common Microsoft licensing mistakes, most of which turn out to be allocation mistakes that a mix model surfaces the moment it is built. Next session opens module four with Microsoft 365 Copilot: what the subscription actually licenses, the prerequisites, the per user economics, and the deployment questions that change the count. See you there.