The sales compensation problem every AI company will eventually hit: How to pay sales on usage
Everything I learned about the trade-offs between incremental ARR, gross usage, and committed spend compensation models
It seems that every week I get a version of the same message from a founder or GTM leader: “We’re an AI company, we charge per token, and our sales comp plan is a mess. How did you figure this out?”
I spent eight years running Sales Operations at MongoDB, including the years when we made the transition from subscription software to a consumption model. I wrote this article for the founders and GTM leaders navigating this now, particularly those building AI products where per-token or per-API-call pricing is the default. If you charge on usage, you need to think about comp on usage. Here’s everything I learned.
TL;DR:
If you’re building an AI business, it’s likely priced based on usage. The pay-per-use model pioneered by AWS is now standard for AI-native companies: per-token, per-API-call, or hybrid seat-plus-usage.
Traditional SaaS comp breaks in a consumption world. When revenue is usage-driven, the deal close is just the starting line. Measuring rep impact, setting fair quotas, and avoiding perverse incentives all require fresh thinking.
There are three main models: paying on committed spend (similar to traditional SaaS), paying on incremental usage, paying on gross usage, or some combination of those three. Each has trade-offs.
I share my personal experience iterating on the MongoDB compensation plans when I was head of Sales Operations. We used the incremental usage model, and fine-tuned it over the years.
What do we mean by a “consumption” or “usage” based pricing model?
Before we get into the compensation mechanics, it’s worth grounding ourselves in what makes a consumption model fundamentally different from what came before it. Let’s explore the three eras of software pricing:
The perpetual license era (think Oracle) meant the customer bought the software outright, typically via large upfront deals. The vendor owned the market, pricing was complex, and the customer was locked in. This was a very vendor-friendly world.
The SaaS era (think Salesforce) shifted toward subscription-based pricing where the customer “rents” the software and renews annually. More customer-friendly, but still with friction, including large upfront commitments and complex pricing tiers. And from a metrics standpoint, you have a misalignment between bookings and actual revenue recognition. (Bookings are recognized upfront while the revenue is recognized ratably over the course of the contract.)
The consumption era (pioneered by AWS and now AI-native startups) means that the customer pays for what they use, billed in arrears. Usually paired with a product-led growth and/or self serve model, the product has to continue to prove itself in every single billing cycle.
“For customers, the benefits of doing business with vendors that offer a usage-based pricing model are clear: use the products you want, when you want, and be billed when you do.”
— Ben Chambers, Sales Compensation Consultant (formerly New Relic, Databricks)
This pricing model is particularly relevant in the age of AI. Many AI native companies price on a per API call or per token basis, or use a hybrid of per seat models with usage. If you’re building a product that calls an LLM under the hood, your pricing model is almost certainly consumption-based in some form, which means your sales comp model needs to be too.
During my tenure leading Sales Operations at MongoDB, we shifted our pricing and sales motion from subscription to consumption based. In this article, I’ll share the evolution of that model over time and compare it to other companies that I studied while designing the plans, such as AWS, Twilio, Snowflake, and others. These insights should be applicable for founders and GTM leaders at AI companies who are navigating building their business around usage-based pricing.
The two main usage-based compensation models: incremental usage and gross usage
In working on MongoDB’s shift to consumption, I researched several different approaches and spoke with RevOps leaders at many companies. The compensation models typically fell into the following categories:
Pay on committed spend, similar to a traditional SaaS model
Pay on incremental usage (example: MongoDB)
Pay on gross usage (example: AWS)
Some combination of the above, e.g. a comp plan with an element for committed spend as well as usage
I’ll start with the incremental approach, since that is what we adopted at MongoDB. We didn’t get there overnight, so let me walk you through the process.
Compensating on incremental usage
MongoDB built their sales incentives around a metric we called Net ARR. I want to share how we actually got there at MongoDB, because it took several iterations on the plans over many years, each one fixing a problem the previous stage created.
Stage 1: Paying on commitment
When MongoDB first introduced its cloud product, Atlas, in 2016, the company was operating in a world built around traditional software sales. Sales had been selling an on-prem product (MongoDB Enterprise Advanced) where they were credited using a traditional New Annual Contract Value (NACV) method. Atlas, in contrast, would be billed based on usage.
When we introduced Atlas, we initially applied the same NACV logic to sales compensation. Reps were credited when they got the customer to agree to purchase a predefined pool of credits, from which the customer would draw down as they used the product. When they ran out of credits, they would have to go back to sales to either renew early or do a short “top-up” deal to bridge their usage until the end of the contract.
Challenges with this approach:
It introduced friction into the sales cycle. Customers had been conditioned by the hyperscalers to pay on a usage basis and had come to expect that pricing model.
To purchase a commit, the sales would need to go through a sizing exercise to figure out how much the customer should buy. Sales engineers were spending weeks trying to help the customer predict their spend.
There was an incentive for reps to pressure customers into commits before they were ready. Even worse, in some cases they might oversell the product, getting customers to make large commitments and then walk away before the customer implemented the technology.
Reps were wasting cycles chasing paperwork for “top-up” deals with customers once they ran out of credits. This was annoying for the customer too, most of which preferred to be billed overages in arrears rather than sign a new contract.
Stage 2: Neutralizing the incentives with run rate crediting
The goal of Stage 2 was neutralization: we wanted reps to be indifferent between selling an Enterprise Advanced commit, an Atlas commit, or having a customer pay-as-they-go. Whatever was right for the customer should be right for the rep.
After a customer consumed their commit, we would bill in arrears and pay reps on the incremental run rate above the commit. This solved the problem of reps chasing top-up deals.
Once the customer burned through their commitment, the rep would automatically get credited for any incremental ARR. And if the customer had no commitment at all, we’d pay on the run rate directly. This addressed the issue of reps prematurely pushing commitments, and also reduced (but didn’t eliminate) the time spent working on sizing deals.
Example
Let me illustrate it for you in an example.
Q1: The customer commits to 120 and they use 25. That means that their annualized run rate is 100 (25 per quarter x 4 quarters). The rep would get credited for the commit of 120.
Q2: The customer starts to ramp up their usage and consumes 35. This means that their annualized run rate is 140, exceeding their original commit. However, because they have only consumed a total of 60 (25 in Q1 and 35 in Q2), the rep wouldn’t earn any incremental credit.
Q3: The customer’s usage accelerates further and they consume 50. This brings their ARR to 200 (50 per quarter x 4 quarters), and they have used up their commit of 120 (25 in Q1, plus 35 in Q2, plus 50 in Q3 is 135). The customer wouldn’t need to go through procurement again; they would start getting billed for the incremental usage. And the rep would get credited 80, which represents the difference between their baseline of 120 (established by the original commit) and their run rate (200).
Q4: The baseline on the account would be 200. In order for the rep to earn further credit, the customer would need to increase their usage or commit to more than 200.
What worked:
Reps were still incentivized to drive commitments, but they weren’t pushing them on customers unnaturally.
Sales and the customer spent less time on sizing commitments.
Reps (and customers) no longer had to do top-up deals.
Challenges with this approach:
We started to notice reps racing to pull renewal commitments forward at the end of quarters, and sometimes even sacrificing discounts, in cases where a customer’s run rate exceeded their commit but they hadn’t yet exhausted the commit balance.
When a customer’s use declined below the baseline, reps were subject to commissions and crediting clawbacks.
Stage 3: Greater of the run rate or the commit
To address the issue of reps pulling forward renewals, we made a simple change to the crediting guidelines. The rep would be paid on the greater of the customer’s ARR run rate or their commit, whichever is higher, regardless of whether they had exhausted their commitment.
If we revisit the example above, under the new crediting rules, the rep would have earned credit of 20 in Q2 because their run rate (140) exceeded the baseline set by the commit (120) even though the customer hadn’t exhausted their commit. This effectively pulled forward ARR crediting, and had to be taken into consideration in quota setting. (Said another way: quotas went up because reps could get ARR more quickly and easily.)
What worked:
Reps no longer pushed customers to renew early if they hadn’t exhausted their commitment, putting them in a better negotiating position.
Challenges with this approach:
We continued to have challenges with customer churn impacting reps’ paychecks. This was largely addressed through an exception process that was highly manual, and was the major pain point of this comp plan.
Compensating on gross usage
While MongoDB was undergoing this transformation, I spoke with peers at many other companies, and most had some element of compensation on gross usage. The logic is intuitive: every dollar the customer consumes is a dollar of revenue for the company, so give the rep credit for every dollar billed. The quota is set as a total billing target, factoring in an expected organic growth rate, plus an additional uplift that the reps were responsible for driving.
Here’s a simple example of how you might set a quota in this model:
Territory billed $1,00,000 in the prior year
Organic growth is 25% → $1,250,000 of billing expected
Quota is set with an uplift of 20% → $1,500,000 quota
What works:
The elegant part of this model is the alignment: the customer, the company, and the rep are all measuring the same thing. Unlike the incremental crediting approach, the crediting model is simple, and you don’t have to clawback if a customer’s usage drops. (The reps just earn less of their overall variable and have to make it up elsewhere.)
Reps have predictable payouts as customers consume.
This can be paired with a separate element for commitments. In some cases, prior year commits informed the consumption element of the comp plan, and the commit element would be weighted (e.g. 30% on commitment, 70% on usage) based on how many customers were available for renewal.
Challenges with this approach:
The biggest challenge is quota-setting. You need a model to project growth for all of your accounts, and these growth expectations can feel like a black box to reps.
Reps earn commissions on the usage across their entire territory, including the portion that would have grown without them. You’re effectively paying on retention as well as expansion. And you can suffer from the “free rider” effect, where reps can earn a large portion of their variable just for retaining the customer.
It’s harder to make an attractive comp plan with big upside, because the quotas end up being so large.
There’s no perfect comp plan for consumption
When I’m asked about compensation plans for consumption businesses, my answer is always the same: There is no perfect solution, only trade-offs. I’ve described many above, but here is the cheat sheet:
If you’re building an AI company on usage-based pricing, expect to start somewhere imperfect and improve from there. The goal isn’t to design the ideal plan on day one. It’s to design a plan that you can measure, that reps can understand, and that you can change when the incentives drift from the behavior you actually want.
Sources & Related Reads
The AI pricing and monetization playbook from Bessemer Venture Partners
A new framework for AI agent pricing from Growth Unhinged
How Do I Build a Usage-based Sales Compensation Plan? from the A16Z blog, co-authored by my former colleague Joe Morrissey
Overages: The Overlooked Problem in Usage-based Pricing (and How to Fix It) from the A16Z blog, also by Joe Morrissey
Navigating Consumption-Based Pricing with Mike Scarpelli, CFO of Snowflake
Sales Compensation in a Consumption Pricing World, Andrew Straus on the Snowflake blog
Going Usage-Based? It’s Time to Rethink your Sales Comp by Ben Chambers
The Cloud Consumption-Based Model: Changes Sales Leaders Can Make to Ensure Success, Laura Palmer on LinkedIn
Usage-Based Pricing: Behind the Scenes of New Relic’s Transformation, OpenView blog
Google Cloud Considers Scrapping Sales Commissions Based on Deal Values, The Information
Finally, embedded below is a talk I gave at SaaStr on this topic in 2023
When I saw your title, I was like, ah yes I’ve know this problem intimately! And then I saw you worked at MongoDB too haha. Great breakdown and interesting to see what changed over time!