TL;DR — The software pricing discourse keeps debating which pricing model to choose — subscription, usage-based, credits, outcome-based. It’s the wrong question. Pricing models are wrappers around value metrics, and the value metric decision is upstream of everything. Companies that pick the model first end up shipping pricing changes every ninety days while their core economics stay broken. Companies that pick the metric first iterate on everything else calmly. Most of the AI pricing debate playing out right now — credits versus tokens versus seats — is the same error, in a new wrapper.
Pricing model vs value metric — the short definition. A value metric is the unit of measurement the price attaches to — users, API calls, resolved tickets, GB processed. It answers what are we charging for? at the conceptual level. A pricing model, in its precise sense, is a computational rulebook that takes the chosen metric and turns it into a rational net price for every combination of what you sell, at every volume you sell it at, consistent across every deal. Price-setting logic, discount rules, incentive structures, volume breaks, approval thresholds — these are the pricing model’s components. The metric names the unit. The pricing model produces the number on the invoice.
In common industry use, though, the phrase “pricing model” has drifted into a generic catch-all that collapses three distinct decisions — licensing model, pricing model (the computational rulebook above), and packaging — into one term. That conflation is part of why teams reach for “pick a pricing model” instead of doing the three-decision work: the vocabulary lets one choice feel like it covers three. Many pricing problems that look like a model problem are actually a metric problem underneath — and the linguistic habit is what keeps that misread in place.
The industry keeps asking the wrong question
A common pattern in the current pricing discourse reads roughly like this: pick a pricing model that maps to how customers realize value, tells your differentiation story, and reduces buying friction. The advice is not wrong. It is just meaningless without its prerequisite — which is identifying how customers realize value in the first place. That is the value metric question. The model-first framing smuggles the hard decision out of view and hands you a menu of wrappers to pick from, as if the hard part were wrapper selection.
This is not a semantic distinction. We consistently see companies that inverted the order end up shipping pricing changes every ninety days while their core economics stay broken. In our client engagements and across the public pricing pages we track, pricing-change frequency has roughly doubled over the last two years — and the vast majority of that activity concentrates on packaging revisions and price-level adjustments, not on underlying architecture. The pattern invites a dangerous interpretation: that pricing is now an everyday activity that does not need strategic engagement. That reading misses what is actually happening. The real description is high-velocity packaging churn on top of metric architectures that were never right to begin with. The companies logging four pricing changes a year are not agile. They are iterating on the wrong variable.
Pricing models are wrappers. Value metrics are the cargo.
A useful distinction the industry rarely makes: pricing architecture is made up of three separate decisions, not one. There is the licensing model — what access the customer is granted and how it is measured. There is the pricing model — the rulebook that computes a rational net price on every invoice, covering price-setting logic, discount rules, incentive structures, volume breaks, and the approval thresholds that keep deals consistent. And there is packaging — how capabilities are grouped into editions and add-ons. The industry lumps all three under “pricing model,” which is the vocabulary gap at the root of the confusion. You cannot clearly debate three decisions when you only have one word for them.
The lever inside all of this is the value metric — the unit of measurement the price attaches to. Users, API calls, resolved tickets, GB processed. The value metric lives inside the licensing model decision. When someone says “usage-based pricing,” they have named a family of metrics (some activity unit) but have not yet picked a specific one. “Outcome-based” similarly wraps a family of potential value metrics. “Credit-based” is closer to a specific choice — credits are the billing unit — but credits are really a grouping function that can wrap any mix of underlying consumption, so the metric question often stays unresolved. The mechanics of each belong in a glossary entry, not a thesis. What matters here is that all three leave the actual lever — the metric — unchosen.
That lever matters more than the wrapper for a simple reason: you can ship the same product on subscription or perpetual, with or without usage-based components, and have pricing work — as long as the value metric underneath is right. You can also ship with the wrong metric. You just pay for it, and you pay differently depending on your motion.
In enterprise deals, the punishment is loud. Buyers push back once procurement puts a spreadsheet on the table showing what they would actually pay under a better metric — the deal stalls, the discount ladder gets invoked, and the pricing you fought for becomes the pricing you apologize for. At least you hear about it.
In self-serve motions, the punishment is invisible, which is worse. There is no procurement team pushing back with data. You see a conversion rate, a signup count, a revenue line, and nothing telling you what those numbers could have been with a better metric. If you acquire ten accounts a week, you will never know whether it should have been fifty. You report the ten as growth. The customers who silently did not convert, did not expand, or did not refer — they never tell you why, so the gap never gets named. You end up in the founder meetup telling friends about your growth dynamics, unaware that your pricing architecture is quietly capping the outcome.
And in both cases, you open the door to a competitor who picked the right metric and priced cleanly against it. The metric decision is upstream of everything the industry is currently debating, and almost nobody is treating it as the first question.
A value metric is the answer to a question most companies never fully work through: how does value get extracted from your software and services by the people using them, how does that extracted value return to the buyer’s organization, and what has it transformed into along the way? The metric is what represents that full transformation in a single billable unit — what the buyer’s organization ultimately receives, not what the end user directly touches. The answer is rarely the obvious raw count. For a SaaS CRM, the metric might not be users at all — it might be sales reps with active pipeline, a refinement that ignores idle logins and rewards the outcome the buyer actually budgets against. For a monitoring tool, not hosts monitored but high-severity alerts routed to the right owner. For a contact center AI, not calls handled but resolutions that did not require human escalation. For a clinical workflow tool, not patients in active care but patient encounters that produced a documented outcome. The art of metric selection is exactly this refinement — moving from the activity the end user performs inside the software to the transformed value the buyer’s organization actually receives. The metric decision determines whether customer growth drives revenue growth, whether discounting eats margin or expands deal size, whether renewal conversations are about usage expansion or about justifying the base fee. Every downstream decision in the software pricing architecture inherits the metric’s properties.
And once the metric is right, everything else stays flexible. A company can evolve its pricing model — adjusting price levels, tightening discount governance, adding new incentive structures — and re-cut its packaging, reshape editions, add and retire add-ons, all while keeping the same underlying value metric. The licensing model itself does not move, because the metric lives inside it and the metric is the decision we are explicitly holding still. Changing the metric under customers who signed up expecting a different one is brutal. It requires contract renegotiation, billing system changes, sales team retraining, and often a meaningful revenue transition. The value metric should be chosen deliberately, on a long-term horizon. Nothing in software is ever truly permanent — products evolve, customer realities shift, new capabilities demand new measurements — but the metric is the slowest-moving of the three decisions by design. The pricing model and the packaging stay flexible precisely because the metric does not change at the same cadence.
Is Your Cargo Worth More Than Your Wrapper?
Your value metric drives more revenue impact than your pricing model architecture. We assess whether your metric captures how customers actually derive value.
Why the model debate feels satisfying even though it’s wrong
The reason the industry defaults to model-first thinking is not that people are confused about definitions. It is that model selection feels concrete — there is a finite list of options, visible tradeoffs, frameworks for weighing them. Metric selection feels abstract and open-ended. Teams reach for the concrete-feeling decision first. The work feels more productive. The deliverable is easier to defend in a meeting.
But the feeling is inverted. Model selection is the amorphous one. You are picking a wrapper without knowing what is inside. You can commit to subscription or usage-based or credits with complete confidence and still have no way to know whether the pricing system you just chose carries a metric that does not match how customers actually experience value, a unit the sales team cannot explain, or a billing structure that punishes the customers you most want to keep. Metric selection looks harder because it forces those questions into the open. Teams default to the wrapper because the wrapper lets them ship a decision without answering them.
There is a second cost to wrapper-selection thinking, and it is strategic rather than psychological. The “finite list of options” is finite because it is a catalog of what other companies have already done. Pricing-model taxonomies in industry articles come from the same underlying exercise: surveying what is in the market today, categorizing what is already in use, publishing the categories as a framework. That is an inherently outside-in method — useful for navigating the market as it stands, useless for designing a pricing architecture that does not look like everyone else’s. When a team commits to subscription or usage-based or credits, it is picking from the same menu every competitor is also picking from. The best outcome available is optimized position in a crowded set. That is the red ocean.
When the exercise starts with the metric instead, the space opens up. The value metric is specific to your product, your customers, and the pattern of value creation that nobody else is instrumenting in exactly the same way. Once the metric is chosen, the wrapper around it can be something that has not appeared in any industry article — because the industry articles are not looking at your customers, your transaction data, or the specific decisions your customers make when they derive value. The creativity sits in the wrapper that fits the metric, not in picking from a list of wrappers that already fit somebody else.
But model selection done before metric selection is picking a shipping container before you know what you are shipping. If the cargo turns out to be liquid and the container is a pallet, the mismatch is structural, not cosmetic. You cannot fix it by repainting. The choice is real, the tradeoffs are real, the comparison frameworks are real — and none of it matters until you know what is actually going inside.
Consider a product whose value is episodic — a wireless backup solution that customers find essential when their primary network is down, but never touch while the network is up. The company picks subscription, the default wrapper for every SaaS product. Customers sign up during an outage, use it heavily for a few weeks, and cancel three months later because the monthly bill keeps arriving for something they are not using. Nobody designed this misalignment; it happened because the wrapper was selected from the standard menu before anyone asked what pattern of value the customer actually experiences. The right wrapper for that product might be insurance-shaped — retainer pricing, pay-per-incident, availability fees. None of those appear on the standard SaaS pricing-model list, because the standard list is a survey of what everybody else is already using for continuous-value products. The team that starts at the metric (“our customers derive value during outages — how often do they occur, how critical are they, what is the buyer willing to pay for the guarantee that we are there when it matters?”) arrives at an answer that sits outside the standard list entirely. The team that starts at the model is stuck renaming subscription editions and watching churn climb.
Getting the metric right requires uncomfortable questions. What actually grows in a customer’s world when they get more value? Does growth in that metric correlate with willingness to pay? Is it resistant to gaming — or will customers artificially suppress it to cut their bill in ways that damage their own outcomes? None of these questions have a framework that produces an answer. They require judgment grounded in how the product works, how the market buys, and how similar metric decisions have played out across other software categories. That is the reason the model-first path is so popular: it offers a way to skip the hard question and still feel like a decision has been made.
The same misread is especially visible in product-led growth discussions. PLG is a channel strategy — a decision about how customers discover and adopt software, not a pricing decision. How a customer found the software — product-led, sales-led, freemium trial, partner referral, outbound — does not change what the software does for them or how they measure their own success using it. If the same customer bought the same product through a self-serve checkout, or through a CEO-negotiated enterprise contract, the value they derive from the software is identical. Value-added reseller arrangements are the narrow exception — the reseller’s services layer adds value on top of the software itself. The value metric is a property of the product and the customer’s use of it, not of the channel that delivered the sale. PLG companies need the same value-metric work as sales-led companies. The channel does not make the metric question easier, harder, or different — it just changes where the customer enters the funnel.
The AI pricing moment is the case study
Most of the current AI pricing debate is the model-first error playing out in real time. The public discourse is consumed with whether to charge by credits or tokens or seats or hybrids of each, whether to move to outcome-based billing, whether platform + tokens is a breakthrough structure or a cost-plus trap. These are all model-level questions. The value metric question — what, exactly, is the customer getting more of when they use our AI features, and is that the thing we should be counting? — barely enters the conversation.
We see the downstream damage regularly in client work. A company adds generative AI features to an existing product — often after investing millions in the underlying infrastructure, model orchestration, and production deployment. The team debates whether to bundle the AI capacity into existing editions or charge separately via credits. They pick credits. They launch. Adoption is weak. We have worked with clients whose new-customer sales of the AI offering measure in the single digits months after launch, with the existing customer base barely touching it. The team concludes the pricing model needs revision and begins debating whether to switch to a bundled-per-seat approach.
What the team did not do — at any point — was revisit the metric. Credits are a billing structure on top of whatever is being consumed. If the underlying metric is wrong (tokens for a workflow that doesn’t scale on tokens, or API calls for a use case where one call is worth thousands of dollars and another is worth nothing), the credit model will keep failing no matter how it is priced. The metric needed to be: what is the customer actually accomplishing with the AI, and how do we count that? Instead, the discussion stayed at the wrapper level.
The pattern extends to the broader “how should AI be priced” question. Industry observers have increasingly anchored on internal cost and margin as the primary consideration in AI pricing — a classic cost-plus anti-pattern that the pricing discipline has spent decades moving clients away from. When the cost of providing a service is the starting point, the value metric becomes “the thing that tracks our cost” rather than “the thing that tracks customer value.” Those two are almost never the same. Prices that anchor to vendor cost drift quickly away from willingness-to-pay, usually in ways that compress margin as AI costs fall and leave customer value capture on the table. (This is the same pattern that shows up in traditional software when a team reaches for cost-plus thinking — see our longer treatment of value-based pricing for the broader anti-pattern.)
A correctly framed AI pricing question starts at the metric. What, specifically, is the customer getting more of as they use the AI? If it is decisions made, meetings saved, tickets resolved, documents reviewed, leads qualified — one of those might be the metric. Or the metric may sit outside any of them, in a unit specific to how that customer measures progress in their own work. The pricing model is a decision about how to package and bill against whatever the metric turns out to be. The value metric vs pricing model question is the one to answer; the model follows.
A more precise point matters here. Tokens are what your AI system consumes internally — they are input, not output. The customer is not paying to move tokens through your model; they are paying for what your system transforms those tokens into. Decisions made, meetings saved, tickets resolved, documents processed, leads qualified — often, within the same customer, several of these at once, interrelated. The art and the science of metric selection is capturing that multi-dimensional transformation in a single unit the customer and their finance team can both track and estimate. That is the hard part, and it is why companies hire an expert for this work. The transformation is not obvious from the inside, and the wrong translation of inputs into outputs produces the exact pricing misalignment the industry keeps trying to solve at the model level.
Should You Switch from Per-Seat to Credits?
LevelSetter models the revenue impact of changing your AI product’s value metric across your entire customer base before you make the switch.
Every metric carries its own sales-objection blueprint
The part of the metric work that usually gets skipped is the sales-objection rehearsal. Every metric carries its own distinctive objection pattern, and the sales team has to be ready for it. Pick pageviews and the first question every buyer asks is what happens if my estimate is wrong? — followed by a long conversation about caps, true-ups, and behavior on a surprise traffic spike. Pick a custom consumption unit and buckle up for a two-hour technical walkthrough on why you round up to the nearest hour on compute, and a follow-up on how that rounding behaves during batch processing. Pick monitored assets as the metric and the buyer wants to know exactly what counts as an asset, whether a shared sensor feeding two systems counts once or twice, and how decommissioning is handled mid-contract. Every metric implies an objection blueprint. Shipping the metric without rehearsing the blueprint means discovering it mid-deal, on a call with a skeptical CFO, with money on the line.
This is where the self-serve trap sharpens again. In a direct sales channel, those objections surface because somebody is in the room to ask them. In self-serve, the buyer has the same questions — and nobody is there to pose them or answer them. The buyer works through it alone (rarely), asks the internet (often), or quietly decides the pricing is too ambiguous to commit to (most commonly). You never see the objections. You never see the decisions that were made because of them. The metric work that enterprise teams are forced to do in the deal room is the same work self-serve teams have to do in advance — before the product ships — because there is no deal room later.
What getting it right looks like
Early in an engagement, a customer came to us asking how to choose a pricing model for a new product line. The executive team had done their homework: read the relevant articles, benchmarked against category leaders, built the internal case for usage-based pricing, committed to a rollout timeline. The question they brought to us was implementation — how to structure the rollout, what to price each unit at, how to communicate the shift to existing customers. The model decision, they believed, was already made.
Our first few sessions were not about rollout mechanics. They were about a single question: what is the actual unit of value your customers measure their own success by? The team answered confidently at first — “API calls, obviously” — and then less confidently as we worked through their sales data. The customers they won consistently, at the highest price points, were not high-API-volume customers. They were customers who prioritized the safe and efficient operation of the plant using the software’s monitoring features. The metric that correlated with willingness-to-pay was the one tied closely to the footprint of measurements being monitored by the product, not the volume of underlying API activity. The team was about to build a usage-based pricing system around a metric that had almost no correlation with value realization.
The rollout the team had been planning was paused and rebuilt around the correct metric. Six months later, net revenue retention had moved meaningfully, deal-size distributions tightened, and the company was not in the pricing-churn cycle their competitors were. They were iterating on packaging and price levels — the legitimate places to iterate — while the metric architecture held stable.
Then the architecture faced two stress tests. The first came roughly two years after our engagement, when the company retained a global pricing consultancy to re-validate the architecture as part of acquisition-preparation diligence. Fifteen-plus consultants on the engagement. A multi-month timeline. Seven-figure fees. The final recommendation was identical to ours — the same value metric, the same licensing structure, the same packaging approach. The executive team had expected the second opinion to meaningfully refine or materially challenge the original work. What they received was a line-for-line duplication. They were aghast at the spend, and said so.
The second stress test was the acquisition diligence itself. A strategic acquirer’s diligence team examines every pricing assumption a company has made — contract by contract, renewal by renewal, discount exception by discount exception. Pricing architecture built on a shaky metric does not survive that exam; it collapses into revisions and carve-outs the acquirer cites as risk. The right metric, chosen early, is what withstands it. The exit proceeded at a valuation north of $3B, on the pricing architecture we had originally built.
Nothing about that outcome required a novel pricing model. It required picking the right metric first, letting the model follow, and building architecture solid enough that a competitor consultancy could not improve it and an acquirer’s diligence team could not break it. That is what matters more than it used to. The rising tempo of pricing changes across B2B software does not eliminate the need for strategic pricing judgment — it raises the cost of getting the metric wrong and rewards companies that chose well early. Strategic pricing consulting focused on metric selection rather than model tactics is what sits behind architectures that hold up when the market forces you to keep changing everything else.
The structural take-away is simple: prices can change often. Packaging can change often. Value metrics should change rarely, and only when the underlying business reality has shifted. Teams that invert this — changing metrics with every quarterly experiment and leaving packaging untouched for years — are optimizing the wrong layer.
If your team is mid-debate on a pricing model, the question that will save you the most pain is not “which model?” It is “what is the metric underneath, and is it actually the unit of value our customers experience?” Metric-based pricing — pricing that starts at the value metric and lets the wrapper follow — is what works. If the answer to the second question is clear, the first one answers itself. If the answer is not clear, no amount of model-selection work will compensate.
Our approach starts at the metric — working from transaction data and customer context to identify the unit of value, then building the licensing, packaging, and pricing decisions around it. See how we work, or talk to our team about where your current pricing architecture is carrying risk.
