Per Seat or Usage-Based Pricing on a Pitch Deck: Name
Should you charge per user or by usage, and how do you explain the choice to investors?
Per Seat or Usage-Based Pricing on a Pitch Deck: Name the Unit, Say Why It Fits, Show How Revenue Grows
Every software company has to decide what it charges for. Some charge for each person who logs in, a seat. Some charge for how much the product is used: requests, data, storage, outputs. Many mix the two. Investors care about this choice because it decides how revenue grows inside each customer and how predictable it is. Yet most business model slides show a price and skip the unit. This guide looks at three companies that put the unit itself on the slide, Evervault, FLORA and Cloudsmith, and at what each one explains well and leaves out.
TL;DR
Name the unit in one line, then give the reason it suits the buyer, then show how an account's bill grows. Evervault's slide does the first two in three bullets: 'Heroku-style usage based pricing', 'Companies pay based on how often they use a cloud enclave and how much data they send it' and 'Cost grows as usage grows and is closely aligned with their spend on cloud infrastructure', which 'makes it predictable for CFOs and CTOs'. FLORA explains why it rejected seats: 'Pay for Output, Not Seats. Usage-based pricing allows teams to add collaborators without increasing costs.' Cloudsmith shows growth: subscription tiers with average sale price multiples of 1x, 3x, 20x and 39x, plus usage on top, capped on the lower tiers 'to encourage upward movement'. Add one number that proves the unit works, such as how much existing accounts grew.
Three slides that explain a pricing unit
Each slide is read at full size. Quotes are exact.
Evervault business model slide — slide 11
Data security infrastructure for developers. Pricing slide (undated).
Evervault deck, slide 11. Exact stored slide matched to this analysis.
Our analysis: A precise unit with the predictability worry answered in words.
Evidence and limitation: Usage units named and tied to the buyer's cloud budget; no prices or bill figures.
What a founder can adapt: Add one figure, such as average account bill growth.
Supporting analysis
What the deck claims: "Heroku-style usage based pricing"; "Companies pay based on how often they use a cloud enclave and how much data they send it."; "Cost grows as usage grows and is closely aligned with their spend on cloud infrastructure" which "makes it predictable for CFOs and CTOs."
Presentation choice: Names exactly what is metered and speaks to both the CFO and the CTO.
When it does not fit: Claiming predictability without showing it.
Cloudsmith deck, slide 19. Exact stored slide matched to this analysis.
Our analysis: The fullest picture of how an account's bill grows.
Evidence and limitation: Tier multiples, usage unit, purchase options and caps given; amounts redacted.
What a founder can adapt: Give one real price or contract size so the multiples have a base.
Supporting analysis
What the deck claims: "Subscription model scaling with usage-based pricing."; ASP multiplier 1x, 3x, 20x, 39x across Team, Velocity, Ultra, Enterprise; "Usage comprises of upfront/on-demand storage and bandwidth for software"; "Usage is capped at Team and Velocity tiers, to encourage upward movement".
Presentation choice: Shows tiers and usage working together, with caps that push upgrades.
When it does not fit: Multiples with no base figure anywhere.
Unit named, reason given, predictability, growth path and figures.
Example
Unit named
Reason for the unit
Predictability
Growth path
Figures
Evervault
Enclave use and data sent
Tracks cloud spend
Claimed, tied to cloud budget
Cost grows with usage
None
FLORA
Output (undefined)
Add collaborators free
Not addressed
More output
None
Cloudsmith
Tiers plus storage and bandwidth
More control, adoption and scale
Pre-purchase option
1x to 39x across tiers
Multiples only; ARR redacted
Key Takeaways
Name the unit you charge for, not only the price.
Say why that unit suits the person who approves the bill.
If you chose usage over seats, say what seats would have blocked.
Show how a customer's bill grows: tiers, multiples or usage.
Explain any caps or limits that push customers to upgrade.
Back the unit with one figure: account growth or revenue per customer.
Prepare your pricing unit slide
Answer these before writing the slide.
Value. What grows when a customer gets more value: people, work done, or both?
Unit. What exactly do you meter or count, in plain words?
Alternative. What would seat (or usage) pricing have blocked?
Predictability. What keeps the bill steady enough for the buyer to approve?
Growth. How does a typical account's bill rise, and by how much so far?
Copyable framework: "We charge per [unit] because value grows with [driver]; accounts grew [x]% last year."
Illustrative example 1 — written by us
Before: "Pay for Output, Not Seats"
After: "Pay per [unit of output], not per seat: add collaborators free; accounts grew [x]% in year one."
What improved: Our illustrative rewrite of FLORA's line. The bracketed unit and figure are not on the slide.
The question this guide answers
This guide answers one founder question: should we charge per user or by usage, and how do we explain that choice on the business model slide so investors see it as a strength?
Our main business model guide says traction should be measured in the same unit you charge for. If you charge per seat, show seats, not downloads. It does not help you choose the unit or explain it. Our pricing tiers coverage is about how many plans to show and at what price. Our revenue mix guide is about combining different revenue streams. None of them deals with the unit itself: seat, usage or a hybrid, and the reason for it. That is this guide's subject.
How we chose and read the examples
We searched extracted text across the library for 'usage-based pricing', 'pay-as-you-go' and 'per seat'. About fifty slides matched. Most mention a pricing model in passing inside a list of revenue streams. We kept slides where the pricing unit is the main point of the slide or of a clearly labelled block on it.
We set aside Databricks' Series D 'Making Big Data Simple with the Cloud' slide. Its 'pay-as-you-go' line describes Amazon Web Services' infrastructure under the product, not how Databricks charges its own customers. We kept three slides with distinct approaches. Evervault's 'Pricing' slide names a pure usage unit. FLORA's 'Designed for Enterprise Scale' slide contrasts usage with seats. Cloudsmith's 'Pricing' slide combines subscription tiers with usage. None of the three slides shows a date. Each was rendered from the source deck and read at full size. Any calculations are ours. We did not check any claim against outside sources.
Why investors care about the pricing unit
It decides how revenue grows inside an account. With seats, a customer pays more when it hires more people who use the product. With usage, it pays more when it does more work through the product, even with the same team. Investors want to know which kind of growth your customers actually have.
It decides how predictable revenue is. Seats are easy to forecast, because headcount changes slowly. Usage can rise and fall with the customer's own business. A usage model needs a reason to believe bills will be steady enough for the buyer to approve and for you to plan around.
It decides how the product spreads. Seat pricing makes every new user a purchase decision, which can slow adoption across a team. Usage pricing can let anyone join, but it may leave light users paying almost nothing. The slide should show the founder knows which trade-off they chose.
It must match the rest of the deck. The traction slide, the revenue forecast and net revenue retention all depend on the unit. If the unit is unclear on the business model slide, those later numbers are hard to read.
Pure usage, explained for the buyer: Evervault
Evervault, a data security infrastructure company for developers, has a slide headed simply 'Pricing'. It has one main line, 'Heroku-style usage based pricing', and two bullets under it: 'Companies pay based on how often they use a cloud enclave and how much data they send it.' and 'Cost grows as usage grows and is closely aligned with their spend on cloud infrastructure', with an arrow to 'makes it predictable for CFOs and CTOs.'
This slide does three things in very few words. It names the units precisely: how often a customer uses an enclave, and how much data it sends. It uses a comparison developers will know, Heroku, so a technical investor can picture the model at once. And it answers the obvious worry about usage pricing, unpredictability, by tying the bill to something the buyer already budgets for: their cloud infrastructure spend. That line speaks to two buyers by name, the CFO who approves the cost and the CTO who chooses the tool.
What it leaves out is any figure. There is no price per unit, no typical bill, and no sign that bills have grown as customers' usage grew. It also asserts that the cost is predictable without showing it. A founder copying this slide should keep the structure and add one line of evidence, such as how much the average account's monthly bill grew in its first year.
Why not seats: FLORA
FLORA, a creative workflow software company, has a slide headed 'Designed for Enterprise Scale'. On the left, under 'Trusted by creative professionals from', are logos including Pentagram, Red Antler, Levi's and Lionsgate. On the right are three blocks. The first reads 'Pay for Output, Not Seats' and 'Usage-based pricing allows teams to add collaborators without increasing costs.' The others cover security ('SOC 2 compliant with full commercial usage rights over outputs') and support ('Forward Deployed Creatives work with teams to build and scale workflows from day one').
The useful part is the contrast. FLORA does not only say it charges by usage. It names the alternative it rejected, seats, and gives the buyer's reason: a creative team can bring more collaborators in without the bill going up. For a product used by groups of designers, agencies and studios, that removes a common reason teams limit access. It also tells an investor how FLORA expects to grow inside an account: through more output, not more logins.
It is a positioning block, not evidence. The slide does not say what the unit of output is, what it costs, or whether accounts have grown. Placing pricing on an enterprise slide next to security and support also signals that FLORA sees pricing as part of the enterprise sale, but the slide does not show enterprise contract sizes. A founder copying it should keep the 'X, not Y' line and add the unit name and one growth figure.
Tiers plus usage, with growth shown: Cloudsmith
Cloudsmith, a software package management company, has a slide headed 'Pricing' with the subtitle 'Subscription model scaling with usage-based pricing.' A staircase chart shows five steps: 'TRIAL, OSS or FREEMIUM', then 'TEAM', 'VELOCITY', 'ULTRA' and 'ENTERPRISE'. Under the paid tiers is a row labelled 'Average Sale Price (ASP) Multiplier Scale' reading 1x, 3x, 20x and 39x. Each paid tier has a box marked 'USAGE' stacked above it, and the ARR figures on the tiers are redacted.
The bullets under 'KEY ATTRIBUTES' explain the mechanics: 'Each tier provides more depth/breadth of control and insight', 'Upwards pressure via features, user adoption (rollout) and larger scaling', 'Usage comprises of upfront/on-demand storage and bandwidth for software', 'Usage is driven by users distributing with more teams and technologies', 'Usage can be pre-purchased upfront (w/ discount) or on-demand' and 'Usage is capped at Team and Velocity tiers, to encourage upward movement'.
This is the most complete example in the set because it shows how an account's bill grows. By our arithmetic, an Enterprise account sells for 39 times a Team account on average, and Ultra for 20 times. The slide names three forces that move customers up: features, adoption across more users, and scale. It defines the usage unit as storage and bandwidth. And it explains the caps on the two lower tiers as a deliberate push to upgrade. Offering usage either pre-purchased at a discount or on demand also answers the predictability question: customers who want a fixed bill can buy it up front.
The limit is the redaction. With every ARR figure hidden, the slide shows the shape of growth but not its size, and the multiples alone cannot show how many customers actually move up. If you are not redacting, put one real figure on the chart, such as the average contract value at the Team tier, so the multiples have a base.
How to choose and explain your unit
Start from what grows when the customer gets more value. If value grows with the number of people who use the product, seats fit. If value grows with work done, such as data processed, files stored or outputs made, usage fits. If both matter, a tier plus usage, as Cloudsmith shows, lets you charge for each.
Name the unit in the customer's language. 'How often they use a cloud enclave and how much data they send it' is clearer than 'consumption-based'. 'Storage and bandwidth' is clearer than 'usage'.
Answer the buyer's worry. Usage pricing raises a predictability question, so say what makes the bill steady: a link to a budget the buyer already has, as Evervault does, or a pre-purchase option, as Cloudsmith offers. Seat pricing raises an adoption question, so say why teams will still add users.
Show growth inside an account. A tier multiple, an expansion rate or a before-and-after for a typical customer tells investors the unit produces growth, not just revenue.
What to put on the slide
Unit. The thing you charge for, in plain words.
Reason. Why that unit fits the customer's value, and what the alternative would have blocked.
Predictability. What keeps the bill steady enough for the buyer to approve.
Growth path. Tiers, multiples or usage bands that show how an account's bill rises.
Limits. Caps or thresholds that move customers to the next tier, and why.
Proof. One measured figure, such as average account growth or net revenue retention.
Common traps
A price with no unit. '$99 a month' says nothing about what grows.
A label instead of a unit. 'Usage-based' without saying usage of what.
Predictability claimed, not shown. Say what makes the bill steady.
Growth claimed with no base. Multiples need at least one real price or contract size beside them.
A unit that doesn't match traction. If you charge by data, don't report traction only in users.
Where this belongs in the deck
The unit and its reason belong on the business model or pricing slide, as all three examples place it. The proof that it works, such as account expansion, belongs on the traction slide, measured in the same unit. If you have a net revenue retention figure, link the two: 'usage pricing; existing accounts grew [x]% last year'.
Reason: 'Because customers get more value when they [add people / process more / produce more], not when they [the alternative].'
Predictability: 'Bills track [a budget the buyer already has]; customers can pre-purchase at a discount.'
Growth: 'Accounts move from [tier] to [tier], an average of [n]x; existing accounts grew [x]% last year.'
What these examples can and cannot show
These three slides show how founders explained a pricing unit. They can't show whether the pricing worked, whether customers' bills grew as described, or whether the businesses succeeded. We did not check any figure against outside sources.
Treat them as patterns. Evervault names a usage unit precisely and answers the predictability worry, but gives no figures. FLORA names the rejected alternative and the buyer's reason, but not the unit's size. Cloudsmith shows how bills grow across tiers and usage, with the amounts redacted. Combine the three and you have a complete pricing slide.
Common mistakes
Price without unit. A monthly price with no statement of what is charged for.
Vague usage. 'Usage-based' without naming the metered thing.
Unsupported predictability. Steady bills claimed with no mechanism or figure.
Baseless multiples. Growth multiples with no real price beside them.
Mismatched traction. Charging by usage but reporting traction only in users.
Diagnostic checklist
Unit named in plain words.
Reason the unit fits the customer.
Predictability addressed.
Growth path shown.
One measured figure.
Frequently asked questions
Do investors prefer usage pricing to seats?
Neither is better in general. They want the unit that grows with the customer's value, and evidence that bills do grow. Explain your choice rather than following a trend.
Can I show tier multiples without revealing prices?
Yes, as Cloudsmith did, but the multiples read better with one base figure. If you can't share prices, share the average contract size at one tier.
How we chose these examples
Corpus: published pitch deck teardowns on StartupFundraising.com. Founder-uploaded private decks are excluded.
Selection (2026-10-01): we searched extracted text for usage-based, pay-as-you-go and per-seat phrases; set aside passing mentions inside revenue-stream lists and Databricks' Series D cloud slide (describes AWS infrastructure, not Databricks' own pricing); kept three private-company slides with distinct approaches.
Review: the three slides were rendered from the source decks on 2026-10-01 and read in full at full size against company, deck and page number (editorial model review, with AI assistance in drafting; not human-reviewed). No claim was checked against outside sources.
