← Back to Concept Contrast

Concept Contrast Fable

Usage-based pricing and outcome-based pricing

Conclusion first:Both are breaking away from the old path of charging by seat, but they start from completely opposite directions. Usage-based pricing looks at how many resources the customer used—how many API calls, how many tokens were run, how much compute time was occupied; outcome-based pricing looks at how much value the customer obtained—how many tickets were resolved, how many leads were converted, how many labor hours were saved. Using one to replace the other either undercharges what should be charged, or starts billing when the customer has not yet obtained the result.

Both are breaking away from the old path of charging by seat, but they start from completely opposite directions. Usage-based pricing looks at how many resources the customer used—how many API calls, how many tokens were run, how much compute time was occupied; outcome-based pricing looks at how much value the customer obtained—how many tickets were resolved, how many leads were converted, how many labor hours were saved. Using one to replace the other either undercharges what should be charged, or starts billing when the customer has not yet obtained the result.

Fable

The two ferries by the river

On a river there had long been two ferry companies. The one on the north bank charged by the trip: whether carrying people, goods or mail, the boat counted as one trip once it left shore. The fare slip only recorded the number of crossings, and passengers had to pay as soon as they boarded, even if the boat was turned back halfway by wind and waves.

The one on the south bank was the exact opposite. They posted only a price list at the dock, and instead of trips it listed how many copper coins for a person to reach the far bank, how many for goods to reach the far-bank warehouse, and how many for a letter to reach the recipient's hands. No payment if the boat didn't reach the far bank, and on stormy days the boat operator swallowed the cost of an empty run.

One summer the wind and waves were especially rough. The boats on the north bank succeeded in crossing only three out of ten trips, but the books recorded money for ten trips. The boats on the south bank also crossed only three times, and the books also charged only for three trips; the fuel and labor for the remaining seven trips were covered by themselves. The north bank accountant was beaming, while the south bank boat captain was so worried he could not sleep all night.

By autumn the river slowed, and a boat on the south bank could make twenty crossings a day, all completed, all paid for. The north bank still honestly charged by the trip, with prices unchanged for three years. Passengers therefore flocked in whole groups to the south bank. The north bank's chief manager scratched his head and said: our boats are as good as theirs, so why have the people run off?

The boat passenger representative put it bluntly: you charge for the boat moving, they charge for me arriving ashore. In summer we paid for seven wasted trips, and in autumn they run more and we're happy to pay. In the end, you count your effort, they count my results.

The north bank later changed its rules once: regardless of whether it was stormy or clear, payment was collected only upon reaching the opposite shore, but the unit price also rose by twenty percent. Old ferry passengers reacted very differently: those who crossed often thought it fair, those who crossed occasionally thought it expensive. So the north bank added options—those who made fewer than ten trips a month paid per trip, those who made ten or more paid by the number of shore arrivals, with a further discount on the unit price.

This compromise made the accountant discover a secret: customers priced by usage cared about frequency, while customers priced by outcome did not care about frequency but about whether they could stop worrying entirely. The mental accounting of the two customer types was completely different.

Later the accountant put the two ledgers on the same page: the usage ledger reviewed daily, the results ledger reviewed at month-end. Who bears the risk and who takes the incremental gain were finally written clearly.

Usage-based pricing

Billing based on the actual amount of resources the customer uses—such as API calls, token consumption, or compute time—so revenue is directly tied to customer usage.

Outcome-based pricing

Billing based on specific business outcomes the customer achieves—such as number of problems solved, number of conversion events, labor hours saved—with revenue tied to the customer's actual results.

Story Mapping

  • The north shore charges per trip (usage-based pricing): the boat counts as soon as it moves, regardless of whether it succeeds
  • South bank charges on arrival (outcome-based pricing): you only pay once the person reaches the other shore
  • The summer disaster: usage-based pricing still bills under adverse conditions, so the pricing itself swallows the loss
  • Autumn harvest: outcome-based pricing earns higher returns and customer loyalty when delivery is stable
  • The compromise option on the north shore: a hybrid solution captures the real needs of two different customer types

Applying it to Andy Ren Xu's project

Usage-based pricing suits foundational capabilities where your AI is already stable and customers are willing to use it frequently. Outcome-based pricing suits cases where your AI achieves a business goal the customer quantitatively cares about—saving three work hours, signing two more deals. At the early stage, usage-based pricing is recommended to fill in cost data; once you can accurately estimate the average resource consumption per outcome, switch to outcome-based pricing. Charging by outcome from the start is equivalent to bearing all volatility risk yourself when you do not have enough data.

京ICP备2026014272号