Tag: SaaS pricing

If your pricing discussion keeps bouncing between competitor screenshots, delivery costs, and whatever Sales thinks the market will accept, you are not yet deciding a price. You are mixing four separate decisions: the pricing model, the pricing metric, the package, and the amount charged.

Separate those decisions and make them in the right order. You will get a pricing system that customers can understand, Finance can model, Sales can explain, and Product can improve as real behavior replaces assumptions.

Find the value, then choose a metric that tracks it

Value-based pricing does not mean charging the highest number a customer will tolerate. It means connecting what the customer pays to a result the customer cares about. Your costs still determine whether the offer is sustainable, but they do not explain why the buyer should purchase it.

Start by keeping four commonly confused decisions separate:

Define value in the buyer’s language

Your first customer conversations should not begin with a proposed price. Begin with the decision the buyer is trying to make and the change the buyer expects after adopting the product. Ask for recent, concrete examples rather than opinions about a hypothetical offer.

• What event made this problem important enough to address?
• What happens if the buyer leaves the problem unsolved?
• Who experiences the problem, and who controls the budget?
• What observable change would count as success?
• How does the buyer prove that change internally?
• What alternatives compete for the same budget, including manual work and doing nothing?
• What causes value to grow: more users, more activity, more completed work, better results, or lower risk?

Turn the answers into one working statement: For [buyer], the product creates value when [observable result] improves [business or operational consequence], compared with [current alternative]. This is not positioning copy. It is a testable value hypothesis that will guide the metric and package.

If different segments complete that sentence differently, do not average the answers into a vague promise. That is evidence that the segments may need different packages, metrics, or sales motions. A support leader buying fewer escalations and an operations leader buying more throughput may use the same product while evaluating its value in different ways.

Turn value into a billable unit

The pricing metric is the bridge between the value hypothesis and the invoice. For an AI support agent, for example, the model can charge only for results, while the unit is an outcome counted when the agent resolves a customer query without further help. The principle is attractive because payment moves with delivered value. The definition is difficult because every ambiguous edge case can become an invoice dispute.

Write the metric specification before selecting the price. It should define:

• The event that starts the measurement.
• The event that qualifies the unit as complete.
• Any quality threshold required before it is billable.
• Exclusions, such as tests, spam, duplicates, abandoned work, or activity outside the contracted scope.
• Attribution when a human, an automation, and an AI system all contribute.
• How reversals, reopened work, refunds, and corrections affect the count.
• What the customer can see before the count appears on an invoice.
• Which record resolves a disagreement between product analytics and billing.

My rule is simple: if a buyer cannot understand what will be counted and predict the direction of the next bill, the metric is not ready. Evaluate every candidate against six tests:

• Value alignment: Does an increase in the unit normally mean the customer received more value?
• Predictability: Can the customer forecast the unit well enough to plan a budget?
• Auditability: Can both sides inspect the same underlying events?
• Controllability: Can the customer influence usage or set limits without abandoning the product?
• Operational feasibility: Can your product, data, billing, and support systems calculate the unit consistently?
• Economic alignment: Does revenue scale sensibly relative to the cost and risk of delivering the value?

A value-based design does not always require a literal outcome metric. A proxy can be the better choice when it is closely related to value and much easier to forecast and audit. Raw activity is a poor proxy when it can grow without improving the customer’s result. A seat is a poor proxy when adding users does not increase value. An outcome is a poor metric when success cannot be defined consistently. Choose the least complicated unit that preserves alignment.

Before charging anyone, run the proposed rules against beta or historical events. Generate shadow invoices, inspect unusually high and low accounts, and reconcile the count from the raw event through the customer-facing bill. This exposes definitional and data problems while they are still product problems rather than financial disputes.

Make packaging do the segmentation work

Pricing determines how revenue scales. Packaging determines which customers select which offer. A package is therefore not a decorative feature table. It is a mechanism for matching different value patterns, operating needs, and willingness to pay without creating a custom product for every account.

1. Segment customers by how they receive value. Company size may matter, but workflow complexity, risk, required integrations, volume, and the cost of failure can be more revealing.
2. Identify the minimum complete experience. Every package should let its intended customer reach the core outcome; a deliberately crippled entry plan teaches the market that the product does not work.
3. Place differentiators where their value is concentrated. Advanced governance, analytics, automation, integrations, service levels, and support may matter much more to one segment than another.
4. Choose the relationship between access and consumption. Decide what is included, what is metered, whether unused commitments expire, how overages work, and whether customers can set caps or alerts.
5. Test whether buyers can self-select. Show realistic scenarios, ask which package they would choose, and then ask them to explain why. Their explanation is more diagnostic than the selected tier.

Choose modular, bundled, or hybrid architecture deliberately

Modular pricing works best when capabilities have distinct buyers, adoption paths, and measurable outcomes. It lets a customer buy one job without funding unrelated functionality. Its weakness appears as the portfolio expands: each additional module adds another decision, metric, contract term, and sales explanation.

Bundling works better when capabilities reinforce one workflow or when customers experience the combined result rather than the individual components. It reduces buying friction, but it can hide which capability creates value and can force smaller customers to pay for breadth they do not need.

A hybrid can separate platform access from variable value: a base package covers the shared product, an included allowance makes the initial bill predictable, and overages or commitments let revenue grow with delivered value. Use that structure only when each component answers a different commercial question. Adding a platform fee, several meters, tier thresholds, credits, and add-ons without a clear role for each one creates a billing puzzle, not a pricing strategy.

Look for these packaging failure signals:

• Customers repeatedly need capabilities scattered across several tiers.
• The entry package cannot produce the outcome used to sell it.
• The highest tier is simply every leftover feature rather than an offer for a distinct need.
• Two packages attract the same customer for reasons your sales team cannot explain consistently.
• The economically best package for you is visibly wrong for the customer.
• Customers need a spreadsheet or a salesperson to estimate a normal bill.
• Every new capability becomes a new add-on because the portfolio has no shared packaging logic.

Do not ask customers whether they like the package names or feature list. Give them a buying situation, expected volume, required controls, and a budget constraint. Ask them to choose, identify what feels unnecessary, and state what is missing. You are testing whether the architecture supports a decision, not whether the page looks polished.

Measure willingness to pay only after the offer is clear

Quantitative pricing work becomes useful only after buyers understand the model, metric, and package. Otherwise, a survey can produce a precise answer to a question the market would never ask. Use qualitative discovery to establish the buyer’s language and mental model, then carry that exact framing into willingness-to-pay testing.

Methods such as Gabor-Granger and Van Westendorp answer different questions. Gabor-Granger-style testing helps estimate purchase willingness across proposed price points. Van Westendorp-style questions help expose perceived price boundaries, including where an offer begins to feel implausibly cheap or prohibitively expensive. Neither method discovers the value metric for you, and neither produces a universally correct price.

A defensible survey sequence looks like this:

1. Describe the customer problem and product outcome without promotional language.
2. State exactly how charging works.
3. Define the billable unit, including the success condition.
4. Show what the package contains and what it excludes.
5. Give the respondent a realistic usage or outcome scenario.
6. Ask about willingness to purchase at a specific price or across a controlled sequence of prices.
7. Capture the respondent’s role, segment, buying authority, expected volume, and current alternative so the results can be interpreted rather than merely averaged.

A demand curve is more useful than a single average. In one outcome-priced case, stated purchase willingness moved from 69% at $0.86 per outcome to 39% at $1.42. Those figures are not benchmarks for another product. They demonstrate why the decision is strategic: moving along the curve changes expected adoption as well as revenue captured from each unit.

A simple price multiplied by the share willing to buy can identify a survey-based revenue peak, but that point is not automatically your final recommendation. It does not, by itself, include realized discounts, differences in unit volume, cost to serve, retention, expansion, sales effort, or the value of establishing market share.

Decide what the price is meant to accomplish before interpreting the curve:

• If the priority is adoption, you may accept less revenue per unit to reach more qualified customers.
• If the priority is near-term revenue, you may choose a higher point while accepting a lower attach rate.
• If the product requires substantial support or delivery cost, margin may eliminate prices that look attractive in a demand survey.
• If the category is unfamiliar, simplicity and predictability may be more important than extracting the theoretical maximum.
• If the product is part of a broader platform, the effect on cross-sell, retention, and portfolio coherence may matter more than stand-alone revenue.

Treat willingness-to-pay results as stated intent, not observed buying behavior. Segment the curve before using it. A blended result can conceal a high-value segment with strong demand and another segment that should not be targeted at all. It can also overstate confidence when respondents use the product but do not own the budget.

Convert the demand curve into a commercial model

The survey narrows the plausible range. The commercial model tells you whether an option can survive contact with actual customers, contracts, usage, discounts, and delivery costs. This is where a promising price becomes an operating plan.

1. Set a candidate list price. Choose a point that reflects the demand curve and the strategic objective, not just the highest theoretical revenue index.
2. Estimate realized price. Apply expected discounts, negotiated rates, credits, promotions, and channel effects. A list price that relies on constant exceptions is not the real price.
3. Project units by segment. Use beta or observed usage to estimate outcomes, transactions, seats, or another billable quantity. Preserve the distribution instead of relying only on the mean.
4. Model attach rate. Estimate what share of eligible customers will buy in conservative, base, and upside cases. Connect each case to an explicit assumption rather than a general level of optimism.
5. Calculate customer and portfolio revenue. For a metered product, combine realized unit price with expected annual units. Then roll the result across eligible customers and segments.
6. Include delivery economics. Subtract variable delivery costs and account for service obligations that grow with usage. For AI products, inspect how model, infrastructure, support, and exception-handling costs behave at both low and high volume.
7. Connect the recommendation to the operating plan. Show the implications for customer count, adoption, annual recurring revenue, gross margin, expansion, and any dependencies on the rest of the portfolio.

Stress-test the assumptions that can break the plan

A single base case hides the shape of the risk. Change one major assumption at a time so decision-makers can see what the recommendation depends on.

• Discount sensitivity: What happens if realized price is materially below list price?
• Volume sensitivity: What happens when customers generate far fewer or far more units than the average?
• Attach sensitivity: How much adoption is required before the product covers its fixed investment?
• Cost sensitivity: Does high usage improve gross profit, or does the delivery cost scale almost as quickly as revenue?
• Concentration risk: Does the forecast depend on a small number of unusually large customers?
• Invoice volatility: Can normal changes in behavior create bills that customers will perceive as unpredictable?
• Metric leakage: Are valuable events going unbilled, or are low-quality events being counted as successful outcomes?

Inspect account-level scenarios, not just portfolio totals. A model can produce acceptable average revenue while creating obviously unreasonable bills for a small customer, a seasonal customer, or a high-volume account. Those tails often become the discount exceptions, support escalations, and renewal problems that the average concealed.

Make the recommendation easy to challenge

The approval memo should contain the decision and the logic required to dispute it. Include:

• The buyer, value hypothesis, model, metric, and metric definition.
• The proposed packages and the segment each package is designed to serve.
• The willingness-to-pay range and how it changes by segment.
• The recommended list price, expected realized price, and discount guardrails.
• Conservative, base, and upside forecasts for adoption, revenue, and margin.
• The most sensitive assumptions and the evidence supporting them.
• Alternatives considered, why they were rejected, and what evidence would reopen them.
• Operational dependencies across Product, Research, Data, Finance, Engineering, Sales, Customer Success, Support, and billing.

Cross-functional review is not ceremonial. Finance can expose a margin or forecasting problem. Engineering can show that the proposed event cannot be measured reliably. Sales can identify a model buyers cannot procure. Support can anticipate disputes. Product can determine whether the metric rewards the behavior the product is supposed to create. Resolve those conflicts before the price becomes a public promise.

Launch pricing as a controlled learning system

Approval is the end of price design and the start of price operations. Customers experience pricing through entitlements, usage counters, contracts, invoices, renewal conversations, and support responses. A sensible strategy can fail if those surfaces disagree.

Complete the billing path before charging

• Write a billing specification that maps raw events to billable units and contract terms.
• Verify entitlements, included allowances, overages, caps, credits, and exception handling.
• Run parallel or shadow invoices and reconcile them from event log to customer-facing total.
• Give customers a usage view that uses the same definitions and timing as billing.
• Enable Sales with qualification rules, scenario-based pricing examples, and clear discount authority.
• Prepare Customer Success and Support to explain the metric, diagnose discrepancies, and escalate genuine billing errors.
• Instrument proof of value next to proof of usage so the commercial conversation is not reduced to a meter.
• Communicate the effective date, affected products, counting rules, package changes, and available customer controls in plain language.

Do not alter existing charges on the assumption that a product announcement overrides a contract. Review contractual commitments, renewal timing, migration rules, and customer communications before changing what an existing customer pays. An informal migration can create financial disputes and destroy trust even when the new model is better designed.

Use behavior to diagnose the next problem

Instrument the system from the first launch cohort. Review both commercial performance and customer experience:

• Eligibility, attach rate, and package selection by segment.
• List price, realized price, discount frequency, and exception rates.
• The full distribution of billable units per customer, not just the average.
• Revenue and gross margin by segment, package, and usage band.
• Invoice variance and how accurately customers forecast their charges.
• Billing questions, disputes, credits, and metric-definition escalations.
• Activation, continued usage, achieved outcomes, expansion, contraction, renewal, and churn.
• Sales-cycle friction caused by the model, procurement requirements, or package complexity.

Use each signal to choose the next investigation. Low attach can point to weak qualification, unclear value, the wrong package, or the wrong price. Strong attach followed by low activity can indicate an onboarding or product-value problem. High activity with poor margin calls for an economics or discount review. Frequent disputes usually justify inspecting the metric definition, event quality, and customer visibility. These patterns are diagnostic prompts, not causal proof; pair the numbers with targeted customer and GTM conversations.

Review the architecture, not only the number, when the product expands. Modular outcome pricing can work cleanly while each capability has a distinct result. As a platform adds capabilities, buyers may face several meters, overlapping modules, and an invoice they cannot predict. That is a signal to reconsider how access, bundles, allowances, and outcomes fit together, not merely to adjust every component independently.

Reopen the pricing system when customers cannot forecast bills, new capabilities do not fit an existing package, discount exceptions become routine, sales explanations diverge, gross margin behaves differently from the model, or the value customers receive is no longer represented by the metric. Pricing should be treated as a living system informed by research, customer behavior, and go-to-market learning, not a launch artifact that becomes untouchable.

Key takeaways

• Make four decisions separately: pricing model, pricing metric, package, and price.
• Define value using an observable customer result before asking what anyone will pay.
• Choose a metric that aligns with value but remains predictable, auditable, operationally feasible, and economically sound.
• Design packages around distinct value patterns and buying needs, not an arbitrary progression of feature counts.
• Use willingness-to-pay work to build a demand curve, then combine it with usage, attach, discounts, and margin in a commercial model.
• Validate the complete billing path before launch and use observed behavior to improve the system afterward.

If your team is stuck debating the number, stop the meeting and complete six lines first: buyer, customer outcome, billable unit, measurement proof, package boundary, and commercial assumptions. Any line you cannot defend is the next research or modeling task. Put a price on the page only after those six lines tell one coherent story.

References

• Intercom – Inside My Pricing Playbook: Building Value-Based Packaging That Balances Growth and Profit