{"slug": "three-ways-to-sell-the-same-software", "title": "Three Ways to Sell the Same Software", "summary": "Software vendors can now sell the same AI support agent under three pricing models—subscription at $500 per month, usage at $1 per conversation, or outcome-based at $5 per resolved issue—each shifting risk and incentives differently. The choice of model determines whether the vendor is on the hook for access, activity, or results, and AI's per-task compute costs are making flat subscriptions harder to sustain.", "body_md": "An AI support agent, the kind that answers customer questions in a chat window and hands over to a human when it gets stuck, can be sold in three very different ways. Say $500 a month for access, $1 for every conversation it handles, or $5 only when the customer's problem is actually resolved. The software underneath could be identical in all three cases. What differs is what the vendor is on the hook for, and the chosen pricing model is one of the clearest expressions of that. A subscription sells access. Usage pricing sells activity. Outcome pricing sells a result, or at least puts some of the vendor's own revenue at risk against one. In practice the lines blur, and products often use more than one at a time. What has changed recently is that software now does enough of the job for the third to be a serious option at all.\n\n*Illustrative pricing models*\n\nIt is worth being precise about what a price does here. The customer gets some value from the result, the vendor incurs some cost to deliver it, and the gap between the two is the economic surplus: the value the transaction creates. The price is the line drawn through that gap, deciding how much of the surplus each side keeps. This is basic economics, but worth keeping in mind. Importantly, when holding value and cost fixed, moving the line does not make the gap any wider; whatever one side keeps, the other does not. That is usually only true in the short term, though. Over a longer horizon the pricing model shapes how much a product gets used and what the vendor is incentivised to improve, which changes the size of the gap itself. What each pricing model really decides is how that line behaves: whether it sits still regardless of what the customer gets, moves with how much they use, or moves with a contractually defined result. That is also what decides which side carries the risk if the value never appears at all.\n\nStarting with the line that sits still. As SaaS took hold the subscription became the industry standard, and for good reason: it is a genuinely good arrangement in a lot of ways. A flat fee gives the customer a number they can budget against and removes the need to weigh up whether each individual use was worth it, which is how a product becomes sticky rather than a recurring decision. Research in consumer services has found that people sometimes choose flat rates even when metering would cost them less, partly for the convenience and partly as insurance against an unexpectedly high bill. [1] The vendor carries the risk that a customer uses the product far more heavily than expected. The customer carries the risk that access produces nothing at all.\n\nBecause the price does not move, how much value the customer ends up keeping depends entirely on how much they get out of the product. A customer who gets a great deal of value out of the product keeps a large surplus. A customer who gets very little value pays exactly the same and keeps almost no surplus. That is what a subscription is really saying. Here is the tool, we will keep it available and working, and what you achieve with it is up to you. That was a fair reflection of who was doing what: the software supplied the capability, the customer did the work.\n\nFlat subscription pricing is easiest to sustain in cases where serving a heavy customer costs the vendor little more than serving a light one, in other words when marginal cost is minimal. AI has been making these cases rarer: LLM inference introduces material per-task compute costs, so a heavy user can cost many times what a light one does, [something I wrote about here](https://nicolo.xyz/note/something-is-changing-in-the-unit-economics-of-software/).\n\nOne response to this is usage pricing, where the bill follows activity. It suits products whose marginal cost rises materially with activity, and it suits customers too: a small buyer can start small, and the bill contracts when demand falls. Going back to the line, it now moves rather than sitting still, but it moves with activity. The customer wants their problem solved; the vendor is paid for the attempt. The surplus is spread more evenly across customers than under a flat fee, since heavy users now pay for what they take, but the bill still tracks the work done rather than the result it produced.\n\nThere is a tension in that. Holding the price per unit constant, a vendor's revenue falls if the user reaches the same result with fewer billable units. Competition, retention, and the fact that fewer units also mean lower costs to serve may all outweigh that, but the meter itself does not strictly reward the vendor for efficiency.\n\nOne way to fix that is to stop metering the work and meter the result instead. Returning to the customer support example, under outcome pricing the vendor is paid only when the customer's problem is resolved, so a conversation that goes nowhere still costs money to process and earns the vendor nothing. That is a transfer of performance risk from the buyer to the seller, and it changes what the vendor optimises for. It rewards fewer wasted attempts and cheaper routes to the same result, and it focuses the vendor on actually solving the customer's problem. It also removes the worst case for the customer under the other two models, which is paying for something that did not work at all: a negative surplus.\n\n*Illustrative pricing table*\n\nOutcome pricing does not, however, automatically leave every customer better off, and it does not suit every product. A vendor carrying performance risk may charge a premium, restrict which cases qualify, demand cleaner inputs, or retain a monthly fee alongside the per-result price. The customer is buying a degree of performance insurance, but not necessarily at the price the equivalent subscription would have cost.\n\nOverall, the three models are different answers to the same question: how much of the result can the vendor reasonably be held to? That depends on how much of the process the vendor's software actually performs. A spreadsheet does not promise your analysis is right and a design tool does not promise the advertising campaign works, because the customer performed most of the work and therefore kept most of the risk. That is changing. Software has recently started interpreting a request, choosing an approach, doing the work and deciding when to escalate, which puts it in a different position. It is doing enough of the job that a customer can reasonably ask it to stand behind the result.\n\nThat argument only holds as far as the software's control actually extends, and in practice it often stops short. A support agent might fail because the company's own policy forbids the resolution, or the underlying data is wrong, or another system is down, or the customer simply stopped replying. Some of those failures may sit outside the vendor's control, so an outcome contract has to decide which the vendor accepts, which it excludes, and which remain with the customer.\n\nOutcome pricing therefore works cleanly only when three conditions hold:\n\n- The result has to be\n**observable**, so both sides can tell whether it happened. - It has to be\n**attributable**, so there is a credible account of what caused it. - Enough of the process has to sit\n**inside the vendor's control** that they are not being asked to guarantee somebody else's behaviour.\n\nEven where all three hold, a difficulty can remain in some cases. Outcome pricing aligns the vendor with whatever the contract calls success, which is not always the same as success. A vendor paid per resolved ticket has reason to close tickets, discourage reopening, favour the easy cases and let the hard ones fall outside the measured population. None of this requires bad intent; it is a familiar problem in incentive design. What is different is scale. A commission changes how a few people behave; a measure built into the product changes how every ticket gets handled.\n\nNone of this is a progression, with outcome pricing as the enlightened endpoint. They are three ways of splitting risk, and the set has been expanding rather than replacing itself: each suits different conditions, and in practice plenty of real products combine them. Pricing is also only one of the ways a vendor takes on responsibility: warranties, refunds and service guarantees can shift risk or provide recourse without ever appearing on the invoice.\n\nWhat I keep coming back to is what pricing now has to express. When software supplied a tool, billing could reasonably focus on access or consumption. When it chooses the method and performs more of the job itself, a customer can fairly ask how much of the result it is willing to stand behind. Answering that means deciding where the software's job ends and the customer's begins, which is a harder question than it sounds and one both sides are only starting to negotiate. The hard part is no longer only picking a unit to charge for. It is working out exactly what the vendor should be answerable for.\n\nLambrecht and Skiera,\n\n[\"Paying Too Much and Being Happy About It\"](https://www.anderson.ucla.edu/documents/areas/fac/marketing/paying_too_much.pdf?ref=nicolo.xyz), on why consumers often choose flat rates over cheaper metered alternatives.[↩︎](#fnref1)", "url": "https://wpnews.pro/news/three-ways-to-sell-the-same-software", "canonical_source": "https://nicolo.xyz/note/three-ways-to-sell-the-same-software/", "published_at": "2026-08-09 13:58:40+00:00", "updated_at": "2026-08-09 14:04:19.197302+00:00", "lang": "en", "topics": ["ai-products", "ai-infrastructure"], "entities": [], "alternates": {"html": "https://wpnews.pro/news/three-ways-to-sell-the-same-software", "markdown": "https://wpnews.pro/news/three-ways-to-sell-the-same-software.md", "text": "https://wpnews.pro/news/three-ways-to-sell-the-same-software.txt", "jsonld": "https://wpnews.pro/news/three-ways-to-sell-the-same-software.jsonld"}}