Raising prices can be fraught with peril. Even small price increases can raise revenue dramatically, but if you double the net revenue from each customer and churn more than half of your customers, you’ve lost money. 

‍

So how can you avoid unhappy customers, while simultaneously asking them to give you more money than they did last month?

‍

Highlight increased value early and often

As your SaaS business develops, you constantly add new features that  provide greater value to your existing customers. If you keep customers up-to-date on the ongoing changes to your product (something which, by the way, our friends at Ignition make easy), they’re more likely to recognize that they’ve been receiving more and more value from the software over the term of their subscription. That makes a price increase much more palatable than a sudden announcement, even if the announcement does include a description of those new features. 

‍

Provide advance notice

Messaging is important. If you explain the reason why you’re increasing your prices, it’s more likely that customers will find the change palatable. Even if you don’t provide a detailed explanation, just sending a message well ahead of time that the price will increase can help - you’ve seen this yourself with services like Netflix and Spotify. They don’t give very detailed reasons. For example, Spotify’s most recent increase explains only that:

‍

“We’re increasing the price of Premium Individual so that we can continue to invest in and innovate on our product offerings and features, and bring you the best experience.”

‍

Presumably, Spotify could continue to invest the revenue from their existing rates as well. But by providing a message, indicating ahead of time that the price will change, and giving an explanation (even a shallow explanation) of why the change is coming, they minimize customer churn. 

‍

Blame inflation

Do not actually blame inflation. You’re running a SaaS business, not a cable news network. 

‍

‍

Limit fallout by limiting blast radius

In a perfect world, you’re able to allow existing customers to continue to enjoy the prices that applied when they joined the platform. After all, the acquisition cost of an existing customer is 0 as long as they stay happy, and it makes sense to allow them to share the benefit! 

‍

So if it’s possible, you should distinguish between new customers whose subscriptions have the new price and existing customers whose subscriptions have a legacy price. That way, you can avoid turning existing happy customers into detractors. And if you do decide to raise prices on existing customers, you have plenty of time to remind them of the ever-growing value of your software, and plenty of time to provide advance notice. 

‍

You can also encourage customers to move from the old pricing to the new pricing organically, by restricting that new value you provide to those who are paying for the latest version of the software. This carries with it the happy opportunity to allow customers to avoid paying for new features they don’t want!

‍

Of course, if your codebase is peppered with conditional logic that says things like “If the customer is on the pro plan,” that can be difficult. You don’t want to maintain two versions, and say “If the customer is on the pro plan or the new pro plan,” either. Those multi-clause conditionals end up growing further: “If the customer is on the pro plan or the new pro plan unless the current user is a Saggitarius and it’s Thursday,” and your engineering team will have some choice words for whoever wrote the spec that forces them to maintain such a nasty conditional. 

‍

Alternatively, you can build an in-house system that allows the flexibility to distinguish between your legacy “pro” customer and your new “pro” customer, and to provide entitlements based on the appropriate payment. But I’d like to invite you to consider using Stage, which will allow you to make these distinctions and adjust the conditions without ongoing engineering effort. 

‍

‍