Discovery, Event Management, and a unit that inflates through autoscaling while your headcount stays flat. 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 seventeen. Last session was ITSM, where the unit is a person and the discipline is the roster. Today the unit changes completely, and this is the session where a lot of buyers first realise that ServiceNow is not one licensing model but several living under one roof. ITOM does not count people. It counts managed configuration items, which means infrastructure, and the consequence of that is genuinely strange the first time you see it. Your ITOM bill can grow substantially in a year in which you hired nobody, deployed no new modules, and made no purchasing decision at all. It grows because your engineers did their jobs well, because somebody enabled autoscaling, because a container platform matured, because a discovery schedule was set sensibly wide two years ago and nobody revisited it. That decoupling from headcount is the whole character of this product. Three checks, homework, and by the end you will know your own price per managed CI, which most buyers never calculate. Let's go.
Five objectives. First, define the unit, understanding what makes a configuration item billable and why a resource you never intended to manage can quietly become one. Second, name the five drivers, the specific mechanisms that inflate the billable count, with the buyer response to each, because a driver you can name is a driver you can fix. Third, rescope safely, cutting the billable count without losing operational coverage, and that qualifier is what makes the saving defensible when your infrastructure team asks whether you are compromising their visibility. Fourth, refuse the suite when it fails the arithmetic, recognising when a full suite bundle discount does not survive contact with actual consumption, and knowing what to buy instead. And fifth, calculate the benchmark, price per managed CI, which is the number that decides an ITOM renewal and which, in my experience, almost no buyer has ever worked out for their own estate.
Four numbers. One in two, estates paying for managed CIs that their own governance would have excluded, mostly transient cloud resources nobody ever intended to license. Half. Twenty to thirty five percent, the billable CI reduction from Discovery schedule rescoping with no loss of operational coverage, and that combination makes it the rare saving nobody has to weigh against a risk, because you are not giving anything up. Fourteen of about thirty, full suite buyers running AIOps at a fraction of entitlement for the entire term, where the bundle discount never offset the shelfware. And approximately zero, the renewal overage exposure of estates that audited their CI count quarterly, against annual reviewers who faced true up claims. Now the note underneath, which explains why this never self corrects. The inflation is structural rather than malicious. Default schedules scan widely because that is the safe engineering choice, the CMDB dutifully records everything it is told about, and the billable count rises without anybody approving it. There is no villain in this story and no decision point either. Let's hear it from the field.
Guest analyst clip. ITOM produces the single most awkward conversation in this whole product family, and it is awkward because both sides are right. Here is how it goes. The licensing person discovers the billable CI count has grown forty percent and goes to the infrastructure team to ask what happened. And the infrastructure team explains, correctly and rather proudly, that they moved to containers, they implemented autoscaling, they improved their discovery coverage so the CMDB is finally accurate. Every one of those is a genuine engineering achievement. Several of them were probably objectives in somebody's performance review. And every one of them increased the bill. So you have a situation where the organisation rewarded the behaviour that caused the cost, and now somebody from procurement is implicitly questioning it. That conversation goes badly if you frame it as a problem the infrastructure team created. It goes well if you frame it as a problem the licensing model creates, which is the truth. What I say is, everything you did was right, and the commercial model prices it in a way nobody told you about, so let us work out together which of these resources you actually need managed. That reframe matters, because you need those engineers on your side to do the rescoping, and you will not get them by implying they overspent.
The organisation rewarded the behaviour that caused the cost. That is precisely the dynamic, and the reframe is the practical advice. This is a problem the licensing model creates, not one the infrastructure team created, and you need those engineers as allies because they are the only people who can tell you which resources genuinely need managing. Now, what actually makes a CI billable.
What makes a configuration item billable, four rows. The definition, any resource the licensed products actively discover, monitor, or correlate, as against a record sitting in the CMDB that no licensed product is working on. So presence in the CMDB is not by itself the trigger, activity by a licensed product is. The trigger, being in scope of a Discovery schedule, an event stream, or a mapping, as against merely existing in your data centre unnoticed by the platform. The surprise, autoscaling groups and short lived containers each minting billable CIs, as against the stable servers everybody remembers to count, and notice which of those two categories your governance process was designed around. And the consequence, good cloud practice increases the bill automatically, while nothing whatsoever about your headcount predicts any of it. The note underneath is worth keeping as a general principle. This is the cleanest example in the whole course of an operational decision carrying a licensing consequence. A wide subnet scan is a sensible engineering default and an expensive licensing one, simultaneously, and no part of the tooling tells you that.
Five drivers, and each has a specific response. Default Discovery schedules, which scan broadly, often entire subnets, because that is the safe engineering default, and the response is to scope schedules to governed resources instead. Ephemeral cloud resources, containers and autoscaled instances existing for minutes and minting billable CIs anyway, and the response is to exclude them by rule rather than by hand, because anything handled by hand regrows on the next deployment. Duplicate CI records, the same resource discovered through several sources and counted more than once, and the response is deduplication across sources, which is a data quality fix with a direct financial return. Retired infrastructure, decommissioned kit still present in the CMDB and still in scope, and the response is lifecycle governance that purges rather than archives, because archived and in scope is still billable. And AIOps tier creep, higher tier monitoring applied to low value resources because applying it was easier than deciding, and the response is pulling the tier back where value does not justify it. Five drivers, five responses, and every one of them is inside your control without a vendor conversation.
Knowledge check one. Your platform team autoscales a workload nightly, creating and destroying instances as demand moves. Nothing changed in headcount, nothing changed in ITSM, no purchase was made. What happened to your ITOM bill? A, nothing, the instances are transient. B, the billable CI count rose, because discovered resources count regardless of lifespan. C, it fell, because the resources are consolidated. Or D, nothing until the next contract, when it gets re baselined. Pause here, and ask what the unit actually counts.
The answer is B, the count rose. Transience is not an exemption. If a licensed product discovered it, it minted a billable CI, and that is precisely why one estate in two was found paying for exactly this category of resource. Answer A is the intuition almost everybody has, and it is wrong in a way that costs real money, because a resource that lived for eleven minutes feels like it cannot possibly be a licensing event. Answer D misreads the timing, because the count accrues continuously and the contract is merely where it surfaces, which is session fourteen's true up mechanism showing up in a new product. Now the uncomfortable implication, and I want to state it plainly rather than dance around it. The engineering practices your organisation is actively rewarded for adopting are the ones that inflate this line. Nothing about that is going to change. The only thing that breaks the link is an exclusion rule.
So, rescoping, cutting the count without losing coverage, four steps. Scope to governed resources, aiming schedules at what you actually manage rather than at whole subnets, and remembering that broad scanning is a default rather than a requirement. Exclude the ephemeral by rule, and I stress rule rather than cleanup, because a manual cleanup regrows on the next deployment cycle and you will be doing it again in a month. Deduplicate and purge, one record per resource across sources, with retired infrastructure removed through lifecycle governance rather than left archived but still in scope. And right tier the monitoring, with AIOps and higher tiers reserved for resources whose value justifies them, decided deliberately rather than inherited from whatever was configured during implementation. Now the note, and this sentence is the one to take into the meeting with your infrastructure team. Each step reduces what is counted, not what is observed. That distinction is the entire argument when somebody asks whether this weakens their visibility, and the honest answer is that it does not, which is why the twenty to thirty five percent cut comes with no operational loss attached.
Knowledge check two. Your account team proposes the full ITOM suite up front, arguing that the bundle discount beats adding tiers later, which is a genuinely reasonable sounding argument. What does the evidence say? A, take it, bundle discounts are structurally better value. B, in roughly half the files, full suite buyers ran AIOps at a fraction of entitlement for the whole term. C, take it only if the discount exceeds forty percent. Or D, never buy more than one ITOM module at a time. Pause, and ask what a discount on unused capability actually buys you.
The answer is B. In fourteen of roughly thirty files the discount never offset the shelfware, because a deep discount on capability you do not run is still money for nothing, and that is session three's bundle lesson wearing ITOM clothing. Answer C is the sophisticated looking mistake, inventing a discount threshold, and it fails because the problem is consumption rather than percentage. A sixty percent discount on a tier you never enable is worse value than list price on a tier you use daily. Answer D overcorrects into a rule, and rules like that cost you real bundle value when the consumption genuinely is there. And here is what the winners did, which is the actual answer. They bought Discovery and Event Management scoped to a governed CMDB, proved the value, and then added tiers at renewal using their own usage evidence as leverage. Demonstrated consumption sequences the purchase, not the discount table.
Now the benchmark, and this is a four step arithmetic exercise that will take you about ten minutes and that most buyers have simply never performed. Find the line, the ITOM figure on your order form for the term, which is the gross number everybody quotes and nobody decomposes. Find the count, the billable CI count from subscription unit reporting, which is the single document that decides an ITOM renewal and which is rarely opened between cycles. Divide, line by count, which gives you price per managed CI, and now you are holding a unit price, the only genuinely comparable thing in this product. And then clean, and re divide, recalculating after rescoping, because the same spend across fewer CIs is a worse unit price, and that comparison is your argument. Sit with the note, because it is the operational habit that matters most here. Subscription unit consumption reporting decides this renewal, and most estates never look at it between cycles. Reading it quarterly is exactly what took overage exposure to approximately zero for the estates that did.
Guest analyst clip. The unit price calculation is the thing I most wish buyers did before their first ITOM conversation, and it takes ten minutes. Order form line, divided by billable CI count. That is it. And the reason it matters so much is that ITOM negotiations are almost always conducted in totals, and totals are incomparable. If I tell you a customer pays two million for ITOM, you have learned nothing, because you do not know whether they manage twenty thousand CIs or two hundred thousand. But if I tell you their price per managed CI, now we can actually talk, you can compare across time, across your own products, and against what I see elsewhere. And here is the tactical part. When you rescope and cut the count by thirty percent, your unit price gets thirty percent worse overnight, on unchanged spend. That is uncomfortable to look at and it is your single best negotiating exhibit, because you can put two numbers side by side and say, this is what we were paying per managed CI, and this is what we are paying now for the same money, and the difference is not a request, it is arithmetic. I have watched that one slide do more work than an hour of argument, because it converts a discussion about fairness into a discussion about a number.
Totals are incomparable, unit prices are comparable. And notice the tactical inversion in there, the fact that cleaning makes your unit price look worse is exactly what makes it useful, because it shows the same money buying less. Most buyers would hide that number. You should lead with it. Third check.
Knowledge check three. You rescope and cut billable CIs by thirty percent. Your contracted ITOM spend is unchanged. What have you actually created? A, a thirty percent saving, realized immediately. B, a worse unit price, and the evidence to renegotiate at renewal. C, nothing, because spend did not change. Or D, a compliance risk, since coverage was reduced. Pause, and remember session twelve's lesson about consumption and entitlement.
The answer is B, and this check exists because both of the obvious answers are wrong in instructive ways. Answer A claims a saving that has not happened, because consumption falling does not reduce entitlement, exactly as in session twelve, and you keep paying the contracted figure until the paper changes. That is the trap that catches optimists. But answer C, nothing happened, is the trap that catches cynics, and it is equally wrong, because the same spend spread across thirty percent fewer CIs is a visibly worse unit price and that comparison is your entire argument at the renewal. Something very valuable happened, it just was not a saving yet. And answer D confuses what is counted with what is observed, which is precisely the distinction the rescoping method exists to preserve, and it is the objection you should expect from infrastructure, answered by pointing out that coverage is unchanged.
The ITOM renewal, three levers plus one product specific move. The cleaned count, rescoped, deduplicated, purged, with before and after documented, and the count is the negotiation here exactly as the roster was in ITSM. The unit benchmark, price per managed CI calculated before and after cleaning, so the conversation happens about a comparable number rather than a total. Tier rightsizing, AIOps and higher tiers only where value is demonstrated, with the full suite arithmetic actually done rather than assumed. And then the fourth card, bands rather than headroom, which is the ITOM specific move and the reason I am spending a moment on it. Because the count grows on its own, buying headroom in advance means guessing at growth you cannot predict, and you will guess wrong in one direction or the other. Pre agreed expansion bands at locked unit rates solve that properly. You are not buying capacity, you are buying the price of future capacity, which is exactly the right thing to fix in advance for a meter that moves by itself.
Guest analyst clip. Expansion bands are the piece of ITOM contracting I would most like buyers to adopt, and almost nobody asks for them, so let me describe what they look like. Instead of negotiating a CI count and buying some headroom on top, you agree a schedule. Up to this many managed CIs, this unit rate. From there to the next threshold, this rate. And so on, for the term. Now think about what that does to your risk. Your count is going to grow, because containers and cloud make that inevitable regardless of anybody's intentions. Under a headroom model you either overbuy, and pay for capacity that sits idle, or you underbuy, and land in a true up at whatever rate applies at that moment, which is never a good rate because you have no leverage mid term. Under a band model neither of those happens. Growth is priced in advance, at rates you negotiated when you had leverage, and there is no cliff to fall off. And here is why vendors often accept it more readily than buyers expect, it gives them predictable expansion revenue, which their forecasting genuinely values. So it is one of those rare structures that is better for both sides, and it goes unrequested mostly because buyers do not know it is available.
Growth priced in advance at rates you negotiated when you had leverage, with no cliff to fall off. Ask for bands. And note the closing observation, it is a structure that is genuinely better for both sides and goes unrequested because buyers do not know it exists, which is true of a surprising amount of enterprise contracting. Let's recap.
ITOM, in three sentences. The unit is the managed configuration item, anything the licensed products discover, monitor, or correlate, so autoscaling groups and short lived containers mint billable CIs and the count grows with no hiring at all, which decouples this line from every other one in your estate. Rescoping cut billable counts twenty to thirty five percent with no operational coverage lost, because each step reduces what is counted rather than what is observed, and one estate in two was paying for resources its own governance would have excluded. And the renewal turns on price per managed CI, a number most buyers have never calculated, with growth belonging in pre agreed expansion bands rather than in headroom bought up front for growth nobody can predict. Next session, ITAM and SAM, and there is a genuine irony waiting there. You are buying a licence management tool, priced per device rather than per user, and its own licensing has all the same problems as everything it is meant to help you manage.
Homework, about an hour, and one item on this list is worth the whole hour. One, open the report, find your subscription unit consumption reporting and read the billable CI count, and if nobody at your organisation has opened it this year, that absence is your finding. Two, calculate the benchmark, ITOM order form line divided by billable CI count, and write down your price per managed CI, because almost nobody knows theirs and you are about to. Three, audit the schedules, listing your Discovery schedules, their scope, and their owner, marking any that scan a subnet rather than a governed resource set. Four, hunt the ephemeral, estimating how many billable CIs come from containers and autoscaled instances, which is the one in two finding and usually the largest single number on this list. And five, check the AIOps tier, which resources sit on higher monitoring tiers and whether anybody actually chose that, or whether it was inherited from the original implementation.
Further reading, five guides. The ITOM licensing guide is today's session in written form, the five cost drivers, the rescoping method, the suite arithmetic, and the unit benchmark, and it carries the benchmark data behind every number I quoted. The Discovery licensing guide goes at Discovery specifically, how schedules mint billable CIs and the scoping rules that keep the count governed. The visibility and Discovery guide covers the tiers, what each adds, and where AIOps tier creep tends to appear. The Discovery white paper is the long form treatment with the governance model for keeping the CMDB and the billable count aligned, which is the structural fix. And the products list shows where ITOM sits among the technology workflows and how its unit differs from every other family in the catalog. That is session seventeen. Calculate your price per managed CI, and I will see you in session eighteen for ITAM.