Steven Rothstein lined up for yet another one of his 10,000+ flights. But when a gate attendant handed him a letter, his life changed: After flying more than daily for 25 years, American Airlines was canceling his ticket, effective immediately.
Rothstein was one of 66 lucky people who took advantage of one of business history’s biggest pricing mistakes: In 1981, cash-strapped American Airlines offered the AAirpass, a $250k ticket that gave you unlimited first-class flights anywhere, forever.
What seemed like a smart strategy to raise money without losing equity became a headache: Travelers like Rothstein took the “unlimited” seriously.
He’d board a plane in Chicago to have lunch in Paris before finishing his day with coffee in Ontario. An airport celebrity, Rothstein recognized American Airlines’ booking agents by their voices. His son’s funeral was attended by 10 American Airlines employees.
But not everyone at American liked Rothstein: At the corporate offices, the team calculated he alone was losing them $1 million a year—let alone the 65 other pass holders. The sugar high from Rothstein’s $250k had turned sour.
His incessant first-class flights meant lost revenue. Add airport fees, fuel and other costs, and you know why the AAirpass is discontinued.
The reason we’re talking about airlines on a SaaS blog is that AI could put us in a similar scenario:
Traditional SaaS pricing grants (more or less) access for a fixed fee with similarly stable costs. But paid-by-the-token APIs, we could get a Steve Rothstein-esque scenario: Power users taking the “unlimited” too literally and bankrupting you. In nerdspeak: AI apps have COGS.
This has spawned much social media chatter in the SaaS community. Should you pay based on usage? Should users foot their own AI bill?
Much of that comes from people who haven’t priced an AI product. We have. When we launched Copilot, we spoke with many customers to find out how they feel about paying for AI products (and how they don’t want to pay). In this article, you’ll find out what we learned and why we don’t think the “Steve Rothstein risk” is real:
Let’s start with 3 principles:
The 3 jobs of pricing (and why software became a subscription)
Like with any eternally debated topic, there’s no universally correct answer to “how should you price?”. You need to derive the right answer for your company and your product from first principles. So let’s explore three of them:
1. Maximize revenue
This is most obvious: If you had perfect information, you could calculate the maximum a customer is willing to pay—and charge them that amount.
Because we live in reality and not in economic models, you can’t perfectly calculate this for each customer. But your prices should attempt to get you the maximum amount of money.
2. Maintain cash flow
Companies run on money, so your pricing needs to ensure you keep money in the bank. This means your pricing needs to line up (somewhat) with your cost structure so you don’t end up in a cash crunch.
As an example, this is why almost all software became a subscription:
Before the internet, a software product’s costs plummeted once it was burned onto a CD-ROM. That’s why companies charged a high one-time fee for software every few years.
But cloud-based software has ongoing costs for hosting and vendors, which meant pricing became recurring as well.
3. Align incentives
Show me the incentive and I’ll show you the outcome. -Charlie Munger
The classic example is that a consultant paid by the day finds the project needs 3 additional months. A writer paid by the word says in 5000 words what could be said in 500.
Software products evolve—especially those of startups. Your pricing model should ensure you have the incentive to built the best product for your users.
An example here comes from typical subscription pricing: Users can cancel whenever they want, which creates incentives for you to provide a great experience. You can’t coast on “they’ve already paid me”.
Your customer has an incentive to pay a subscription because it’s an insurance against paying thousands for something they don’t use. You have an incentive to build a great product because your customer can leave anytime.
Both sides want the outcome they’re getting from doing what the other side wants them to do. This is what good pricing aims for.
Now, with the theory out of the way, let’s get into how we explored pricing Copilot:
1. Success-based
AI introduces introduces two variables two new variables to SaaS:
- Cost variable: Two users paying the same price can now have radically different costs.
- Performance variable: Before AI, your product did what you told it to do. AI can produce outputs you never programmed it to do.
Customers buy value, not software. Because of AI’s imperfections, delivery of that value can be uncertain and raise customer objections.
This has made some companies adopt success-based pricing. They only charge the customer when the AI feature successfully does its job. Intercom’s Fin is an example of this:
This model has made billions in the non-AI world: Stripe charges 2.9% + $.30 when a transaction goes through. They only make money when you do.
Sounds easy, right? Customers don’t pay for bad AI responses. But it’s not that simple. In practice, defining this is hard: If a user starts an AI chat and gets so frustrated they leave without writing a ticket—is that a resolution?
For AI support, success definitions are fuzzy. We found it too difficult to define success because there are so many edge cases that the pricing model would take more time to maintain than it saves.
A better example here is Chargeflow, an AI-powered chargeback recovery tool. The success condition here is crystal-clear because it’s based on the credit card company’s judgment.
This is a great use of success-based pricing! But most use cases for SaaS aren’t as clear-cut as credit card chargebacks. And they harm UX.
How success-based pricing harms UX
Success-based pricing also makes software harder to use. Not from an interface standpoint, but from an organizational standpoint.
Take this bit of copy: “[…] take control of your spend by setting up notifications or stop Fin delivering AI answers to customers when a defined resolution limit is reached.”
This is a nice gesture, but makes people’s jobs more complicated. What if you exhaust your monthly AI spend in 10 days? Do you double your human agents’ workloads? Do you need to request more budget from finance?
That’s where success-based AI pricing is annoying: You need to worry how much AI to use, where to deploy it, etc. That makes it harder to use than a tool you get access to and implement wherever useful.
This is also better for the software vendor: The more entrenched a product is in someone’s product, the higher your product’s switching costs.
There’s a close cousin to success-based pricing that’s more common: Usage-based pricing.
2. Usage-based AI pricing
With high interest rates, money is harder to come by, so new subscriptions are harder to get approved. That’s why usage-based pricing is making a comeback.
In the non-AI world, this is most common with infrastructure products like Twilio and Snowflake. Within AI, the best example is OpenAI itself: You pay $30 per million “tokens”.
If you offer an AI solution built on OpenAI, you could charge the same way. This effectively makes you a reseller: You buy tokens from OpenAI for a price x and sell them for x+n.
The incentives here are to get users to engage with your product more often. But API usage doesn’t always correlate to value. If we charged for Copilot by the API usage, a longer chat is usually a bad signal because the problem is taking longer to get resolved. (Not always — sometimes it means the user is vibing with Copilot.)
This misaligns incentives: We’d make more money by providing a worse experience. So we didn’t do that! It can also make it harder to buy your software because it’s hard to get an uncertain spend approved by finance.
In The State of Pricing, Kyle Poyar shared this great graphic:
This shows that pricing always starts with first principles. Adapting the trendy social media pricing scheme won’t get you far.
Next a subcategory of usage-based pricing:
Usage-based subscriptions
Many AI companies allocate each subscription an amount of AI credits they can top up if they run out. See an example from Craft:
This is like buying Dave and Buster’s tokens: The user guarantees a regular exchange of money to a made-up currency. But it’s ultimately still a form of usage-based pricing since your access is still capped after a certain amount of usage.
We looked at pricing this way, but noticed that Copilot’s value comes from its availability. One of its core use cases is as a first line of defense for customer support. If it suddenly refused service because a customer used up their allocated AI responses, it would flood the human support team and create a worse user experience.
Note: Copilot is different from some tools because our customers don’t initiate when the AI is triggered. Their users do. If availability isn’t one of your AI product’s core promises, usage-based pricing might be better.
So while usage-based subscriptions give customers peace of mind, it doesn’t solve the core issue of equating API usage with value.
Most SaaS companies have some form of usage-based subscription, including CommandBar (see the seat/MAU and other limitations). The above is specifically about AI features in traditional SaaS.
The third is a new type of pricing model we’ve rarely seen before AI:
3. Bring your own key
Some companies allow customers to foot their own API bill by inserting their own API key. This makes the product similar to leasing a car. You pay a monthly fee to get access to it, but still need to put gas in the tank yourself.
Here’s an example from Cursor.sh:
We tried this. It didn’t work for a simple reason: Customers didn’t want to provision their own keys. And that’s the biggest disadvantage of BYOK pricing: It makes it harder to buy from you.
First, Getting finance to approve a spend of X is easier than a spend somewhere in the range of Y and Z.
Second, if a customer doesn’t have an OpenAI API key, they need to start a long process to obtain one and enter it.
Third, it creates dependencies that affect your product: If your customer’s API key gets revoked or compromised, your product’s performance suffers.
By letting customers bring their own key, you’re creating room for error that doesn’t need to exist. Customers don’t buy software—they buy outcomes. And the more work they need to do for that outcome, the less they like it. This is why we unshipped API key input—and arrived at the simplest possible AI pricing:
4. Don’t break it out
We settled on the simplest answer: Include Copilot in our normal subscription pricing.
Sure, a customer could theoretically bankrupt us because we’re paying for OpenAI’s API. If a customer’s end user has Copilot reproduce Tolstoy’s War and Peace daily, we might end up with a mounting OpenAI bill.
We realized we could mitigate this risk in two very-basic-and-foolproof ways:
- Rate-limiting: We apply basic rate limiting by pricing (partly) based on MAUs.
- Paying attention early: By looking at API usage, we can investigate spikes and alert customers or ban account.
This lets customers “just use” Copilot. They don’t worry about whether each use case is worth AI credits or quibble with our definition of success.
It also lets customers “just buy” CommandBar. They pay for our product, which comes with Copilot. They don’t need to worry about whether to get the AI upgrade or do scenario planning of how much they’ll use AI features.
Critics might argue that our AI features simply give us higher COGS while we charge the same. This isn’t true. Because (good) AI use cases create extra value, they allow you to charge a premium and recoup your API costs that way.
Why we’re not afraid of SaaS’ Steve Rothstein
Price is what you pay. Value is what you get. -Warren Buffett
When Steve Rothstein boarded one of this 10,000+ flights on American Airlines, he received value each time he had a first-class meal served and safely landed at his destination.
While most people would get declining value out of flying multiple times per day, Steve Rothstein didn’t. To align incentives, pricing needs to correspond to how your customer derives value from your product.
This is something Jake Saper points out in How to price AI in SaaS:
“By definition, these foundational models are accessible to every SaaS provider, so how should you think about pricing what is, in effect, a commodity you’ve integrated into your product? Start with first principles: how much differentiated value does this AI feature create?”
This sounds like a hard, abstract topic. But Sarah Tavel’s Sell work, not software makes this easier: Think about AI SaaS pricing like you do about employee compensation.
Most employees are paid like software engineers—a fixed market price. Any other compensation would be absurd: Paying per GitHub commit would incentivize small contributions.
Sales commissions are closest to success-based compensation. But even there, you can get misaligned incentives—think of salespeople selling 10-year deals because they get commission for all 10 years immediately. Or giving huge discounts because some commission is better than no commission.
As outlined in our manifesto, we thought about how we’d pay a physical user assistant—someone standing by the user’s side and walking them through how to use the product. We’d pay that person like a software engineer, not a salesperson. And when our contracts renew, we can do the work to understand how much value we created and whether our customers are getting good ROIs. We hope we’ll earn a bonus.
If Copilot was paid like a salesperson, we’d constantly wonder: Is it worth dispatching the assistant or can the user just figure it out?
But customers get value when Copilot resolves an issue a human agent would’ve otherwise handled. We call this “ticket deflection”.
This meant two attributes mattered more for V1 than any others:
- Consistency: For Copilot to deflect tickets, it needs to become the go-to for users. Building that trust requires consistently answering user questions so well it resolves the issue they came for.
- Ubiquity: Using Copilot won’t become a habit for users if it’s only available on certain pages or for certain topics. Only if Copilot is ubiquitous in our customer’s products will it become their default help solution.
And the “is it worth it” question thus prevents customers and end users from realizing Copilot’s value:
These are the insights our pricing flows from: If we shut down Copilot because our customer ran out of AI credits, it’s no longer consistent. And if customers worry about API usage, they might limit Copilot to the hardest to understand parts of the product. That’s why we landed on a simple subscription: It’s the easiest pricing model to provide Copilot’s value.
Those are the criteria we used. Your AI feature or product might be different. To evaluate your pricing from first principles, copy our process.
- Determine how your customers get value from your product
- Identify the characteristics that matter most for you to provide that value
- Choose the pricing scheme that makes it easiest to provide that value
That’s as simple as it is.
What’s next?
The term “AI” is like “Cloud” was 10 years ago: It’s the cool new thing, but will soon be so normal we’ll just call it software.
Subscription-based pricing was rare—almost unheard of—before the cloud became ubiquitous. Today, we’re surprised when we pay a one-time price. So, might we see a new pricing model emerge from the era of AI?
I’ll keep my eyes open. Until then, enjoy (basically) unlimited Copilot at one monthly fee.
