The four categories, the behavioral test, and why classification, not head count, prices the platform. 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 two of forty, and today we take apart the first meter, the people meter, properly. Last time I told you that on ServiceNow the user question is never how many people, it is who acts. Today you get the whole machinery behind that sentence. The four categories, the behavioral test that sorts people into them, the role paths that quietly push people up into the expensive category, and the thirty day review that pushes them back down. If session one was the map, this is the first territory, and I picked it first for a reason. Of everything we cover in forty sessions, this is the fastest money. No negotiation, no vendor conversation, just your own house put in order, and it routinely takes fifteen to thirty percent off the platform bill. Same format as always. I teach, you get three knowledge checks, pause on each one, and there is an hour of homework at the end that feeds directly into session three. Let's go.
Five objectives for the session. First, name the four categories. Fulfillers, business stakeholders, requesters, and platform units, and what each one is actually allowed to do. Second, apply the behavioral test, classifying any user from what the activity record shows them doing, not from their job title, and not from what access somebody once thought they might need. Third, trace the role path. A user becomes billable because a role reached them somehow, directly, through a group, through a template, and that path is where the overcount starts, so you need to see it clearly. Fourth, run the review. The thirty day reclassification review, four steps, that removes the inflated share of your fulfiller count with evidence attached. And fifth, fix the words. The definitions your count is measured against are ServiceNow's documents, they move, and you will learn where to freeze them. By the end of today you should be able to look at your own user file and see money in it.
Here is the shape of the problem, in four numbers. Four categories. Fulfillers act. Stakeholders approve and view. Requesters submit. And platform units cover the applications and integrations that consume the platform without being people at all. One of those four is expensive and three are cheap, and the entire discipline of this session is keeping people out of the expensive one unless the evidence puts them there. Four to six x. That is the price gap between a fulfiller subscription and a lighter license. Hold that multiple in your head, because it means every single wrong classification is not a rounding error, it is a several fold overpayment, per person, per year. Fifteen to thirty percent. That is what honest reclassification took off the platform bill across our reviews, and the word honest matters, nobody lost a capability they actually exercised. And groups. That is the mechanism. Roles granted through group membership quietly turn viewers into billable fulfillers, with no decision made by anyone. One more thing before the clip. Misclassification compounds. An inflated count is not a one year error. It is the base every renewal prices from, it absorbs the uplift, and it survives every cycle until someone explicitly corrects it. Let's hear what that looks like from inside the engagements.
Guest analyst clip. The user file is always where I start, and I will tell you why. It is the only part of a ServiceNow estate where the money is just sitting there, waiting for somebody to look. On one review, a global manufacturer, we pulled the activity record for every licensed fulfiller, about six thousand of them. Then we asked one question per user. What did this person actually do in the last ninety days. Around a third of them had never resolved anything, never configured anything, never touched another person's record. They were approvers, dashboard readers, people who had been put in a group during a project three years earlier. Every one of them was paying the full subscription. Nobody had done anything wrong, exactly. The platform team granted access generously because access is how work gets done, and the license consequence was invisible to them because licensing was not their job. It was nobody's job, that was the finding. When we moved those users to the licenses their activity supported, the platform got about a quarter cheaper, and not one person came back complaining they had lost something. That is the strange part of this work. The most defensible saving in enterprise software, and it is lying in a table nobody exports.
A third of the fulfillers, never fulfilled anything. I want you to notice two things in that story. First, the method is embarrassingly simple. One question per user, what did you actually do in ninety days. There is no clever tooling, the platform already records everything. Second, notice whose job it was. Nobody's. The platform team owns access, sourcing owns the contract, and the billing consequence of a group membership falls exactly in the gap between them. Remember the operating model from session one, the named owner. This is the first thing that owner owns. Now, the four categories themselves.
Four categories, and I will take them in cost order. The fulfiller acts on other people's records. Resolves incidents, works tasks, configures workflows, administers the platform. That is the full subscription at the full rate, and it is the license your service desk, your platform engineers, and your process owners genuinely need. The business stakeholder approves requests and views reports and dashboards beyond their own items. A fraction of the fulfiller rate. And here is the sentence that saves the most money in this session, approving is not fulfilling. Most managers who approve things belong here, not one category up. The requester submits and tracks their own items through the portal, and requesters are included for every employee. Zero additional cost, and they cover most of your company. And platform units, the fourth category, are not people at all. Custom applications, API transactions, integration accounts, automated processes. They consume the platform and they are metered, but on platform metrics, not on named user licenses. The commercial physics of this list is one directional. ServiceNow's default motion pushes users up it, safety pushes users up it, convenience pushes users up it. The only force pushing down is a deliberate review, and that is why the review has to exist.
The behavioral test, category by category, and the key word is behavioral. The fulfiller test is, does this user resolve, configure, or administer, does the record show them acting on items that are not their own. If yes, fulfiller, full stop, that is the license they need and denying it does not save money, it breaks work. The stakeholder test is approving and reading beyond your own items. The requester test is everything within your own items, submit, track, comment. And the platform unit test is simply, is there a person here at all. If a credential runs a job and no human is behind it, it does not belong on a named license. Now look at the errors column, because every one of those errors has the same shape. The fulfiller error is granted to be safe. The stakeholder error is approval looks like acting, so the manager gets a fulfiller license. The requester error is an ITIL role handed out for portal access that never needed one. The integration error is machine work billed as a person. Different flavors, same root cause, classification decided by convenience instead of evidence. The test cuts through all of it because the activity record does not have opinions. Job titles are not evidence. Org charts are not evidence. What someone might need next quarter is not evidence. Ninety days of the record is evidence. First check.
Knowledge check one. An HR manager approves onboarding requests, reads the department dashboard every week, and comments on her own tickets now and then. Which category does the activity record support? A, fulfiller, because she touches other people's records when she approves. B, business stakeholder. C, requester. Or D, platform unit. Pause the video, and be careful with A, it is worded to tempt you.
The answer is B, business stakeholder. Approving and viewing beyond your own items is the stakeholder definition, word for word, and that is everything her record shows. She never resolves, never configures, never administers. Answer A is the tempting one, and it is exactly the confusion that inflates fulfiller counts everywhere, because an approval does touch someone else's request. But approval is a stakeholder action, the category exists precisely for approvers, and licensing her as a fulfiller pays four to six times the justified rate. Answer C is too light, the approvals and the dashboard are beyond her own items. And answer D is for systems. If you got this one right for the right reason, you already have the core skill of the session.
So if the test is that clear, how do the wrong people end up billable? Through the role paths, and there are five of them. Direct grant, an admin assigns a fulfiller role during onboarding or a project, and the control there is an approval step, nobody hands out a billable role without a license decision attached. Group membership, the big one. A user joins a group, the group carries fulfiller roles, and the license consumption follows silently. The control is group hygiene, you maintain the list of which groups carry billable roles and you gate joining them. Templates and cloning, where new users are stamped out from a template that includes fulfiller roles by default, and one fix to the template stops the bleeding permanently. Integration accounts, service credentials holding fulfiller roles and consuming named capacity for machine work, which belong on platform metrics instead. And leavers and movers, people who changed jobs or left entirely, with the roles still sitting on the account. The control is a joiner mover leaver hook wired into your HR events. I want to be fair to everyone involved here, role creep is not misconduct. Access is granted generously because access is how work gets done, and that is a healthy instinct. The problem is purely that nobody is watching the billing consequence, and that is what the next check is about.
Knowledge check two. Three months after an HR workflow goes live, your fulfiller count is up by two hundred forty, and HR has twelve actual agents working cases. What is the most likely cause? A, ServiceNow changed the fulfiller definition mid term. B, the go live added HR staff to groups that carry fulfiller roles. C, two hundred forty HR employees genuinely became fulfillers. Or D, the counters are wrong and you should dispute them. Pause here, and think about the mechanism.
The answer is B, the groups. This is the classic pattern, almost a signature. A go live provisions people into working groups so the workflow functions, the groups carry billable roles, and the count jumps with no licensing decision made anywhere in the chain. Answer C fails simple arithmetic, twelve agents do the fulfilling, so where did the other two hundred twenty eight come from. Answer A, definition drift, is real across packaging generations, but it does not silently rewrite signed paper mid term. And answer D is the losing argument, I want to underline this one. The counters read your own instance. They are almost never wrong, and disputing them burns credibility you will want later. The winning move is never to argue the number, it is to fix the groups, rerun the count, and present the corrected number yourself. Which is exactly the review we are about to build.
Before the review, know your targets. Five populations inflate almost every fulfiller count. One, upgraded approvers, the managers licensed as fulfillers because approval looked like acting. You now know exactly where they belong. Two, occasional actors, people who resolved something once, months ago, and kept the role forever. The activity record decides, not the possibility, and if the job genuinely needs the capability back, the role can be granted back. Three, dormant accounts, the leavers and the long absentees still holding billable roles. That is pure waste, no judgment call involved, and it is the first thing any review removes. Four, integration accounts, machine credentials on named licenses, doing machine work at person prices. And five, delegated administrators, the local power users who got admin roles for convenience during a project that ended a year ago. Convenience has a monthly price. When you run your homework tonight, these five are what you are hunting.
The thirty day reclassification review, four steps. Step one, export the evidence. The activity record per user, ninety days, what they resolved, configured, approved, submitted, plus every role they hold and, critically, how each role reached them, direct, group, or template. Step two, apply the test. Every named user classified against behavior. Fulfiller only where the record shows acting on other people's records, everyone else moves down a category. Step three, strip and migrate. Roles come off dormant and mismatched accounts, the groups and templates that granted them get fixed so the problem does not regrow, and integration accounts move to platform metrics. Step four, document the position. A dated statement of the corrected count, per category, evidence attached. That document is your opening number at the renewal. Two things make this defensible. Nobody loses capability they actually used, because the test only moves users whose record shows lighter activity. And the output is evidence, not opinion, which matters in front of ServiceNow and in front of your own CIO. Across our engagements this one month of work erased fifteen to twenty five percent of apparent true up overage before any negotiation started. Let's hear it from the field.
Guest analyst clip. I want to tell you about the timing of this, because the timing is what people get wrong. A customer calls us when the true up letter has already arrived, and the number in it is huge, and they want to fight it. And the honest answer is, the number is probably correct. It came out of their own instance. What is wrong is not the count, it is the classification underneath the count, and here is the thing, you can still fix that. We ran exactly this review at a financial services customer with a true up on the table. Thirty days. We stripped roles from dormant accounts, moved a few hundred approvers down to stakeholder, took the integration credentials off named licenses. Then we reran the same counters ServiceNow reads, and the apparent overage shrank by about a fifth before a single commercial conversation happened. Not by arguing, by cleaning. When we finally sat down with the vendor, we opened with our corrected count and the evidence file behind it, and the conversation started from our number, not theirs. That is the whole game in one sentence. You cannot negotiate the counters, but you can absolutely negotiate what the counters are counting, as long as you do the work before you sit down.
You cannot negotiate the counters, but you can negotiate what the counters are counting. That is the cleanest summary of ServiceNow compliance you will hear. And notice the sequencing lesson inside the story, the review happened after the true up letter and still worked, but it worked under time pressure, with a deadline the vendor controlled. Run the same review on your own calendar, quarters ahead of the renewal, and you get the same result without the pressure, plus a full negotiating cycle to use it in. Now, the last piece of today, the words on paper.
Everything we have done so far assumed we know what a fulfiller is. But who decides that? ServiceNow does, in the subscription unit definitions, and those documents move. Between releases, between packaging generations, the words shift, and a classification that was correct when you signed can drift out of compliance without you changing a single thing in your instance. Your protection is the order form. The signed order form's definitions, with an explicit version reference, are what bind you, and freezing them there at signature is the clause that keeps the taxonomy from repricing itself. This is one of the eight clauses that set the long run cost of a ServiceNow relationship, and I would argue it is the second most valuable after the uplift cap. Because look how they interact. Misclassification compounds through the uplift, the inflated base absorbs the increase every year. And a definition that drifts wider quietly reclassifies people upward, inflating the base again. Vague words widen in one direction only, theirs. So the rule is, the count is the negotiation. An internal classification review run before the renewal beats any discount argument made after it, because the discount moves the rate, and the review moves the base the rate is multiplied by. Final check.
Knowledge check three. Which contract move most directly protects your user classification from repricing itself over the term? A, a larger first year discount on fulfiller licenses. B, freezing the subscription unit definition version in the order form. C, a right to run your own usage reports. Or D, moving all users to the highest tier for simplicity. Pause here. Which option controls the words the count is measured against?
The answer is B, the definition freeze. The count is measured against words, and the freeze is the only option on that list that controls the words. The discount, answer A, moves the rate once and says nothing about the taxonomy, so a drifting definition eats it within a couple of cycles. Answer C, usage reporting, is hygiene you should have anyway, but it reads the count, it does not define what gets counted. And answer D is the expensive default this entire session exists to prevent, dressed up as simplicity. Here is the way to remember it. If the definitions can drift, everything else you negotiated drifts with them, silently, in the vendor's favor. Freeze the words, then negotiate the numbers.
How do you keep the count honest after the review? Five habits, and they are cheap once the first review is done. A quarterly role review, the thirty day version shrunk to a standing pass, one day per quarter to hold the line. A joiner mover leaver hook, license checks wired into the HR events that create, move, and remove people, so the roles leave when the job does. Group hygiene, a maintained list of which groups carry billable roles, an owner for each, and a gate on joining. Evidence retention, keep the quarterly activity exports, because a classification backed by four quarters of evidence is unarguable in a true up. And owner sign off, the license owner signs the count each quarter, and no number reaches a renewal table before they have read it. One more perspective before we close, on what this looks like when it works.
Guest analyst clip. Let me describe the estate that gets this right, because I have seen a handful, and they all look the same. There is one person who owns the number. Not a committee, one name. Every quarter, the platform team sends that person the user file, classified, with the movers flagged, here is who went up, here is who went down, here is why. It takes them about a day to review. When a new workflow goes live, the groups it creates get checked for billable roles before launch, not discovered at the true up. And when the renewal comes, and this is my favorite part, the opening deck is theirs, not ServiceNow's. Page one is the corrected user count with four quarters of evidence behind it. I sat in one of those renewals, and the account team had come in with a true up estimate built on the raw counters. The customer slid their classification file across the table, and you could watch the number on the projector become irrelevant. The whole conversation moved onto the customer's data. That renewal closed flat, no uplift, no true up, and the account team knew exactly why. Discipline is boring right up until the moment it wins.
The opening deck is theirs, not ServiceNow's. Sessions one and two keep arriving at the same place, whoever presents the reconciled number first controls the conversation, and now you have seen the machinery that produces that number. One owner, a quarterly pass, evidence retained, and the corrected count as page one. Let's recap the session.
The fulfiller line, in three sentences. Four categories carry the estate, one is expensive, and the full subscription belongs only to users whose activity record shows them acting on other people's records. The overcount is mechanical, not malicious, roles arrive through groups, templates, and projects, and they stay until a review strips them, and that review is worth fifteen to thirty percent of the platform bill. And the definitions the count is measured against are ServiceNow's to revise and yours to freeze, and the order form is where you freeze them. Next session we climb from the people meter to the product meter. Nine workflow families, twenty five plus products, tier ladders on every one of them, and the map that tells you where your spend actually concentrates.
Homework, about an hour, and tonight it is a miniature of the real review. First, pull the activity record, ninety days, for your fifty most expensive users. Second, classify those fifty with the behavioral test, and mark the movers, fulfiller confirmed, stakeholder, requester, or dormant. I will make a prediction, you will find movers in the first ten. Third, map the groups, every group that carries a fulfiller role, who owns it, and how a user gets in. Fourth, find the machines, every integration or service account sitting on a named fulfiller license. And fifth, read your definition, the actual fulfiller definition your order form incorporates, and check whether the version is stated anywhere. If it is not, you have found your first contract fix, and module six will give you the language for it.
Further reading, five guides. The fulfiller versus requester explainer walks today's line slowly, with the edge cases. The license types buyer guide has the four categories and the evidence behind the fifteen to thirty percent figure. The rightsizing playbook is the thirty day review as a checklist you can hand to your platform team. The true up white paper shows how role creep becomes a true up number, and how the counter reading defense works. And the pharmaceutical case study is all of it at enterprise scale, one point two million dollars saved, mostly on the fulfiller line. That is session two. Do the homework, especially the fifty user classification, and I will see you in session three for the catalog.