Per seat

What this model actually means

Per-seat pricing, also called per-user pricing, means the customer pays a fixed fee for each person with access to the product. Add a user, the price goes up by exactly one seat. Remove a user, it goes down. There is no meter to track, no consumption to estimate, and no outcome to define. The billing unit is a person, and people are easy to count.

This simplicity is the model's primary advantage. The customer knows what they will pay before they sign. The vendor knows what they will earn before the month starts. Budget approval is straightforward: "we have twelve people who need this, at $25 per person, that is $300 per month." No further analysis required.

Slack, Microsoft 365, Salesforce, Notion, Linear: the canonical examples of per-seat SaaS pricing are some of the most widely used software products in the world. The model created the SaaS category as it exists today, and it remains the dominant structure for collaboration and productivity tools.

Why you land here

The Pricing Unit Picker routes you to per-seat pricing when your product's value genuinely scales with the number of people using it, your buyers are accustomed to headcount-based software budgets, and the product does not produce discrete, metered outputs that would make a usage or outcome model more natural.

Collaboration tools are the clearest case. The value of a shared workspace, a communication platform, or a team knowledge base increases as more people participate in it. A team of twelve using a shared tool is not just twelve times more valuable than one person using it. The shared context, the searchable history, the notification threads: these compound with headcount in a way that makes per-seat pricing feel proportional.

CRM software at the sales team level is another natural fit. Each sales rep needs their own access to track their own pipeline. The value the software delivers to the organization scales with the number of reps using it. The pricing scales the same way.

Where per-seat pricing breaks down

The assumption embedded in per-seat pricing is that value scales with user count. For a large class of software, that assumption is wrong, and the pricing model ends up misleading both the vendor and the customer.

Consider an analytics platform. A team of twenty might have twenty people who could theoretically access it, but in practice, three analysts run all the queries and the other seventeen check a dashboard once a week. Charging for twenty seats does not reflect where the value is being created. The heavy users are a small fraction of the seat count, and the light users are generating almost no value and feeling overcharged.

AI-assisted tools are hitting this issue specifically. When an AI model handles work that previously required multiple people, the number of human seats involved in that work drops. An AI agent that automates the work of three junior analysts does not consume three seats. It consumes zero. Seat-based pricing for AI-augmented products often produces a perverse result: customers who adopt the product well and see the most automation benefit end up with the fewest chargeable users, which minimizes the vendor's revenue at exactly the moment the customer is getting the most value.

The headcount plateau problem

Per-seat revenue has a natural ceiling: the number of people in the organization who need the product. For most B2B tools, that number reaches a steady state relatively quickly after initial expansion. Once you have sold to everyone who was going to buy a seat, the only way to grow revenue from that account is to raise the per-seat price, add new seats through company growth, or sell additional products.

This is fine if your product category grows faster than your customers lose headcount. It becomes a structural problem when AI-driven productivity improvements reduce the headcount in the roles your product serves. A customer who replaces five analysts with two analysts and an AI tool will not renew five analyst seats at renewal. They will renew two, and maybe try to negotiate a lower rate for those given their reduced team size.

The headcount plateau is also an expansion ceiling. Once you have all the seats in a department, expanding revenue means selling to another department with a different use case, which often requires a different product pitch and a different pricing justification. The model does not naturally expand beyond the team that first bought it.

The procurement advantage

Whatever its limitations, per-seat pricing has one genuine structural advantage that other models cannot match: it is the easiest model to get through enterprise procurement. Finance teams understand headcount budgets. They do not understand variable consumption billing or outcome-based invoices. A $25/seat/month enterprise software purchase goes through approval in one conversation. A usage-based product with variable monthly billing requires a budget range, a risk conversation, and sometimes a spending cap negotiation.

For products selling to large organizations, this matters. The procurement advantage alone is enough to justify per-seat pricing for some products even if a different model would theoretically be more value-aligned. The deal you can close in two weeks beats the deal that requires three months of internal approval even if the latter has better unit economics in theory.

Risks and failure modes

Seat sharing. When per-seat pricing is expensive relative to the product's value for light users, teams share credentials. One login, five people. The vendor's revenue is capped at one seat while five people get the value. Contractually prevent this, enforce it technically, or price the seat low enough that sharing is not worth the hassle.

Renewal stagnation. Unlike usage models that naturally expand with customer growth, per-seat deals renew at the same number of seats they started with unless the customer grew. For products where the customer's team is stable or shrinking, per-seat pricing produces flat renewal revenue with no organic growth driver.

AI seat erosion. If your product is genuinely AI-enhanced, and it makes each user more productive, there is a real risk that efficiency gains reduce the headcount the customer thinks they need. You are pricing on the thing your product replaces.

What to do from here

Use per-seat pricing if your product's value demonstrably scales with the number of people participating in it. Collaboration, communication, and workflow tools that require everyone to be in the same system are the natural cases. If you need someone to explain why adding more seats adds more value, consider whether the model is right for what you are building.

If you are selling to enterprises and per-seat pricing is structurally the right fit for procurement, make the per-seat price low enough that seat expansion is easy to approve and sharing is not worth doing. Growth comes from breadth at this point.

The question that tests whether per-seat pricing makes sense: if your most productive customer used your product to reduce their team size by thirty percent, would that feel like success or like a pricing problem? If it feels like a pricing problem, the seat is not the right unit.