Per Seat Licensing Is an Umbrella, and Nobody Decided Which Variation Your Contract Grants

TL;DR Per seat licensing is not one model. It is an umbrella that absorbed separate decisions on separate axes as variations accumulated: what the licensed unit attaches to, what window counts it as used, and which user type holds it. Those axes keep producing new variations, which is why two agreements can both say per seat and grant materially different things. Separate the axes before arguing about price.

Two of your customers each bought five hundred user licenses. One hired four hundred people this year and owes you nothing more. The other hired nobody and is about to trigger an expansion order. No account team did anything differently. The two agreements granted different rights, and nobody at your company decided that on purpose.

Both contracts say per seat. The phrase covers several arrangements at once, and which one each contract carried was settled by whichever template the first deal started from. That is a software licensing decision made by inheritance, and it sets what you can invoice.

Per Seat Licensing Is an Umbrella, and the Variations Under It Were Never Reconciled

A software licensing model is two decisions: the value metric names the unit you sell, and the grant defines what that unit entitles a buyer to do. Per seat answers the first and leaves the second open, which is why the phrase kept taking on new arrangements without losing its name.

The family grew the way the software did. A unit was pinned to a machine, then to a pool a network could hand out from and take back, then to one identified person, then to consumers that were not people, with time windows and user types layered over the top. The earlier meanings were never reconciled with the later ones; they accumulated onto different axes: what the licensed unit attaches to, what time window counts it as used, and which type of user holds it. Each is being answered in your agreement whether or not anyone answered it deliberately.

Whether per-user pricing still tracks value once software does the work belongs to the move from per-seat to usage. Before deciding whether to leave seats, know which seat you sell.

What the Licensed Unit Attaches To

This is the axis most people mean by per seat, and it carries the most variations.

A device

The unit follows a machine, and whoever picks it up inherits the access. What is never simple is which machines count. A hot-desked laptop, a shop-floor terminal, a warehouse handheld, a phone in a field technician’s pocket, a head unit in a vehicle: each is a device by any plain reading, and each carries a different ratio of people to units. Some grants count all of them; some count a named subset and stay silent about the rest, granting the rest for free. Either way, headcount can triple against a device grant without a single additional unit becoming due.

Virtualization and mobility made the question permanent. A device is now a definition, and one that enumerates classes behaves differently at renewal than one that says “device” and hopes.

A seat

A seat is a slot. Anyone the customer chooses may occupy it; the unit is tied to no particular person. Read the phrase literally and that is all it says, which is why it became the umbrella: it commits to a count and nothing else. Most agreements quietly resolve the slot into a named holder in the definitions without noticing they made a second decision.

A named user

The unit attaches to one identified individual, and changing who holds it is an administrative act inside the customer. Identity is the record, so both sides count the same way, and neither party needs a conversion table to know what was bought. That is the modern default in B2B software.

A pool drawn from at the moment of use

Concurrent, or floating. A pool smaller than the population it serves. Any set of users may work simultaneously up to the size of the pool, units check in and out as people come and go, and when it is full the next person waits. Access is conditional by construction: the grant conveys the right to use the software only while a unit is free, though the agreement’s term never wavers.

It survives for structural reasons, not nostalgic ones. In engineering, design, and simulation tooling and in shift-based operations, the population needing the software far exceeds the population using it at once, and the per-unit price is high enough that licensing everyone is a conversation no budget holds. Peer-reviewed work on enterprise software licensing also finds buyers preferring it for cost predictability rather than affection for the mechanism.

Something that is not a person

The holder does not have to be human. A service account, a scheduled process, a machine on a line, or an AI agent can each consume the product, and each is a candidate holder of a unit. Answered here, on this axis, it is one decision rather than several renewals of patched definitions.

The Time Window Is a Flavor, Not a New Assignment

Per active seat. Per monthly seat. Per daily seat. Anything introducing a period is a variation layered on an assignment, never a replacement for one. An active-user grant is still a named grant with a window attached, and the window excludes the people who held a unit and did nothing inside it.

Active user is routinely listed as a peer of named, floating, and device, as though choosing it replaced choosing one of those. It never does: you still have to say what the unit attaches to, then what window counts. Filed as a peer, that second question is answered later by whoever has the most at stake.

Buyers ask for a window because it self-corrects for the population that was provisioned and never arrived, the complaint that opens most renewals. It remains a per-user grant, not a usage meter and not a credit pool: credits, points, and compute units are surrogate units. What it introduces is a definition problem, namely what counts as acting.

User Type Multiplies Against Everything Above

Read-only, designer, power user, approver, and onward. This axis says what the holder may do, and it moves independently of the other two: a named designer unit and a named read-only unit are different grants sharing a word. It multiplies rather than adds, because every user type you introduce lands on every assignment and window you already sell, and each combination is a grant somebody will ask you to define.

How Per Seat Licensing Behaves on Expansion, Audit, and Renewal

What the unit attaches to decides whether growth arrives as an expansion call or as nothing at all. A named grant grows with headcount, close to one for one, on a trigger your customer’s own recruiting pulls for you. A pooled grant grows only when simultaneity grows: a customer can double its workforce and owe you nothing, because peak demand moved less than headcount did. A device grant grows with whatever the agreement calls a device, which is no personnel number. Add a window and the grant can decline without the customer cancelling anything or telling you.

Verification splits the same way, and a grant your systems cannot verify is a grant in name only. A named grant is checked against a roster; a pooled grant cannot be, because the question is not who holds a unit but how many were held at once. Reassignment is the quieter one: a named grant with unrestricted same-day reassignment is a pooled grant with extra paperwork, which should be a decision rather than a discovery, and usually is a discovery.

It converges at renewal, because the variation you granted sets the argument your customer arrives with: a list of people who never logged in, a peak-usage report, a consolidation plan, or a quiet quarter. Each one your own grant handed them. License and entitlement management makes a grant operational at scale, but it enforces a coherent grant and an incoherent one with equal fidelity. If your forecast keeps missing in a direction nobody can explain, describe the contract you sell to a pricing expert before assuming the meter is the problem.

What AI Agents Do to the Question

The enforcement layer is already counting what the grants never named. GitHub’s Copilot usage metrics API now reports activity broken out by individual third-party agent, with interaction and session counts per agent. OpenAI’s chief financial officer has framed the shift as software moving from being measured by seats, active users, and renewals toward work accomplished.

Every variation written for people answers this badly. A grant anchored to a human leaves agent activity outside the unit you sold rather than inside it at a discount, a revenue question long before a legal one. A pool sized for human rhythms stops describing peak demand once agentic processes hold sessions for as long as the work runs. A window assumes a login, and an agent acting for a licensed person produces activity under that person’s identity or none.

Read that as a metric argument and you will go shopping for a new unit, the conversation the repricing argument around compressing seat counts works through. Read it as a grant argument and the question narrows: does the unit your paper defines already cover a consumer that is not a person?

Tests to Run Against Your Own Agreement

Open the agreement you sell, find the section defining the unit, and separate the axes before arguing about anything else.

What does the unit attach to? Not what your pricing page implies, and not what your product enforces. What the paper says.

If a customer doubled headcount without changing simultaneous usage, would that produce revenue? If it would not, you are selling a pooled grant whatever the order form calls it.

Is there a time window, and does the agreement say what counts as use inside it? A window nobody defined is one your customer will define later.

How many user types do you sell, and does each carry its own assignment and window? If those combinations were never written down, some have no price.

When a process that is not a person consumes the product, which unit is it consuming? If nobody can answer from the paper, the grant has an opening and something will fill it.

Which variation fits depends on what you sell, who buys it, and what your pricing must do as their organizations grow. That is pricing architecture work, and deciding it once on purpose beats inheriting it a contract at a time. If your agreement does not answer the questions above, talk to a pricing expert and describe what you sell.

FAQs