Mowt
FeaturesIntegrationsPricingMobileAbout
Start free trial
SaaS glossary · Revenue

Seat-Based Pricing.

A pricing model where customers pay a fixed recurring fee for every user ("seat") who can access the product, so revenue scales with the customer's headcount rather than their usage.

Formula

Seat-based MRR = Σ (paid seats × normalised monthly price per seat)

Worked example

A team plan charges £15 per seat per month. A customer starts with 8 seats and adds 4 more at the start of month four as the team grows.

Months 1–3: 8 × £15 = £120 MRR. From month 4: 12 × £15 = £180 MRR. Expansion MRR = £180 − £120 = £60 from seat growth alone.

Seat-based (per-seat or per-user) pricing is the classic SaaS model: each licensed user occupies a seat, and the customer pays a set price per seat per month or year. Seats usually sit inside a plan tier, so a Growth seat costs more than a Starter seat. In Stripe, a seat-based plan is a licensed per-unit price with a quantity: adding or removing seats changes the quantity on the same subscription rather than creating a new one.

The appeal is predictability on both sides. The buyer can budget against headcount, and the seller can forecast MRR as seats multiplied by price per seat. Expansion is built in: as a customer hires, they add seats, so net revenue retention climbs without a sales conversation. That self-serve expansion motion is why per-seat became the default for collaboration tools like Slack and Figma, where every additional user genuinely gets value.

The model breaks when seats are not your value metric. If only a fraction of a customer's team ever logs in, or the product does its work through an API or AI agents that never occupy a seat, per-seat pricing caps your revenue while encouraging licence-sharing and rationed adoption. That mismatch is why hybrid models pairing seats with usage components or feature tiers have become increasingly common.

The most common mistake is defaulting to per-seat because it is familiar, without checking that value actually scales with users. The operational version is mishandling mid-cycle seat changes: seats added mid-period should trigger a prorated true-up, and every quantity change should be recorded as expansion or contraction MRR. Treat seat changes as flat renewals and your expansion, contraction, and NRR figures will all be quietly wrong.

Why it matters

Your pricing metric sets the ceiling on nearly every other number you track. Get it right and expansion MRR compounds as customers hire, lifting NRR and LTV with no extra acquisition spend. Get it wrong and you cap ARPU, invite licence-sharing, and slow adoption inside accounts. On Stripe, seat changes are quantity updates with prorations, and tracking those movements cleanly is what keeps expansion and contraction MRR trustworthy.

Benchmark

Pure seat-based pricing is no longer the default: in Metronome and Greyhound Capital's State of Usage-Based Pricing 2025 survey of 100 SaaS companies (from under $20M to over $100M ARR), 85% had adopted some form of usage-based pricing — in practice usually layered alongside seats or subscriptions rather than replacing them.

Keep exploring
FAQ

Seat-Based Pricing FAQs

What does "per seat" mean in SaaS pricing?

A seat is one licensed user account. Under per-seat pricing the customer pays a fixed recurring fee for each user who can access the product — 10 users on a £15/seat plan costs £150 per month. Only users with a licence get access.

What is the difference between seat-based and usage-based pricing?

Seat-based pricing charges for who can access the product, regardless of how much they use it. Usage-based pricing charges for what is consumed — API calls, messages, credits. Seats give predictable bills; usage aligns cost with value. Many SaaS companies now combine both in a hybrid model.

What happens when a customer adds seats mid-billing-cycle?

The extra seats are typically charged pro rata for the remainder of the billing period — a true-up. In Stripe this happens automatically when you update the subscription quantity with proration enabled. Each seat added counts as expansion MRR; each seat removed counts as contraction MRR.

Is seat-based pricing dying because of AI?

It is shrinking as a pure model, not disappearing. AI agents do work without logging in, so headcount maps less cleanly to value than it used to. The dominant response is hybrid pricing — keeping seats for human users while adding usage or outcome components — rather than abandoning seats entirely.

Get started

Track Seat-Based Pricing
automatically.

Connect your Stripe account and see your real MRR, churn, and LTV in real time — on desktop and mobile.

Start 7-day free trial

No credit card required · Connect Stripe in 1 click