You modeled it out. Twenty seats per customer, $50 per seat per month, $1,000 monthly contract. Clean math, neat ARR projections, a pricing page that looks like every other B2B SaaS company. Then you get into your first customer conversation and the buyer asks: "Do I have to pay for the receptionist?" You say yes. They say they'll think about it. The deal stalls.
SaaS per-user pricing made sense for the products that popularized it — collaboration tools, CRMs, communication platforms where each additional user creates incremental, measurable value. In those contexts, the pricing model is intuitive: more people using it means more value, so more cost. But in vertical SaaS — where you're building workflow software for a specific kind of operational business — the per-user model frequently creates friction that kills adoption and makes expansion harder than it should be.
How vertical buyers actually think about per-user pricing
The typical buyer for a vertical SaaS product in a trades, services, or specialty business is an owner-operator or an operations manager. They think about software the way they think about any other business expense: what is this costing me per month to run my operation? They don't think about it on a per-employee basis because their employee count fluctuates — seasonal workers, part-time staff, contractors who need occasional system access, new hires they're onboarding and might not keep.
When you present per-user pricing to this buyer, you've introduced a variable they didn't expect. The software cost isn't a fixed line item; it's a function of their headcount decisions. That's a different mental model than "I pay $X a month for this tool." And it generates specific objections that slow every deal: Do part-timers count? What about contractors? If I add someone for a busy season, does my price go up? If I remove them in the off-season, do I have to call you?
These are not unreasonable questions. They're the natural consequence of pricing structure that doesn't fit how this buyer thinks about their business costs.
The pricing model that fits operational verticals
The models that work best in operational verticals are the ones where the buyer can answer one question without calling you: how much am I paying this month?
Flat monthly with feature tiers works in many segments — a base plan for core features, a higher tier for advanced reporting, integrations, or multi-location capability. The buyer's cost is predictable. They can explain it to their accountant in a single line item. The tier is determined by what the software does for them, not by how many people happen to be on payroll that month.
Per-location pricing works well for businesses with multiple sites or territories. An HVAC company with three branches, a gym chain with six locations, a pest control operator with regional divisions — billing per location aligns the software cost with the operational unit that matters to the buyer. They add a location, they expect to pay more. That's intuitive in a way that per-user headcount is not.
Usage-based pricing tied to a transaction volume the buyer controls — jobs completed, policies processed, service tickets closed — also works in specific segments, particularly when the transaction is the core workflow object. The buyer sees the cost as a percentage of their activity rather than an overhead. The challenge is forecasting, but many operational buyers prefer it because it aligns their payment with their results.
When per-user pricing does work in vertical SaaS
There are segments where per-user pricing is the right call, even in vertical SaaS. The test is whether each user's access to the system creates direct, differentiated value tied to their individual role — not just operational access to shared infrastructure.
A field service management platform where each technician's app is tracking their location, job updates, and customer communication? Each technician is generating and consuming data specific to their role. Per-user or per-technician pricing aligns. A compliance tool where each licensed professional is individually subject to audit? Per-user makes sense because the licensing is per-person.
The failure mode is applying this logic by default — assuming that because the software is used by multiple people, it should be priced per person. That's a product category assumption borrowed from productivity software, and it doesn't hold when the software is workflow infrastructure for the business rather than a personal productivity tool for each employee.
Testing your pricing model with real buyers
The fastest way to validate a pricing model is to present it to ten prospects and watch the response. Not the polite response — the cognitive response. Do they immediately understand what they'd pay? Do they nod or do they start asking clarifying questions about edge cases?
When you get the "do I have to pay for the receptionist?" question, you haven't found a difficult customer. You've found a signal that your pricing structure requires your buyer to do mental accounting that they shouldn't have to do. That accounting creates friction at exactly the moment you want momentum — the close.
Operator founders building vertical SaaS have an advantage here: they know how the businesses in their vertical think about cost. They know what line items the buyer's accountant will ask about, what the owner-operator cares about when reviewing their P&L, and how the business thinks about adding software expenses. Use that knowledge to design a pricing model that fits the buyer's mental model, not the pricing template from the last YC batch.
The pricing question you should be asking instead
Instead of starting with "what is our pricing model?" start with "what is the natural unit of value in my customer's business?" For a field service operator, the job is the unit. For an insurance agency, the policy or the client is the unit. For a restaurant, the location is the unit. For a construction contractor, the project is the unit.
Your pricing model should, wherever possible, be denominated in that unit — or in a proxy for it that the buyer recognizes as fair. When it is, the buyer's cost scales with the value they're getting, the math is intuitive, and the expansion conversation is natural. Adding a location means adding a location to the subscription. Closing more jobs means the software is working. The cost and the outcome track together.
Per-user pricing will sometimes be right. But it's the default for reasons that have more to do with SaaS company financial modeling conventions than with how operational buyers actually experience value. Operator founders are in the best position to reject the default when it doesn't fit — because they know their buyer better than anyone who built the template.