Seat-based Pricing

Back when software was bought once and installed, the price was set per company. After a single payment, the vendor had no way of knowing how many people inside that company used it, and no reason to care.

Under that arrangement the price fit nobody. A five-person company and a five-hundred-person company paid the same amount, so the small one couldn't afford it and the large one got far more than it paid for. Every contract negotiation turned into haggling over size. "We barely have anyone using it, so give us a discount" met "we have no way to verify that," and the same product ended up priced differently for every customer.

The spread of SaaS — software reached through a browser with nothing installed — solved that. The vendor's own servers now knew how many accounts were signing in. Once counting was possible, attaching the price to the number of people took hold, and it matched the intuition that more users means more value received. It also gave both sides a number they could check, which is most of why the haggling stopped.

One account is treated as one seat, and the bill is the seat count times a rate. Five things have to be decided for that to work.

1. Define what counts as a seat. Every invited account, only accounts that signed in this month, read-only accounts excluded or not. The same thirty-person team is 30 seats under one definition and 18 under another, and the customer notices that gap long before the vendor does.
2. Set the rate and the cycle. At $8 per seat per month, a company with thirty people pays $240 a month. An annual discount that takes two months off in exchange for paying up front is a common companion.
3. Decide how mid-cycle changes are handled. Adding three people on the 15th bills half a month for them, prorated by date. Without that rule, teams learn to add people only at the start of a month, which delays the rollout the vendor wants.
4. Decide whether there's a minimum. Selling from five seats up trims the support load of very small teams, but it also shuts out the three-person team entirely.
5. Decide whether it multiplies with tiers. Combined with tiered pricing, where feature bundles are split into levels, the bill becomes tier rate times seat count. Revenue then has two directions to grow: up a tier, or out by seats. Most teams find the second one easier, because it needs no new feature to justify it.

Because the counting rule is the invoice, a loosely written definition in step one brings the same argument back at every renewal. That's why the contract pins the definition of a seat down in one sentence, in language an admin and a finance team read the same way.

It fits products whose value rises with the number of people in them. Collaboration tools, where several people work on the same documents and projects, are the clearest case. When a product is half useful alone and comes into its own once the whole team is in, a bill that tracks headcount is something a customer can follow. The pricing then explains itself during the sale instead of needing a chart.

What the vendor gets is revenue that grows when the customer grows. A company of twenty that hires its way to forty-five more than doubles its bill without anyone selling anything. Revenue that comes from existing customers this way is expansion revenue, and it's the main reason teams choose this model.

The places it doesn't fit are equally clear: products where usage has nothing to do with headcount. If one company runs a million operations a day through three accounts and another runs a hundred a day through thirty, a price based on seats has come loose from what's actually being exchanged. Usage-based pricing, which charges for what gets consumed, is the fit there.

This model also carries a built-in incentive for customers to share logins, since three people on one seat cuts the price to a third. Products that price this way tend to block simultaneous sessions on one account, or keep per-account records of who did what. Those are less features than scaffolding the pricing needs to stand up. Skip them and the seat count drifts away from the number of people actually working in the product.

"What's the per-seat rate? What does thirty people come to a month?"

Multiplying rate by headcount to get a budget figure before taking it to whoever approves spending.

"Drop the eight accounts that never signed in this month."

A request to narrow the counting rule to active accounts, usually the first move an admin makes at renewal.

"Let's make read-only accounts free. Otherwise the rollout stops right there."

Choosing more users over a larger invoice today, on the bet that the seats will come later.

When Pagedeck built its team plan, the decision that took longest was the definition of a seat. Mia argued for counting every invited account; Sofia pushed back, saying that pushes customers into auditing their user list during the contract stage and delays every rollout by a month.

They settled on counting only accounts that signed in at least once that month. What Grace based the call on wasn't revenue but spread: charge for accounts nobody uses and the customer's own admin starts rationing invitations, and once invitations get rationed the product stops spreading inside the company.

The most common mistake is assuming revenue rises on its own as headcount does. The formula looks like it should. But the customer has someone whose job is bringing that cost down. At renewal they clear out inactive accounts, keep only the people who need it, and pull a department-wide rollout back to one team. So under this model a drop in seat count is treated as a signal that arrives before churn does. Revenue bleeding slightly every quarter while every contract renews is what missing that signal looks like, and it shows up in a dashboard long after the decision that caused it.

Assuming simple arithmetic means simple operations is the other one. It looks like one multiplication, but the real work is in mid-cycle changes. Five people join and two leave in the same month — what's the invoice? Seats get cut during an annual term — refund the remainder or carry it forward? All of that has to exist as a rule beforehand. Without the rules, each customer gets handled slightly differently, and those differences come back later as contract disputes.