What is Value Based Pricing?
Written by Arnon Shimoni
✓ Expert
Last updated on:
Value-based pricing sets a price from the economic value a customer receives rather than from what the product costs to deliver or what competitors charge. The price reflects the outcome (revenue gained, cost avoided, risk reduced, time returned) and a defensible share of it goes to the vendor. It's the recommended strategy for most differentiated B2B software, and it's the hardest to execute, because it requires measuring willingness to pay rather than assuming it.
Field | Detail |
|---|---|
Also known as | Value pricing, customer value-based pricing |
Price anchored to | The customer's economic outcome |
Alternatives | |
Requires | A quantified value model and a WTP measurement |
Measurement methods | Conjoint, Van Westendorp, Gabor-Granger, win/loss analysis |
Natural pricing models | |
Main failure mode | Claiming a value-based strategy while running a cost-plus process |
Best for | Differentiated products with measurable customer outcomes |
Worst for | Commodities, undifferentiated infrastructure, unmeasurable value |
Value-based, cost-plus, and market-based
Three ways to answer "where does the number come from."
Cost-plus | Market-based | Value-based | |
|---|---|---|---|
Anchor | Delivery cost plus target margin | What competitors charge | Customer's economic outcome |
Data needed | Your unit economics | Competitor price points | Customer value model plus WTP |
Works well for | Commodities, regulated pass-through, infrastructure resale | Established categories with clear substitutes | Differentiated products with measurable outcomes |
Fails by | Ignoring what buyers will actually pay | Racing to the bottom, commoditising your own category | Being genuinely difficult, so teams fake it |
Effort | Low | Low | High |
Most companies say value-based and do cost-plus with a bigger multiplier. The test is simple: if you can't state, in the customer's numbers, what your product is worth to a named segment, you're not doing value-based pricing. You're doing cost-plus with better slides.
The three aren't mutually exclusive in practice. Cost-plus sets a floor you shouldn't go below. Market-based sets a range you can't stray too far from without an argument. Value-based decides where you sit inside that space and how much of it you can defend.
Building a value model
Step 1. Quantify the economic value, in the customer's units. Not your features. Their money. Four shapes it usually takes:
Revenue gained. "Customers using automated dunning recover 8% of failed payments." Multiply by their failed payment volume.
Cost avoided. "Replaces 20 hours a month of analyst time." Multiply by fully loaded hourly cost.
Risk reduced. "Cuts revenue leakage from 3% to under 0.5%." Multiply by revenue.
Time to value. "Ships in 6 weeks instead of 9 months of internal build." Multiply engineering cost by the difference, and add the value of the 7 months of revenue they weren't collecting properly.
The output is a number per segment, and it's a ceiling, not a price.
Step 2. Find the alternative and its cost. Value is always relative to what they'd do otherwise: a competitor, an internal build, a contractor, a spreadsheet, or nothing. The gap between your value and the alternative's value is the part you can actually charge for. A product worth €200k a year against a €150k incumbent has €50k of differentiated value, not €200k.
Step 3. Measure willingness to pay rather than inferring it. This is where the strategy usually collapses. The value model produces a ceiling; WTP research tells you where buyers actually sit under it. Methods, roughly by cost:
Interviews about the current alternative and its cost. Do these first, always.
Van Westendorp for a credible range in a new category.
Gabor-Granger for a revenue-maximising point in an established one.
Conjoint when the question is which features belong in which tier.
Win/loss and discount analysis once you're selling, which beats all of the above.
Step 4. Segment by value received. The same product delivers wildly different value to different customers. A 40-person startup and a 4,000-person enterprise get different absolute value from identical software, which is the entire economic argument for tiering and for usage-based structures. See the WTP distribution discussion.
Step 5. Decide your share of the value. The rule of thumb in enterprise software is that the vendor captures 10-30% of the quantified value, leaving the rest as the customer's reason to buy. Capture too little and you've built a charity with a sales team. Capture too much and there's no surplus left to motivate a switch, especially against an incumbent with switching costs on its side. Treat that band as a heuristic rather than a law: it varies with competition, switching cost, and how confidently the value can be attributed to you.
Step 6. Build the price architecture. A base price, a scaling dimension that tracks value, add-ons for value that only some segments get, and enterprise terms for the tail. The scaling dimension is the important decision, covered next.
Picking the value metric
A value-based price needs a unit that grows with the value the customer receives. Get this wrong and no amount of research saves the price.
Good value metrics move with customer outcomes, are visible to the customer, are hard to game, and don't punish adoption. Resolved tickets, processed invoices, enriched records, transactions, GB analysed, active end-customers.
Bad value metrics move with your cost rather than their value (compute-seconds), punish the behaviour you want (charging per admin seat), or can be gamed by batching (per API call, when the customer can just batch harder).
Seats are a proxy that's breaking. Seat-based pricing was a fine value proxy when more users meant more value. For AI products where one person orchestrates agents doing the work of ten, seats measure headcount rather than value delivered, and headcount is going the wrong way. We've argued this in seats are a relic.
Usage as value-based pricing, made automatic. When the metered unit is a genuine value proxy, usage-based pricing enforces value-based pricing without you having to renegotiate. Customers who get more value pay more, continuously, with no annual true-up conversation. That's the appeal, and it depends entirely on picking a unit that tracks value rather than one that tracks your infrastructure bill.
Outcome pricing is the pure form, and it's hard. Charging per resolved ticket or per successful placement aligns price to value exactly. It also requires agreeing what "resolved" means, attributing the outcome to you rather than to the customer's own process, and accepting revenue volatility you don't control. See outcome-based pricing.
Value-based pricing for AI products
AI has made value-based pricing simultaneously more attractive and harder to execute.
More attractive because AI products often replace labour, and labour has a price. When your agent does work a €70k analyst was doing, the value model writes itself, and the buyer already has the budget line. This is the cleanest value story available in software right now.
Harder for three reasons:
Costs are variable and moving. Unlike traditional SaaS, where marginal cost was near zero and value-based pricing had no floor to worry about, AI products have real per-transaction cost that moves when a provider changes their rate card. Value sets your ceiling and the marginal cost sets a floor that won't hold still.
Pricing has to be checked against margin continuously rather than annually.
Value varies enormously between customers. Two customers running the same agent get 10x different value depending on their workflow, their data quality, and what they were doing before. Single-price value capture leaves most of the money uncollected. This pushes toward usage or outcome structures rather than flat tiers.
Attribution is contested. If a support agent resolves 60% of tickets, how much of that is your model and how much is the customer's knowledge base? Buyers negotiate hard on this and they're not wrong to.
That's why a hybrid of a platform fee (captures baseline value, gives you predictable revenue), a usage or outcome component (captures variable value), and enterprise commits (gives the buyer predictability and you a floor) are still favoured. We covered the data behind that pattern in hybrid pricing is the default now.
Common mistakes with value based pricing
Mistake | What happens | What to do instead |
|---|---|---|
Starting from cost and adding margin | You've done cost-plus and called it value-based | Start from the customer's outcome, use cost as a floor check |
Never measuring WTP | The value model gives a ceiling nobody validated | Run a survey method, then correct with win/loss data |
Pricing to the average customer | High-value accounts underpay, low-value accounts churn | Segment and tier |
Picking a value metric that tracks your cost | Customers feel billed for your infrastructure | Pick a unit the buyer already measures |
Capturing too much of the value | No surplus, no reason to switch, long sales cycles | Target a defensible share, leave a visible reason to buy |
Setting price once | Product changed, costs changed, competitors moved | Schedule review, own it explicitly |
Ignoring the alternative | You price against your value, not your differentiated value | Model the incumbent's value too, price the gap |
Value claims sales can't defend | The model dies in the first procurement call | Give reps a value calculator with the customer's own inputs |
Related terms
Frequently asked questions
What is value-based pricing in simple terms?
Charging based on what the outcome is worth to the customer rather than on what it costs you to deliver. If your product saves a customer €200k a year, the price is set from that number, not from your hosting bill.
What's the difference between value-based and cost-plus pricing?
Cost-plus starts from your delivery cost and adds a margin, which ignores what buyers would actually pay. Value-based starts from the customer's economics. Cost-plus is useful as a floor check, not as a method for setting the price.
How do I quantify the value my product delivers?
Find the customer's alternative and price it: headcount they'd need, incumbent tool they'd buy, losses they'd absorb, or revenue they'd miss. That's the reference. Your differentiated value is the gap between your outcome and that alternative's outcome.
How much of the delivered value should I capture?
Common practice in enterprise software is 10-30%, leaving the customer a clear surplus as their reason to buy. The right share depends on competition, switching costs, and how confidently the outcome can be attributed to you. Treat the band as a starting heuristic.
How do I measure willingness to pay?
Interviews about the current alternative first. Then a survey method: Van Westendorp for a range in new categories, Gabor-Granger for a price point in established ones, conjoint when packaging is part of the question. Once you're selling, win/loss and discount data beat all of them.
Does value-based pricing work with usage-based billing?
It works particularly well, provided the metered unit is a genuine value proxy rather than a cost proxy. Metering something the customer already tracks as an outcome makes usage billing an automatic form of value capture.
What's a value metric?
The unit your price scales on. A good one grows with customer value, is visible to the customer, resists gaming, and doesn't discourage adoption. Resolved tickets, processed documents, and active end-customers are good candidates; compute-seconds usually isn't.
Why is value-based pricing hard to implement?
It needs a quantified value model per segment, a real willingness-to-pay measurement, a value metric that holds up, and a sales team that can defend the value claim in a procurement conversation. Each of those is work, which is why most teams stop after the first slide.
Does value-based pricing work for AI products?
It's the natural fit, because AI often replaces labour and labour has a known price. The complications are variable unit costs that move with provider rate cards, value that varies 10x between customers, and contested attribution of the outcome.
How often should value-based pricing be revisited?
Whenever the value model's inputs change: your product's capability, your unit costs, the customer's alternative, or the segment mix you're selling into. For AI products that's realistically every couple of quarters.
What if my customers can't measure the value they get?
Then value-based pricing will be contested in every negotiation, and you should invest in making the outcome measurable before you invest in the pricing. Reporting that shows the customer what they got is a pricing asset, not a product nicety.
Can I use value-based pricing in a commodity market?
Rarely, and only where you've genuinely differentiated on something buyers pay for (reliability, compliance, support, integration depth). In a true commodity, market-based pricing with a cost floor is the honest answer.
Educational reference. Value-based pricing means the price changes when the value story changes, so the cost of changing a price becomes a strategic constraint. Solvimon holds plans, rate cards, and entitlements as configuration. See pricing methodology for the research methods behind the number.
Ready for billing v2?
Solvimon is monetization infrastructure for companies that have outgrown billing v1. One system, entire lifecycle, built by the team that did this at Adyen.
