The price gap, the role table that actually meters you, and the gray zone where activity and licensing disagree. 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 eleven, and module three starts here. This module is five sessions on one topic, the fulfiller problem, and I want to justify that allocation before we begin. Every platform has a signature exposure. On SAP it is indirect access. On Oracle it is virtualization. On ServiceNow it is this line, the line between somebody who fulfills and somebody who requests, because that line carries a four to six times price multiple and it runs through every single person in your organisation. Get it right and the platform is affordable. Get it wrong and you pay several times over for thousands of people, quietly, every month, for the length of your term. Today we place the line properly. And there is a genuine surprise in this session, something that contradicts what I taught you in session two, or rather completes it, and I will flag it clearly when we reach it because it changes what you actually do. Three checks, homework, let's go.
Five objectives. First, place the line functionally, on what a user does rather than where they sit in the org chart, and that word functionally is going to do a lot of work today. Second, read the real meter, which means understanding why the role table rather than the activity log is what a compliance review counts, and what follows from that. This is the correction I mentioned. Third, price the gap in actual money, four to six times requester access, at eighty to two hundred dollars per user per month depending on edition. Fourth, free the approvers, because approving does not require a fulfiller licence and this single reclassification is the fastest recovery available on the platform. And fifth, work the gray zone, the occasional actor, the dashboard viewer, the accidental fulfiller, because the easy cases classify themselves and the arguments all happen in the middle.
Four numbers. Four to six x, the fulfiller cost multiple over requester access. Every misplaced user is a multiple, not a rounding error, repeated every month of your term. Eighty to two hundred dollars, the net fulfiller rate per user per month across the ITSM editions after typical discounts, and notice the spread, more than double from bottom to top, which is why edition and classification compound each other. Get both wrong on the same population and the errors multiply. Twenty to thirty percent, the share of assigned fulfiller seats showing fewer than five worked records per quarter across our license reviews. Assigned, but barely used, and I want you to hear how strange that is. Between a fifth and a third of the most expensive licences on the platform are held by people doing almost nothing with them. And one in three, the share of estates where requesters had been accidentally granted write roles, silently converting free users into billable ones. Nobody decided that. A template did it. Two things account teams rarely volunteer are on that note, and we get to both. First, a view from the reviews.
Guest analyst clip. If you want to understand ServiceNow's commercial model, you only really need to understand one boundary, and everything else is detail. There is a line, people are on one side or the other, and one side costs four to six times the other. That is the business. Now here is what makes it interesting rather than simple. Nobody in your organisation experiences that line. A manager approving a request and a service desk agent resolving an incident are both, from the inside, just using the tool. They both log in, they both see records, they both click things. The line is invisible to the people it prices. So it gets crossed constantly, and it gets crossed for reasons that have nothing to do with licensing. Somebody needed to see a queue during an incident. A template was copied from another team. A group was joined for a project. Every one of those is a sensible operational decision made by a competent person, and every one of them can move somebody across a boundary that costs a multiple. That is why I tell clients this is not a compliance problem, it is an architecture problem. You are not looking for people who did something wrong. You are looking for a system that prices decisions nobody knew were priced.
A system that prices decisions nobody knew were priced. That is the fairest description of this problem I have heard, and it should shape how you raise it internally. Nobody did anything wrong. If you walk into your platform team accusing them of overspending, you will get defensiveness and you will deserve it. Walk in saying the platform prices things we did not know were priced, and let's find them together, and you get help. Now, where the line actually sits.
Three rows, and the columns matter as much as the rows. The fulfiller works other people's records, assigning, updating, resolving, configuring, and costs eighty to two hundred dollars per user per month net by edition. The common misclassification is the occasional user holding a full seat for two records a month. The business stakeholder gets dashboards, reports, and approvals beyond their own items, at a fraction of the fulfiller rate, and their common misclassification is managers licensed as fulfillers because approval felt like work. And the requester raises and tracks their own items, portal, knowledge, approvals, included for every employee at no additional cost, with the misclassification being requesters granted itil or custom write roles by a template. Now the note underneath, and this is the sentence to carry through the entire module. The distinction is functional, not organizational. A service desk agent, a developer, an admin, anyone who assigns, updates, resolves, or configures other people's records is a fulfiller. And seniority has nothing to do with it. Your CIO can be a requester. Your most junior contractor can be a fulfiller. The org chart is not the licence model, and every estate I have seen that classified by seniority overpaid.
Now the correction I promised, and it is important enough that I want you to stop and take it in. In session two I taught you the behavioral test, classify people on what the activity record shows them doing. That test is right, and it is how you decide what somebody should hold. But here is what I did not tell you then. The role table is the meter, not the activity log. Any role granting write access to task records, itil most commonly, makes a user a billable fulfiller whether or not they ever work a queue. And a compliance review counts assigned roles, not actual activity. Read that again, because it explains something that confuses almost every buyer. It is why the audit finding and your intuition about who uses the platform routinely disagree, and neither of you is lying. So two counts exist. Yours, built on what people do. Theirs, built on what people hold. Both are correct about different things. Which means, and this is the practical consequence, activity evidence is your argument for removing a role, not your defence against the count. Do not sit in a meeting arguing that somebody is not really a fulfiller while they still hold the role. Remove the role. Then the count changes. Then talk. Mechanical, in that order.
Knowledge check one, and it tests exactly that. A user holds the itil role but has worked zero records in six months. Zero. What does a compliance review count them as? A, a requester, because activity is what matters. B, a billable fulfiller, because the role is assigned. C, a business stakeholder by default. Or D, nothing, because dormant accounts are excluded. Pause here and ask what the review actually reads.
The answer is B, a billable fulfiller. The role table is the meter. That user costs full price, six months of doing nothing notwithstanding, and that is precisely how twenty to thirty percent of assigned fulfiller seats end up showing fewer than five worked records a quarter while billing at eighty to two hundred dollars a month each. Answer A describes your argument, not their count, and I want to be blunt, confusing those two is the single most expensive misunderstanding in ServiceNow licensing. People walk into reviews armed with activity data, feeling well prepared, and discover the vendor is counting something else entirely. The activity evidence is exactly why you go and remove the role. It is not a shield you hold up while the role stays assigned. Until you remove it, the seat bills, every month, no matter how compelling your spreadsheet is.
Approvals, and this is the fastest recovery available on this platform. Approving a request, a change, or a purchase does not require a fulfiller licence. Full stop. Estates that license their approval chains as fulfillers, and many do, are paying full seat rate for people who never touch a queue. So, what approval actually is, acting on your own decision about someone else's request, a workflow step rather than record work. Where approvers belong, requester if they only approve and handle their own items, business stakeholder if they also need dashboards and reports beyond their own items. Why they end up wrong, three reasons and none of them are licensing reasons. Approval feels like work. Managers are senior. And a template granted the role at onboarding. And what it is worth, reclassifying approvers alone routinely recovers six figures at renewal. Here is why I would lead with this correction rather than any other. Nobody loses a capability. The approver keeps approving, exactly as before, sees the same screens, does the same job. Only the licence line changes. There is no internal opposition to manage, which makes it the easiest money in the module.
Knowledge check two. A finance director approves purchase requests, reviews a spend dashboard monthly, and raises her own IT tickets. Which licence? A, fulfiller, because she approves other people's requests. B, business stakeholder, for the dashboard beyond her own items. C, requester, since approvals and own items are included. Or D, fulfiller, because of her seniority and spend authority. Pause here, and identify which single activity pushes her above requester.
The answer is B, business stakeholder, and the reasoning is precise. Her approvals cost nothing. Her own tickets cost nothing. So answer A, which is the classic and expensive error, licenses her at four to six times for activity that is entirely free. What actually lifts her above requester is one thing only, the spend dashboard, because that is reporting beyond her own items, and that is exactly what the business stakeholder licence exists to cover, at a fraction of the fulfiller rate. Answer C is close and misses that single activity, which is why you check every activity rather than the headline one. And answer D is not a licensing test at all. Seniority never appears in the definitions, not once, in any of them. Here is the elegant part, and it is worth saying to your finance director. If she dropped the dashboard, she would be a requester, and free. The licence follows the activity, and activities are negotiable inside your own organisation.
The gray zone, five hard cases, and these are where the real arguments happen. The occasional actor, tested by how many records they work per quarter and whether the work could be routed to a real fulfiller instead, and the usual answer is remove the role and reroute the work, because fewer than five records a quarter rarely justifies a seat. The dashboard viewer, tested by whether the reporting goes beyond their own items, and the answer is business stakeholder, that middle licence that exists exactly for them and which most estates forget they own. The approver, tested by whether they do anything besides approve and handle their own items, answer requester, or stakeholder if reports are involved. The former agent, tested by whether they still work a queue or moved roles and kept access, and that is session two's joiner mover leaver gap showing up as money. And the break glass admin, tested by how often the emergency access is genuinely used and whether it could be granted on demand, with the answer being time bound or on request access rather than a standing billable role. Look at the resolution column. Every single one resolves by asking what the person does and whether the role can be removed without breaking work. The answer is usually that it can, and usually nobody notices.
Guest analyst clip. The gray zone conversations are the ones people dread, and I want to demystify them, because they are far less confrontational than buyers expect. Here is how I run them. I do not go to a team and say, we think forty of your people are over licensed. That invites a defensive answer and you will get one. Instead I bring the activity data and I ask a genuinely open question. These twelve people hold a role that lets them work other people's records, and the record shows none of them have done that in six months. Help me understand what the role is for. And roughly nine times out of ten the answer is some version of, honestly, I am not sure, they probably needed it for something once. Occasionally, and this is the valuable part, the answer is something real. They cover the on call rota twice a year. They need it for month end. And now you have learned something you could not have learned from data, and you can design around it, an on demand grant, a shared account, a rota-based assignment. What I would warn against is treating the gray zone as an enforcement exercise. The people holding these roles are not adversaries, they are colleagues who were given something they did not ask for. Approach it that way and they will help you find the other four hundred.
Help me understand what the role is for. That is the question, and notice it is genuinely open rather than rhetorical. Nine times in ten you get, I am not sure, and one time in ten you learn about a rota or a month end process you could not have found in the data, which is worth the whole conversation. And the framing point stands, the people holding these roles are not adversaries. They were given something they never asked for. Now, how the accidental fulfiller gets made.
Five ways to manufacture an accidental fulfiller. The onboarding template, a new starter template that includes a write role, applied thousands of times over years without anyone re reading it, and this one is my favourite because one template fix produces a permanent saving with no ongoing effort. The group that carries roles, session two's mechanism, joining a working group inherits its roles, so nobody granted anything, membership did it. The custom role nobody audited, a locally built role that happens to grant write on a task table, and this is the sneaky one, because it does not look like itil, it is called something like regional dispatch viewer, and it meters exactly like itil. The integration account, a service credential sitting on a named licence doing machine work at person prices, with no human to defend it or object to its removal. And the project that ended, elevated access granted for a go live two years ago, never revoked, billing every month since. Notice the common thread. Not one of these involved a licensing decision. Every one of them was an operational action with an invisible price tag attached.
Knowledge check three. You find four hundred requesters holding a locally built role that grants write on a task table. Four hundred. What is the correct read? A, harmless, it is a custom role and not itil. B, four hundred billable fulfillers, because write on task records is the trigger. C, billable only for those who actually wrote a record. Or D, a platform bug to raise with ServiceNow support. Pause here, and ask what the meter reads, the role's name or what it grants.
The answer is B, four hundred billable fulfillers. The trigger is the capability the role grants, not the name somebody gave it, and that is exactly how one estate in three ends up with requesters silently reclassified into the expensive category. Answer A is the comforting read and it is wrong, custom does not mean exempt. Answer C is your argument for removing the role, not the basis of their count, which is the session's central correction appearing for the third time because it matters that much. And answer D, raising it with support, misunderstands the situation, the platform is doing exactly what it was configured to do. Now here is the genuinely good news, and it is worth ending the check on. Four hundred people are almost certainly not doing fulfiller work. So this is not a negotiation at all. It is a template and role definition fix, entirely inside your control, and the four hundred seats simply stop counting once the role stops granting write.
Four moves that hold the line, because a classification is only as durable as the controls around it and I have watched clean counts drift back within two quarters. Audit what roles grant, not what they are called, capabilities rather than names, and every role granting write on a task table is a billable role whoever built it. Fix the templates, so new starters default to requester and fulfiller roles are granted by exception with a licence decision attached, never by a template nobody has re read since it was written. Gate the groups, a maintained list of which groups carry billable roles, an owner for each, and a check before anyone is added, which is the difference between a one time cleanup and a control. And freeze the definition, session four's clause applied here specifically, because the fulfiller definition in your order form is the one you classify against, versioned and dated, and if it drifts every piece of work in this module gets re priced without you doing anything. Session twelve turns these four into the audit itself, how you run it, what evidence to keep, and how to make the reclassification stick.
Guest analyst clip. Let me tell you what happens after a successful reclassification, because this is the part nobody warns you about and I have seen it undo good work twice. A customer does the exercise properly. They find twelve hundred over licensed users, they clean up, and at the renewal they save a genuinely significant amount. Everyone is pleased, the project closes, the team moves on. Eighteen months later I get a call because the count is back. Not all of it, but most of it, and nobody can explain how. The explanation is always the same and it is completely mundane. The cleanup fixed the users. It did not fix the machinery that produced them. The onboarding template still granted the role. The groups still carried it. The custom role still existed. So the estate simply regenerated its own problem at the natural rate of joiners and movers, which in a large organisation is a few percent a month, and a few percent a month compounds back to where you started in about two years. So when you plan this work, please plan two things, not one. The cleanup, which is visible and gets you the win. And the plumbing, which is invisible and is the only reason the win survives. If you only have budget or attention for one of them, fix the plumbing. The users will follow.
If you only have attention for one, fix the plumbing. That is the right prioritization and it is counterintuitive, because the cleanup is what produces the number you present to your CFO and the plumbing is invisible. But the cleanup without the plumbing is a two year loan, not a saving. Session twelve builds both. Let's recap.
The line, in three sentences. The distinction is functional rather than organizational, fulfillers work other people's records, stakeholders approve and read reports beyond their own items, requesters handle their own, at a four to six times price gap and eighty to two hundred dollars a month for the expensive side. The role table is the meter, so a compliance review counts assigned roles and not activity, which means your activity evidence is the argument for removing a role rather than a defence against the count, and the action is always mechanical, remove first and discuss after. And approving is free, so reclassifying approvers alone routinely recovers six figures, and it is the easiest change you will ever propose because nobody loses a capability when only the licence line moves. Next session we run the audit itself, the role right sizing exercise end to end, the evidence to keep, and how to make it stick past the two year regeneration the clip just described.
Homework, about an hour, and this week it is reconnaissance for the audit we run next session. One, list the billable roles, every role in your instance granting write on a task table, including the custom ones, and remember names are irrelevant, capability is the test. Two, count the quiet seats, fulfillers with fewer than five worked records last quarter, and compare that number against your total fulfiller count, because the ratio is your headline. Three, find the approvers, users whose only activity is approvals and their own items while holding a fulfiller role, and price that group at your net rate so you are carrying a money figure rather than a headcount. Four, read one template, open your standard new starter template and check which roles it grants, which is a five minute task with a permanent payoff. And five, check your definition, confirm the fulfiller definition your order form incorporates is versioned, which you did back in session four, so this is just confirming it still holds after any renewal since.
Further reading, five guides. The fulfiller versus requester explainer is today's line at full resolution with the rate ranges by edition and the misclassification patterns behind every number I quoted. The license types buyer guide covers the four categories and where the business stakeholder licence sits between fulfiller and requester, which is the licence most estates forget they own. The rightsizing playbook is the preparation for session twelve. The true up compliance guide shows what happens when assigned roles and actual activity diverge for long enough. And the pharmaceutical case study is this line applied at enterprise scale, one point two million dollars, almost entirely from moving people onto the licence their activity supported. That is session eleven. Do the reconnaissance, especially the template, and I will see you in session twelve to run the audit.