What's the difference between per-seat and usage-based SaaS pricing, and which model actually costs less for a group running multiple companies?
Per-seat pricing charges by the number of named users, regardless of how much any of them actually use the system; usage-based pricing charges by consumption, whether that is records, workflows or messages sent. For a group running several trading entities, usage-based pricing usually costs less overall, because it lets the group add occasional users in smaller entities, such as a finance lead who logs in twice a month, without buying them a full seat each. The trade-off is forecasting: a usage-based bill moves with a busy month in a way a seat count never does, so finance teams need to budget a range rather than a fixed figure.
Neither model is tied to what the customer costs to serve, which is the deeper problem this hub is about.
Per seat. Per workflow. Per marketing email sent.
None of it is tied to the value the customer gets, and hardly any of it relates to what that customer actually costs to serve. It is a set of billing units that were easy to count, adopted because they were easy to count, and then defended long after anyone could explain why they were the right ones.
The lock-in is on the vendor, not the customer
Established SaaS vendors rarely move off per-seat pricing once it is embedded in a large installed base. The reason is not that they think it is correct. It is that they cannot afford to find out.
Take a worked example. A group with four trading entities and 60 total users, but only 25 of them logging in daily, pays for 60 seats under a per-seat contract regardless of that gap. Under a usage-based model priced on active records or workflows run, the same group pays close to what the 25 heavy users actually generate, with the other 35 occasional users costing a fraction of a seat each rather than a full one. That gap between seats bought and seats used is exactly where usage-based pricing tends to come out cheaper for a multi-entity structure, and exactly why a vendor with millions of seats already sold has no incentive to offer it.
Changing the pricing model of a large installed base causes churn and lost revenue in the quarter you do it. For a public company with a revenue line to defend, that is close to impossible to justify, whatever the long-run argument. The model is load-bearing for the valuation, so it stays.
Which means a product either gets built on a collaborative model from the start, or it does not get one at all. This is not a claim about anyone's intentions. It is a claim about what their balance sheet will permit. For more on why that structural incentive runs through the rest of the category, see why generic CRMs underserve multi-entity groups.
What per-seat does to a business
Per-seat pricing turns access to your own customer data into a budget decision. Every person you might add to the system, the account manager who should see the history, the finance lead who needs the numbers, the person covering someone's leave, arrives with a line item attached. So teams ration access, share logins, or work around the system in spreadsheets. The pricing model quietly decides who is allowed to know things.
For a group running several entities, this compounds: the same person often needs presence in more than one brand. A sales lead covering two sister companies, or a finance director consolidating numbers across the group, ends up paying for two full seats to do one job, which is the precise cost usage-based pricing is built to avoid. See how permissions between brands should actually work for the access side of the same problem, and group-level reporting across entities for the reporting side.
What this hub covers
Pricing models compared honestly, including where usage-based pricing fails too; what value-tied pricing would mean in practice; how to audit what you are paying for and not using; and how to think about the total cost of a platform once implementation and customisation are counted.
Frequently asked questions
What's the difference between per-seat and usage-based SaaS pricing, and which model actually costs less for a group running multiple companies?
Per-seat pricing charges per named user regardless of use; usage-based pricing charges by consumption, such as records or workflows run. Usage-based pricing typically costs less for a group running multiple companies, since it avoids paying full seat prices for occasional users spread thinly across several entities, though it is harder to forecast month to month.