Adoption telemetry, the business case that survives a CFO, and the evidence file that decides the renewal. 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 twenty of forty, and this closes module four. We have priced the Copilot subscription, priced the meter, priced the agents, and negotiated the shape of the commitment. What we have not done is the thing that decides whether any of it survives the next renewal, which is proving it worked. And I want to be careful about the tone of this session, because it would be easy to hear it as anti Copilot and it is not. The productivity gains are real for the right persona on the right workload. What this session is sceptical about is arithmetic done with somebody else's inputs, which is a completely different objection and a much more useful one. By the end you will be able to build a business case out of your own wage costs, your own adoption data, and your own role specific evidence, and you will know the two adoption thresholds where the maths stops working.
Five takeaways. One, the published claim: Microsoft's productivity case centres on around fourteen minutes saved per user per day, with wide variance across roles and tasks, and that is a number to test rather than to repeat. Two, the buyer side calculation: fully loaded wage cost, documented adoption rate, and role specific time saved evidence, which is three inputs you own replacing three you were handed. Three, the thresholds: below thirty percent active adoption the maths turns negative for most roles, and below fifteen percent it turns negative for almost every role. Four, where the value concentrates: knowledge worker personas carrying heavy email, meeting, and document burden, not operations and not field roles, and saying that plainly protects the case. Five, the evidence file: what you need in hand before the renewal, gathered while the deployment runs rather than assembled in the last six weeks before it.
The claim and the arithmetic, three things to hold at once. The gains are real for the right work: for the right persona on the right workload they exist, and starting from denial produces a case nobody in the business believes and costs you the credibility you need for the harder argument, which is about scope rather than about merit. The published averages are not your numbers: around fourteen minutes per user per day with wide variance by role and task, and an average across a vendor's entire customer base is a starting hypothesis about your estate rather than a finding within it. And the liability is annual and certain: thirty dollars a month is three hundred and sixty dollars per user per year, committed, whether or not the minutes materialise. So the cost is certain and the benefit is probabilistic, which is precisely the asymmetry a CFO is paid to notice, and you should notice it before they do.
The buyer side ROI calculation, five inputs and where each comes from. Fully loaded wage cost: from finance, per persona, including on costs, and the common error is using salary alone, which actually understates your own benefit. Time saved per day: role specific evidence from your own pilot, and the error is importing the published average across every role. Active adoption rate: your telemetry, monthly active against assigned, and the error is counting assigned seats as adopted ones. Realisation factor: how much saved time converts into output, where the error is assuming a hundred percent, which no CFO will accept. And cost: three hundred and sixty dollars per user per year at list, or your own rate, with the error being to price the pilot rather than the committed population. That fourth row separates a credible paper from a hopeful one, because time saved is not automatically value created, and a case that claims it is gets dismantled in its first finance review.
First check. Your business case uses the published fourteen minutes per user per day across all five thousand seats. What is wrong with it? A, nothing, it is the vendor's own published figure. B, it applies an average with wide role variance uniformly, when the value concentrates in heavy document and email roles, so the case overstates most of the estate and cannot be defended per persona. C, the figure is too low and should be higher. D, it should be halved as a safety margin. Pause it, and as you think, ask what fourteen minutes a day would mean for somebody who spends their working day on a forklift.
The answer is B. The published claim carries wide variance across roles and tasks, and the most reliable returns come from knowledge worker personas with heavy email, meeting, and document burden rather than from operations or field roles. Applying the average uniformly makes an implicit claim about every single person in the estate, including the ones whose work the tool barely touches, and the first person to notice will be whoever runs that part of the business, in a meeting, in front of everybody. A treats a vendor average as a measurement of your organisation. C is the direction enthusiastic business cases travel in, and it makes the paper less survivable rather than more. D is the instinct to be conservative and it is still the wrong shape, because halving an average across everybody preserves the error that actually matters, which is uniformity. Segment first, apply role specific evidence, and let the personas that do not benefit show plainly as not benefiting. That honesty is what makes the rest believable.
Where the maths turns, five numbers to keep in front of you. Thirty percent is the hinge: below thirty percent active adoption the maths turns negative for most roles, and that is the single most useful threshold in this session, so it belongs on the first page of any paper you write. Fifteen percent is the floor: below that the case turns negative for almost every role including the strong ones, and there is no persona whose upside survives it. Twenty five to forty five percent is typical, because that is where measured active use sat at six months, and reading that against the two thresholds above is what makes tranches arithmetic rather than caution. Three hundred and sixty dollars is the annual unit, and always present the annual figure, because the monthly one is what makes a large commitment feel small. And active, not assigned: adoption means monthly active users against assigned licences, and any other denominator flatters the number and will not survive the first question about it.
Guest analyst The best Copilot business case I have read was also the smallest, and I think those two facts are related. A manufacturer, and the licence manager had been asked to justify continuing about two thousand seats. What she produced was three pages. The first page had one chart: monthly active users against assigned licences, by persona, for eleven months. Not a projection, just what had happened. Four personas were between forty and sixty percent and climbing gently. Three were under ten percent and flat from month two onward. The second page took the four strong personas and did the arithmetic properly, with fully loaded wage cost from finance, minutes evidenced from a structured sample of their own people rather than the published figure, and a realisation factor of fifty percent that she had agreed with the CFO before she measured anything, which I thought was the cleverest thing in the document. And the third page said, plainly, we should stop paying for these seven hundred seats, here is the annual saving, and here is why training will not fix it because these roles do not do the work the tool helps with. Now the outcome. The CFO approved the strong population without an argument and asked for the seven hundred to be released at anniversary. And the reason it went that smoothly, she told me later, was the third page. Because she had already argued against part of her own case, nobody felt the need to argue against the rest of it.
Three pages, and the page that recommended stopping is what made the other two credible. Second check.
Check two. Adoption across your Copilot estate sits at twenty two percent active. What does the business case say now? A, it holds, adoption is still climbing. B, it is negative for most roles at that level, so the response is to segment: find the personas above thirty percent, keep those, and stop paying for the population that is below fifteen. C, cancel the whole deployment. D, fund a training programme and re measure next year. Pause it. The estate average is twenty two percent, so ask yourself what the distribution behind that average is likely to look like.
The answer is B. Twenty two percent across an estate is almost never twenty two percent everywhere. It is usually a strong persona somewhere in the fifties and several weak ones in single figures, exactly as in the story a moment ago, and those two groups need opposite decisions taken about them. Segment and you can defend both: keep the seats where evidence clears the threshold, and stop paying for the population sitting below the floor where the case is negative for almost every role. A is the hope that adoption curves keep rising, which is testable rather than assumable, and the six month data says the band is twenty five to forty five percent rather than a climb toward a hundred. C throws away the part that demonstrably works, which is as much an analytical failure as A is. D is the instinct from the session sixteen story, and training is a reasonable response only for personas whose work the tool genuinely fits. Training a forklift driver to use Copilot does not change the arithmetic.
Which personas earn the seat, three groups, and this maps directly onto the licence mix model from session fifteen. Earns it reliably: knowledge workers with heavy email, meeting, and document burden, drafting, summarising, correspondence at volume, long document work. That is where the most reliable ROI has been observed and where your first tranche belongs. Earns it conditionally: analysts, specialists, and managers whose document load is real but intermittent, where the case depends on your own measured minutes rather than the published average, which means these personas need a pilot before a commitment. And rarely earns it: operations and field roles, and anybody whose work is physical, systems based, or conducted mostly in conversation. Saying that plainly is what makes the rest of your paper credible and it is the section most business cases omit. And note the coincidence from session sixteen: those weakest cases also carry the base plan upgrade, so the weakest value carries the highest total cost.
The evidence file, what you need before the renewal and when to collect it. Monthly active by persona, proving who actually uses it and at what rate, gathered monthly from day one because it cannot be reconstructed later. Time saved, role specific, proving your minutes rather than the published average, gathered during the pilot with a named method. Realisation evidence, proving that saved time produced output, gathered quarterly from the persona's own manager. Tool retirement, anything Copilot replaced and was decommissioned, recorded as it happens with dates, per session twelve. And the consumption record, the metered layer beside the seats, monthly, from session seventeen. Every row in that table says gather it as you go, and that is the entire point. An evidence file assembled in the last six weeks before a renewal is a reconstruction and the account team will recognise it as one. A file gathered monthly is a record, and a record changes what you are able to ask for.
Last check, and this is the situation most people listening will actually be in. Renewal is in eight weeks and nobody has collected adoption data. What is the realistic position? A, pull the data now, eight weeks is plenty. B, take what current telemetry exists, be explicit that trend evidence is missing, negotiate a shorter term with reduction rights, and start the monthly record immediately so the next renewal is different. C, renew flat, there is no basis to argue. D, cancel and re procure later. Pause it. Current state is available in an afternoon, so ask yourself what is not available, and what its absence costs you.
The answer is B. Current state telemetry is genuinely available quickly, so A is half right and worth doing, but it gives you a snapshot rather than a trend, and a snapshot cannot show whether adoption is rising, flat, or decaying, which is the question that decides the seat count. Say that out loud rather than dressing a snapshot up as a trend, because the credibility you keep by admitting it is worth more than the point you would win by hiding it. Then negotiate for what a buyer without evidence should hold: a shorter term and a reduction right, so the decision can be revisited once the record exists. C is the outcome from the session sixteen story, three years of spend and no more knowledge than you started with, and it happens whenever nobody says the evidence is missing. D discards a capability some of your people are using well, on the basis of a measurement failure rather than a product failure. And start the monthly record in week one.
The measurement method, three habits, starting the week seats are assigned. One, monthly active by persona: one number per persona per month, from your own telemetry, stored somewhere a colleague could find it without asking you. That single series is the foundation of every argument in this session and once set up it takes minutes to produce. Two, a named method for minutes: how you measure time saved, agreed with finance before the pilot rather than after, and any defensible method beats a better one invented later, because the objection you will face is not that your method was imperfect, it is that it was chosen to suit the answer. Three, a standing review: quarterly, with the persona owners, against the thirty percent threshold, where seats below it either get a reason or get released. That closes module four. You now have the Copilot stack end to end, and module five turns to the rest of the estate under the agreement.
Session twenty, three sentences. One: the gains are real for the right persona on the right workload, and the published average of around fourteen minutes a day carries wide role variance, so it is a hypothesis to test with your own wage cost, your own adoption, and your own role specific evidence. Two: below thirty percent active adoption the maths turns negative for most roles and below fifteen percent it turns negative for almost all of them, which is why measured active use of twenty five to forty five percent makes segmentation arithmetic rather than caution. Three: the evidence file is gathered monthly from day one, because a record changes what you can ask for at renewal while a reconstruction assembled in the last six weeks does not. Module four is complete. Next session opens module five and the largest line in most Microsoft agreements that is not a licence at all.
Homework, about an hour, and this week you start the record. One, pull monthly active: active users against assigned licences, by persona if you can, for the last three months, and note specifically which months you can no longer recover, because that gap is a finding in itself. Two, mark the thresholds: which personas sit above thirty percent, which sit between fifteen and thirty, and which are below fifteen. Three groups, three different decisions. Three, get the wage input: fully loaded cost per persona from finance, and ask for fully loaded, because salary alone understates your own case. Four, agree the minutes method: one paragraph on how you will evidence time saved, sent to finance for agreement before you measure anything. Five, book the review: a quarterly slot with the persona owners, in the calendar now, with the thirty percent rule written into the invitation so nobody is surprised by it later.
Five reads before next session, all free on redress compliance dot com. First, the Copilot ROI calculator deep dive, which carries the full arithmetic, the adoption curve, and the thresholds where the case turns. Second, the CIO playbook on adopting Microsoft 365 Copilot and AI services, for the deployment side of adoption that actually produces the evidence. Third, auditing your Microsoft licence usage, on how to produce the telemetry the evidence file depends on. Fourth, the Copilot true cost analysis, covering both layers of the cost side of the ratio, because a business case that only counts seats is measuring half the denominator. And fifth, negotiating Microsoft generative AI contracts, where the evidence file turns into an actual negotiating position. Next session opens module five with Azure commitments: how MACC works, how it interacts with the licensing lines, and the forfeit risk in a number sized by somebody else's forecast. See you there.