Aligning incentives through software pricing

How much do you charge for the golden eggs from the legendary goose? The eggs are valuable but cost nothing to produce - such is the story of software products.  Once upon a time, the only way to make money at scale was by selling physical products. The pricing of those products has always been constrained by the fundamental condition for profit: the product needs to sell for more than what it cost to produce and distribute. Software has a negligible incremental cost. This allows a more diverse range of price models to emerge and turns pricing into a powerful lever in business strategy.

We’ll go through a framework for evaluating pricing mechanisms, see the trade-offs of common price models like flat rate, per-seat, and usage-based, and look at how they’re combined in practice as building blocks of pricing strategy.

What does each side want:

Seller incentives:

Drive adoption by having price points that maximize revenue without scaring off customers: It can be as simple as choosing the highest total price the customer will pay but is usually more nuanced in a B2B context because companies balance customer acquisition against total lifetime value. It’s common to choose a lower price initial price point to start the relationship and plan on selling more later. The desire for adoption typically drives prices lower and drives freemium and PLG models.

• The seller needs to ensure the things they do monetize don’t impact the product’s ability to deliver value by disincentivizing adoption. For example, Slack needs its users to be able to reach each other and send each other messages for its product to be useful. Slack uses a unique billing model that only charges for active users that we dig into further down.

Revenue expansion:

B2B companies are typically quite top-heavy, so it’s crucial to be able to increase revenue from existing customers [1]. The two main mechanisms are:

• Upselling: Selling larger amounts of the same product. This can be easier or harder depending on the initial price model — usage-based price models have pre-negotiated upsell mechanisms.
• Cross-selling: Selling more features. Most companies that upsell will also eventually cross-sell. Upselling is always more convenient than cross-selling because the seller doesn’t have the overhead of a new feature to market, sell, negotiate and implement, which is why companies find usage-based models so alluring.

Ease of operationalizing: How much work is it to negotiate, billing, and collect the revenue? Companies field surprisingly large billing organizations of dozens to even hundreds of engineers to handle billing - the hard part isn’t necessarily the math; it’s all the baggage that comes with billing, which touches every aspect of the company. Sales need to send quotes, the product team needs to handle provisioning, and the finance team needs reporting.

Justifiable pricing segmentation: A seller can use factors like the buyer’s ability to pay and the value the buyer gets from the product to get to a maximum theoretical price but the buyer needs to ultimately accept the price to close a deal. Arbitrarily charging deeper pocketed customers more is difficult to defend, especially if they learn what the seller charged other customers. More complex price models or feature segmentation often provide more negotiating room to justify a price point. For example, companies will put cheap to build compliance features like auditable user logs or single sign-on in an expensive package because they know those are usually required by large corporations.

‍

Buyer incentives:

• Predictability of costs. Companies need to predict their costs so they can ensure their product is profitable. This results in major pushback on pure usage-based models at every customer size —  smaller companies care because they’re going through dramatic growth anticipate they’ll 2x, 3x each year. Larger companies care because actual usage amounts tend to be quite high.
• Staying within budget - Companies have budgets and approval thresholds and each buyer persona will have a different amount they can personally approve or can get approved without too much difficulty. This is a different point from predictability - it’s around ease of getting approval. Something that requires CFO approval needs to feel obviously useful to the CFO. [1]
• The approval ranges are more compressed than many imagine because start-ups sell often into an out-of-band discretionary budget, not the formal company budget. Many ICs can stand behind a $1k a month purchase but CFO approval can start kicking in around $50k or even $25k a year. Large amounts of money (like should we hire 20 more engineers?) need to be planned typically on a half-year or annual cycle. Higher-ups in the company do influence a lot of spending as they’re involved in that planning process but that’s a longer timeline sales cycle.

💡 Sales note: Money is just one cost associated with buying a solution and one that is relatively easy for a profitable company to pay. Internal buy-in and time from humans outside the buyer’s department are harder. Even a deep-pocketed buyer with authority like a CEO will run into this issue. The CEO doesn’t directly install solutions - they’ll need someone in the company who will agree to be held accountable for it

‍

Price models

Flat rate pricing

With a flat-rate model, the buyer pays a fixed rate monthly or annual and gets access to all the features of the product. In our research, many B2B startups signed their first customers on flat-rate pricing.

Flat rate’s benefits:

• Operationalization: Really easy to operationalize manually. It allows the seller a way to customize prices for each customer without getting bogged down in billing or negotiation logistics that distract the company.
• Budget: Straightforward approval procedures: A flat rate also allows the buyer to operate comfortably within typical corporate operating procedures around approving expenses - people know who can approve a 10k purchase; it’s not clear who can approve a 0.1% of all company revenue purchase.
• Clarity on final monetization, which is helpful for newer companies and products. Sophisticated price models like usage-based require the seller to know which aspects of the product the biggest users are going to use heavily and find acceptable to pay for. For example, one company we talked to monetizes edit actions but they have a large user that only takes a few edit actions and has a huge number of view actions.

Flat rate’s problems:

• Fairness: A single list price will be too high or too low at different stages in the customer journey. This means it’s difficult to publish public prices. List price can be either too high or too low at different stages in customer journey.
• Adoption: Using a flat rate means that the first team to adopt the product has the take full cost of the entire product even if multiple teams use it.  This disincentivizes early adopters and is especially problematic for start-ups that sell into enterprises because department budgets are more rigid.

Per seat pricing

In a per-seat model, each user pays a flat price monthly or annually and gets access to all the features of the product. It’s commonly used in combination with the good, better, best model (GBB) where there are three tiers with access to different features. It’s the standard-bearer of SaaS pricing and typically the first pricing tier for companies that sell directly to a business user as if they were a consumer such as Dropbox, Notion, and Figma.

‍

Per-seat works well SaaS use cases because:

• Revenue expansion: It scales with customer growth in a way that feels fair and safe for the customer. Increases in headcount it is something the customer, not the seller has control over.
• Operations: It’s easy to operationalize collections. There’s an ecosystem of strong providers like Stripe, Recurly, and Chargebee for recurring per seat billing. Large corporations that want to run an exotic price model at scale will often spin up teams of hundreds of engineers to handle operationalizing it.

B2B sellers often find that per-seat falls short because:

Revenue expansion:

• The value of a product is not always associated with the number of seats. Per seat wouldn’t make sense in a situation where a small team at a big company needs a product to do their job. [2]
• It doesn’t allow the seller to scale with its best customers aggressively enough. Regardless of the pricing model, B2B businesses are top-heavy. There’s a narrative that PLG models monetize on the long tail of users but we generally see that top 25-50 customers always drives the lion's share of the revenue. In 2021, Stripe onboarded 1200 customers per day (that’s 500k users added in 2021 alone!) and processed 640 billion in payments. Ayden processed a comparable amount at €516 billion ($590 billion) on a base of several thousand customers [3]. Ayden’s top 10 customers accounted for 29% of all revenue and wouldn’t come close to being 29% of all active users.
• Adoption: It creates misaligned incentives around product usage and user experience. Charging per-seat means the buyer minimizes the number of users but the long-term success of most B2B software involves people at the company actually using the software. Putting a direct cost on users also results in bad end-user experiences where users are using hacky workarounds to share accounts.

💡 What about the O.G. SaaS behemoth Salesforce? Per-seat pricing is a perfect fit for Salesforce because it powers sales teams -  a company’s sales headcount tends to grow linearly with the company’s revenue. It also has a minimal risk that its customers buy fewer seats to save money because its product sits so close to revenue - the default framing for its products is investing money to make even more money.

Usage-based pricing

In a vanilla usage based model, customer are charged for usage of the product so they more of the product they use, the more they are charged.

‍

There’s a renewed focus on usage-based pricing models with Twilio and Snowflake leading the charge. Notably, we see the biggest usage-based pricing in categories like developer tooling, fintech, and infra as a service that don’t monetize well using a per-seat model.

Dev tools companies are part of a larger and incredible development where software has gotten way better and capable of not just assisting a human with something, it’s straight-up doing all the work. In that case, there are minimal users - just human administrators and outcomes! You see this commonly with APIs like Checkr. It’s not just developer tools - Profitwell’s collections product automatically collects overdue invoices and monetizes by charging a portion of recovered amounts.

FinTech and Infra as-a-service products can’t succeed with per-seat because there’s a material underlying cost to serve the product. There’s no way to offer a pure flat rate on these industries as most users would have to pay an extremely high price to subsidize the largest users who are the most capable of paying - it’s the exact opposite of what you want your price model to do. These industries need to be sold per unit for the same reasons physical products have always been sold per unit.

‍

‍

Usage-based billing starts from that same need to ensure the product is sold for a positive margin. However, the scale and ease of distribution of software provide the space for more creative pricing models.

We see that usage-based models are often run on two common variations that are more widely deployed but have parallels in the physical goods pricing. The most innovative companies are deploying new pricing frameworks that allow pricing to support the product and business strategy through deeper alignment on incentives.

Real-world combinations

Platform or per-seat fee with included usage and overage: The customer pays a fixed portion which includes a certain amount of usage and pays an additional rate for any additional amounts above the included usage. This can be deployed for the following benefits:

• Revenue: Increasing revenue from the long tail of customers by ensuring that the seller makes a minimum amount per customer. A pure-usage-based model will often charge much less than what a small customer is actually willing to pay for scalable access to the service.
• Budget: Give the buyer who needs to operate within a budget predictable prices.
• Revenue expansion: Bring the buyer back to the negotiating table if their usage doesn’t scale. The buyer is really paying a flat rate and then the overage exists as a pre-negotiated mechanism to bring the customer back to the negotiating table without incurring the negative sentiment of a naked price increase.
• Preserve margin when some aspect of the end-to-end product experience has an associated cost. For example, a collaborative editor might want primarily want to monetize the editor features but allow users to store as much data as they would like in the state.

Credit burn down: The customer buys a bucket of credits which they spend down in some specified period. This is useful for:

• Budget: Giving the buyer who needs to operate within budget predictability on prices while preserving a more direct usage-based billing model. This is common when selling to a buyer with unpredictable usage patterns. For example, a retail customer might have seasonal demand or a media company might spike heavily when content pieces go viral. These users often prefer to buy a bucket of credits they can spend down.
• Adoption: Customers onboarding onto a platform for the first time might not be able to predict their expected usage over time and don’t want to
• Operations: Enable low friction micro-transactions without losing most of the payment in processing fees. This is more of a consumer software mechanism where the seller wants to monetize a small amount over a large user base that cannot be guaranteed to pay. For example, in League of Legends, you buy Riot Points and then spend them down and on Reddit you buy coins. Credit burndowns are quite a bit of work to operationalize. B2B sellers are usually more confident their customers will pay, it’s easier to let your user run up a tab and bill them on regular amount and time thresholds. For example, Apple will bundle several apps store $1.99 app purchases into one credit card transaction.

‍

🔮 What does the future hold?

Usage-based pricing isn’t the last stop. Pricing models are getting more sophisticated. They’re used to subsidize strategic actions that improve adoption and the customer’s experience.

• Slack runs a fair billing model where customers only pay for a specific definition of active users. Users who haven't used slack in 14 days are considered inactive and credit is given for the unused billing period. Slack’s product depends on network effects so Slack wants to make sure that everyone who a user might want to talk to is available. This mechanism makes it easy for admins to err on the side of giving everyone who might want to use Slack an account.
• Snowflake charges on a lot of dimensions but it’s quite savvy on the pricing. It charges very little to get data into its system (only 6 percent of its revenue) and makes its money when customers query the data.
• Retool, the internal tools editor, charges for active viewers per month, not editors, and limited platform fees. Before Retool’s users can get value from the product, someone technical from their customer’s company needs to create an internal tool using Retool. By making editing free, they make it easy for a user to adopt the product and the price only goes up once the product is firmly established. Interestingly, Figma charges on editors, which is the exact opposite of Retool, and both are multi-unicorns.

Pricing models are a formal way of stating incentives. We think it’s really exciting that the latest generation of incentives celebrates longer-term value-oriented relationships between businesses and their customers.

‍

‍

[1] Some shapes of products don’t have great mechanisms for revenue expansion or a large user base to serve and just have to be expensive. For example, workflow tooling for enterprise finance and legal teams.

[2] There’s actually a whole rabbit hole for who is willing to put the cost in their budget. Fortunate products have a really natural and powerful buyer - Design departments will defend any Figma spend to the last pixel. Productivity software can be harder — everyone uses something like task tracking or docs so why should it come out of the budget from say the engineering department in particular?

[3] Adyen had ~3500 customers on ~300B of revenue in 2020, so I assumed they ~doubled their user base to get to ~several thousand.

‍