The pricing conversation comes up early for most vertical SaaS founders. They look at Stripe (usage-based), Salesforce (per seat), and Zendesk (tiered) and pick the model that feels closest to what they're building. That's how they end up with the wrong model.
Usage-based pricing — charging customers based on what they consume rather than how many seats they hold — works in specific conditions. For vertical SaaS founders, the question isn't whether usage-based is inherently better. It's whether your customers' value derives from volume, and whether you can measure that volume without friction.
What usage-based pricing actually covers
The term covers at least three distinct models, and conflating them is where the confusion starts.
Consumption-based: Customers pay per unit consumed — per API call, per document processed, per transaction. Stripe charges per payment. Twilio charges per message. The bill scales exactly with usage.
Outcome-based: Customers pay based on a business result, not raw consumption. Some companies price per appointment booked, per invoice paid, per lead converted. This model is rare and hard to implement, but it aligns pricing directly with delivered value.
Threshold-based: A flat platform fee covers a usage ceiling, with per-unit pricing above it. This hybrid is where most B2B vertical SaaS companies land after a year in market — it gives customers cost predictability while capturing upside from heavy users.
Why operators have an advantage here
The reason usage-based pricing fails at most generic SaaS companies is that they don't know which usage metric actually predicts customer value. They instrument everything, run retention cohort analyses, and debate which product event correlates with long-term accounts.
Operator founders don't have this problem. If you've spent 10 years running a field service operation, you know value is delivered per job completed — not per user logged in. If you managed an insurance agency, the relevant unit is policies in force, not seats. That knowledge, which most SaaS founders spend 18 months trying to reverse-engineer from product analytics, is something you walked in the door with.
The practical result: you can set a usage metric with conviction in week one instead of month 18. Your first pricing page isn't a guess — it's what you would have paid if this software had existed when you were on the other side of the transaction.
Three situations where usage-based pricing backfires
Even operators get this wrong when they miss the conditions that make the model work.
Revenue becomes unpredictable. When customers can't forecast their bill, procurement slows down. Enterprise buyers and SMBs both prefer predictable costs, especially in year one with a new vendor. If your customers' workload varies significantly by season or project cycle — common in field service, construction, and professional services — pure consumption pricing creates buyer resistance at exactly the moment you need customers to sign.
Support costs scale with usage. If a high-volume customer creates 10x the support tickets of a low-volume one, you're subsidizing your heaviest users. Usage-based pricing without tiered support entitlements turns your biggest customers into your most expensive ones. The unit economics break at the accounts you most want to keep.
The usage metric isn't something customers control. If customers feel charged for outcomes they can't influence, pricing becomes a friction point inside your product. Charging per record imported works if customers own the import process. It breaks down if the import requires your team's involvement.
How to structure it for vertical B2B
The model most vertical SaaS founders land on after 12–18 months: a base platform fee covering a fixed usage tier, with per-unit pricing above that threshold.
The platform fee accomplishes two things. It gives customers a predictable cost floor, removing procurement friction. It also ensures revenue during low-usage months — which matters when your customers are seasonal or project-based.
Per-unit pricing above the threshold lets heavy users pay more without creating friction for average accounts. Set the threshold at roughly the 70th percentile of your customer base — high enough that most customers never hit it, low enough that your largest accounts contribute meaningfully to overage.
For the base price, anchor to your customer's cost of the alternative. If the workflow you're replacing costs a dispatcher 4 hours per week at $30/hour, you have a $480/month ceiling before you're more expensive than the status quo. Price at 30–40% of that replacement cost in the early stages, with room to increase as the platform expands.
The signal that tells you the model is working
Usage-based pricing is working when customers expand their consumption without a dedicated expansion conversation. If accounts are moving up tiers because the product is getting more integrated into their workflow, the model is doing its job.
If customers are managing against usage thresholds — skipping features they'd otherwise use, batching activity to stay under limits — you've either priced the metric too aggressively or chosen a metric that doesn't align with value.
Watch expansion revenue by cohort for the first 6 months. If average consumption per customer grows without a direct upsell motion, the model is calibrated correctly. If usage is flat or customers are actively limiting it, the problem is pricing architecture, not sales.
The SaaS pricing strategy guide covers the broader framework. If you're a vertical SaaS founder who wants a build partner who's worked through these pricing questions with operators before, tell us what you're building.