Performance Guarantees in Consumption-Based Pricing

Imagine two companies selling the same AI support agent. The first asks for a fixed monthly fee no matter what happens. The second says nothing is owed until the agent actually finishes a piece of work, and then charges a small amount for each finished piece. The second approach is consumption-based pricing. The customer is not buying access for a period of time. The customer is buying completed units of work done by the AI system, and the bill grows with the number of those units.

Keep one question in mind as you read. What would have to be true about the work for a per-unit charge to feel fair to both the buyer and the seller? The answer depends first on what counts as a unit, and then on what protects the buyer when results fall short.

The unit is the central design choice in this model. A billing unit has to be something both sides can point to and count the same way. The source states the condition directly: the model works when the unit of consumption is unambiguous and both parties trust how it is measured. If either condition fails, the bill becomes a point of dispute rather than a record of value.

Consider the three examples the source gives of units: a support ticket resolved, a call handled, and a document processed. A resolved support ticket qualifies only if everyone agrees on what resolved means and can check whether it happened. For this reason the source explains that verifiable outcomes make better units than raw activity counts. Counting how many times the system was used is easy to log, but it does not tell the customer whether any useful work was finished.

The figure contrasts units that can be counted the same way by both parties with units that cannot. The condition that matters is not whether the thing is countable in a technical sense. It is whether both parties agree that one unit has been completed and can check it. A conversation that has no clear finish point gives the two sides no shared count to bill against.

Follow a single support issue through the system. The AI agent works on it. The outcome is then verified as resolved, which is the step that makes the unit countable. Only after verification does the unit join the running count for the billing period. At the end of the period the count is multiplied by the agreed rate, and the product becomes a line on the invoice. Each stage depends on the one before it, so a unit that never reaches verification never reaches the invoice.

Notice that the bill is built entirely from counted units. The calculation does not need a monthly seat fee, a contract term, or a forecast of how busy the team expects to be. The only inputs are the count of completed units and the agreed rate. That simplicity is the appeal of the model, and it is also why the unit definition must be precise: every number on the bill depends on it.

Under a per-unit structure, the vendor earns more when the system handles more volume of work that the customer values. The source describes this as aligning the vendor's revenue with the volume of value delivered. The incentive is easy to state. A vendor paid per resolved issue has a reason to make the system resolve issues. A vendor paid a flat fee has less direct reason to tie income to results.

The alignment holds only when the counted value is real. If a unit is cheap to produce but worth little to the buyer, the vendor's revenue can rise while the buyer's benefit does not. This is why the trust condition matters so much. The measurement has to reflect value, not merely a number that is easy to log.

A per-unit price tells the customer what each completed unit costs. It does not, by itself, tell the customer whether the system will perform well enough. Performance guarantees address that gap. In the source's description, a performance guarantee is a commitment from the vendor that the AI system will meet certain performance thresholds.

The source gives Intercom's Fin AI Agent as the cleanest public case of this model. Fin is priced at 0.99 dollars per resolved support outcome. The guarantee in that example is tied to the resolution rate. If the resolution rate falls below the threshold agreed with the customer, Intercom backs the guarantee with up to 1 million dollars per customer. The source describes this as Intercom being willing to put its own balance sheet behind the guarantee.

The guarantee is a second layer of protection on top of the per-unit price. The per-unit price governs what each resolved outcome costs. The guarantee governs what happens if the agreed performance level is not reached. The source frames the guarantee as a pledge to cover a shortfall up to a stated limit, not as a per-unit refund rule.

In this formula C is the charge for the billing period, n is the count of completed units, and r is the agreed rate per completed unit. Only the count and the rate are needed. Units that were never completed do not appear in n.

The running total in the example is the trace of the billing period's state. Each week the count moves up only by the units that were verified as complete. The final charge is computed once, at the end, from the accumulated count.