Customer-centric Growth by Lincoln Murphy

SaaS Pricing Model: Mo’ Money, Mo’ Problems

mo-money-mo-problemsThis is a post about SaaS pricing models… but it starts with a story about human behavior.

We all know that money doesn’t buy happiness – it buys freedom, and it’s with that freedom that you can choose to do things that make you happy. Money is just the means.

But quite often, as people and companies start to get more money, they run into problems… their lives and businesses start to become more complicated creating a situation counter to their original goals.

In this post, we’ll explore how to use this idea of “Mo Money’, Mo’ Problems” (shout out to the Notorious One) to create a more effective – and profitable – SaaS pricing model.

As we grow up we realize that ‘stuff’ isn’t the most important thing in the world – that when pressed for why we’re working so hard on our businesses, or why we’re killing it every day at work, it isn’t to have a bigger TV, or a fancy sports car, boat or giant house.

Rather, it is the experience that those things might allow us to have with family, friends, and our employees or co-workers that matters. It is the people – and experiences with those people – that are the real reason we work so hard.

Complexity Creates Obstacles

But what’s interesting is that as people start to get more money, they run into more and more problems; this applies to businesses as well.

Maybe those are things to do with compliance, operational efficiency, etc. Maybe those problems are actually opportunities that they cannot take on right now but want to.

While “more money” usually means an increase in revenue, it does not necessarily mean “more profit” – but it usually means more *complexity* which equates to more overhead, more employees, less efficiency, more headaches, more time away from family and ultimately less happiness.

Sort of the opposite of all of our goals, right?

Putting the Value in Value Pricing

So when I’m helping SaaS & Web App companies – startups or established alike – with their pricing strategies, I like to see if there is a way to scale pricing not with the size of their customer – revenue, employees, etc. – but with the complexity of the customers’ organizations.

For some Apps, this isn’t going to work or matter – but in a lot of cases, we can see a direct correlation between the types of customers and the complexity of those organizations as it relates to the problem being solved by the App and their willingness to pay.

In other words, as an organization grows its revenue, the side effect of that growth is that the complexity of the organization – human resources, operations, finance, everything else, grows too.

This is a perfect example of “Mo’ Money, Mo’ Problems.”

Complexity Creates Opportunities

And there’s an opportunity for you if you can come in and eliminate or reduce those problems so they can enjoy that new money!

So while having more revenue might seem like a blessing for your customers, if that suddenly means more work and more stress, that extra money might not seem worth it.

Don’t you think people would be willing to pay if you could help them reduce complexity? It seems logical that the more you can help them with the complexities of their business the more they would pay.

As I said, this won’t apply to every App or every situation, obviously, but if you haven’t considered this idea, you should take a look at it.

While small and medium-sized businesses certainly feel this pain more than larger organizations simply because it’s new to them, every company goes through this.

Remember that you’re selling to human beings regardless of the size of the company. What motivates them as people? Figure that out and you’re golden.

How does this play out in your SaaS business, though?

A Thought Experiment: Per-Seat Pricing

Let me present an example of applying this complexity-based thinking when you’re building your SaaS pricing strategy – or even if you already have it in place.

Let’s say you offer all features to all customers, but differentiate pricing bundles or versions with a  metric like “number of users.”

While user-based pricing is certainly very common – a carryover from enterprise software “per seat” pricing – it could actually cause you miss out on a lot of profit.

Let’s assume you have these two subscribers:

There are a lot of things going on here, let me break it down for you.

  1. The smaller organization is likely using more features and functionality within the system because they need access to all of that… but they’re paying LESS – due to your pricing model – than the larger organization who is likely using only the basic features
  2. The smaller organization might increase their usage of your product if they had unlimited users, but since you put a value on a user and not what they find value in, they’ll just keep the smaller account, perhaps sharing logins or otherwise gaming the system to keep from having to upgrade. You created an artificial usage barrier.
  3. This may seem illogical if they’re getting value from the system, but it’s because you put a value on a metric that they don’t find value in and that’s how they’re determining their usage of your product.
  4. The larger organization may also find value in having more people in the system – and perhaps a subset of those would need the more advanced features – but they won’t add users because that will cost more. By misaligning your pricing, you’ve created an opportunity for a price objection and – as well – created a barrier to expansion within the organization.
  5. If you changed your thinking to align with the complexity of the organization, you would remove barriers to adoption and instead align price with where they actually get value
  6. By aligning your price with what – in this example – is a low-value metric, you created a low-value position in their minds for your otherwise super-valuable product. This resulted in neither company being willing to pay you more since “number of users” isn’t where they find the most value

If you scaled your pricing with the complexity of the customer organization, you would have sold the cheaper version with fewer features and unlimited users to the company that previously paid for the 50-user level and sold the substantially more expensive version with unlimited users to the company that is more complex, instead of the 2-user version.

Wait… that sounds like I’m saying charge the 50-user client less than the smaller subscriber. That’s not it at all.

I contend that by aligning better with the value perceptions of the customers – in this case, their complexity – each company would actually pay MORE in this scenario – both initially and over time, driving up your Customer Lifetime Value (LTV) with it – because you priced based on perceived value and not some low-value metric like “number of users.”

It’s hard to talk about this in generic terms, so I’ll tell you a real story. Gather ’round, kids.

Beware the “Seems Like” Value Metric

Here’s an example from a company that didn’t start with per-user pricing… and still ended up in this same dilemma; a  shipping and fulfillment SaaS vendor.

Their pricing was based on the number of packages the customer shipped each month, but all customers got access to all features.

On the surface, “number of packages” seems like a pretty safe metric to go with.

That seems like it would be a value metric.

For an e-commerce company shipping packages to customers from their warehouse, you’d think a package is the key metric to peg off of.

But, consider these two types of customers:

  1. A company that ships novelty items with an average value of $5, but ships 100,000 packages/month
  2. A company that ships electronics with an average value of $5,000, but ships just 300 packages/month

Said that way, what we thought was a pretty safe metric to price off of… isn’t.

The second company – though their volume is significantly smaller – has greater needs. They need to be able to rate shop, buy insurance, deal with customs, etc. while the first company just needs to move product, probably with just one carrier.

What if this SaaS vendor offered pricing that included “unlimited packages” but instead priced around functionality tied to organizational complexity?

The first company in the example above might pay the same, but company two would pay more for access to the functionality they need.

And because you’re aligning with an understanding of how they operate, the more complex company will be willing to pay for the additional functionality.

A couple of other examples of aligning pricing (and offerings) with complexity are:

But… what if no one else has ever done this? How would you look at complexity-based segmentation in your pricing?

A great place to start is remembering this:

The main thing here is to just get you thinking.

That said…

Price Objections are Value Objections

So, when you start matching your pricing model to the needs of your customers – in this case scaling pricing tiers with the growing complexities of an organization – you are aligning with metrics that the companies and the decision makers inside the organizations will find the most value in.

The higher the value perception, the higher the willingness to pay.

They have Mo’ Money and Mo’ Problems… and now there’s Mo’ Money for you since you helped them fix that by clearly understanding their value perception.

Oh, and since you fixed this on your Pricing Page and streamlined your sales process, this additional money you now have was generated through no additional effort, stress, or time and takes you one step closer to your goals of freedom and a better life!

Exit mobile version