Licence Models and What Each Costs You

The pricing model determines what optimisation is available. A per-seat application needs seat hygiene; a consumption application needs something else entirely.

Per seat

The dominant model. Pay per named user per period.

Optimisation: remove unused seats. Straightforward, measurable, and the largest available saving in most estates.

The trap: seats are frequently purchased in blocks and cannot be reduced mid-term. Reduction happens at renewal, which makes the renewal calendar the critical artefact.

Watch for: minimum commitments, and definitions of "user" that include anyone with an account rather than anyone who logs in.

Tiered by feature

Bands of functionality at different prices.

Optimisation: check whether the features distinguishing your tier are actually used. Organisations routinely sit on a premium tier for one feature used by three people, and mixed tiers are frequently possible.

The trap: upgrades are easy and downgrades require a conversation.

Consumption

Pay for what you use — storage, API calls, messages, compute.

Optimisation: technical. Find what generates volume and reduce it.

The trap: cost scales with success, and a change in one integration can produce a surprising invoice. Alerting on consumption is required rather than optional.

Active users

Pay only for users who did something in the period.

Sounds better than per seat and needs the definition checked. What counts as active varies, and a single automated login may qualify.

Platform fee plus per seat

A base cost plus a variable.

The base fee makes small deployments expensive per user and is the argument for consolidation.

Enterprise agreement

A negotiated bundle, frequently multi-year, covering several products.

Optimisation happens once, at negotiation, and then you live with it.

The trap: bundles conceal what each component costs, which makes it impossible to know whether an unused component is worth removing at the next negotiation. Ask for the itemised build-up and keep it.

What to record per application

Model, from the list above.

Unit of charge, defined precisely.

Committed quantity and current quantity.

Term and renewal date.

Notice period.

Whether quantity can be reduced mid-term. This single field determines whether a finding is actionable now or at renewal.

Price per unit, including any escalator.

Where the money actually is

Across most estates, in order:

Unused per-seat licences. The largest and easiest.

Over-tiered subscriptions, where a premium tier serves a handful of users.

Duplicate applications in the same category.

Consumption growth nobody is watching.

Automatic renewal at an increased price, unchallenged.

The first two account for the majority and both are visible from data you already have — assigned seats against last-login, and feature usage against tier.

Forecasting a consumption bill

Per-seat costs are predictable. Consumption costs are not, unless someone instruments them.

Identify what drives the charge: API calls, storage, messages, compute minutes, records.

Find the top consumers, which is usually a small number of integrations or reports rather than human activity.

Set an alert at a threshold below your budget, not at the budget.

Model the growth. Consumption typically scales with something — headcount, customers, transactions — and knowing which makes the forecast possible.

Review after any integration change, which is the most common cause of a step change in a consumption bill.

Ask the vendor for a commitment discount once the baseline is stable. Committed consumption is usually cheaper than on-demand and it requires knowing your baseline, which is the point of the instrumentation.

The true-up you can forecast

Enterprise agreements reconcile against actual usage, and the reconciliation is predictable if anyone watches.

Know what is metered and what the committed quantity is.

Track actual against committed monthly, not annually.

Forecast the year end from the trend, and raise it internally while there is time to act.

Act on the overage rather than accepting it: reduce usage, or negotiate the increase in advance when you have a choice rather than an invoice.

A true-up discovered at reconciliation is a bill. The same number, forecast six months earlier, is a negotiation — and the difference is entirely whether somebody was tracking it.