Pricing Challenges and Outcome Pricing

Imagine two software products that are both sold to the same company. The first charges a fixed fee for each employee who logs in. The second charges only when it closes a sale on the customer's behalf. Both are software, yet they are priced on completely different foundations. Why would one vendor charge for access while another charges for a finished result?

This article answers that question. The short answer comes from a two-by-two view of pricing. Every pricing model can be located by asking two questions: how much of the outcome can be credited to the product, and how much autonomy the software has in producing that outcome. The pricing model is therefore a consequence of the product's role, not a marketing choice made in isolation. Keep both questions in mind, because the rest of the article shows how their answers move the price, and what that choice obliges the vendor to do.

Think of these two definitions as the two axes of a grid. Low attribution and low autonomy describe a tool that helps someone who is still doing the job. The software makes the person faster or better informed, but the person is the one who finishes the work and the result cannot cleanly be credited to the software. High attribution and high autonomy describe a system that performs the job itself and can be credited for the outcome it produces.

Notice that the two axes measure different things. A product can do a lot of work on its own and still be hard to credit if other factors also shaped the result. Likewise, a product can be clearly responsible for a result while a human still does much of the core work. Attribution asks about credit. Autonomy asks about who performs the work. Pricing models are placed by where a product lands on both at once.

Consider a customer question that arrives through a chat window. Trace what happens to the state of the work, step by step, in the first arrangement.

The software contributed, but the human decided the result and completed it. In this arrangement a seat-based price fits, because the customer is paying for access to a tool used by people. The price tracks the number of people using the tool, which matches the fact that people are doing the work.

Now place the three pricing models on the grid. Seat pricing sits in the weak-attribution corner: the software helps a human, and the human is the one who finishes the work. Usage pricing, which is the amount paid to a foundation-model provider for consumption, sits between the extremes. Outcome pricing sits where the software owns the result, so the vendor is paid for a finished thing, such as a resolved inquiry or a completed sale.

Read the grid from left to right. Each step rightward means the product can claim more of the result and does more of the work without a person. The placements follow from the product's role. A seat fee charges for people using the software, a usage fee charges for consumption, and an outcome fee charges for a finished result. The three models therefore differ in what they charge for, who carries the risk when results vary, and what the customer actually pays for.

The source makes a specific claim about agents: they push software up both axes at once. Agency means the software takes actions toward a goal rather than waiting for each step to be directed by a person. Cleaner attribution means it becomes easier to say which result the product was responsible for. Because an agent can do both, the case for outcome pricing gets stronger with each step agentic software takes.

The source observes that every category the company Sierra competes in is drifting toward outcomes. This claim describes a direction of movement across categories. It is not a rule that every product must price by outcome today. The reasoning is that as software gains autonomy and attribution, the outcome becomes the most natural unit to charge for.

Once a vendor is paid for the outcome, a new obligation appears. If the price depends on a result, then the result has to be reliably produced, not merely attempted. The source states the bridge plainly: if you price the outcome, someone has to guarantee the outcome, and that someone is the forward-deployed function.

Trace the chain in one direction. Outcome pricing is what makes the guarantee necessary, and the forward-deployed function is what makes the guarantee real. Responsibility passes from software to people at the point where the vendor's promised result has to be secured. Without a party accountable for the result, an outcome-priced contract would have nobody standing behind the number it charges for. The source describes this as the cleanest one-line justification of the forward-deployed role that the pricing literature has produced.