How to Right Size ITSM Agent and Fulfiller Counts

Right-sizing agent and fulfiller counts means making sure the expensive, work-resolving license class is held only by people who actually resolve work, and moving everyone else to the cheap or free requester class. It is the single highest-value move in most ITSM estates because the gap between a fulfiller seat and a requester seat is large and it multiplies across every misclassified person. The job is a population split driven by feature-level usage, done before the renewal so the corrected counts are what the vendor quotes. This piece sits under our complete guide to ITSM license optimization.

Define the line between the two classes

Before touching the population, write down precisely what the expensive class is for on your platform. A fulfiller or agent resolves incidents, works assigned queues, edits records, runs against the catalog as a provider. A requester opens tickets, adds context, and checks status. The vendor's own license definitions draw this line; your job is to apply it with usage data rather than assumption. Get the definition exact, because every reclassification you propose will be tested against it.

Pull feature-level usage, not just logins

A login count cannot tell you whether someone resolves or requests. You need feature-level telemetry: who assigns, who resolves, who closes, who only creates and comments. Map each provisioned full seat to the resolving actions it has actually performed over a representative window, ideally a full quarter so seasonal work is captured. Assembling that record defensibly is its own discipline, covered in how to build ITSM utilization evidence, and the upstream entitlement mapping is in how to map ITSM entitlements to actual usage.

Split the population into three buckets

From the usage picture, sort every full seat into three groups. Confirmed resolvers, who perform resolving actions regularly and stay on the expensive class. Clear requesters, who have never performed a resolving action and move down immediately. And the boundary cases, who resolve occasionally or seasonally, which need a judgement call about whether a shared or concurrent license, or a small buffer of full seats, serves them more cheaply than a permanent expensive seat each. The first two buckets are where the certain saving lives; the third is where you set policy.

Reclassify before the quote, not after

Timing is everything here. Move the clear requesters down during the audit window so the count the vendor sees is the corrected one. Reclassify after the renewal and you are asking for a credit against seats you have already committed to pay for; reclassify before and you simply buy fewer expensive seats. The largest version of this saving, and why it tops every optimization list, is set out in the fulfiller to requester reseat.

Where the platform changes the math

The principle is universal but the seat economics are not. ServiceNow's fulfiller-versus-requester distinction tends to produce the biggest reclassification savings because the fulfiller seat is expensive and the requester is effectively free, and its True Forward mechanic punishes estates that grow the expensive class without cleaning it first. Our ServiceNow pricing 2026 guide works the split through ServiceNow's specific license classes. On platforms with concurrent or shared licensing the boundary-case bucket matters more, because a small pool of shared full seats can cover intermittent resolvers far more cheaply than naming each one.

Hold the right-sizing in place

Counts creep back the moment provisioning is not governed: a new joiner defaulted to a full seat, a requester promoted without anyone checking the license, a team lead who asks for agent access "to be safe." Close with an allocation rule that assigns the cheap class by default and requires a resolving-work justification for the expensive one. That governance is what turns a one-time reclassification into a count that stays right between renewals, and it is the difference between a saving you bank once and one that compounds. Running the split and governing the counts is part of our buyer-side license optimization work.

Frequently asked questions