A capped rate with no monitoring is a cap you discover at true up, so this is the monthly discipline that keeps the terms you negotiated worth something. Three knowledge checks along the way, and 3 clips from a senior licensing analyst.
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. 3 times in the session the frame splits and a senior licensing analyst gives the view from inside real ServiceNow 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 three. Back in session eight we did the assist consumption model, the pool, what draws on it, and the four terms that cap the variable half of the bill. Pool sized to a modelled year, unit rate capped for the term, rollover so unused capacity carries forward, and an annual ceiling that triggers a review rather than an invoice. Good work, genuinely, and if you got all four you did better than most. Today is the uncomfortable follow up, which is that every one of those clauses is worth exactly nothing if nobody looks at the number between the day you sign and the day you true up. There is a line I keep coming back to. A capped rate with no monitoring is a cap you discover at true up. So this session is not a negotiation session at all. It is an operating session. Three checks, homework, let's go.
Five objectives. First, build the monthly report, five lines on one page, trended against the pool, with non production sitting on the same page as production rather than in a separate conversation nobody has. Second, attribute the burn, by capability, by team, by agent, because an aggregate number tells you that you have a problem and never once tells you which one. Third, set thresholds that trigger something, because a number with no action attached to it is a dashboard, and dashboards do not govern anything. Fourth, use the mid year window, which is the moment you can finally see the shape of the year and are still months away from anybody negotiating a renewal. And fifth, separate the two diagnoses, because burning fast when the AI is working is a good problem and burning fast because a workflow loops is a different one, and they get opposite responses.
Four numbers. Fifteen to thirty percent, where overage landed against tier spend once Now Assist and agents were in real use, and read the second half of that tile because it is the whole session, the tier price was predictable and the meter was not. Same pool, because development and sub production usage draws on the production meter, and teams exhausted their pools without a single production user noticing anything at all. Twenty two percent, the median overage, and I want to be precise about the word median, because that is not a tail risk, that is the middle of the distribution being surprised. And at true up, which is when an unmonitored cap gets discovered, and the painful version of that sentence is that the clause was negotiated correctly and it protected a number nobody was tracking. The note underneath. Bundling lowered the anxiety and raised the bill, because a visible add on line became an invisible meter. That trade is only a bad one if you leave it invisible.
Guest analyst clip. I worked with a customer who did the negotiation part of this beautifully. They had modelled the pool properly, they had the unit rate capped for the term, they had rollover, and they had a ceiling. Four for four. I would have used their order form as a teaching example. And they came back to me fourteen months later having been billed a very substantial overage, and they were upset, and the sentence somebody said in that meeting has stayed with me. They said, but we capped the rate. And they had. The cap worked exactly as intended. What the cap does is limit what each unit costs you beyond the pool. What it cannot do is limit how many units you consume, and nobody had looked at the consumption number for eleven months. When we went back through it, the burn had crossed the pool somewhere in month five, and there was a projection you could have drawn in month four with the data they already had, in about twenty minutes. So my advice is blunt and it is not about negotiation at all. When you finish negotiating a consumption clause, the very next thing you do, before you celebrate, is decide who reads the number every month and what happens when it moves. Otherwise you have bought insurance and never checked whether the building was on fire.
But we capped the rate. The cap limits what a unit costs, never how many units you consume. So the very next thing after negotiating a consumption clause is deciding who reads the number and what happens when it moves. Which is a one page report, so let's build it.
Five lines. Consumed to date, against the pool, as a percentage, which is the headline and which on its own is genuinely not enough. Burn rate, this month plus the trailing three month average, because a single month is noise and three months is a trajectory. Projected year end, the trailing average extended to the term end, and this is the number the entire report exists to produce. Non production share, what proportion of the burn is dev, test, and load, because that is the overage source almost nobody models. And top five by capability, which skills and agents consumed the most, which is the only line on the page that tells you what to actually do about any of it. Now the note. Projected year end is what turns a report into a decision. Percentage consumed tells you where you have been. The projection tells you whether to act, and in month four there is an enormous difference between those two things.
Attribution, and the framing is that an aggregate number is a fire alarm with no address. By capability, summarization, case generation, code assistance, agent runs, because they burn at very different rates and only some of them are load bearing for your business. By team, because the conversation about slowing down is a conversation with a named team, and it goes completely differently when you can show somebody their own line rather than a total. By agent, because an autonomous agent completing a task consumes several times an interactive prompt, running many actions per task, which means one agent can dominate your whole chart. By environment, production against dev and test and load, and that split is precisely what stops a testing programme quietly eating a production budget. And then keep the list short, top five rather than everything, because a report nobody reads governs nothing and the tail is rarely where the money is.
Knowledge check one. Month four, you are thirty percent through the pool. Production adoption is modest. What is the first question? A, nothing to do, thirty percent at month four is on track. B, how much of that burn is non production, and which capability leads the list. C, how many users are licensed for Now Assist. D, whether to buy a top up pack now while rates are known. Pause here. Thirty percent at month four looks fine. Does it?
The answer is B. Thirty percent at month four is only on track if adoption has already reached its steady state, and we told you it has not, production adoption is modest. So the burn is coming from somewhere other than the users you are counting, and the obvious candidate is the one the benchmark keeps naming, because dev and sub production draw on the same pool. Answer A reads the percentage without the trajectory, which is exactly what the projection line exists to prevent, and it is the most common wrong answer because thirty percent at a third of the year genuinely does look reassuring. Answer C is the seat instinct in a consumption world, one more time. And answer D buys capacity before diagnosing the burn, which is how you end up funding a looping workflow for a year at a capped rate you were pleased about.
Thresholds, and the rule is that each one names an action and an owner. Projection above a hundred percent, the action is diagnose before you buy, an attribution review inside two weeks, and the owner is the platform owner rather than procurement, because this is an operational question first. Non production above twenty percent of burn, the testing plan gets reviewed and load tests get scheduled against a quota, owned by the delivery lead running the programme. Any single capability above forty percent, confirm that it is the one delivering your value or throttle it, and that is owned by the business owner of that workflow because only they can answer it. And projection under sixty percent at mid year, which triggers a rollover conversation and a check that adoption is real, owned jointly by the platform owner and the AI programme sponsor. Look at that last row, because it is the one nobody ever writes. Under consuming is a finding too, and a pool you are not using is a value problem that will be read as a saving right up until the renewal.
Knowledge check two. Your projection says you finish the year at a hundred and forty percent of the pool. It is month five. Which move comes first? A, buy top up capacity now at the capped rate. B, run the attribution review, then decide whether the burn is value or waste. C, suspend Now Assist until the renewal. D, ask ServiceNow for a bigger pool at no cost. Pause here, and ask yourself what you do not yet know.
The answer is B, attribution first. You do not yet know what is burning, and the two possible answers lead to opposite decisions. If the top capability is deflecting cases at scale then buying capacity is correct and it is cheap at the rate you negotiated. If it is a test harness somebody left running or an agent retrying in a loop, then buying capacity funds a defect for a year and you will do it again next year. Answer A is the reasonable sounding move, and its real cost is that it removes your reason to look. Answer C throws the value away with the waste and the business will reverse it within a month, correctly. And answer D is a request with no argument attached, and month five is precisely when you still have time to build one. Diagnose, then decide. In that order, and the order is the whole answer.
The mid year window, which almost nobody uses. Around month six you can see the shape of the year with enough confidence to act on it, and you are still far enough from your renewal that the conversation is operational rather than commercial. Four cards. What you have, six months of trended burn, attribution by capability, and a projection you can defend, and that is a stronger position than most renewal teams ever manage to assemble. What you ask for, a pool resize against measured demand, or the rollover clause exercised, or the ceiling review triggered, and notice that all three of those were negotiated for exactly this moment and then never used. Why now beats later, because at renewal the same data becomes a compliance discussion, and mid year it is a planning discussion, and planning discussions have better prices. And what it costs you to skip it, which is ten months of overage accruing at whatever rate you agreed, discovered in a meeting where you are simultaneously negotiating everything else you own.
Guest analyst clip. There is a thing I have noticed about mid year conversations, which is that people are reluctant to have them for a reason that has nothing to do with commercial strategy. They are reluctant because raising a consumption problem in month six feels like admitting something. You modelled the pool, you argued for it, you got budget approved, and now you have to go back and say the model was wrong. Nobody enjoys that. And so it waits, and it waits, and by month eleven it is not a conversation you are choosing to have, it is a conversation happening to you. What I would say to anybody in that position is that the model was always going to be wrong, and everybody involved knows it. You forecast a consumption meter for a technology that was six months old, in an organisation that was still deciding what it wanted to do with it. Of course the model was wrong. The question was never whether it was accurate, it was whether you would notice in time to do something. So going back at month six with a corrected projection is not an admission of failure. It is the thing the forecast was for. I have watched customers get pool resizes at month six that they would never have got at month eleven, for the same data, because at month six they were planning and at month eleven they were explaining.
At month six you are planning, at month eleven you are explaining. And that reluctance is real and it is human and it is worth naming out loud in your own governance forum, because the forum that treats a corrected projection as a normal event is the one that gets to use its clauses. Now, the diagnosis itself.
Two problems that look identical on the chart, and really four quadrants. Burning fast and producing value, deflection up, handling time down, cases closing without a fulfiller ever touching them. Buy the capacity. That is the outcome you paid for and you should be pleased. Burning fast and producing nothing, a workflow that loops, an agent retrying, a test harness somebody left running. Fix the defect and do not buy capacity to feed it. Burning slowly and producing value, which is a narrow well targeted deployment, and that is fine, but check that rollover applies before anybody gets congratulated on the underspend. And burning slowly and producing nothing, which is the most expensive quadrant on the board precisely because it is invisible, since you are paying for a bundled capability nobody adopted and it will be quietly renewed next year and the year after. Then the fifth line, which is the honest limitation. The report cannot tell you which quadrant you are in. Consumption data gives you the burn. The value half comes from the workflow owner, which is exactly why attribution is by team and not only by capability.
Knowledge check three. Consumption is well under the pool and the AI programme is being reported as a success on cost. What should the governance forum record? A, a saving, and reduce the pool at renewal. B, an adoption question, plus a rollover check, before anybody calls the underspend a saving. C, nothing, under consumption carries no risk. D, a case for buying more AI capability with the headroom. Pause here, and ask what an unused pool actually means.
The answer is B. An unused pool is capacity you have already paid for inside the tier, so calling it a saving mistakes shelfware for thrift, and that is the same error as low HRSD adoption back in session nineteen. Answer A is half right and premature, because reducing the pool is a perfectly reasonable renewal move once you know whether the underspend reflects a targeted deployment or a stalled programme, and those need different conversations. Answer C ignores the fact that rollover has to be claimed, and unclaimed rollover is money you negotiated for and then left on the table. And answer D spends against headroom before establishing that the capability you already hold is being used, which is how estates end up owning three AI capabilities and adopting one.
The operating model, four habits, running all year. Monitor before overage rather than after, which means alerts fire on the projection crossing the pool, not on the pool being spent, because by the time it is spent the decision has already been made for you. Dev and test on the same dashboard as production, one page, both environments, because separate reporting is exactly how a testing programme exhausts a production budget without anybody lying to anybody. Recheck the model as agents ship, since consumption scales with automation rather than headcount, so every new agent you deploy invalidates a little more of the forecast that justified your pool. And one owner, named, where the platform owner holds the number monthly and procurement holds the clauses, because neither of those two alone has ever caught an overage in time. None of this is negotiation. It is what makes the next negotiation short.
Guest analyst clip. If you take one structural thing away from this session, make it the ownership split, because it is the one I see broken almost everywhere. Procurement owns the contract. They negotiated the pool, the rate cap, the rollover, the ceiling, and they filed it, and their attention quite reasonably moved to the next negotiation. The platform team owns the instance. They can see consumption in real time, in detail, better than anyone. What almost never exists is the connection between those two. The platform team can see the burn and does not know there is a ceiling clause that could be triggered. Procurement knows the clause exists and has no idea the burn is tracking at a hundred and forty percent. And both groups are doing their jobs perfectly well. I have started asking one question in reviews, which is, who reads the consumption number every month, and then, does that person know what the contract says. When the answer to the second part is no, and it usually is, you have found the gap that produces the entire overage problem, and closing it costs one meeting a month and one shared page. That is the cheapest control in enterprise software and hardly anybody has it.
Who reads the number, and does that person know what the contract says. One meeting a month and one shared page. Session twenty four closes module five on the estate itself, production and non production, and the multi instance estates where everything we have discussed today runs three to five times over.
Three sentences. Overage landed at fifteen to thirty percent of tier spend with a twenty two percent median once assist and agents were in real use, and the terms you negotiated in session eight only hold if somebody watches the number between signature and true up. The monthly page is five lines, consumed, burn rate, projected year end, non production share, and the top five capabilities, and the projection is the line that turns a report into a decision. And every threshold names an action and an owner, the mid year window is where a planning conversation replaces a compliance one, and an underspent pool is an adoption finding rather than a saving.
Homework, about an hour, five items. Draft the one page report, five lines against your own pool, and if any line cannot be filled from data you already hold today, that gap is itself the finding and it is worth reporting. Split production from everything else, what share of your assist burn is dev, test, and load, and I would expect that number to come in higher than anybody in the room guesses. Rank the capabilities, top five by consumption with the owning team beside each one, then go and ask each of those owners what it produced, because that is the half the data cannot give you. Project the year, trailing three month average extended to term end, against the pool, and write the number down and date it, because a dated projection is evidence. And check the clauses are live, rollover, capped rate, ceiling, confirming each one is exercisable and naming who exercises it, because a clause nobody can name is a clause nobody will ever use.
Five guides. Now Assist consumption and overage in 2026 carries the fifteen to thirty percent benchmark, the actions model, the shared production meter, and the four terms, and it is the written version of today. The Now Assist pricing deep dive covers what an assist costs and what different actions consume, which is the arithmetic sitting under every line of your monthly report. The Now Assist pillar is the full capability and packaging treatment, including what arrived bundled and therefore needs adoption evidence rather than a purchase decision. Now Assist strategy for 2026 is about sequencing a rollout so consumption follows value, which is the difference between those two fast burning quadrants. And the 2026 pricing tiers pillar tells you which pool your tier ships with and how the Foundation, Advanced, and Prime ladder sets the starting point for all of it. Next time, instances and environments, where every meter we have built runs three to five times over. See you there.