How to Choose an AI Pricing Model Without Breaking Your Existing Book

Match your AI feature's pricing model to what the customer can already see as valuable, and sequence any change to your existing base as deliberately as the pricing decision itself.

Maintained in the open at github.com/Golden-Section-Tx/playbook · CC BY-SA 4.0

PlayersFounder, CFO, Product Manager
Initial Effort8 SP
Ongoing3 SP
FrequencyAs Needed
StageGrowth

Every AI feature you ship comes with a pricing decision attached, and it is tempting to treat it as an afterthought: bolt on a token meter, or fold it into the tier you already sell, and move on. The companies that get this right treat the pricing model as a product decision, made before the sales team starts pitching it, not backed into after the first renewal conversation goes sideways.

The mistake is rarely picking the wrong model. It is picking a defensible model and then converting your entire existing base to it in one move, without sequencing the change or telling anyone it was coming. A pricing model that is right for the long run can still read as a bad quarter if the transition into it was not managed as its own decision.

The goal: Choose the AI pricing model that matches what your customer can already see as valuable, and roll it out in a sequence that does not spook your existing base.

Background

AI pricing sorts into five broad models, and none of them is universally right:

  1. Outcome pricing. You charge for a result the customer can already name: a resolved ticket, a completed task, a basis point of margin. Most defensible when you can point to a specific number, and hardest to execute honestly, because you have to draw a straight line from your price to that number.
  2. Bundled pricing. The AI feature ships inside a tier or edition you already sell, with no new line item. Lowest risk and lowest visibility: you absorb the inference cost as overhead and cannot yet show a board a separate AI revenue line.
  3. Usage or consumption pricing. You charge per unit of something the customer consumes. This only survives contact with the customer when more usage is visibly more value to them. Where the metered unit is a backend cost like tokens or API calls that the customer cannot independently value, it reads as an unpredictable tax, not a fair exchange.
  4. Hybrid subscription plus credits. A base subscription with a consumption top-up. Honest about your cost structure, but it hands the job of translating "credits" into a felt outcome to your sales and success teams. Treat it as a transition state, not a destination.
  5. Absorb the cost, don't reprice. You leave pricing untouched and invest in cutting your own inference cost instead. Carries none of the sales-cycle risk of a pricing change, at the cost of a margin drag until the unit economics catch up.

Steps

  1. Name the outcome your AI feature produces, in the customer's own words, before you touch a price. If you cannot say it in one sentence a customer would recognize, you do not yet have a candidate for outcome pricing, so bundle it into an existing tier until you do.
  2. If you are considering usage-based pricing, ask whether the metered unit is something the customer wants more of or something they are forced to tolerate. A meter on their outcome is durable; a meter on your cost is not.
  3. Decide whether you can carry the inference cost as a margin drag long enough to prove the feature, or whether it needs to be passed through now. If you have the runway, absorbing the cost buys you time and removes the pricing decision from the sales conversation entirely.
  4. Model the downside of any usage-based line as carefully as the upside: what happens to revenue if your most sophisticated customer becomes more efficient and consumes less.
  5. If the decision converts any part of your existing seat base rather than adding a new line for new logos, sequence it: launch it as a new-logo motion first, a renewal-time upsell second, never as a mid-contract change nobody saw coming.
  6. Write down, before you launch, what you will tell customers, your board, or your investors about why growth may look different for a quarter or two because of this choice. A deliberate pricing decision should never be allowed to read as a demand problem after the fact.
  7. Review the model against outcomes every quarter with the Founder and CFO: is the metered unit still something customers value, is churn or downgrade activity concentrated in the accounts you converted, and does the model still match the stage the product is at.

Troubleshooting

  • My board wants to see an AI revenue line, so I have to meter something. A bundled feature that drives tier upgrades and retention is an AI revenue story without a separate SKU: the upgrade rate and the retention lift are the numbers to bring, not a token count.
  • We already sold AI on seats, so can we still move to outcome pricing? Yes, but not by converting everyone at once. Treat the existing base as its own rollout, sequenced behind new business, with the growth-rate conversation had proactively rather than discovered at the next board update.
Mistakes this play prevents: #20 #139

Questions this play answers

How should I price a new AI feature?

Name the outcome your AI feature produces, in the customer's own words, before you touch a price. If you cannot say it in one sentence a customer would recognize, you do not yet have a candidate for outcome pricing, so bundle it into an existing tier until you do.

Should I charge per seat, per token, or per outcome for an AI product?

Every AI feature you ship comes with a pricing decision attached, and it is tempting to treat it as an afterthought: bolt on a token meter, or fold it into the tier you already sell, and move on. The companies that get this right treat the pricing model as a product decision, made before the sales team starts pitching it, not backed into after the first renewal conversation goes sideways.

What is the risk of moving existing customers from seats to outcome-based pricing?

We already sold AI on seats, so can we still move to outcome pricing? Yes, but not by converting everyone at once. Treat the existing base as its own rollout, sequenced behind new business, with the growth-rate conversation had proactively rather than discovered at the next board update.

How do I know if usage-based pricing will hold up with my customers?

If you are considering usage-based pricing, ask whether the metered unit is something the customer wants more of or something they are forced to tolerate. A meter on their outcome is durable; a meter on your cost is not.