InsightLab Perspective  •  SaaS Pricing

Should You Charge for Usage?

How to test the right SaaS pricing model before changing what customers pay for

SaaS pricing is getting more complicated because the products themselves are changing.

For a long time, charging by the seat made a lot of sense. More employees usually meant more people using the product, more activity and, at least roughly, more value.

That relationship is starting to break down.

An AI agent can complete thousands of tasks without a company adding a single employee. Software can process more data, automate more workflows and complete more work while the number of users stays exactly the same.

So it makes sense that more SaaS companies are looking at usage-based pricing.

But that doesn't mean usage is automatically the answer.

Before changing the pricing model, I would want to know whether the proposed usage metric actually represents customer value. I would want to know whether customers understand it, whether they can predict their bill and whether charging for usage changes how they use the product.

So instead of starting with Should we move to usage-based pricing?, I would start with:

Start With What the Customer Is Actually Buying

Before deciding how to meter a product, I would first understand what customers believe they are buying.

Take an AI customer-service platform.

You could potentially charge for users, conversations, tokens, AI actions, tickets, successful resolutions or simply access to the platform.

All of those things can be measured.

That doesn't make all of them good pricing metrics.

Tokens may be closely connected to the company's costs, but customers may not care about tokens at all. Successful resolutions may be much closer to the value customers receive, but they can be harder to measure and predict.

This is why I would start with the value exchange rather than the billing system.

What creates value for the customer?

Then:

What can we measure that moves with that value?

A good pricing metric doesn't have to measure value perfectly. But it should be connected to value, understandable, measurable and reasonably predictable. Customers should also have some control over it.

And ideally, it shouldn't encourage customers to use less of the product.

There Are More Options Than Just Seats or Usage

There isn't one SaaS pricing model that is always better than the others.

Pricing Model 01

Subscription

A fixed subscription works well when customers value ongoing access, costs are relatively stable and customers want to know what they are going to spend.

That simplicity can be a real advantage.

Customers can use the product without wondering whether every additional action is going to increase the bill.

Subscription becomes more difficult when customers create dramatically different amounts of value or cost while paying roughly the same amount.

But even then, the answer may not be to abandon subscription pricing. The problem could be the tiers, packaging or value metric.

Pricing Model 02

Seat-Based Pricing

Seats still work when the number or type of users actually corresponds with value.

For collaboration software and many workflow products, that can still be perfectly reasonable.

The problem comes when automation breaks the connection between users and value.

If five people using an AI-enabled product can accomplish what previously required fifty people, charging for five seats probably isn't capturing what has changed.

Pricing Model 03

Usage-Based Pricing

Usage pricing works best when more consumption generally means more customer value.

Transactions, API calls, data processed, messages and other measures can all work if customers understand what they are buying and have some control over how much they use.

There is a nice logic to it.

Customers can start small. If they receive more value and use more of the product, spending grows with them.

But there is also a potential problem.

If customers know every additional action costs money, they may start looking for ways to reduce usage.

That can put the pricing model in direct conflict with what the company actually wants: more adoption and more use of the product.

Pricing Model 04

Outcome-Based Pricing

Another option is to move even closer to the customer's result.

Instead of charging for what the product does, charge for what the customer accomplishes.

An AI support platform might charge for successful resolutions instead of tokens. A recruiting product might charge for qualified candidates.

I like the logic behind this because price becomes much more closely connected to value.

The challenge is making sure everyone agrees on what counts as an outcome and who deserves credit for it.

If the outcome can't be measured clearly and consistently, the pricing model can become difficult very quickly.

Pricing Model 05

Hybrid Pricing

Hybrid pricing tries to balance predictability and usage.

Example

$500 per month including 5,000 transactions, then $0.10 per additional transaction.

The customer knows what the normal bill should look like. The vendor gets predictable recurring revenue. And spending can still grow when usage grows.

For many SaaS companies, especially those with meaningful variable costs, this can make a lot of sense.

But hybrid doesn't solve the most important question.

You still need to know whether you are charging for the right thing.

Don't Just Ask Customers If They Want Usage Pricing

This is where I think pricing research becomes especially important.

You could simply ask customers:

"Would you prefer predictable subscription pricing or usage-based pricing where you only pay for what you use?"

But I wouldn't put much confidence in the answer.

The wording alone can influence the choice.

Instead, I would build the evidence in stages.

  1. Understand Value

    Does usage actually correspond with customer value?

  2. Test Understanding

    Do customers understand what they would be paying for?

  3. Test Predictability, Control and Fairness

    Does the model feel manageable and reasonable from the customer's point of view?

  4. Measure Willingness to Pay

    How much will customers pay once the offer and pricing metric are clearly understood?

  5. Make Customers Choose

    Which architecture wins when customers have to make realistic tradeoffs?

  6. Reprice Existing Customers

    What happens when the proposed model is applied to actual historical usage?

  7. Watch What Customers Actually Do

    Does the pricing model change conversion, adoption, usage, expansion, retention or margin?

1. Understand Value

The first question is:

Does usage actually correspond with customer value?

This is where I would start with qualitative research.

Customer interviews, Jobs-to-be-Done interviews and value mapping can help uncover what customers are trying to accomplish, which outcomes matter and why one customer might receive much more value than another.

You can also estimate economic value.

Does the product save labor? Generate revenue? Reduce errors? Save time? Reduce risk? Increase throughput?

At this point, I wouldn't be trying to determine the price.

I would be trying to identify a few reasonable things we could charge for.

Maybe we start believing transactions are the obvious answer and discover that customers think almost entirely in terms of completed workflows.

That would be important to know before rebuilding the pricing model around transactions.

2. See Whether Customers Understand It

Once there are a few reasonable pricing metrics, put them in front of customers.

Example pricing concepts

Option A
$500 per month

Option B
$100 per month + $0.25 per transaction

Option C
$400 per month including 2,000 transactions + $0.15 thereafter

Then talk through the choices.

Which one is easiest to understand?

Which feels most connected to value?

Which would be easiest to budget?

What makes them uncomfortable?

Could they estimate what they would spend next month?

What happens if their usage doubles?

I think those conversations can uncover problems that aren't obvious when you are building the pricing model internally.

3. Test Predictability, Control and Fairness

A pricing model can make perfect economic sense and still make customers uncomfortable.

Imagine one option costs $12,000 per year.

Another will probably cost around $900 per month but could occasionally reach $1,500.

The second option might actually cost less over the course of the year.

Some customers will still prefer the first one.

And that isn't necessarily irrational.

Knowing what something will cost has value.

That's why I would want the research to look at more than willingness to pay. I would also want to understand whether customers believe the model is fair, whether they can predict it and whether they feel they have control over what they spend.

4. Measure Willingness to Pay

Once customers understand the offer, more traditional pricing research becomes useful.

Gabor-Granger can help estimate how purchase likelihood changes at different price points.

Van Westendorp can provide directional information about what customers consider inexpensive, acceptable, expensive and too expensive.

Both can be useful.

Before worrying about whether a transaction should cost $0.10 or $0.20, I would want evidence that transactions are actually the right thing to charge for.

5. Make Customers Choose

This is where conjoint or discrete-choice research can become really useful.

Instead of asking customers whether they like usage pricing, give them realistic alternatives.

Offer A Offer B Offer C
Base fee $500 $200 $350
Included usage Unlimited 2,000 5,000
Overage None $0.15 $0.10
Spend cap N/A $800 $1,000
Contract Annual Monthly Annual

Now there are tradeoffs.

Customers have to decide whether a lower base price is worth more uncertainty. We can see how much included usage matters. We can test whether a spending cap makes usage pricing more attractive.

And we may find that different types of customers make very different choices.

That tells us much more than asking whether people "like" usage pricing.

6. Reprice Your Existing Customers

Research shouldn't stop with what customers say.

If you already have usage data, use it.

Take the last 12 to 24 months and calculate what every customer would have paid under the different models.

What would they have paid under subscription?

Under seats?

Under usage?

Under hybrid?

Then look beyond the average.

Which customers get a big price increase?

Which get a decrease?

How volatile are the bills?

What happens to gross margin?

What happens with seasonal customers?

What happens with your biggest and best customers?

A model can look great when you look at total revenue and still create some pretty serious problems when you look at individual customers.

I would rather discover those problems in the analysis than after the invoices go out.

7. See What Customers Actually Do

Eventually, we need to move from what customers say to what customers do.

Pilot the pricing model with a defined group of customers or prospects.

Then watch what happens.

Conversion. Adoption. Usage. Expansion. Billing questions. Retention. Margin.

And there is one measure I would pay particularly close attention to:

Suppose the research looks great.

Customers understand the metric. They tell us it feels fair. The economics work.

Then the pilot launches and usage falls 20%.

I would want to know that.

Because the pricing model may be doing exactly what we designed it to do financially while encouraging the opposite of what we want customers to do.

Let the Evidence Narrow the Decision

The goal of all this research isn't to prove that usage pricing is better.

It's to figure out which model actually fits.

Maybe usage is strongly connected to value and customers have no problem understanding or predicting it.

Great. Usage pricing may be the answer.

Maybe usage is connected to value, but customers really dislike the uncertainty.

That might point toward hybrid pricing, included allowances, committed usage or spending caps.

Maybe customers care much more about outcomes than activity.

That could make outcome pricing worth testing.

Or maybe customers value broad access, costs are stable and usage is unpredictable.

In that situation, a subscription may still be the better answer.

There is nothing outdated about a simple pricing model if it fits how customers receive value.

And the Answer May Be Different by Customer

There is one more possibility I would keep open.

There may not be one pricing model that works equally well for everyone.

A smaller customer may like a low starting commitment and the ability to pay more as they grow.

An enterprise customer may be perfectly willing to commit to significant spending but care much more about knowing exactly what next year's budget will be.

A high-volume customer may want committed usage and volume discounts.

Another customer may prefer unlimited usage because they don't want employees thinking about cost every time they use the product.

At that point, this becomes a segmentation question as much as a pricing question.

Not just:

Which pricing model works?

But:

Which pricing model works for which customer?

Don't Start With the Meter

AI and automation are giving SaaS companies good reasons to rethink traditional pricing.

But they aren't telling us what the answer should be.

Usage pricing can create a much better connection between price and value. It can also create uncertainty and encourage customers to use less.

Subscription can leave money on the table. It can also give customers simplicity and the freedom to use the product without watching a meter.

Hybrid can balance the two. Outcome pricing can move price even closer to value.

I wouldn't start by choosing one.

Then I would use customer research, pricing research, actual usage data and, where possible, a live test to find out.

Because the goal isn't to find the newest pricing model.

It's to find the one that makes the most sense for the customer and the business.

Test the pricing model before you roll it out

Find the pricing model that fits how customers actually receive value.

InsightLab can help identify the right value metric, test pricing architecture with customers and model what a change would mean before it reaches the market.

Start a conversation