Hybrid: base + outcome

What this model actually means

The base + outcome hybrid has two distinct components that serve different purposes. The base fee is a recurring fixed charge, typically monthly or annual. It covers your infrastructure, availability, and the cost of keeping the product running regardless of how much work it does. The outcome fee is a variable charge that triggers when a defined result is produced: a task completed, a conversion achieved, a case resolved.

Together, they solve a problem that pure pay-per-result pricing creates at the enterprise end of the market. Procurement teams need a number to budget against. A fully variable invoice that might be $200 one month and $4,000 the next is hard to get approved in advance. The base fee translates the relationship into something that fits a purchase order. The outcome fee then adds transparency: every invoice tells the customer exactly how much value the product delivered above its fixed cost.

This is not a compromise. It is a deliberate structure that serves both parties better than either component would alone.

Why you land here

The Pricing Unit Picker routes you here when your product delivers verifiable outcomes but also has real infrastructure costs that cannot be absorbed into per-outcome economics. Or when your customer is a larger organization where budget approval requires a fixed-cost commitment, but you still want to demonstrate outcome alignment rather than charging a flat subscription that hides how well the product is working.

Products that fit this model well are ones where the platform has ongoing costs independent of task volume (model inference availability, data storage, support staffing) and where the task outcomes are measurable but arrive in bursts. Seasonal spikes in usage would swing a pure outcome invoice dramatically. The base fee smooths that for the customer's finance team while the outcome fee keeps the vendor honest about results.

What it is often confused with

The most common confusion is with base + usage pricing. Both are hybrids with a fixed floor and a variable top. The difference is what the variable component measures. Base + usage bills for consumption: API calls, tokens, data processed, compute minutes. Base + outcome bills for results: the thing that actually mattered to the customer, not the machinery behind it.

This distinction matters in two specific ways. First, it changes what bad performance costs the customer. In a base + usage model, a month where the AI ran a lot of requests but delivered poor results still generates a large usage bill. In a base + outcome model, failed or low-quality outputs simply do not trigger the variable fee. The customer is still paying the base, but the outcome component holds you accountable. Second, it changes what you optimize your product for. Usage billing incentivizes throughput. Outcome billing incentivizes success rate.

If you are not confident in your product's ability to deliver consistent, verifiable outcomes, the base + usage model is the more honest choice. It does not ask you to absorb the risk of failure into your variable economics.

The procurement problem this solves

Enterprise software sales have a structural challenge: the people who understand value are rarely the same people who approve the budget. An engineer or operations lead sees immediately that paying $1.50 per resolved ticket is cheap compared to $35 per human-handled ticket. But the CFO approving the purchase order needs a line item that says "Software: $X per month." Variable invoices require a different approval process and a different level of trust in the vendor.

The base fee bridges this gap. It gives finance a predictable recurring cost to put in the budget. It signals that the vendor has enough confidence in their product to commit to a baseline relationship rather than operating purely on transaction fees. And it creates the contract structure that allows legal and procurement to sign off efficiently.

Once the relationship is live, the outcome fee adds the transparency that the technical buyer was originally sold on. The monthly invoice shows exactly how many outcomes were produced and at what cost, making ROI calculations straightforward and renewal conversations data-rich.

Setting the base correctly

The base fee needs to be high enough to cover your fixed costs and low enough to feel like a commitment, not a price. This is harder to get right than it sounds.

If the base is too high, customers start treating it as the real cost and the outcome fee as a penalty. They resist usage rather than driving it, because every outcome fee reduces the apparent value of the subscription they already paid for. The mental accounting shifts from "I'm getting value" to "this is getting expensive."

If the base is too low, it becomes theater. A $29/month base on a product that generates $2,000/month in outcome fees does not actually solve the procurement problem. Finance will still treat the invoice as variable. You need the base to carry genuine weight as a cost center line item.

A useful calibration: the base should represent real infrastructure commitment, not a token gesture. If your product could not run without a meaningful fixed cost structure, price the base to recover that. If it could, ask whether the base is actually earning its place in the model or just creating complexity.

Risks and failure modes

Outcome definition disputes. Just as with pure pay-per-result pricing, the variable component requires a precise definition. Every ambiguity in what counts as a billable outcome will surface as a dispute, and disputes feel worse in a hybrid model because the customer is already paying a base fee and expecting clarity in return.

Base creep. When revenue is slow, the temptation is to raise the base rather than improve outcomes. This works once, maybe twice. After that, customers recognize what is happening and the base becomes a trust erosion mechanism rather than a procurement convenience.

Complexity cost. Two billing components require two explanations in sales conversations and two line items on every invoice. Keep both components simple enough that a non-technical buyer can explain the model to their CFO in one sentence: "We pay $X per month plus $Y per completed task."

What to do from here

Define the outcome before you price anything. The same discipline that pay-per-result pricing requires applies here, with the added constraint that you need to make the definition legible to procurement teams, not just technical buyers.

Then price the base against your actual fixed costs plus a margin that signals commitment. Price the outcome fee against the value of each result to the customer, discounted for the predictability the base already provides. The customer should feel like the base is fair access and the outcome fee is a reward structure they want to trigger as often as possible.

If your outcome is well-defined and your customer's procurement process is the main obstacle, this model removes that obstacle without hiding how the product performs. That is the core reason to use it.