Production, non production, and the three to five tenant estate, where the same worker holds a paid seat twice and the credit is only real if it is in the contract. 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 four, and today we widen the frame. Every single lesson in this course so far has quietly assumed one instance. One fulfiller pool, one assist meter, one transaction threshold, one contract. That assumption is wrong for most large enterprises, and it has been wrong the whole time. Most of them run three to five production tenants, and everything we have covered runs several times over across them. What makes that expensive is not the duplication itself, because some of it is genuinely justified, it is that nobody has ever priced it. And there is one number in here that I find slightly hard to say out loud, which is the share of licensed fulfillers who turn out to be the same human being holding a full price seat in two different tenants. Three checks, homework, let's go.
Five objectives. First, count the estate, because most large enterprises run three to five production tenants and each one carries its own fulfiller pool, its own contract line, and its own set of sub production copies. Second, find the duplicate fulfillers, because twelve to twenty percent of licensed fulfillers are the same worker holding a seat in two or more tenants, billed twice, at full price, for one person doing one job. Third, price non production honestly, because dev, test, and staging copies consume entitlement and draw on exactly the same consumption meters we spent the last two sessions on. Fourth, get the credit into the contract, because a retiring tenant's licence book returns twenty to forty percent when it is negotiated into the surviving order form and zero when it lives in an email. And fifth, sequence to the renewal, because the saving lands at the contract signature and not at the technical cutover, and those two dates are frequently a year apart.
Four numbers. Three to five, production tenants in a typical large enterprise estate, arriving through acquisitions, regional rollouts, and business unit autonomy. Twelve to twenty percent, licensed fulfillers who are duplicates of the same worker holding a seat in two or more tenants, and I want that to land properly, that is one person and two full price seats. Twenty to forty percent, the credit on a retiring tenant's licence book when it is negotiated into the surviving contract, and zero when it is left to a side email, and the gap between those two outcomes is a sentence in a document. And twelve to eighteen months, a typical end to end consolidation, where workflow harmonization rather than the technical clone is the long pole. The note underneath matters and I want to be fair about it. A multi tenant estate is the normal end state for a large enterprise, not a defect. It becomes a defect when nobody has priced it, and that is a different problem and a much more fixable one.
Guest analyst clip. The duplicate fulfiller finding is the one that gets the strongest reaction in the room, and I think it is because of how obvious it sounds once you say it and how completely invisible it is beforehand. We ran an identity match across three tenants for a manufacturing client, and it took a couple of days, because you have to reconcile people across three directories that do not agree about name formats. And when it came back, somewhere around fifteen percent of their licensed fulfillers appeared more than once. The same engineer, working in the group tenant and in the tenant that came with an acquisition, holding a full price seat in both, because he genuinely worked in both. And every part of that is correct. He does need access to both. Both tenants are licensed properly. Neither tenant's own reporting can see the other one, so no report anywhere in that organisation was wrong. The duplication exists only in the space between the two systems, and no system owns that space. What I would say to anybody running a multi tenant estate is that this is the one number you cannot get from your platform team, however good they are, because it is not visible from inside any single instance. Somebody has to deliberately go and match identities across tenants, and until somebody does, that money leaves every year and nobody sees it go.
The duplication exists only in the space between the systems, and no system owns that space. That is worth remembering as a general shape, because it is why nobody is at fault and why nobody finds it. Let's look at why the tenants are there in the first place.
Four drivers, and read the right hand column carefully because that is where the money stays. Acquisitions, where the target keeps running its own instance after close, and it survives because identity and finance integrate first and the ServiceNow tenant gets deferred, typically right past the first joint renewal. Regional rollouts, a separate instance per region for data residency, surviving because data protection concerns outlive the technical case by years, sometimes correctly. Business unit autonomy, where a division bought ServiceNow independently, and it survives because that division controls its own roadmap and quite reasonably resists migrating into somebody else's tenant. And sub production sprawl, where every production tenant carries its own dev, test, and staging copies, surviving because nobody ever retires an environment and there is no cost signal attached to keeping one. Acquisitions are the largest single driver. The counter move is to put the ServiceNow tenant on the integration backlog at deal close rather than at the first joint renewal, because the credit conversation is far stronger while the surviving contract is being negotiated anyway.
Five points on the duplicate fulfiller. The mechanic, which is that ServiceNow licenses the fulfiller, the full access user who works records, and the same person holding a seat in two tenants is billed in both, at full price, in both. The scale, twelve to twenty percent of licensed fulfillers across the estates reviewed, and nothing in either tenant flags it because neither tenant can see the other one. The price, where analyst ranges put a fulfiller at roughly a hundred to two hundred and fifteen dollars a month depending on tier, so a benchmark hundred and thirty five dollars is about sixteen hundred and twenty a year, twice, for one worker. The orphans alongside them, because inactive and orphaned accounts never get cleaned up while a tenant runs in isolation, so your duplicate audit finds those in the same pass and they add to the recovery. And then the fifth, which is the important one. It is invisible by construction. Each tenant's own usage data is complete and correct. The duplication exists only in the space between them, and no report in your organisation covers that space.
Knowledge check one. You run three tenants with a thousand licensed fulfillers between them. Where do you expect the largest single recovery? A, negotiating a better per fulfiller rate across all three. B, deduplicating workers who hold a seat in more than one tenant, plus the orphans found alongside them. C, downgrading tiers on the two smaller tenants. D, reducing sub production copies. Pause here, and ask which of those is a full price seat being paid twice for one person.
The answer is B, deduplication. Duplicate fulfillers are the most expensive consequence of a multi tenant estate, and in the worked benchmark a thousand licensed seats collapse to eight hundred and twenty unique active fulfillers. That reclaims a hundred and eighty seats at roughly sixteen hundred and twenty dollars each, about two hundred and ninety one thousand six hundred a year, and that is before anybody touches the platform stacks underneath. Answers C and D are both real and both smaller. And answer A is the reflex this course keeps interrupting, because a better rate applied to a population that contains a hundred and eighty people who should not be in it is a discount on a mistake. It also feels like the most active thing you could do, which is exactly why it gets chosen.
Non production, the environments nobody prices. Four cards. They consume entitlement, because sub production copies draw on the platform stack and the benchmark puts platform and sub production overhead at a material six figure line per tenant, which multiplies by the number of tenants you run. They share the assist pool, because development and sub production usage draws on the production meter, and teams have exhausted their pools without a single production user noticing, which is last session's finding arriving with a multiplier. They run the transaction meter, because test harnesses run harder than users do and a load test is a machine built specifically to generate volume, which is session twenty two exactly. And nobody retires one, because there is no cost signal on an idle environment, so the answer is a named owner and a review date, precisely as with custom applications. Now read the note, because I think it is the most useful sentence in this session. This is the third time in three sessions that the answer has been an inventory with owners and review dates. That repetition is the point. Consumption problems are governance problems wearing different technical clothing.
Knowledge check two. Your assist pool is forty percent consumed at month three and production adoption has barely started. You run four tenants. Where do you look first? A, production usage in the largest tenant. B, non production and sub production activity, which draws on the same meter. C, the licensed user count for Now Assist. D, nowhere, forty percent at month three is within tolerance. Pause here. You met this pattern last session, and the estate makes it larger.
The answer is B, non production. Development and sub production draw on the production meter, and a four tenant estate carries four separate sets of development and test environments, so the non production share of your burn scales with the size of the estate rather than with your adoption. Answer A is where people look first, and it is precisely where the usage is not, because you were told production adoption has barely started. Answer C is the seat instinct again, and by session twenty four you should be catching that one automatically. Answer D reads a percentage without a projection, which is what we spent a whole slide on last session. The estate does not create this problem. It multiplies it, and multiplication is the theme of the entire session.
The credit mechanic, four paths, and only one of them returns anything. Written into the surviving order form, with recognition language signed alongside the renewal, returns twenty to forty percent of book value, thirty at the midpoint. Promised in an account team email, which has no contractual force at signature, returns nothing, and by then the account team has usually rotated anyway so there is nobody to appeal to. Raised after the surviving deal is signed, which means reopening a closed negotiation with nothing left to trade, returns very little and only as goodwill. And never raised, where the retired book simply disappears and nobody in the organisation ever knows it existed. Now the note. In the worked scenario two retiring tenants carry a combined fulfiller book of six hundred and forty eight thousand dollars a year. At the thirty percent midpoint that is a hundred and ninety four thousand four hundred recognized against the new commitment, or it is nothing at all, and the only difference between those two outcomes is where the sentence was written down.
Guest analyst clip. The credit conversation is one where I have watched genuinely capable procurement people get caught, and the reason is that it does not feel like a negotiation while it is happening. You are retiring a tenant. Everybody agrees it is a good thing. The account team is supportive, because they would rather have you consolidated on a bigger surviving contract than running an inherited instance they cannot grow. And somebody says, of course we will recognise the value of the retiring licences, and they mean it when they say it. It is not a trick. And then the surviving contract gets signed, twelve months later, negotiated by different people on both sides, and the recognition language is not in it, because nobody drafted it, because it was never a disputed point. That is the mechanism. It is not bad faith, it is the ordinary way a verbal understanding evaporates across a year and a personnel change. So the discipline is unglamorous. When somebody agrees the credit in principle, that is the moment you ask for the sentence, in the order form or in a signed amendment to it, and you ask for it while everybody is still enthusiastic. A credit that everyone agrees with and nobody has written down is worth precisely the same as a credit nobody agreed to.
A credit everyone agrees with and nobody wrote down is worth the same as a credit nobody agreed to. And notice that it fails through ordinary organisational drift rather than through anybody behaving badly, which is a pattern by now. Now the programme itself.
Twelve to eighteen months, four phases, and the long pole is not the one people expect. Inventory and scope, months one to three, mapping every tenant, fulfiller, workflow, and integration, and the duplicates you find here are the savings case that funds everything after it. Workflow harmonization, months three to ten, aligning incident, change, request, and CMDB models across business units, and this is the long pole, and it is a people and process programme rather than a data move. Migration and test, months eight to fourteen, where you plan for sixty to seventy percent automated migration through clone and update sets, and the remainder, custom applications and complex integrations, gets rebuilt by hand. Cutover and retirement, months fourteen to eighteen, legacy tenants retired, data archived to a retention plan rather than deleted, and the licence credit recognized at signature. And the fifth point, heavy customization in customer service or HR workflows pushes this toward twenty four to thirty months, so scope that manual rebuild before you sign a migration plan, because the thirty to forty percent the toolkit cannot move is where these programmes overrun.
Knowledge check three. Your integrator proposes booking the consolidation saving at technical go live. What is wrong with that? A, nothing, the saving is real once the tenant is retired. B, the saving lands at the surviving contract signature, so the plan should sequence retirement to the renewal. C, the saving should be booked at project start. D, savings cannot be booked until the following fiscal year. Pause here, and ask when money actually moves in this relationship.
The answer is B. Consolidation is a contract event wearing a technical costume. The licence credit and the reduced commitment are recognized at the surviving contract signature date, not at cutover, which means a tenant retired six months after you signed a renewal saves you nothing at all until the next one comes around. Answer A is the standard integrator framing and it is not dishonest, it simply misreads where the money moves, because from a delivery perspective the work does finish at go live. The practical consequence is a sequencing decision that belongs in the programme plan on day one. Put workflow harmonization on the critical path, because it sets the real timeline, and time the cutover to land on the renewal you are already going to be negotiating.
Four sessions into module five, so let me draw the shape. App Engine, transactions, the assist pool, and the estate itself. Four completely different meters, one repeated pattern. The decision is made elsewhere, in design reviews, engineering choices, testing plans, and acquisition integrations, and none of those rooms contains the licence while all of them set it. Growth needs no approval, because tables, transactions, assists, and tenants all accumulate without a decision and nothing in the platform stops any of them. An inventory with owners is the control, for custom apps, scheduled jobs, capabilities, and environments, and it is the same answer four times because it is the answer. And timing decides the price, before the threshold, at mid year, at deal close, sequenced to the renewal, because the same finding costs more the later it surfaces. If module five has one lesson, it is that the platform layer is governed rather than negotiated, and the governance is what makes the negotiation cheap.
Guest analyst clip. I want to push back gently on something that comes out of consolidation conversations, because I have heard it used badly. People come away from a session like this thinking the goal is one tenant, and that consolidating is automatically virtuous. It is not. I have seen organisations spend two years and a great deal of goodwill forcing a division onto a shared instance when the division had entirely legitimate reasons to run its own, and the licence saving did not come close to covering the disruption. A regional instance that exists because a regulator requires data to stay in country is not sprawl, it is compliance. A tenant that belongs to a business you are actively preparing to divest should absolutely stay separate. What I actually argue for is much narrower. Know how many you have, know what the duplication costs, and make the decision deliberately rather than inheriting it. If you run four tenants and you can articulate why each one exists and what it costs you, that is a well run estate and I have no argument with it. The failure mode is not multiplicity. The failure mode is not knowing, which is where most estates sit, and the fix for that is two days of work rather than a two year programme.
The failure mode is not multiplicity, it is not knowing. Four tenants you can justify and price is a well run estate. Session twenty five closes module five with the consumption review itself, finding what you pay for and do not use, across every meter these four sessions have opened.
Three sentences. Most large enterprises run three to five production tenants after acquisitions, regional rollouts, and business unit autonomy, and twelve to twenty percent of licensed fulfillers turn out to be the same worker holding a full price seat in more than one of them. Non production is the quiet multiplier, because every tenant carries its own dev, test, and staging copies that consume entitlement and draw on the same assist and transaction meters as production. And a retiring tenant's licence book returns twenty to forty percent when the recognition language is written into the surviving order form and nothing when it is promised in an email, with the saving landing at the contract signature rather than at the technical cutover.
Homework, about an hour, five items. Count the tenants, every production instance with its fulfiller count, its tier, and its renewal date, and I would pay attention to those renewal dates because on their own they often explain a great deal about how the estate got here. Find the duplicates, which means matching fulfiller identities across tenants, expecting twelve to twenty percent, and pricing the overlap at your own per seat rate rather than at the benchmark. List the environments, development, test, and staging copies per tenant with an owner for each, and note specifically which ones nobody can name a purpose for. Check the inherited tenant, and if you have acquired a company, ask whether its ServiceNow instance is on any integration backlog at all or whether it is simply waiting for a renewal to notice it. And read the credit language, because if you have ever retired a tenant, you should be able to find where that credit was recognized, and if the answer is an email then that is the lesson and it is not too late for the next one.
Five guides. Consolidate ServiceNow instances and cut licence cost is the worked consolidation in full, the duplicate fulfiller arithmetic, the credit mechanic, and the twelve to eighteen month sequence, and it is the one to read this week if any of today applied to you. Now Platform negotiation covers the platform line underneath every tenant, which is precisely what multiplies when the estate does. Fulfiller versus requester licensing explained is the seat definition that gets paid twice in a multi tenant estate, and it is worth rereading with today in mind. The license rightsizing playbook has the identity matching and activity audit that produce your duplicate list, applied across instances rather than within one. And the renewal negotiation playbook covers where the credit language belongs and how a consolidation gets sequenced to the renewal that recognizes it. Next time, shelfware and the consumption review, and module five closes. See you there.