Choosing the wrong pricing model can kill your SaaS business, or at least hamper your growth.

One of the big decisions to make is between a seat-based model (how many human beings are using the platform) or a usage-based model (how much do your customers use your product).

As AI products and modules get rolled out and disrupt the concept of what a ‘user’ is, vendors like you are taking another look at how they monetise their platform - but its not an easy decision to navigate!

Seat-based model

Also called a user-based model.

Examples of this are Salesforce, Workday, Google Workspace - you pay for the number of people that you want to have an account.

Each of these products is a company-wide platform - every employee gets Gmail and Google Calendar, every salesperson gets CRM.

There is little decision for the customer to make when they hire (or layoff) team members - “we need more (or less) licences”.

Usage-based model

Also called a consumption or transaction-based model.

Examples are the main cloud platforms - Azure, AWS and GCP, data platforms like Snowflake and Databricks, communications platforms like Twilio, or financial platforms like Stripe.

It doesn’t matter how many people use the platform (probably a smaller number of developers and data analysts). Instead, the platform is charged on how many transactions are put through:

Data volumes stored
SMS’s sent
Dollars processed

The companies listed above are quite clear cut in which model is best. And indeed multi-product companies like Google have different models for different products (GCP and Adwords - usage based, Google Workspace - seat based)

But what happens when it is not so clear which model to choose? Imagine a product that does not HAVE to be used by every employee.

To keep things simple - let’s assume that an average seat consumes 100 transactions per annum, and a seat is charged at 100 times the transaction cost. i.e. there is no commercial difference between the two models if users follow the average usage.

Challenges with the seat-based model

The seat based model is tempting from a Chief Revenue Officer perspective - as you can charge more today, and typically lock in the revenue up front.

But, having sold your initial deal you now face two options to grow your revenues.

Increase the ARR from your existing users.

The challenge here is that because you are on a user model, you can’t charge them more just because they are heavy adopters - as a Gmail user you can send as many emails as you like, or a Salesforce user you can create as many opportunities as you like.

Instead, you need to launch new products, either to cross-sell, or to roll into the core product to allow you to increase pricing at renewal - both long term strategies.

Sell to new users.

You may have sold the initial deal as a land and expand - “let’s get this one in, then we can use it to promote into other teams”.

But the problem with a seat based model is that a user is ‘all in or all out’.

To commit to bringing on a new user you need to be confident that that human will use the average 100 transactions, otherwise you are not getting good value from your licence.

This makes it very hard to roll out pilots and proofs of concept in new business units or regions.

Signs you have hit this problem including hearing:

“Let’s start with just two people in the team”
“Let’s have one account and ask everyone to share it”
“Let’s forward the work to the one person with the licence”

These are behaviours that slow adoption and often end up with a failed pilot and a stalled roll-out - people just carry on working as they did in the past.

Challenges with the usage-based model

You might be thinking - ok, let’s just do the usage-based pricing then - but this comes with its own set of challenges that aren’t apparent on a pricing model spreadsheet.

How long is a piece of string?

If I ask you how many employees you have you can tell me.

If I ask you how many salespeople you have you can tell me.

If I ask you how many AI prompts you’ll write or how many e-signatures you will complete next year you have no idea - and this makes it hard for you to budget.

Your customer can make an assumption - but they will likely make an assumption, and financial commitment on the low end - after all, they can always buy more later.

This puts your sellers and your customers on opposing sides.

Your sellers are trying to convince your customers why they should buy more, and your customers are trying to convince your sellers why they can’t commit to that.

It costs every time you use the platform

The beauty of the usage based model is you only pay when you use the platform.

But the hidden danger is the reverse - every time you use the platform you pay.

As your product gains traction and is used in more use cases and teams you will see adoption soar.

But remember, your customer created a pessimistic budget and is now seeing that budget blown out of the water.

Now instead of being overjoyed with the success of the project, they are looking at ways to limit its adoption.

You’ll know you have hit this problem when you hear:

“Do we need to do this on the platform?”
“Could we consolidate this into one job?”
“Let’s push back that team’s roll-out until the next financial year”

Listen to your customers

There are nuances in your business - your target customer, the type of product you offer and how much you charge.

So speak to your customers and ask them:

How do they want to use your product?
How do they budget for a solution like this?
How do they decide or limit who has access?
How do they plan to run pilots and proofs of concept?
What happens if usage is higher or lower than they expect?
What would they do if they needed more users/transactions than budgeted?

Getting an idea for how your customers plan to budget for and promote your product will help guide you.

Split test

This can be hard to do publicly, but if you already offer one model, then try offering the other model to a subset of customers on a limited test basis.

“We normally charge you by the user - but for a small set of customers we are offering a transaction based model….”

Create a hypothesis around how the alternative model will change the customer behaviour and monitor over the course of a year. Decide whether to implement the test more widely.

Get started

Whenever you are ready, there are three ways that I can help you accelerate your revenue.

Buyer Enablement Assessment - Answer nine questions in five minutes and receive your free personalised report to help you SDRs and AEs generate pipeline.
Revenue 360 Assessments - inspire and lead your revenue teams with revenue specific 360 reports designed for marketing, sales and customer success teams.
Buyer Enablement Platform - We’ll design, build and manage your buyer enablement platform on your behalf - generating quality pipeline in under 90 days.

Deciding between seat-based and usage-based pricing