Nine workflow families, twenty five plus products, one platform premium, and the map that keeps a quote honest. 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 three of forty. Last time we took apart the people meter, and if you did the homework you have already classified fifty of your own users and, I suspect, found a few movers. Today we climb one meter up, to the product meter. ServiceNow sells more than twenty five products across nine workflow families, every one of them with its own SKU, its own tier ladder, and its own counting unit, and all of it runs on one platform, which is exactly what makes the catalog hard to see clearly. And here is the session in one sentence, you cannot control a quote for a catalog you cannot see. So today we draw the map. The families, the units, where the money concentrates, how the tier ladders work, what bundles actually do, and the inventory document that keeps all of it honest. Three knowledge checks as always, homework at the end, and by the next session you will have your own catalog mapped. Let's start.
Five objectives. First, draw the map, the nine workflow families, the flagship products in each, and the licensing unit each one is counted in, because the unit changes family by family and that changes everything about how each line grows. Second, follow the money, where spend concentrates in a typical estate and which lines grow fastest between renewals, so you know where to aim your effort. Third, read a ladder. Every product carries a tier structure, the pattern repeats across the catalog, and you will learn to price a tier against the features you actually use rather than the roadmap you were shown. Fourth, control a quote, breaking any bundle into per product unit prices and naming the terms that stop attached products from becoming shelfware. And fifth, keep the inventory, the deployed product inventory, licensed, live, or leaving, that decides what renews and what does not. This session pairs with session two. That one built your user file, this one builds your deployment map, and those are two of the three documents that win renewals.
The shape of the problem, in four numbers. Nine. Nine workflow families on one platform, technology, employee, customer, creator, security, risk, finance, industry, and AI, more than twenty five products, each with its own SKU and unit. That breadth is a sales strategy, the wider the catalog, the harder the quote is to itemize. Five to seven. That is how many products a typical estate has licensed, against three or four actually running in production. Sit with that gap for a second, roughly a third of the typical product spend is not running, and it renews by default, every year. Ladder. Every product carries a tier ladder and the step ups carry the margin. Since April twenty twenty six the ITSM ladder reads Foundation, Advanced, Prime, and the same climb one tier motion repeats across the whole catalog. And fifteen to twenty five percent. That is what buyers cut from bundle costs just by demanding per product unit pricing before accepting a package rate. The bundle hides the units for a reason. Before we draw the map, let's get the view from inside the estates.
Guest analyst clip. Here is a little exercise I run at the start of almost every engagement. I ask the customer to list, from memory, every ServiceNow product they are paying for. Then we pull the order forms and compare. In years of doing this, I can count on one hand the estates that got it right. The usual miss is two or three products, and it is always the same kind of product. The thing that came attached to a bundle four years ago. The module a departed executive was excited about. The add on that was included in the deal, which, by the way, is never true, nothing is included, it is priced in and hidden. And every one of those forgotten products has been renewing, with an uplift, since the day it was signed. My favorite was a customer paying six figures annually for a product whose go live project had been cancelled, the project, not the subscription, five years earlier. Nobody cancelled the line because nobody could see the line. That is the whole reason the map matters. The account team knows your catalog perfectly. Their compensation depends on it. On your side, the knowledge walked out the door with whoever signed the deal. The map is how you get it back.
Five years of renewals on a cancelled project. And notice the asymmetry at the end of the clip, because it is the same asymmetry as session one, the account team knows your catalog perfectly, and on your side the knowledge left with the person who signed. Every document this course makes you build, the user file, the deployment map, the entitlement baseline, exists to close that gap. Alright, the map itself, nine families.
Six rows on the slide, nine families in the catalog, and the ones I have condensed are the finance, industry, and platform foundation lines. Walk the units column with me, because that is the row that matters. Technology workflows, the biggest family, ITSM counted in fulfillers, the people you licensed in session two. But ITOM, in the same family, counts nodes and subscription units, infrastructure, not people. And ITAM counts assets under management. Employee workflows, HRSD and its siblings, fulfillers plus covered employee counts, onboarding department by department. Customer workflows, CSM and field service, fulfillers and cases, with portal and community add ons. Creator and platform, App Engine, Automation Engine, Integration Hub, counted in custom tables, creators, users, and transactions, and I want to flag this family especially, because these are build decisions that become license decisions, an architect draws a custom table and your bill changes, and we give that its own session in module five. Security and risk, SecOps and IRM, fulfillers plus their own unit metrics. And the AI layer, Now Assist and the agents, counted in consumption, the assist pool from session one. Here is the takeaway sentence. No single number describes a ServiceNow estate. Anyone who quotes you one number is hiding at least five others.
Now follow the money, because the families are not equal. ITSM is the anchor, the largest line in most estates and the reference price for everything else. The account team prices the expansion path against it, which means its terms leak into every other line, and that is why your best contract language goes here. ITOM is the multiplier. Discovery and Event Management scale with infrastructure, not staff, so this line grows while your head count stays flat, every virtualization project, every acquisition, every container cluster feeds it. HRSD and CSM are the spreaders, they arrive department by department, usually mid term, on go live dates that rarely match your renewal date, which is exactly why phasing and co terming exist. App Engine is the sleeper. Every custom application your teams build has a licensing consequence, tables and users, and it usually gets reviewed for the first time at a renewal, after the spend already happened. And Now Assist is the new line, bundled into the tiers, metered by consumption, growing with adoption, where this year's pilot quietly becomes next year's budget item. The principle is effort follows money. Anchor gets terms, multiplier and spreaders get caps and phasing, sleeper gets governance, new line gets a pool sized on evidence. First check.
Knowledge check one. Your ITOM quote scales on a different unit than your ITSM quote. What is ITOM typically counted in? A, fulfiller users, like ITSM. B, covered employees, like HRSD. C, nodes and subscription units tied to infrastructure. Or D, assist consumption from the bundled pool. Pause here, and think about what ITOM actually manages.
The answer is C, nodes and subscription units. ITOM manages infrastructure, so it is counted in infrastructure, devices, nodes, units that scale with your estate rather than your staff. And that is precisely why I called it the multiplier, it grows when you virtualize, when you containerize, when you acquire a company, all with zero new hires and zero new fulfillers. Answers A and B are the units for the people centered families, and D is the AI meter. Why does this check matter? Because you cannot cap the growth of a line if you do not know what makes it grow. A head count cap on an infrastructure metered line protects you from exactly nothing. Match the control to the unit, always.
The tier ladders. Every product in the catalog carries one, Standard, Pro, Enterprise style, learn to read one and you can read them all. On ITSM, since April twenty twenty six, the ladder reads Foundation, Advanced, and Prime, ordered by AI capability, with the fully autonomous agents gated to Prime only. Now, the commercial mechanics of a ladder. The step up sells the future. Higher tiers are pitched on roadmap, on AI ambition, on where your platform journey is going. But the invoice is monthly, and it starts now, whether the ambition ever ships or not. So the buyer side discipline is, price the tier against usage. List the features your teams actually exercised last quarter, put them against the tier grid, and find the lowest tier that contains them. That is your tier. Everything above it is a monthly fee for a slideware future. And the ladder goes down as well as up, this is the part account teams never mention. We ran an edition downgrade at one enterprise that saved eight hundred thousand dollars, an Enterprise tier bought years earlier for features that, on the evidence, nobody had ever turned on. The feature grid was the entire argument. Which sets up the next check nicely.
Knowledge check two. Your teams use incident, change, Virtual Agent, and standard reporting. The account team proposes Prime, for the AI roadmap. What is the buyer side move? A, accept Prime, future proofing avoids a migration later. B, map used features to the tier grid and price the lowest tier that contains them. C, refuse AI entirely and demand a legacy tier. Or D, split the difference and take the middle tier. Pause here. What evidence should decide a tier?
The answer is B, the feature to tier map, and it is the only evidence based option on the list. Here is the context that makes it urgent. In six out of ten estates we reviewed under the new packaging, the pitched tier was above the demonstrated need, sold exactly this way, as an AI upgrade. Answer A, future proofing, pays a premium every single month for a roadmap that may never be exercised, and notice the asymmetry, if you genuinely need the higher tier later, upgrading is a phone call they will take with delight. Downgrading, as you saw, is an argument. Answer C fights the packaging instead of the price, and the legacy tiers hit end of sale in July twenty twenty six, that door is closed. And answer D, splitting the difference, is a negotiation habit pretending to be analysis. Tiers are bought on evidence, exactly like users are. Same discipline, one meter up.
The AI layer deserves its own five minutes, because it is a consumption line wearing a product name. Five things. Now Assist ships per product, Now Assist for ITSM, for HRSD, for CSM, and each of them draws on the assist pool your tier bundles, so the seat price and the meter are separate questions, always ask both. It is bundled since April twenty twenty six, which means every renewal now contains a consumption negotiation, including renewals where the buyer thinks they did not buy AI. The agents sit at the top, fully autonomous agents and custom skill building are Prime only, so if the demo that excited your leadership showed an agent doing something magical, check which tier the demo assumed before anyone signs. Every environment draws on the pool, development and sub production burn assists exactly like production does, and yes, a load test can eat a month of assists, we have watched it happen. And finally, size on evidence. Pilot consumption times realistic adoption is the pool you need. The pool in the first quote is the pool that made the deal look small. Module five gives this meter a full session, the sizing, the governance, and the overage math. For now, carry the three questions from session one, what is in the pool, what draws on it, what does a unit cost past it.
Now bundles, and quote control. A bundle is how a wide catalog gets sold fast, one price, several products, the unit economics hidden inside, and in six of ten deals we reviewed, the bundle attached one to three products that never reached production. Five controls. Per product pricing, demand the unit price of every product in the package before accepting any bundle rate, buyers who did cut fifteen to twenty five percent against the package price. The attach test, for each attached product, ask who deploys it, when, and on whose budget, because no named owner and no go live date means it is shelfware being priced as value. Swap rights, the right to redeploy unused subscriptions to other products mid term, absent from most contracts by default, and it is the difference between a mistake and a write off. Phase to go live, entitlements start when departments actually onboard, HR going live in month nine should not be billed from month one. And co terming, every add on aligned to the master renewal date, so the estate negotiates as one and no product renews alone, without leverage. Notice what none of these controls do, none of them reduce what you can deploy. They reduce what you pay for not deploying, which is the actual risk in a bundle. Let's hear a bundle negotiation from the inside.
Guest analyst clip. I will walk you through a real one. A customer came to us with a bundle proposal, seven products, one number, and a genuinely impressive discount off the so called package list price. The account team called it a platform deal, and the deck was beautiful. First thing we did was boring, we asked for the seven unit prices. It took three requests to get them, which tells you something on its own. When the numbers finally arrived, two of the seven products were priced at a discount far below the others, and those two were, surprise, the two the customer had no plan to deploy. They existed in the bundle to inflate the package value the discount was calculated against. Deep discount on shelfware is still shelfware. So we reshaped the deal. Five products, per product pricing, phasing on the two that had go live dates later in the year, swap rights on everything, and the total came in under the bundle price, for the things they would actually run. The account team fought hardest on the itemization, not the discount. Remember that. The number they defend tells you where the margin is. On a bundle, the thing they protect is the blend.
The number they defend tells you where the margin is. That is a sentence to keep for module seven, but you just saw the whole method in miniature. Itemize, apply the attach test, phase what has a date, swap protect what has a doubt, and let the dead lines fall out of the deal. Three requests to get unit prices is not an accident, and it is also not a refusal, they will produce them if you insist, because they know you can walk into the renewal without signing the bundle at all. Now, the document that makes all of this repeatable.
The deployed product inventory, the deployment map from session one, formalized. Three columns, licensed, deployed in production, planned with a date, and every product on every order form appears in exactly one of them. Then three layers of detail. The feature layer, for tiered products, which features were actually exercised last quarter against the tier grid, that is your downgrade evidence, the eight hundred thousand dollar kind. The growth units, for ITOM, App Engine, and the AI layer, last quarter's unit consumption and the trend, that is what growth caps get negotiated against, matched to the right unit, as check one taught you. And the switch off list, licensed, not deployed, no owner, no date. I want to be precise about what that list is for. Those lines fund your renewal. They get terminated, they get swapped under your swap rights, or they get traded for something you actually want, but they never, ever renew silently. And like the user file, the inventory is owned and dated, one owner, a quarterly review, and a version that goes into the renewal file. Last check of the day, and it puts the inventory to work.
Knowledge check three. At renewal you find six products licensed, four deployed. The account team offers a deeper bundle discount to keep all six. What is the stronger position? A, take the discount, the effective rate per product drops. B, renew all six but demand price holds on the unused two. C, present the inventory, terminate or swap the two, and negotiate the four on per product pricing. Or D, threaten to leave the platform over the two products. Pause here. Which position is built on your evidence rather than their discount?
The answer is C. Present the inventory, cut or swap the dead lines, and negotiate the living ones on per product pricing. Walk the others. Answer A prices shelfware as value, a lower rate on products you do not run is still waste, and it renews with an uplift, forever, the discount just makes the waste feel negotiated. Answer B keeps paying for the problem, politely. Answer D burns credibility on a threat nobody believes, you are not leaving the platform over two modules, and they know it, save your walk away for module seven where we build one that works. Answer C is your evidence setting the scope of the conversation. The two dead lines fund the deal, and per product pricing keeps the surviving four honest. And notice, none of it is possible without the inventory. The document is the position.
The operating model for the product meter, five habits. Keep the catalog map, the nine families, your products in each, the counting unit per line, one page, updated whenever ServiceNow repackages, which is roughly yearly. Per product pricing always, a standing rule that no bundle rate is accepted without the unit prices behind it, on the quote, in writing. Freeze the product words, the same discipline as session two, the order form freezes product definitions and tier grids so a repackaging cannot silently reprice you. Phase and co term by default, both asked for at signature, when they cost the seller nothing to grant. And review the inventory quarterly, right beside the role review, so the renewal file always holds a current version of both. One more clip before we close, on what this discipline looks like when the renewal actually arrives.
Guest analyst clip. Let me put the two sessions together for you, because this is where it gets fun. The renewal I remember best, the customer walked in with two documents. The user file from their quarterly role reviews, and the product inventory, licensed, live, or leaving, with the feature grids attached. The account team opened with the standard renewal deck, current entitlements, plus uplift, plus two recommended expansions. And the customer just worked through their own documents instead. Here is the corrected user count, here are the four products we are keeping on per product pricing, here are the two we are terminating under the inventory, and here is the feature evidence for the tier we actually need, one below the one we have. Forty minutes. The uplift went away because the base was clean and defended. The expansion conversation happened, but on the customer's terms, priced against features with named owners and go live dates. And the tier came down. The total dropped double digits at a renewal, which, if you know ServiceNow renewals, is not what usually happens. Nothing in that meeting was clever. Every single move was prepared, quarters earlier, by somebody keeping two documents up to date.
Nothing in that meeting was clever, every move was prepared. That is this course's thesis, stated by someone who watched it pay off. You now know two of the three documents, the user file from session two, and the product inventory from today. The third is the consumption read, and module five builds it. Let's recap.
The catalog, in three sentences. Nine workflow families, twenty five plus products, and a counting unit that changes family by family, fulfillers, nodes, employees, tables, transactions, and assists, so no single number describes the estate. Every product carries a tier ladder, the step ups carry the margin, and the tier you owe is the lowest one containing the features your record shows you using, in both directions, down as well as up. And bundles hide unit prices and attach shelfware, so the deployed product inventory, licensed, live, or leaving, is the evidence that keeps every quote honest. Next session we go back to the paper, the contract stack in depth, the subscription agreement, the order forms, the definitions, and the eight clauses that set your cost for the whole term. That one is the lawyers' session, and it might be the highest value hour in the course.
Homework, about an hour, five items, and this week you are building your map. First, draw it, every ServiceNow product on your order forms, sorted into the nine families, with the counting unit for each. Second, mark the three columns, licensed, deployed in production, or planned with a date, and anything sitting in licensed only goes on your switch off list, that list is money. Third, read one ladder, take your biggest tiered product, pull the tier feature grid, and mark what your teams actually used last quarter. Fourth, find the bundle, your most recent bundled quote, and check whether per product unit prices appear anywhere on it, I already know the answer, but check. And fifth, note the growth units, for any ITOM, App Engine, or Now Assist line, last quarter's consumption next to the entitlement. Do the first two at minimum, because session four reads your order forms with you, and the map makes that session land.
Further reading, five guides. The products list is today's map at full resolution, all nine families, product by product. The Standard versus Pro versus Enterprise guide is the ladder logic in depth, with the feature to tier method from check two. The App Engine explainer covers the sleeper line, custom tables and where a build decision becomes a license decision, read it before module five. The Now Assist pillar is the AI layer in full, the pool mechanics and the governance. And the edition downgrade case study is the ladder going down in real life, eight hundred thousand dollars, argued entirely from a feature grid. That is session three, and that is the first module nearly done. Do the homework, draw your map, and I will see you in session four for the contracts.