Imagine a B2B software product whose core functionality does not change. It can be sold as a fixed monthly subscription, priced per seat, metered by API call, wrapped in a minimum-usage commitment, charged per transaction, or partly linked to a measurable outcome.

The code may barely change. The economics around it can change a great deal. A buyer may become more willing to start but less willing to use freely. Budget certainty can improve or deteriorate. Revenue can become steadier or more exposed to usage. Sales, expansion and margin exposure all move with the commercial design.

That is why How much do we charge? is only one pricing question. The others are What do we charge for? Who receives which offer? What does each side commit to? Who absorbs the volatility?

For this article, pricing is an economic architecture rather than a single number.

Split pricing into four separate decisions

A pricing discussion becomes muddy when the list price, billing unit, package, discount and business model are treated as the same thing. I separate four decisions, then test the result economically.

Start with the revenue or value trigger: what value or event is the customer paying for? It might be access for a period, another user, a unit of consumption, a transaction, or a verified result. Financial-reporting categories are not a monetisation framework, but filings make the coexistence of different earning patterns visible. Salesforce’s FY25 annual report, for example, reports two top-level revenue sources: subscription and support, and professional services and other. Term software-licence revenue is included within subscription and support. The pricing metric is a different choice: the billable unit might be a seat, transaction, API call, gigabyte, compute hour, asset or defined outcome. Stripe’s usage-based SaaS guide likewise separates measurable usage from billing mechanics and spend controls. The trigger explains what the customer is paying for; the metric says what gets counted for it.

Packaging then decides which rights, features, limits, service levels and governance capabilities sit inside each offer. Finally, realised-price mechanics determine what is actually paid after discounts, minimum commitments, prepayment, credits, caps, floors, included allowances and overages. AWS Savings Plans show the difference neatly: the customer exchanges a defined usage commitment for lower prices; the underlying consumption metric is still there.

None of those choices proves the design works. The fifth layer is economic validation: bring price, usage, mix, retention, expansion and cost-to-serve back to a consistent unit and cohort and see whether contribution economics improved.

The same product branches into value trigger, billable unit, packaging, and price or commitment choices, which feed customer behaviour, risk allocation, and unit economics.

What you charge for changes how customers use the product

Consider the marginal decision created by each metric. A fixed subscription normally does not charge for one extra use. Per-seat pricing makes each additional user visible to procurement. API or compute pricing attaches a marginal charge to more workload. Transaction pricing ties the seller more directly to activity. Outcome pricing moves the bill towards a result, but then the contract has to cope with measurement, attribution, timing and exceptions.

Value-based and outcome-based pricing are easy to confuse here. Value-based pricing uses customer value as the anchor for what the seller charges; it does not require the invoice to move directly with an outcome. An OECD report on value-based pricing, written in a pharmaceutical setting, discusses willingness to pay and differentiated benefits while also exposing how difficult value measurement can be. It is not a SaaS rule. The transferable point is that willingness-to-pay evidence needs a stated sample, method and decision context.

Usage-linked pricing creates a different trade. It can reduce the commitment required at the start and let spend rise with adoption. Twilio is a company-specific example of substantial usage-based revenue; its annual report discusses customer usage within its expansion mechanics.

The same linkage also imports volatility. Customers may have less certainty about spend and the vendor is more exposed to changes in usage.

With outcome-based pricing, the measurement problem moves closer to the centre of the contract. Stripe’s outcome-based pricing guide discusses measurable outcomes alongside hybrid base and variable fees, caps, floors and commitments. If buyer and seller cannot agree on what caused the result or when it counts, the charging model creates an operating problem rather than solving one.

Demand response needs its own boundary too. An NBER study using randomised interest-rate offers found materially different elasticity estimates at different observation horizons. It provides no reusable SaaS elasticity number. It does show why an elasticity estimate belongs to a setting and a time horizon.

Packaging is not three columns called Basic, Pro and Enterprise

Keep the same software and the same usage metric. Change only the offer: Basic gets the core workflow, Pro adds collaboration and automation, Enterprise adds access control, audit logs, service levels and dedicated support. The billing unit has not moved, but the value fences have.

That changes who selects which deal. Customer mix, conversion, expansion, support burden and margin profile can move even when neither the product nor the billing metric changes.

The word “upgrade” is therefore too coarse for analysis. A customer that voluntarily moves up because it needs more value is not the same as a customer pushed upwards after an existing entitlement disappears from a lower tier. Both can raise ARPU; the second can also raise churn or remove a segment from the product.

Research on bundling, including work by Babaioff, Immorlica, Lucier and Weinberg, analyses bundling versus separate selling under particular assumptions about customer valuations. It is useful evidence that packaging can alter value capture and that the result depends on those assumptions. It does not establish a universal ideal number of tiers.

After a package change, I would rather inspect the population movement than celebrate the tier design: who entered, who moved up, who moved down, who was forced to migrate, who left, and what happened to contribution economics for those groups?

A discount is an exchange, not a minus sign

Suppose a customer asks for a 30% discount. The percentage is not enough to judge the deal.

A reduction exchanged for a three-year commitment, minimum spend, prepayment, greater volume or more predictable demand changes both unit price and the risk or cash-flow profile. The same reduction with nothing in return is economically different. AWS Savings Plans make that exchange unusually explicit: the customer commits to a level of usage over time and receives lower prices.

Before judging the discount, I would ask how much contribution was given up, what commitment came back, and which risk that commitment actually reduced.

A commitment can still be poor economics. Deep discounts can encourage high-cost usage or lock the supplier into a weak contribution profile; a long term does not fix a bad unit.

Once a negotiation starts, the contract is setting the realised price and allocating risk at the same time.

The same product can become six different businesses

The six structures are easier to compare by following the mechanism than by assigning each one a neat High, Medium or Low score.

Monetisation structureWhat makes the customer pay moreHow customer spend movesHow vendor revenue movesMain expansion pathMain operating risk
Fixed subscriptionRenewal, package change or add-onIf the fee is fixed, extra short-term usage does not directly raise the billMainly with customer count, renewal, upgrades and add-onsPackage upgrades and add-onsLight users may see poor value; heavy users may be under-monetised
Per-seatAnother paid seatSpend rises when paid seats riseMoves with paid seats and renewalsMore seatsA visible marginal charge for each user can discourage wider adoption
Metered usageAnother billable unit is consumedMoves directly with measured usageMoves directly with usageNatural usage growthBill and revenue volatility; customers may throttle use
Usage plus commitmentOverage or a higher commitmentA minimum commitment creates a baseline, while overage still moves with usageThe commitment creates some floor, while realised usage and overage still matterOverage and larger commitmentsPoor commitment design can create discount or usage mismatch
Transaction-linkedA qualifying transaction occursMoves with transaction activity or valueMoves with transaction volume, value and mixMore transactions or transaction valueRevenue is more exposed to transaction cycles and mix
Outcome-linkedA contract-defined outcome is verifiedDepends on outcomes and contract terms such as caps or floorsDepends on outcomes and the base-fee/cap/floor structureMore verified outcomesAttribution, measurement, disputes and gaming

The table describes where the meter sits and which variables reach the bill. It does not rank the models. Commitments can also sit on top of a usage metric, shifting some volatility without replacing the metric underneath.

A real company may combine several denominators: a platform fee, usage charge, transaction fee and services revenue can coexist. “Subscription business” can still be a convenient label, but it no longer explains the revenue mechanics on its own.

C3 AI gives us one bounded case rather than a template. In an SEC filing, the company described a move towards consumption-based pricing in part to align more closely with cloud purchasing patterns. It also discussed lower visibility into the timing of consumption revenue. In that setting, lower adoption friction and greater timing uncertainty for the vendor appeared in the same commercial transition. The filing does not establish a universal preference for consumption over subscription.

The product can therefore stay recognisably the same while the business changes around it, because the charging event, expansion path and allocation of volatility have changed.

Revenue went up. Do not declare victory yet

Three months after the pricing change, suppose revenue is up 12% and ARPU is up 9%. Treat both figures as observations, not the verdict. Decompose the revenue movement first: realised price, volume, customer mix, package migration, churn and recognition or transaction timing can all move the total. In DoorDash’s Q1 2025 results, Marketplace GOV, revenue and Net Revenue Margin are reported separately, with affordability initiatives and category mix discussed in the margin context. That is evidence for separating drivers, not a DoorDash bridge to copy into another business.

Cost-to-serve belongs in the same analysis. If the new metric encourages a large amount of low-margin usage, top-line growth can outrun contribution improvement.

ARPU can move mechanically as well. If lower-priced, low-usage customers leave and the remaining base is larger, the average rises. That may be a sensible strategic trade or simple denominator shrinkage. Mix, foreign exchange and cohort age can also improve apparent unit economics without proving that the underlying engine is more efficient. HubSpot’s annual report is useful at the company level because it makes customer mix and metric definitions relevant to the interpretation of averages; its specific result should not be transferred elsewhere.

Netflix’s annual-report materials discuss streaming revenue alongside factors including average paying memberships and price changes. Aggregate revenue clearly has more than one driver. Those materials do not tell us that every cohort’s lifetime value improved.

For the final check, I use economic unit as an operating definition: the smallest decision unit on which revenue, variable cost, retention and acquisition cost can be compared using a consistent denominator. It is not an accounting standard. If the measures use different populations, the ratios can be precise and still answer different questions. Payback has the same dependency. A practitioner formulation can use recurring gross-margin contribution rather than revenue alone to estimate the recovery of acquisition cost; The SaaS CFO’s CAC payback guide is one example. It is a practitioner method, not an accounting rule. When serving the revenue consumes margin, revenue alone makes recovery look faster than the contribution available to fund it.

Those two growth figures are therefore only the start of the diagnosis. On a consistent cohort, unit and contribution basis, what was exchanged for that growth, and what happened to retention, expansion, cost-to-serve and payback?

Choose the risk allocation you can actually operate

“Which pricing model is best?” becomes useful only after the operating constraints are specified.

The charging event has to make sense to the buyer and remain measurable by the seller. The pricing metric has to survive measurement, correction and audit.

Package changes should produce the intended self-selection rather than forced upgrades or cannibalisation. Discounts should be read together with whatever they buy back: term, volume, prepayment, minimum spend, or nothing.

There is also a volatility question. When usage moves, how much uncertainty sits in the customer’s budget and how much sits in the vendor’s revenue? A commercially elegant answer is not much use if the organisation cannot meter, forecast, bill or support it reliably.

One final test keeps the design falsifiable: What evidence would show that the pricing change did not improve the business? If the team can answer that and test the result on fixed cohorts, contribution economics and observed customer behaviour, it has a way to distinguish a better monetisation system from a better-looking revenue chart.

References