Here is the short version. Your bill is the per-unit rate times the count of chargeable units, and the usage-definition clause controls the count. Negotiators obsess over the rate and skim the definitions, which is exactly backwards: a tight definition compounds in your favor at every true-up and every renewal. This clause sits in our wider ITSM contract clause library; this article is the deep read on getting it right.
What is a usage-definition clause?
It is the language that defines the unit of measure you are billed on: who is a named user, an agent or a fulfiller; what separates a chargeable agent from a free requester; and whether system, integration and service accounts count. ITSM vendors use different words for similar things, and the gaps between those words are where cost leaks. If the contract does not define the unit precisely, the vendor defines it for you at audit, and it will not define it in your favor.
Why does the definition matter more than the per-user price?
Because the total is rate times count, and only the definition controls the count. A vendor can hand you a generous-looking per-unit rate and recover it all through a definition that classifies occasional users, contractors and automated accounts as chargeable. Tighten the definition and you reduce the multiplier permanently, which is worth far more over a multi-year term than a one-time percentage off the rate. This is the same discipline behind right-sizing seats, covered across the platform clusters.
How should named, concurrent and requester users be defined?
Each model needs an explicit, narrow definition so the vendor cannot reinterpret it later.
| Unit | What it should mean | Where the count inflates | Buyer-side language to add |
|---|---|---|---|
| Named user / agent / fulfiller | A specific person assigned a license to work tickets | Deactivated accounts left in the tenant; shared logins | Counted only while active; right to reassign on departure; deactivated accounts excluded |
| Concurrent user | Simultaneous active sessions, capped at a peak number | Vendor counting total provisioned rather than concurrent | Measured by peak concurrent sessions over the period, not headcount |
| Requester / end user | Raises and tracks own tickets only | Requesters reclassified as agents for self-service actions | Free or fixed low cost; explicit list of actions that do not trigger an agent license |
| Service / integration account | Non-human account for automation and APIs | Charged as a full named user | Excluded from the chargeable count entirely |
| Contractor / temporary user | Third-party staff needing access for a defined period | Counted permanently after the engagement ends | Time-boxed licenses with a right to remove on contract end |
Where does the count quietly inflate?
Four leaks recur. Deactivated accounts that stay in the tenant and get counted at audit. Service and integration accounts billed as if they were people. Requesters reclassified as agents because they perform one self-service action the vendor decides is "agent work." And contractor licenses that outlive the contractor. Each is invisible until a true-up or audit, at which point the vendor presents it as your overage rather than its definition. The way to limit that reach is paired with audit and true-up clauses.
How do you negotiate the definitions?
- Write the definitions yourself. Do not accept the vendor schedule as given; propose your own narrow definitions and make the vendor argue against them.
- Exclude non-human accounts explicitly. Service, integration and system accounts should be named as out of scope, not left to interpretation.
- List the requester actions that stay free. Enumerate self-service actions so the vendor cannot reclassify requesters into agents.
- Tie counting to active status. Counts measured at a point in time, excluding deactivated and time-expired accounts.
- Connect it to corporate change. An entity reorganisation changes the population, which is why this pairs with assignment and change-of-control clauses.
Across ITSM engagements our firm averages a 30% reduction, with more than $420M negotiated since 2019, and a large share of durable savings comes from definitions rather than discounts. The rate is a number for this year; the definition is a number for every year.
Our gated ITSM Contract Terms and True Forward Guide includes model usage definitions and the audit language that holds them.
Book a negotiation review.
We rewrite the usage definitions so requesters, contractors and service accounts stop inflating your count at every renewal. Fixed fee or gainshare.
Book a contract negotiation review →What to do next
Open the definitions schedule in your current agreement and check four things: are service accounts excluded, are requesters defined narrowly, are deactivated accounts removed from the count, and are contractors time-boxed. Any gap is a future overage. Run the fix through our contract negotiation service on fixed fee or gainshare, and index the rest of the protective terms in the clause library pillar.
Frequently asked questions
- What is a usage-definition clause?
- The language defining the unit you pay for: named users, agents, fulfillers, requesters and whether service accounts count. The price multiplies by this count, so the definition often matters more than the rate.
- Why does the definition matter more than the price per user?
- Because total cost is rate times count, and the definition sets the count. A loose definition inflates the multiplier on every renewal regardless of the rate.
- How should named, concurrent and requester users be defined?
- Named is a specific assigned person, concurrent is peak simultaneous sessions, and a requester only raises tickets and should be free. Exclude service and integration accounts and time-box contractors.