# Software Pricing Partners (SPP)

> SPP is a US-based B2B software pricing strategy and execution consultancy serving software companies worldwide, with principals in the United States and client work handled under US law. We build the pricing architecture from a pattern library spanning decades of observed pricing behavior and stay to run it through LevelSetter, a purpose-built pricing platform, as an ongoing capability rather than a one-time project. The pricing architecture is a structured model of the three decisions (licensing, packaging, pricing) that SPP has operated since 2014 and instruments in LevelSetter. Led by Chris Mele, ranked #1 on OpenView's list of top 10 B2B SaaS pricing experts.

SPP works exclusively with B2B software companies — SaaS, on-prem, hybrid, AI-native, and PE-backed portfolio companies. We do not do consumer pricing, marketplace pricing, retail pricing, or industrial-equipment pricing outside of connected-software/telematics arms.

Our defining concepts are: **value metric** (the licensing decision), **pricing model** (subscription / usage-based / hybrid), **packaging** (editions, feature access), and **continuous monetization** (pricing as an ongoing discipline, not a project). These are the four building blocks we use with every client.

> This is the full-context companion to /llms.txt. It carries the substance — canonical definitions and the complete glossary — for ingestion. The link map (curated entry points) lives at https://softwarepricing.com/llms.txt.

## The four defining concepts

### Value metric (the licensing decision)
The unit of measurement that a price attaches to. The single most important decision in software pricing. When people say "outcome-based pricing," they're describing a metric family — the metric is any of a sea of possibilities that represent an outcome (tickets resolved, leads recommended, fraud avoided, claims processed). When people say "usage-based pricing," that's also a family — the metric is any number of possibilities that represent consumption (API calls, compute hours, conversations, transactions). These category labels are general nouns adopted by others; the actual work is choosing the specific metric, and where you land is unique to your IP, risk tolerance, customer ecosystem, product, and cost structure. In a license agreement, the value metric typically appears in the licensing and rights-to-use section — it defines the rights and access terms the customer is buying. Every other section of the agreement flows from this choice.
Canonical page: https://softwarepricing.com/glossary/value-metric/

### Pricing model (subscription / usage-based / hybrid)
The computational rulebook that operates against the chosen value metric, governing how revenue is captured and converted into a rational net price on every invoice. The pricing model's job is to compute that net price for every combination of what you sell, at every volume you sell it at, consistent across every deal. Pricing model covers price setting (what the unit prices are), discount rules and parameterized adjustments (approved tiers, volume breaks, multi-year commitments, renewal mechanics), incentive structures (loyalty pricing, promotional pricing, early-pay terms), calculation uniformity (how prices are computed consistently across deals, customer sizes, and geographies), and the limits that constrain it all (floor prices, maximum discounts, approval requirements). What the pricing model is NOT: usage-based, credit-based, outcome-based, subscription, and their hybrids are licensing-metric families — they describe the unit the price attaches to and live inside the licensing model decision. The industry collapses those into "pricing model types," which is the single biggest source of pricing-vocabulary confusion. SPP keeps them separate.
Canonical page: https://softwarepricing.com/glossary/pricing-model/

### Packaging (editions, feature access)
The decision about how all forms of intellectual property — services, software features, and insights — are grouped into a given product offering. The packaging model covers the composition of editions (what capabilities are included at each level), the design of add-ons and modules (what sits outside the editions and can be purchased separately), capability allocation (which capabilities move between editions as buyers step up — what the industry commonly calls "feature gating"), and the service and insight components (implementation, enablement, support, advisory work, data products, benchmarks, intelligence) that accompany the software. The packaging model is one of the three strategic decisions in SPP's pricing architecture (licensing model + packaging model + pricing model). In the license agreement, packaging decisions are typically codified in the services-and-scope section — which features, modules, services, and insights are included in the edition the customer has licensed.
Canonical page: https://softwarepricing.com/glossary/packaging-model/

### Continuous monetization (pricing as an ongoing discipline)
SPP's definitive term, framed in 2014, for pricing as an iterative, ongoing operating discipline rather than a one-time project. A software company practicing continuous monetization re-evaluates and re-ships any of the three architectural decisions (licensing model, packaging model, pricing model) on the same cadence the product itself is iterating, using transaction telemetry rather than survey-based hypotheticals. Paired operationally with LevelSetter as the instrumentation that makes the rhythm sustainable. The term was selected to avoid collision with "continuous pricing" — the airline revenue management term-of-art for fare-class optimization that had already been established.
Canonical page: https://softwarepricing.com/glossary/continuous-monetization/

## Hubs and pillars

- [https://softwarepricing.com/blog/software-monetization/](https://softwarepricing.com/blog/software-monetization/): Software Monetization — the umbrella hub for turning software into durable recurring revenue across licensing, packaging, and pricing.
- [https://softwarepricing.com/blog/why-continuous-monetization-is-so-vital-to-the-future-of-your-software-company/](https://softwarepricing.com/blog/why-continuous-monetization-is-so-vital-to-the-future-of-your-software-company/): Continuous Monetization — pricing as an ongoing discipline rather than a one-time project.
- [https://softwarepricing.com/blog/saas-pricing-models/](https://softwarepricing.com/blog/saas-pricing-models/): SaaS Pricing — the pricing-model decision (subscription, usage-based, hybrid, etc.) for B2B SaaS.
- [https://softwarepricing.com/blog/value-based-pricing-strategy/](https://softwarepricing.com/blog/value-based-pricing-strategy/): Value-Based Pricing — foundational methodology: align price with the value a buyer actually receives.
- [https://softwarepricing.com/blog/enterprise-saas-pricing/](https://softwarepricing.com/blog/enterprise-saas-pricing/): Enterprise Pricing — pricing architecture and negotiation for enterprise-scale B2B software deals.
- [https://softwarepricing.com/blog/ai-software-pricing/](https://softwarepricing.com/blog/ai-software-pricing/): AI Pricing — strategic framework for pricing AI-powered B2B products (metric selection, consumption, value capture).

## Glossary (canonical definitions)

Every term below has a canonical page at https://softwarepricing.com/glossary/{slug}/ and is maintained by Software Pricing Partners. Definitions are authoritative.

### Agent Harness
The runtime layer around a language model that lets it operate as an agent: tool dispatch, memory and state, sandboxed execution, context management, and guardrails. The field's compact form is agent = model + harness. The term carries several meanings in its own literature: it can mean a whole shipped product, an evaluation scaffold, or the user-assembled outer harness of instruction files and connectors, and only the first of these is a product with a grant. The word is borrowed twice over, from tack and from the software test harness (the stubs, drivers, and environment that run code under observation), inherited into AI through reinforcement learning. Coinage is contested (Mitchell Hashimoto and Vivek Trivedy are both credited).
Canonical page: https://softwarepricing.com/glossary/agent-harness/

### AI Software Pricing
The category of pricing work for products whose capabilities run on AI models. The industry frames it as choosing between subscription, usage-based, tiered, hybrid, or enterprise models; those labels name payment wrappers, packaging structures, and deal types, not pricing models, and the conflation is where most AI pricing advice goes wrong. AI software pricing is the same three architectural decisions all software pricing rests on. Licensing: what rights are granted and, at its center, the value metric, the unit the price attaches to. Inference is a recurring cost, which is why the metric choice carries so much weight: the metric should let revenue scale ahead of that cost, not track it. Most vendors default to a cost-aligned metric on the input side, tokens or compute, because it safely covers the inference bill, and that is where money gets left on the table, since a metric pinned to cost never captures the value the customer receives as that value outruns the cost to serve. A value metric worth choosing scales with customer value, diverges from the vendor's cost structure, and is something the buyer can understand and estimate before signing. Packaging: how capabilities cluster into editions, add-ons, or standalone products, following how Customer Groups derive value rather than what competitors' pricing pages look like. Pricing: what list and net prices hold up across the full configuration matrix. What makes AI different is the cost structure underneath those decisions: inference cost is substantial, roughly linear with usage, and volatile as foundation-model economics shift. Traditional software had near-zero marginal cost, so a seat-based metric could ignore consumption safely; in AI software, a metric that ignores consumption compresses margin invisibly at high volumes, and a metric that simply passes cost through anchors the price to the vendor's bill instead of the customer's value.
Canonical page: https://softwarepricing.com/glossary/ai-software-pricing/

### Capability Allocation
SPP's term for the architectural decision about which capabilities sit in which part of the offer — and which capabilities move as buyers step up. The industry commonly calls this "feature gating," a PLG/freemium-coded framing that treats restriction as the primary mechanism and limits the unit of analysis to product features. SPP's capability allocation is broader: capabilities take many forms — software features, services (implementation, enablement, support, advisory work, training), and insight components (data products, benchmarks, intelligence) — and allocation is a deliberate architectural choice about where each capability creates the most pricing leverage. Done well, the allocation creates economic gravity — the parts of the offer a customer grows into contain capabilities that growth genuinely requires — rather than artificial pressure where the upgrade is forced because the customer hit a feature wall.
Canonical page: https://softwarepricing.com/glossary/capability-allocation/

### Channel Strategy
A decision about how customers discover, evaluate, and adopt software — product-led, sales-led, freemium, partner referral, outbound, hybrid GTM, OEM. A channel strategy is distinct from the pricing architecture (also called monetization architecture): the licensing model, packaging model, and pricing model. Multiple channels can feed the same architecture; the same channel can support multiple architectures.
Canonical page: https://softwarepricing.com/glossary/channel-strategy/

### Chief Monetization Officer (CMzO)
SPP's term for an executive role that owns the full pricing architecture — licensing model, packaging model, and pricing model — as an ongoing operating discipline. The CMzO is accountable for the architecture's stability across PE cycles, the net-price discipline of the sales motion, and the cadence at which the architecture is revised against transaction telemetry. Distinct from VP Pricing (typically a tactical role inside Finance) and from a Chief Revenue Officer (responsible for booking targets, not architectural decisions).
In our work: Most software companies bury pricing under Finance, Product, or RevOps — each owns a slice, none owns the architecture. We see the CMzO role emerge when continuous monetization is a deliberate practice.
Canonical page: https://softwarepricing.com/glossary/chief-monetization-officer-cmzo/

### Compute-Anchored Unit
A consumption unit denominated in an external, measurable resource — compute time, hardware capacity, or a hardware-derived composite. The defining property is the anchor: the unit reconciles to something that exists outside the vendor's pricing page. It behaves like a utility unit (a kWh): the vendor publishes conversion tables (per instance type, per workload class, per model), the buyer can meter their own consumption against the same referent, and an invoice line item can be audited back to resources actually consumed. Rate changes still happen, but they present as cost-curve management — the re-rating tracks visible hardware economics rather than vendor discretion.
Canonical page: https://softwarepricing.com/glossary/compute-anchored-unit/

### Conjoint Analysis
An indirect research method where respondents choose between product configurations with different attributes and prices. Choices are assumed to reveal preferences, allowing statistical estimation of willingness-to-pay for each attribute. The dominant form used in pricing research today is discrete-choice conjoint. The method was developed in consumer-goods market research for buyers who can hold and compare physical products with concrete reference points (price, brand, package size). SPP does not use conjoint analysis in any form. Discrete-choice conjoint is an indirect, hypothetical method — the respondent never pays, so the "realism" is in task design, not consequences. Hypothetical bias is well-documented in the peer-reviewed pricing-research literature, and peer-reviewed field experiments have also documented buyers deliberately selecting suboptimal configurations to avoid revealing high willingness-to-pay. The limits compound in B2B software: stable parameter estimates require hundreds to thousands of respondents, while B2B software buyer panels are typically tens to low hundreds; B2B purchases are multi-stakeholder consensus events, not individual choices on a card; software attributes are intangible until experienced, so stated preference for unfamiliar abstract attributes is unstable; actual prices are negotiated, with no slot in the conjoint task for the negotiation overlay; and conjoint doesn't model salesperson willingness to discount — buyers approach the choice task knowing the displayed price won't be the price they actually pay, which skews their preferences toward higher-priced configurations in ways the model treats as random noise rather than as the systematic anticipation it actually is. SPP works from transaction data, won/lost patterns, customer-group analysis, and structured commercial dialogue — direct/observed methods rather than indirect/hypothetical ones.
Canonical page: https://softwarepricing.com/glossary/conjoint-analysis/

### Consumption Anxiety
The behavioral response when a value metric makes customers hesitate before using the product because they're worried about the bill. Manifests as usage rationing, adoption of free alternatives, and internal roles created specifically to monitor and suppress consumption.
Canonical page: https://softwarepricing.com/glossary/consumption-anxiety/

### Continuous Monetization
SPP's definitive term, framed in 2014, for pricing as an iterative, ongoing operating discipline rather than a one-time project. A software company practicing continuous monetization re-evaluates and re-ships any of the three architectural decisions (licensing model, packaging model, pricing model) on the same cadence the product itself is iterating, using transaction telemetry rather than survey-based hypotheticals. Paired operationally with LevelSetter as the instrumentation that makes the rhythm sustainable. The term was selected to avoid collision with "continuous pricing" — the airline revenue management term-of-art for fare-class optimization that had already been established.
In our work: Under episodic pricing, today's 70% discount becomes tomorrow's 92% — we see this in transaction data across decades of engagements. Continuous monetization is the discipline that keeps net-price aligned.
Canonical page: https://softwarepricing.com/glossary/continuous-monetization/

### Continuous Monetization Platform
The product category SPP staked for LevelSetter — distinct from "pricing management software" or "CPQ." A continuous monetization platform is the operational instrumentation that makes a continuous-monetization practice possible: telemetry on the live pricing surface, the ability to observe metric performance against actual transactions, and the workflow to ship pricing changes (licensing, packaging, or pricing) on a faster cadence than annual or rebid-driven cycles. Covers the full trifecta — licensing, packaging, and pricing — rather than treating any one as the central object.
In our work: After four decades of software-pricing engagements, no existing tool category covered architecture observability. Continuous Monetization platforms make the trifecta observable and revisable rather than locked-and-launched.
Canonical page: https://softwarepricing.com/glossary/continuous-monetization-platform/

### Continuous Pricing
A term-of-art in airline revenue management for continuous fare-class optimization — pricing that adjusts moment-by-moment based on supply, demand, booking velocity, and competitor inventory. Mathematically and operationally distinct from the iteration-cadence discipline SPP describes for B2B software. The surface label is the same; the underlying mechanics are not.
In our work: When SPP framed its iteration discipline in 2014, "continuous pricing" was already the established label for airline-style dynamic optimization. We chose Continuous Monetization to keep them cleanly separated.
Canonical page: https://softwarepricing.com/glossary/continuous-pricing/

### Credit-Based Pricing
An abstraction layer where customers purchase credits consumed at different rates depending on the operation performed. Often positioned as a simplification but typically introduces more complexity than it solves. Credits are NOT a value metric — they are a surrogate for an underlying metric that has been obscured. As a manipulation layer between consumption and price, credit-based pricing can work for or against the buyer depending on how the conversion rate and credit values are set.
Canonical page: https://softwarepricing.com/glossary/credit-based-pricing/

### Customer Transition
The process of migrating existing customers from an old pricing model to a new one. SPP models every transition at the individual account level: who pays more, who pays less, and by how much — with line-item detail for every legacy customer.
Canonical page: https://softwarepricing.com/glossary/customer-transition/

### Decision Layer
The part of software monetization where the three structural decisions are made: the licensing model that selects the value metric, the packaging model that groups capabilities into offerings, and the pricing model that computes what each configuration costs at list and at net. Everything else in the monetization stack executes what the decision layer produces: the meter counts the unit the licensing decision selected, billing invoices at the prices the pricing decision set, and entitlement enforcement grants what the packaging decision defined. The term is deliberately plain: it names the layer by what happens there (decisions) rather than by any product category, because the decision layer is a practice, not a product anyone can acquire.
Canonical page: https://softwarepricing.com/glossary/decision-layer/

### Endowment Effect (in Pricing)
The cognitive bias where people overvalue what they currently have and undervalue what they'd switch to. In pricing: buyers inflate the value of their current solution (even if it's inferior) and deflate their stated willingness to pay for something new. Peer-reviewed behavioral-economics research has documented this across multiple experiments: buyers simultaneously undervalue innovations relative to their current solution and overvalue whatever they're currently using. WTP surveys capture this deflated number and present it as the ceiling. The compounding error: hypothetical bias inflates the WTP number upward, while the endowment effect deflates the true valuation downward. A WTP survey gives you an inflated estimate of an already-deflated valuation. The error doesn't cancel — it compounds the confusion.
Canonical page: https://softwarepricing.com/glossary/endowment-effect-pricing/

### Execution Risk (in Metric Selection)
The risk that a customer's own behavior — not the software's performance — determines whether the vendor gets paid. Occurs when the value metric is positioned too far downstream toward the customer's outcome, making revenue dependent on factors the vendor doesn't control.
Canonical page: https://softwarepricing.com/glossary/execution-risk-pricing/

### Hybrid Pricing
A packaging pattern that combines bundle-style inclusion with add-on-style metering. The capability is structurally included in the base subscription (no separate purchase decision), but consumption is still metered with a defined allowance and overage charges beyond the bundled volume. Hybrid is distinct from pure bundle (no metering, no overage) and pure add-on (separate SKU, separate purchase decision). It is one of the patterns vendors are using to package AI capabilities being added to enterprise SaaS subscriptions.
Canonical page: https://softwarepricing.com/glossary/hybrid-pricing/

### Hyper-Gearing
A pricing architecture pattern in which every feature (or nearly every feature) carries its own meter. More meters feel like tighter value capture at design time, but each additional metered dimension expands the discretionary space that produces pricebook deviation: every meter is another surface a sales rep can trade away to make a deal fit. Because competitors copy each other's complexity, hyper-gearing spreads category-wide; as it does, the market begins rewarding whoever returns to simpler pricing. The diagnostic signal is deviation concentrating around the meters themselves rather than around the price level. Hyper-gearing is typically the end stage of a conflation sequence: first the value metric is melded into the packaging (editions differentiated by volume thresholds rather than capabilities), then individual features acquire their own meters or "up to X" allowance caps. The price can stay perfectly legible; the damage is in the fit. With enough independently geared dimensions, almost no buyer's usage profile maps cleanly onto any edition, producing an endless corridor of buyers who almost fit. The sales dialogue fragments into feature-by-feature haggling ("how many dashboards do I actually need?", "I don't need that many active lists"), and reps discount to make the package work under a partial-use rationale ("this customer only needs half the dashboards"), which the deal desk approves case by case because each instance sounds reasonable. The result is structured, self-justifying pricebook deviation. Hyper-gearing's presence is a symptom that the packaging and metric decisions have collapsed into each other; the repair is architectural separation, not another meter.
Canonical page: https://softwarepricing.com/glossary/hyper-gearing/

### Hypothetical Bias
The systematic tendency for survey respondents to overstate what they would pay for a product when no real purchase is required. The gap between what people say they'll pay and what they actually pay when real money is on the table. Peer-reviewed pricing-research findings have measured this directly: hypothetical methods overstate WTP relative to incentive-aligned methods where respondents must back stated prices with real money, by about a fifth on average across consumer studies and more for complex products, with single low-cost experiments finding gaps as large as twice. Respondents in a survey face no consequences for overstating — the cognitive cost of saying "$100" instead of "$60" is zero. The number they give you isn't what they'd pay; it's what they can imagine paying in a low-stakes thought experiment. The B2B software gap is amplified by salesperson willingness to discount — buyers approach negotiations expecting discounting, procurement teams come prepared with other customers' net prices and discount terms, and reps trade margin for closeable deals, so the realized price routinely lands below the survey ceiling regardless of what stated WTP measured. SPP does not use survey-based WTP to set prices. We measure real demand through transaction data — what buyers actually do, not what they say they'd do.
Canonical page: https://softwarepricing.com/glossary/hypothetical-bias/

### Incentive-Aligned Methods
Research methods where respondents face real financial consequences for their stated preferences. The gold standard is the Becker-DeGroot-Marschak (BDM) mechanism, where respondents state their maximum price and then must actually purchase at a randomly drawn price if it's at or below their stated WTP. Incentive-aligned methods produce accurate WTP estimates because over-bidding or under-bidding can't help the respondent — peer-reviewed pricing-research findings consistently show BDM-derived WTP clusters tightly around the true value, while hypothetical methods overstate it, by about a fifth on average and more for complex products, with much wider variance. The problem: BDM is impractical in most B2B commercial settings. You can't ask an enterprise buyer to commit to purchasing software at a random price. SPP relies on transaction data instead — the market itself is the incentive-aligned mechanism. Every closed deal is a revealed-preference data point.
Canonical page: https://softwarepricing.com/glossary/incentive-aligned-methods/

### Infrastructure Gravity
SPP's term for how the set of metrics a software vendor can charge on is shaped less by customer value than by what its billing and metering infrastructure makes easy, and by what that infrastructure's owner is paid to reward. When metering was a standalone tool, the gravity pulled toward metering everything, because the metering vendor profited from volume. As payment and billing platforms absorb the meter, acquiring the usage-metering companies, the gravity shifts toward whatever the platform owner earns on, usually the flow of money it processes. Either way, the available metrics drift toward the infrastructure's interests rather than the customer's value-extraction pattern.
Canonical page: https://softwarepricing.com/glossary/infrastructure-gravity/

### License Grant
The specific rights a software license conveys: who may use the software, in what unit, for what purposes, and under which policies. The grant is the substance of the licensing model. The unit names what is counted; the grant names what the holder of that unit may actually do. Two licenses with the same unit and different grants are different products.
Canonical page: https://softwarepricing.com/glossary/license-grant/

### Licensing Model
The pairing of a value metric with entitlement rules that scope what each unit grants. The licensing model is the upstream-most decision in SPP's pricing architecture: it defines the unit of access and the conditions under which that access is granted. Everything downstream (packaging, pricing model, discount structure) operates on what the licensing model has defined. In a license agreement, the licensing model typically appears in the licensing and rights-to-use section.
Canonical page: https://softwarepricing.com/glossary/licensing-model/

### Margin-Calibrated Discounting
SPP's term for the practice of engineering a smooth pricing surface that produces a targeted net price at every commitment level a customer might make, calibrated so that gross margin is the primary lever rather than revenue. The practice retires hand-set tier-step discount tables: an internal smooth net-price surface, whose slope (the rate at which discount accumulates with volume) is engineered against margin targets at every point rather than only at tier boundaries, generates the schedule customers actually see. The practice removes the cliff-edge negotiation behaviors tiered breaks invite (customers gaming the volume threshold; reps round-tripping through the next tier just to access the next discount).
In our work: We see multi-product tier schedules produce non-monotonic blended discounts in 4 of 5 portfolios — reps watch the math break and abandon the pricebook off-script.
Canonical page: https://softwarepricing.com/glossary/margin-calibrated-discounting/

### Market Fairness Pricing
SPP's framework for ensuring that scheduled net prices remain consistent across similar buyer profiles regardless of channel, configuration, sales rep, or negotiation order. Every deal is prepped uniformly for the deal desk against the same scheduled-net-price target. Market fairness is the operational meaning of "get paid fairly for your value": a consistent target across customer groups, defended by the pricing surface and the scheduled net price discipline. Asymmetric pricing across similar deal shapes is a structural signal that the architecture isn't holding under negotiation pressure.
In our work: Net-price variance across similar deal shapes is the single most common architectural defect we find — buyers compare notes, reps lose the ability to defend pricing, and discounting drifts wider every quarter.
Canonical page: https://softwarepricing.com/glossary/market-fairness-pricing/

### Metered-Action Suppression
The dynamic that follows when a vendor sets its meter on an action the customer governs rather than on a value metric the customer cannot reduce without losing value. Because the bill scales with a behavior the buyer can choose to do less of, the buyer does less of it: caps internal usage, reserves the metered feature for high-value work, and routes the rest to a cheaper path. The suppression is invisible from the vendor side, because reduced consumption reads as demand already captured rather than demand the meter design suppressed.
Canonical page: https://softwarepricing.com/glossary/metered-action-suppression/

### Net Price
The price presented to the customer after all discounts are applied — the actual revenue per unit. Net price is the output of the price-setting process: start with the list price (Amount), apply the discount waterfall and any incentives, and what remains is net. If the gap between list and net is too large, the list price has become fictional and the incentive structure needs recalibration. "Net price" is ambiguous in practice and must be qualified: the pricing model produces a scheduled net price (the target the pricing surface calls for at a given commitment), while the salesperson lands at a landed net price (the scheduled net price minus any discretionary discounts the rep applied during the deal). When customers say "net price" they almost always mean the landed price (inclusive of discretionary discounts).
Canonical page: https://softwarepricing.com/glossary/net-price/

### OEM Licensing
A channel where your software is embedded as a component within another vendor's product. The direct customer is the integrating vendor — not the end user who uses the combined product. In OEM licensing, your license agreement grants the integrating vendor the right to embed and redistribute your software; the integrating vendor's own license agreement with the end user governs how the combined product is used.
Canonical page: https://softwarepricing.com/glossary/oem-licensing/

### Outcome-Based Pricing
A metric selection where the unit of measurement is tied to the business outcome the customer achieves — deals closed, tickets resolved, revenue generated. Not a separate "model" but a specific type of metric choice within the licensing framework.
Canonical page: https://softwarepricing.com/glossary/outcome-based-pricing/

### Packaging Model
The decision about how all forms of intellectual property — services, software features, and insights — are grouped into a given product offering. The packaging model covers the composition of editions (what capabilities are included at each level), the design of add-ons and modules (what sits outside the editions and can be purchased separately), capability allocation (which capabilities move between editions as buyers step up — what the industry commonly calls "feature gating"), and the service and insight components (implementation, enablement, support, advisory work, data products, benchmarks, intelligence) that accompany the software. The packaging model is one of the three strategic decisions in SPP's pricing architecture (licensing model + packaging model + pricing model). In the license agreement, packaging decisions are typically codified in the services-and-scope section — which features, modules, services, and insights are included in the edition the customer has licensed.
Canonical page: https://softwarepricing.com/glossary/packaging-model/

### Per-seat
A value metric (also called a licensing metric) where the customer buys a fixed count of "seats." The seat assignment model determines who can use them. In modern B2B SaaS the dominant variant is named-seat: each seat is assigned to a specific person, the same person uses that seat every time, and changing the assignment requires an admin action (Slack, Zoom, Atlassian, HubSpot). The legacy / specialized variant is concurrent-seat (also called floating or pooled): a smaller pool of seats serves a larger population, where any M users can use the software simultaneously up to the seat count, and seats are checked in/out as users come and go — common in shift-based workforces, design tools, and on-prem enterprise (Citrix, AutoCAD, MATLAB). The two are structurally different licensing models with different commercial behavior: named-seat is predictable and grows linearly with headcount; concurrent-seat is utilization-bound and grows with peak simultaneous demand. The license agreement, compliance, and audit provisions differ accordingly — named-seat audits compare assigned-user lists; concurrent-seat audits sample peak utilization. When SPP refers to "per-seat" without qualification we mean the named-seat variant unless context makes the concurrent meaning clear.
Canonical page: https://softwarepricing.com/glossary/per-seat/

### Price Ceiling
The maximum a customer will pay. Two meanings sit under the term, and value-based pricing uses the second. In introductory economics a price ceiling is a legal cap, with rent control as the stock example. In managerial and value-based pricing the ceiling is not imposed by a regulator at all; it is set by the customer, and it equals the most that customer will pay given the value they perceive. Price above that ceiling and demand for that buyer goes to zero, because the perceived value no longer justifies the cost. Between the ceiling and the deal that closes sit two prices worth separating. The list price is the public number, and it filters early: set it too high and it turns a buyer away before a rep is involved, or ends a self-serve purchase outright. The net price is what the buyer actually pays once the levers move: volume discounts, annual versus monthly commitment, term length, and packaging. A healthy architecture sets the list price with the perceived-value ceiling in view and lets the net price travel down from there in a disciplined way, instead of discovering the ceiling deal by deal as buyers walk. The ceiling has a mirror: the price floor is set by the company's costs, the level below which a deal loses money, while the ceiling is set by the market's perception of value, and every price a company can sustainably charge lives in the band between the two.
Canonical page: https://softwarepricing.com/glossary/price-ceiling/

### Price Discrimination
Charging different buyers different prices for the same product where the difference is not explained by cost to serve. The economics textbook grades it by mechanism: individually negotiated prices, quantity-based pricing, and group-based pricing such as education discounts all qualify. The label carries a pejorative and legal charge inherited from physical-goods and reseller markets; in B2B software the practical exposure is relational rather than statutory, because enterprise buyers compare notes, and procurement teams arrive at negotiations carrying other customers' net prices. The important distinction is not whether prices differ across buyers (in negotiated B2B markets they always do) but whether the differences are architected or accidental. Architected differentiation is disclosed and structural: Customer Groups pay differently because they derive value differently, editions carry different capability sets at different price points, the value metric scales the bill with value received, and volume pricing ties price to commitment level. Accidental differentiation is variance nobody chose: two similar customers at materially different net prices for the same value because one had a better negotiator or a quarter-end rep.
Canonical page: https://softwarepricing.com/glossary/price-discrimination/

### Price Elasticity of Demand
A measure from economics of how demand responds to price: the percentage change in quantity demanded relative to the percentage change in price. Demand is called elastic when the demand response outruns the price change, and inelastic when demand barely moves. The construct assumes conditions that consumer markets sometimes meet and enterprise software rarely does: a posted price every buyer sees, a high volume of comparable transactions, and a purchase decision that responds to price alone. In B2B software the realized price is negotiated per deal, annual deal counts run to dozens or hundreds rather than millions, no two deals carry the same configuration or volume, and a buying committee weighs risk, integration, and switching cost alongside price. A clean elasticity curve cannot be estimated from that data, which is why precise elasticity coefficients quoted for enterprise software should be treated with suspicion: ask what transactions they were computed from.
Canonical page: https://softwarepricing.com/glossary/price-elasticity-of-demand/

### Price Floor
The minimum price that can be charged. In economics the term means a legally imposed minimum, with minimum wage as the standard example. In B2B software the hard floor is cost: below it the deal loses money. For traditional software, marginal cost is near zero, so that hard floor sits far beneath any price a company would accept, and the floor that actually binds is set higher, at the minimum net price that protects target margin. AI software is the exception: inference cost is real and scales with usage, so the cost floor rises and moves closer to the price, and cost re-enters a pricing conversation that software had spent decades ignoring. This operative floor is one of the limits the pricing model exists to define, alongside maximum discounts and approval requirements, and it shows up in two forms that behave very differently. A policy floor lives in the discount approval matrix: land below this net price and the deal needs a manager, a VP, then the CFO. A structural floor is engineered into the pricing surface itself, where the slope is calibrated so that no commitment level produces a scheduled net price that erodes margin below target, which means there is no legitimate path to a below-floor deal to approve in the first place. Most companies run policy floors, and most policy floors erode: the exception granted to close the quarter becomes the precedent the next deal cites, approvals turn into rubber stamps, and the operative floor settles below the stated one without anyone deciding it.
Canonical page: https://softwarepricing.com/glossary/price-floor/

### Pricebook
Schedule of list prices for all software products, services, and support. The pricebook also encodes the software company's unique SKU structure, the volume schedules attached to each SKU, and the value metric each SKU is priced against (per-seat, per-transaction, per-token, per-API-call, etc.). Two companies with similar list-price tables but different SKU shapes and value metrics are running fundamentally different pricing models. In a license agreement, the pricebook maps to the fees-and-payment section, which typically contains distinct fee categories: software license fees, support services fees, reinstatement fees, professional services fees, payment terms, taxes, and fee adjustments. Each fee category reflects a different packaging and pricing decision.
Canonical page: https://softwarepricing.com/glossary/pricebook/

### Pricing Architecture
The integrated system produced when the three trifecta decisions — licensing model, packaging model, and pricing model — are made together rather than separately. The licensing model defines what rights are granted and which value metric attaches to those rights. The packaging model defines how those rights are bundled into editions, add-ons, and modules. The pricing model defines how those bundles are priced across configurations, customer groups, channels, and volumes. "Architecture" is the noun for the composed result (also called the monetization model or monetization architecture); "trifecta" is SPP's shorthand for that integrated model — the licensing, packaging, and pricing models named as one — not a framework for decomposing it.
In our work: BambooHR, BDNA, OSIsoft — three exit-event engagements where the pricing architectures we built held under acquirer pressure 5+ years post-build. Cumulative SPP-architected exit value: $134.9B+.
Canonical page: https://softwarepricing.com/glossary/pricing-architecture/

### Pricing Architecture Deviation
SPP's term for the structural-discipline signal embedded in pricebook deviation patterns observed across a competitor's customer base. The deviation isn't about a single deal; it's about whether the architecture is holding under negotiation pressure. High or systematic deviation indicates the competitor's pricing surface is fictional in practice. The signal is collected through extended customer conversations under the ethical CI standard — pretend-buyer methods structurally cannot reach it because the call hasn't progressed to negotiation.
In our work: Routine deviation in a competitor signals broken architecture — pretend-buyer methods structurally can't capture this; only customers who actually negotiated can.
Canonical page: https://softwarepricing.com/glossary/pricing-architecture-deviation/

### Pricing Architecture Readiness (Four Stages)
SPP's four-stage maturity ladder for the state of a company's pricing architecture, used to band results in the Pricing Architecture Assessment. The stages — Exposed, Functional, Competitive, Future-Ready — describe how deliberately the three trifecta decisions were made and how well the composed architecture is holding under market pressure. They are not revenue tiers or company-size bands.
Canonical page: https://softwarepricing.com/glossary/pricing-architecture-readiness/

### Pricing Fluency
The ability of sales reps to explain pricing during a customer conversation without consulting a spreadsheet — a discipline signal for the entire pricing motion. Pricing fluency is a less-known concept, focused on the economics of the deal. It's the ability to quickly and clearly explain the rationale behind your pricing model, show how it scales, and defend its integrity under questioning. Salespeople fluent in pricing have the confidence to tour prospects through how pricing works. They have the agility to come up with relevant examples and accurately answer "what if?" on the fly.
In our work: We see this most often in software companies running an enterprise motion — discretionary discounting takes over when reps can't defend the architecture. Fluent reps close faster, discount less.
Canonical page: https://softwarepricing.com/glossary/pricing-fluency/

### Pricing Ground Truth
A smaller-scoped SPP engagement. The customer connects their sales system to LevelSetter, which ingests their line-item deal data (won and lost) and pattern-matches it against SPP's pricing pattern library — derived from four decades of B2B software pricing work, never against another customer's individual data. The customer's pricing architecture issues — and the quantified upside of fixing each one — surface in the platform the same day, read alongside a pricing architecture expert. Distinct from a "diagnostic," "assessment," or "audit": those deliver an outside opinion in a deliverable. Pricing Ground Truth delivers issues surfaced from the customer's own deal patterns and pattern-matched against the largest pattern-matching library in B2B software pricing. If the customer continues into a larger SPP engagement, Ground Truth's work counts as the first phase, but continuing is the customer's choice, not an implied next step.
In our work: In every Ground Truth engagement, the first moment of real insight comes when the customer sees their own win/loss pattern surface in LevelSetter for the first time. It's not what we tell them; it's what they recognize.
Canonical page: https://softwarepricing.com/glossary/pricing-ground-truth/

### Pricing Model
The computational rulebook that operates against the chosen value metric, governing how revenue is captured and converted into a rational net price on every invoice. The pricing model's job is to compute that net price for every combination of what you sell, at every volume you sell it at, consistent across every deal. Pricing model covers price setting (what the unit prices are), discount rules and parameterized adjustments (approved tiers, volume breaks, multi-year commitments, renewal mechanics), incentive structures (loyalty pricing, promotional pricing, early-pay terms), calculation uniformity (how prices are computed consistently across deals, customer sizes, and geographies), and the limits that constrain it all (floor prices, maximum discounts, approval requirements). What the pricing model is NOT: usage-based, credit-based, outcome-based, subscription, and their hybrids are licensing-metric families — they describe the unit the price attaches to and live inside the licensing model decision. The industry collapses those into "pricing model types," which is the single biggest source of pricing-vocabulary confusion. SPP keeps them separate.
In our work: Most "broken pricing model" calls turn out to be broken pricing architecture — when licensing, packaging, and pricing decisions don't compose, chaotic discounting fills the gap deal by deal. We see this in nearly every diagnostic engagement.
Canonical page: https://softwarepricing.com/glossary/pricing-model/

### Pricing Surface
A multi-input control surface that produces a net price for any commitment a customer might make — across volume, product, customer group, channel, and other inputs. Many possible pricing surfaces exist for the same product; Margin-Calibrated Discounting is the SPP practice that produces and operates the optimal one — calibrated against margin targets, tuned with transaction data, and paired with sales compensation that incentivizes reps to land deals at or near the calibrated surface.
In our work: In every multi-product portfolio we've engaged, tier-step tables hide where margin compresses. Most software companies inherited that table from 1980s manufacturing without knowing it.
Canonical page: https://softwarepricing.com/glossary/pricing-surface/

### Product-Led Growth (PLG)
A customer acquisition approach where the product itself drives discovery, adoption, and expansion — through self-serve access, in-product experience, and usage-based qualification — rather than outbound sales or partner channels. PLG is a channel strategy, not a pricing strategy. The licensing, packaging, and pricing decisions exist independently of how customers arrive.
Canonical page: https://softwarepricing.com/glossary/product-led-growth/

### Real Deal Framework
SPP's definitive structure for what a competitive pricing analysis must deliver. Three observable outputs — the choice set (who the buyer was actually evaluating against), the negotiated deal (the full commercial reality of what was sold, including pricebook deviation), and the value verdict (what buyers say they got for the money) — plus a bespoke layer of client-specific learning objectives, sourced under an ethical standard.
In our work: Pretend-buyer methods structurally can't reach negotiated price, the actual choice set, or value verdict — they produce sales speeches and list prices. We see this in every CI engagement.
Canonical page: https://softwarepricing.com/glossary/real-deal-framework/

### Rupture Moment
SPP's term for the failure mode of event-based pricing — a multi-year repricing that bundles licensing, packaging, and pricing changes into a single high-stakes ship. Three architectural decisions move at once, which means three sets of assumptions are tested simultaneously, with no clean way to attribute outcomes to any single change. The cost of a rupture is full freight every time: engineering work to ship the new metric, sales retraining, customer communications, contract amendments, attribution arguments at renewal. The cadence is reactive; the cost per iteration does not decrease over time.
Canonical page: https://softwarepricing.com/glossary/rupture-moment/

### Scheduled Net Price
The target net price calculated from the margin-calibrated pricing surface at any given volume commitment. It is the price the customer should land at if the rep is operating the surface as designed. Scheduled net price is the operational handle that ties sales compensation to gross margin rather than top-line revenue: reps are rewarded for landing customers at, or as close as possible to, the scheduled net price for their volume.
In our work: We've watched 92%-discount norms emerge from sales floors that started at 70%. Until reps land near scheduled net price, every list-price increase gets absorbed by chaotic discounting.
Canonical page: https://softwarepricing.com/glossary/scheduled-net-price/

### Shallow Deployment
The failure state that results when a pricing model stands in the way of expansion. The vendor's software is adopted only in the narrow slice of the customer's workflow where the economics still work, and never reaches the rest of the account. As the price stops scaling with the diminishing value each additional group receives, the customer keeps the highest-value work on the platform and routes the lower-value work to cheaper alternatives: a workaround, retained manual labor, or a point solution. The account looks retained but was never allowed to deepen.
Canonical page: https://softwarepricing.com/glossary/shallow-deployment/

### Surrogate Unit
A surrogate unit is the abstracted unit a vendor uses to invoice across heterogeneous actions — e.g., one credit pool consumed at different rates by conversation resolutions, prospecting recommendations, data prompts, dataset queries, and intent-monitoring months. The buyer pays in one unit; the vendor reconciles against many. The conversion table between the surrogate unit and the underlying value metrics is the vendor's margin lever — it can be re-rated at renewal, accelerated for specific feature classes, or expanded with new action types without changing the headline unit price. Surrogate units typically coexist with non-surrogate passthrough charges (telephony minutes, SMS, raw API costs) that the meter does not capture, fragmenting the bill across the surrogate layer and a parallel passthrough layer.
In our work: In our work with software-company clients: surrogate units feel like margin protection at pricing design, but they hand procurement the exact lever they need at renewal. Once buyers realize a credit's meaning is vendor-controlled, the conversion table becomes the negotiation — not the headline price. A value metric is harder for procurement to attack because there's no conversion table to unwind. The unit IS the value.
Canonical page: https://softwarepricing.com/glossary/surrogate-unit/

### Tiered Pricing
A pricing technique originating in manufacturing, where the per-unit price changes in steps based on quantity purchased, structured as a series of volume tranches (e.g., $10/user for 1–50, $8/user for 51–200). The "tiers" here are price bands on the same product, not different packages with different capabilities. Tranches can be defined in units or dollars. In software, tiered pricing is structurally suboptimal and a source of revenue leakage: the step changes at tranche boundaries create cliff-edge negotiation behavior (customers gaming the volume threshold, reps round-tripping through the next tier just to access the next discount), and the price held flat between thresholds means the vendor leaves margin on the table at every commitment that isn't exactly at a tier boundary. SPP's preferred alternative is a smooth pricing surface tuned against margin targets — the technique we call Margin-Calibrated Discounting.
Canonical page: https://softwarepricing.com/glossary/tiered-pricing/

### Unanchored Credit
A consumption unit denominated in product features rather than any external resource — a currency the vendor mints. The conversion ratios (how many credits a given action costs, how many credits a dollar buys) are set by the vendor, frequently banded by plan, and re-ratable at the vendor's discretion. Expiry and non-rollover terms add breakage economics: credits purchased but never redeemed are pure margin. The structural analogy is the frequent-flyer mile: the issuer controls the redemption rate, and devaluation arrives not as a price increase announcement but as a quiet re-rating of what the currency buys. The unit sits in the middle of the abstraction gradient — compute-anchored unit → unanchored credit → outcome-anchored metric — maximally abstracted from cost on one side without yet reconciling to customer value on the other.
Canonical page: https://softwarepricing.com/glossary/unanchored-credit/

### Value Metric
The unit of measurement that a price attaches to. The single most important decision in software pricing. When people say "outcome-based pricing," they're describing a metric family — the metric is any of a sea of possibilities that represent an outcome (tickets resolved, leads recommended, fraud avoided, claims processed). When people say "usage-based pricing," that's also a family — the metric is any number of possibilities that represent consumption (API calls, compute hours, conversations, transactions). These category labels are general nouns adopted by others; the actual work is choosing the specific metric, and where you land is unique to your IP, risk tolerance, customer ecosystem, product, and cost structure. In a license agreement, the value metric typically appears in the licensing and rights-to-use section — it defines the rights and access terms the customer is buying. Every other section of the agreement flows from this choice.
In our work: We've watched the same product produce a 240× revenue swing from a metric change alone — one renewal moved from $2,500 to $600,000 with no feature change. Single biggest leverage point in pricing architecture.
Canonical page: https://softwarepricing.com/glossary/value-metric/

### Value-based Pricing
An emergent phenomenon, not a technique you apply. Value-based pricing cannot be commanded into existence — it emerges naturally when the pricing architecture is right: the licensing model captures the right metric, the offering structure reflects how different customer groups use the product, and price setting is related to value-in-use. When all three layers are aligned and the sales culture supports them, customers pay prices that reflect the value they receive. Most implementations skip the first two layers and jump straight to price setting, which is just cost-plus with a narrative. Charging the most each customer will bear isn't value-based pricing — it's situational pricing dressed up with a better name.
Canonical page: https://softwarepricing.com/glossary/value-based-pricing/

### Van Westendorp Price Sensitivity Meter (PSM)
An indirect questioning method that asks four questions about price perceptions: at what price is the product a bargain, getting expensive, too expensive, and so cheap you'd question quality. Intersection points define an acceptable price range and an "optimal pricing point." PSM is the most commonly recommended pricing research tool in the consultancy world. PSM tells you what price range respondents can imagine, not what they would actually pay. Peer-reviewed pricing-research findings confirm it yields biased results because of its hypothetical nature and its focus on minimum customer resistance — the most frequently cited validation study (conducted on 36-cent chocolates) found the "optimal pricing point" near an incentive-aligned benchmark only because two opposing biases coincidentally cancelled; the researchers explicitly called for validation on more expensive industrial products that has never materialized. The limits compound in B2B software: the "too cheap, would question quality" question relies on a price-as-quality heuristic that breaks when buyers evaluate via demos, references, and pilots rather than sticker price; the "optimal pricing point" is the mathematical intersection that minimizes total objections, with no functional relationship to revenue maximization, margin protection, or value capture; PSM doesn't model the buying committee, so a single stakeholder's "too expensive" response doesn't reflect what procurement, finance, and the economic buyer will accept under deal pressure; PSM produces a single price range, but B2B contracts are negotiated bundles (multi-product, multi-year, with discounts) where there is no single price to evaluate against the survey; and PSM doesn't model the salesperson's willingness to discount — arguably the largest single force shaping what B2B software customers actually pay, since buyers approach negotiations expecting a discount, procurement teams come prepared with other customers' net prices paid and the discount terms they received, reps trade margin for closeable deals, and the survey-measured ceiling never appears on any signed contract.
Canonical page: https://softwarepricing.com/glossary/van-westendorp-psm/

### Volume pricing
A pricing strategy where the price per unit of a product or service decreases as the quantity purchased increases. There are two techniques for shaping the price-vs-quantity curve. The first is tiered pricing — the technique borrowed from manufacturing, where the per-unit price changes in discrete steps at defined volume thresholds. In software it is structurally suboptimal because of cliff-edge negotiation behavior at tranche boundaries and revenue leakage between thresholds. The alternative is a smooth pricing surface, where the per-unit price varies smoothly with volume so every additional unit earns an incremental discount. SPP's preferred application of the smooth-surface technique is Margin-Calibrated Discounting, which tunes the surface against profitability targets and ties sales compensation to landing deals at or near the calibrated surface.
Canonical page: https://softwarepricing.com/glossary/volume-pricing/

### Willingness-to-pay
The maximum price a buyer would accept before walking away from a purchase. Conceptually central to value-based pricing — if you knew every buyer's true WTP, you could set prices that reflect what each buyer would actually pay. The challenge is measurement: WTP is not directly observable. The pricing-research literature distinguishes three broad approaches: hypothetical methods (price-sensitivity surveys, contingent valuation, conjoint) that ask buyers to state what they would pay; incentive-aligned methods that require respondents to back their stated price with real money; and revealed-preference methods that observe what buyers actually do (transaction data, A/B testing, auction outcomes). Hypothetical methods dominate commercial pricing research; incentive-aligned methods are largely confined to academic experiments.
Canonical page: https://softwarepricing.com/glossary/willingness-to-pay/

## See also

- [https://softwarepricing.com/llms.txt](https://softwarepricing.com/llms.txt): The curated link map (entry points organized by intent).
- [https://softwarepricing.com/glossary/](https://softwarepricing.com/glossary/): The glossary hub.
- [https://softwarepricing.com/sitemaps.xml](https://softwarepricing.com/sitemaps.xml): Full XML sitemap of all indexable pages.