The unit-and-grant decision in the pricing architecture: which unit gets sold, and what each unit entitles a buyer to do. Value-metric pairing, entitlement scope, seat assignment, deployment, duration, and the boundedness of what gets counted.
← scroll to view full figure →
The unit you sell is the first half of the licensing decision, and it is not chosen well by taste or by copying whatever the category leader counts. The framework we have used across decades of engagements evaluates a candidate value metric on six dimensions. Three of them can only be answered by the grant that scopes the unit, which is why a company can pick a defensible metric and still negotiate at every renewal.
A metric that meters every interaction teaches customers to use less. Granularity that feels precise to a finance team reads as a toll booth to a user, and people route around toll booths: they batch work, they share access, they cap their own adoption. The vendor reads the flat line as a product problem.
Does the meter count at the moments the customer extracts value for their organization, or somewhere disconnected from them?
Each additional unit consumed should track a dollar the customer gained: revenue added, expense removed, or a mandate met. The tighter that correspondence, the longer the metric survives contact with an account that grows.
Does your revenue scale with your customer's ability to extract additional value?
The metric should count something the customer’s organization already recognizes, in the vocabulary their industry already uses. When it does not, sales carries a second job before the first one can start, and at the far end of that gap the metric becomes friction the deal has to overcome.
Does the buyer already think in terms of this count, or will you be teaching it in every deal?
The metric is a mutual agreement about how much access is exchanged for how much money, and it lives inside terms both parties sign. One unambiguous definition holds. A term that needs interpretation will be interpreted later, by whoever has the most at stake when it comes up.
Can a customer intuitively grasp what you are counting, and would two reasonable people read your agreement and count the same thing?
Buyers size their purchase before they have any experience of the product, and your sellers have to substantiate the size they propose. Customers rarely resent buying more when they need more. They resent a misestimate that forces an unplanned purchase before the renewal they budgeted for.
Can a buyer estimate what they need before signing, without a spreadsheet from your sales engineer?
Both sides have to see the count: the customer to budget and plan, you to invoice and verify. A metric is also carried, by sales compensation, contract terms, billing, and provisioning, and changing it means re-gearing all of them.
Can both you and the customer easily monitor the count and agree on it, and can your own company carry it, from billing to provisioning to sales compensation?
[ Four properties cut across all six ]
[ Where the framework stops and the work starts ]
The framework’s power is what you put in it, how you score each metric against the others, and the judgment applied to the result.
Six names do not tell you which candidate wins for your product, your Customer Groups, and the contract you actually sell. That part is done by a pricing architect reading your agreement against the metric it is carrying. Talk to an expert and describe what you sell.
The licensing model is two decisions, not one: which unit gets sold, and what that unit grants.
Most companies decide the first half in a room and inherit the second from whatever the last agreement template said. Ask a pricing team what their licensing model is and the answer comes back as a metric: per-seat, per-transaction, per-gigabyte, per-agent. That is half the question. A value metric with no defined grant is not a licensing model; it is a number waiting for a contract to give it meaning.
Strip the boilerplate and the entitlement resolves into four decisions, each being made whether or not anyone made it deliberately.
Who may use a unit, and whether that assignment is fixed to a person or floats across a population. Per-seat names at least four different arrangements, and most vendors picked one by inheritance.
Where the software may run and be accessed: your environment, the customer's, a named geography, or private infrastructure the customer controls. It changes what the compliance provisions can verify at all.
Whether the grant conveys indefinite rights to a version or a term that ends. The industry's move off the perpetual license was a duration change, not a metric change, and every downstream mechanic reorganized around it.
Whether the quantity being counted has a ceiling. This is the dimension most often left implicit, and it is where unlimited-use language enters agreements that were priced as though it had not.
Predictability is the clearest case. The industry credits it to the seat, and companies reach for seats to buy forecastable revenue; it is actually a property of contract structure and retention. A usage metric with a floor, a commitment, and a defined term is as predictable as a seat count; a seat count with monthly true-down rights and no minimum is not predictable at all.
Pricing policy lives here too, and it is the part of the grant most often left undefined: what happens when a customer goes beyond a grant threshold, how price increases are handled, whether overages bill at a premium per-unit rate, whether a true-up is allowed and on what terms. Each is answerable at design time; left open, each surfaces later as a negotiation. These definitions are also the blueprint of the objections sales will field; a per-employee metric meets the part-timer question in the first deal where the prospect’s workforce is mostly part-timers. The more defined upfront, the less chaos in selling.
A metric can be chosen well and still leave the company negotiating at every renewal, because the grant that scopes it was never written as a decision.
In the tooling vocabulary an entitlement is a runtime construct: a feature flag, a configuration, a usage cap the software enforces. In the licensing model it is the contractual right itself, which exists whether or not any system checks it. When the grant goes undefined, whatever the product happens to check becomes the operative definition of what was sold. A company whose only answer to "what did we sell" is a list of flags has an enforcement inventory, not a licensing model.
Billing is the same story one system over: billing and entitlement come after the decisions, never before. The policy answers above, made at design time, form the choice set those systems are configured against.
Start with The Licensing Model: What the Unit Is, and What It Grants below for the definitive treatment, then the supporting articles for the specific calls: seat assignment, entitlement scope, the enterprise license agreement, and licensing access when nothing consuming the product is a person. Sibling hubs cover the neighboring decisions: the packaging model takes licensed units as its input over in Packaging, the pricing model computes against them, and the full pricing architecture is in Software Monetization.
A licensing model is two decisions. The value metric is the visible half. What each unit grants is the half that decides what your contract can answer.
If your agreement defines a unit but never says what the unit grants, the gap surfaces at renewal, at audit, and the first time something that is not a person starts consuming the product. We help software companies decide both halves and write them down as architecture.
Book a working session →
