The evidence pull, the classification pass, the removals that survive a CFO review, and the plumbing that stops it regenerating. 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 twelve, and today we actually run the thing. Last session I gave you the line and the theory, where fulfilling stops, why the role table is the meter rather than the activity log, and where the gray zone sits. Today is the audit itself, end to end. What to pull, how to classify, which cuts to take in which order, what people will say when you propose removing their access, and then the half of the project nobody budgets for, the plumbing that stops the whole thing regenerating within two years. And I want to set expectations honestly. This is the least glamorous session in the module and probably the most valuable, because everything in it is work you control completely. There is no vendor in this session. No negotiation, no leverage, no clever tactics. Just a sequence, run properly, that takes fifteen to thirty percent off the platform without anybody losing a capability they use. Three checks, homework that starts your real audit, let's go.
Five objectives. First, pull the right evidence, the five exports that make a classification defensible, and specifically the field inside each one that does the work, because most people pull the right file and then use the wrong column. Second, run the classification pass, moving from raw roles to a proposed licence per user with a recorded reason against every change. Third, sequence the cuts, and I mean sequence deliberately, uncontested removals first, reclassifications second, contested cases last, because momentum is a resource and you spend it in an order. Fourth, answer the objections, the four things people say when you propose removing their role, with a response to each that keeps the relationship intact, because you have to work with these colleagues afterwards. And fifth, fix the plumbing, templates, groups, custom roles, and joiner mover leaver, so the count does not simply rebuild itself while you are congratulating yourself.
Four numbers, and the framing on this slide is the session in one line. The cleanup wins the year, the plumbing wins the term. Fifteen to thirty percent, the platform cost reduction from classifying every named user on activity evidence, with, and this qualifier matters enormously, no user losing a capability they actually exercised. Twenty five to forty five percent, the reduction in claimed exposure when the cleanup ran before the count was taken, from the review defences we ran, which is session five's lesson repeating, before is where the value is. Ninety, days without a login, the cleanest cut in the entire exercise and the one nobody argues with, which is exactly why you start there. And two years, roughly how long an unfixed estate takes to regenerate its overcount through joiners and movers alone, at a few percent a month, compounding quietly back to where you began. Every number on this slide comes from work done before a negotiation rather than during one, and that is what makes this the highest return hour in the module. Let's hear how the exercise actually runs.
Guest analyst clip. The first time I ran one of these I made a mistake I now warn everybody about. I did the analysis beautifully. Spreadsheet, every user classified, colour coded, a saving number at the bottom that made the CFO very happy. And then I took it to the platform team as a finished answer, and it died in that room. Not because the analysis was wrong, it was right, but because I had walked in and told a group of professional people what their own users should have, based on data they had not seen, using a method they had not agreed. They spent the meeting finding edge cases, and there are always edge cases, and every one they found made the whole document look shakier. Now I do it the other way round. I bring the method before I bring the answer. Here are the five exports, here is the four column classification, here is the test we are going to apply, does this look right to you. And they always improve it, genuinely, because they know things about their estate that no export contains. Then I run the analysis with their fingerprints on the method, and when the answer arrives it is our answer rather than my answer. Same numbers. Completely different reception. This is an organisational exercise wearing a technical costume, and if you treat it as purely technical you will produce a correct document that nobody implements.
Bring the method before you bring the answer. That is the single best piece of process advice in this module, and it costs you one extra meeting at the start to save a project that would otherwise stall. And note the underlying point, an organisational exercise wearing a technical costume. Every failure mode in this session is social rather than analytical. Now, the evidence.
Five exports, and for each one I have named the field that actually does the work. User and role assignment, and the field is the grant path, direct, group, or template, per role per user. That tells you how each person became billable, which is what tells you what to fix. Activity by user, and the field is records worked in the last ninety days, not logins, and I want to underline that because it is a common error. Logins prove presence. They do not prove fulfilment. A person can log in daily to check their own tickets and never touch a record that is not theirs. Role definitions, the field is write access on task tables, per role, including the custom ones, which tells you which roles are billable at all regardless of their names. Group membership, which groups carry billable roles and who owns them, which shows you where the regeneration happens and who can gate it. And integration and service accounts, with last activity and the licence held, which is machine work billing at person prices, the least contested cut of all. And the note is the important part. Pull all five before classifying anything, because a classification built on activity alone can tell you who to fix and never tells you how to prevent the next one.
The classification pass, one row per named user, four columns. Column one, holds, the billable roles this user currently has with the grant path for each, which is what ServiceNow counts today. Column two, does, records worked, approvals given, reports viewed, over ninety days, the behavioral evidence taken from the record rather than from anybody's memory, and memory is generous in both directions so we do not use it. Column three, should hold, the licence the activity supports, fulfiller, business stakeholder, or requester, and this is usually a demotion. And column four, reason, one line, dormant, approver only, dashboard only, moved roles, machine account, or confirmed fulfiller. Now here is why column four matters more than it looks. The reason is the artifact, not the verdict. When somebody objects in three weeks time, and somebody will, you do not re run the analysis, you point at the reason and ask whether it is wrong. That turns an argument about a spreadsheet into a conversation about one sentence. And then the practical trick, sort by the gap between column one and column three, and you have your work list, ordered by value, before you have spoken to a single human being.
Knowledge check one. You have activity data showing six hundred fulfillers barely work any records, but you have no grant path data. What can you not do? A, propose reclassifications, because without grant paths the activity is meaningless. B, prevent the same six hundred from reappearing, because you cannot see what created them. C, calculate the saving, which needs the grant path. Or D, nothing is blocked, grant paths are administrative detail. Pause here, and ask what the grant path uniquely tells you.
The answer is B. Activity data alone fully supports the cleanup, you can propose every reclassification and price every saving, so A and C are both wrong and I put them there because they tempt people into thinking the grant path is a prerequisite for the whole exercise. It is not. What it is a prerequisite for is prevention. Without it you cannot tell whether those six hundred users got their roles from a template, from group membership, or from a direct grant by an administrator, and so you fix six hundred users while leaving intact the machinery that manufactured them. That is exactly the estate that regenerates its overcount in about two years, which is the story you heard at the end of last session. So the grant path is not administrative detail, answer D, it is the difference between a cleanup and a fix. One of those is a project. The other is a control.
The cuts, in the order that builds momentum, five stages. Machine accounts first, integration and service credentials sitting on named licences, because nobody defends them, nobody loses anything, and the saving is immediate. Start where there is no politics at all. Then the dormant, no login in ninety days, the cleanest cut in the exercise, and build the removal list with names, departments, and dates so that managers are confirming rather than debating, which is a very different meeting. Then the approvers, session eleven's six figure reclassification, and remember the framing, they keep approving, only the licence changes, so the conversation is about paperwork rather than about access. Then the dashboard viewers, moved to business stakeholder, and expect slightly more discussion because people genuinely care about their reports, so lead with the fact that the licence keeps their reports. And contested cases last, the occasional actors and the break glass admins, taken to their managers only once four categories of savings are already banked and the exercise has visible credibility behind it. That sequencing is not squeamishness. It is recognising that your ability to win argument number five depends entirely on having won arguments one through four.
Knowledge check two. Your list has forty integration accounts, three hundred dormant users, and twelve genuinely contested cases. Where should the project start? A, the twelve contested cases, resolve the hard questions first. B, the forty integration accounts, because no owner objects and the saving is immediate. C, all three at once, to finish in one pass. Or D, the three hundred dormant users, because it is the largest number. Pause, and ask what an early win actually buys you later.
The answer is B, the machine accounts. They have no human defender, so they convert into saving with no negotiation whatsoever, and crucially they give the exercise a banked result before anybody has to be persuaded of anything. The three hundred dormant users, answer D, are a very close second and follow immediately, they are also low friction. Answer A is the instinct of a certain kind of thorough person, resolve the hard cases first, and it is how these exercises stall, because you spend your political capital on the twelve hardest conversations before you have demonstrated that the project produces anything. And answer C ignores what the clip told us, this is an organisational exercise as much as a technical one, and momentum is a real resource that gets spent in a sequence. Bank the free wins. Then spend the credibility they bought you.
Now the objections, four of them, and notice as we go that not one is answered with a licensing argument. I might need it one day, and what is behind that is loss aversion rather than a business requirement, so the response is, we will grant it on request within a day, because standing access for a hypothetical is the expensive option. I use it during incidents, which is sometimes genuinely true and worth designing for, so the response is rota based or time bound assignment, the role exists when the on call does. Removing it will break something, which is usually uncertainty about what the role actually grants rather than knowledge that it will, so the response is, we will remove it in a test instance first and share the result, and that is a five day answer rather than an argument. And it looks like a demotion, where the thing behind it is status, which is real and should be handled directly rather than dismissed, so the response is that the licence is invisible to everyone except finance, and capability and title are untouched. Four objections, four operational alternatives. That is why this exercise belongs to the platform team as much as to sourcing, because sourcing cannot offer any of those four answers.
Guest analyst clip. The objection I want to talk about is the status one, because it is the only one people are embarrassed to say out loud, which makes it the one that sinks projects quietly. Nobody sends an email saying I do not want to be downgraded. What they send is a very reasonable sounding note about an edge case, or they simply do not reply, and the project stalls in a way nobody can point at. I had this at a large insurer. A group of senior managers had held fulfiller access for years, never worked a record, and every one of them had a technical objection ready. It took an honest conversation to get to the real one, which was that they had been given this access when they were promoted and reading it as a signal about their standing. Completely understandable. What resolved it was not a licensing argument, it was the head of IT saying, plainly, in the room, that the licence type is a finance category that appears on an invoice and nowhere else, that nobody outside procurement will ever see it, and that their access to everything they had ever actually used was unchanged. The objections evaporated within a week. So my advice is to name that dynamic early rather than let it hide behind edge cases. If somebody is defending a role they have never used, the reason is rarely operational, and you cannot address a reason nobody has said.
You cannot address a reason nobody has said. And notice who resolved it in that story, the head of IT, in the room, saying it plainly. That is a sponsorship point. If you are running this exercise without a senior sponsor willing to say the licence is a finance category and nothing more, the status objection will hide behind technical edge cases indefinitely and you will never see it clearly enough to answer. Now, the plumbing.
Four fixes that stop the whole thing regenerating. Templates default to requester, so new starters get requester and any fulfiller role is granted by exception with a licence decision attached and a name against it. Groups are gated, a maintained list of which groups carry billable roles, an owner for each, and an approval before anybody joins, which turns membership from a silent purchase into a decision. Custom roles are reviewed, because any new role granting write on a task table needs sign off, and remember it will not be called itil, it will be called something perfectly sensible that nobody reads as a licensing event. And leavers and movers strip roles, wired into the HR event, because without that the dormant population rebuilds itself from the top every single year. Now the note, and this is the part I want you to actually act on. These four are the difference between a cleanup and a control, and you should budget for them explicitly, because they produce no headline number of their own and they are therefore the first thing cut when the project gets squeezed. The cleanup has a number attached and gets funded. The plumbing has no number and gets dropped, which is precisely backwards.
Knowledge check three, and this one catches more people than it should. You have removed nine hundred billable roles and agreed the reductions with the account team verbally. Everyone is pleased. What still has to happen? A, nothing, the counters will show the lower number. B, the reduced volumes go into the order form in writing. C, an email confirmation from the account executive. Or D, a support ticket recording the change. Pause here, and ask where an entitlement actually lives.
The answer is B, the order form, and I want to be emphatic because this is where good work most commonly evaporates. Consumption falling does not reduce entitlement. You keep paying the contracted volume until the paper says otherwise, which means answer A leaves the entire saving unrealised, and I have seen exactly that, a beautifully executed cleanup that changed the invoice by nothing at all because nobody amended the contract. Email confirmations, answer C, do not hold up at audit and do not survive an account team change, which is session four's lesson about side assurances arriving in a new costume. And a support ticket, answer D, records a technical event rather than a commercial one. Every cut you win has to land in the order form at the renewal. Otherwise you have done all of the work and kept all of the bill, which is the worst outcome available, because you have also spent the political capital.
So, papering the result, five things. Reduced volumes on the order form, the new counts per licence type written into the renewal paper, and that is the only place a reduction becomes real money. The definition frozen, so you classify against the fulfiller definition your order form incorporates, versioned, because otherwise next year's taxonomy quietly re inflates this year's work and you get to do it all again. True down rights for next time, session four's clause, so your next reduction does not have to wait for a renewal window to be actionable. The evidence retained, exports and classification sheets, dated, because four quarters of those make your count effectively unarguable in a review. And the quarterly pass scheduled, which is this whole audit shrunk to a standing day per quarter, session five's rhythm applied to the largest line in your estate. Do those five and the work you did this quarter is still worth money in three years. Skip them and it is worth money for about one renewal cycle. One more clip, on what happens after.
Guest analyst clip. I want to describe the estate that has genuinely solved this, because it is not the one with the biggest saving, it is the one where the saving stopped being an event. This customer ran the full audit three years ago, took out a substantial number of seats, papered it properly at the renewal. Normal so far. What they did differently was afterwards. They kept the classification sheet alive. Every quarter, one person spends a day, the exports refresh, the four columns update, and the movers get flagged. New starters arrive as requesters because the template says so. Anyone who needs a billable role gets one, quickly, with a name attached to the decision. And the interesting thing is what happened to their conversations with ServiceNow. They stopped having compliance conversations entirely. Not because they are lucky, but because there is nothing to find, and both sides know it. When the account team runs their read of the instance, it matches the customer's sheet, because the sheet is maintained against the same reality. Reviews became a formality. And the second order effect is the one nobody predicts. Because they are visibly on top of their user file, they get taken more seriously on everything else. Pricing conversations, roadmap conversations, escalations. Competence in one area buys credibility across all of them, and that is worth more than the seats.
Competence in one area buys credibility across all of them. That is a good note to end the practical half of this module on, and it is true well beyond ServiceNow. The customer who visibly runs their own estate gets a different quality of relationship, because the other side adjusts to whom they are dealing with. Let's recap.
The audit, in three sentences. Pull five exports and classify every named user across four columns, holds, does, should hold, and the reason, because the reason is the artifact that survives the meeting where somebody objects. Sequence the cuts to build momentum, machine accounts, then dormant users, then approvers, then dashboard viewers, and the genuinely contested cases only after four categories of saving are banked and the exercise has credibility. And the cleanup wins the year while the plumbing wins the term, and neither of them counts as money until the reduced volumes are written into the order form. Next session we move to the second counter in this module, custom tables. What counts, what is exempt, where App Engine begins, and why a build decision made by an architect on a Tuesday can turn into a licence decision nobody discovers until a review.
Homework, about an hour, and this week you start the real audit. One, pull the five exports, roles with grant paths, ninety day activity, role definitions, group membership, and integration accounts, raw files only, no analysis. Two, build one hundred rows, the four columns, for your hundred most expensive users, sorted by the gap between what they hold and what they should hold. Three, price the top category, take whichever category comes out largest, and it will probably be approvers or dormant users, and multiply by your net fulfiller rate so that you are carrying a money number into your next internal conversation rather than a headcount. Four, draft the removal list, machine accounts and ninety day dormant users, with names, departments, and dates, because that is the artifact managers sign off. And five, name the plumbing owner, decide who owns the template fix, the group gate, and the leaver hook, because without a name on those three the plumbing does not get built and you are scheduling this same exercise for two years from now.
Further reading, five guides. The rightsizing playbook is today's audit as a full twelve week workflow with the data pull list and the cuts that survive a CFO review. The rightsizing tool gives you a working sheet for the four column pass so you are not designing the format yourself, and I would genuinely start there rather than from a blank spreadsheet. The fulfiller versus requester explainer is last session's line with the misclassification patterns this audit is built to find. The license audit guide shows what the same evidence looks like from the defence side, for when a review lands before your cleanup does, which happens. And the optimization service page describes how the exercise runs with advisory support, if the honest answer in your organisation is that nobody has a spare day a quarter. That is session twelve. Pull the exports, build your hundred rows, and I will see you in session thirteen for custom tables.