Competition in SaaS is ever-growing. Every week, there’s a new Slack, a new Zoom, or a new Figma launching.
Your buyers’ experience has a massive impact on what sets you apart from your competitors.
In fact, Gartner found that companies that deliver great buying experiences grow twice as fast as companies that deliver average experiences.
Allowing customers to easily choose the plan that best fits their current needs is crucial to retain and grow your customers base - upgrades as well as downgrades.
However, most changes in a customer’s plan won’t happen exactly at the end of a billing period. Buyers don’t wait. In times where outstanding buyer experiences can be a competitive advantage and ‘fair billing’ becomes a promise companies actively make to their customers, this needs to be well thought through and technically set up.
Building Stigg, we put a lot of emphasis on research. In this article, we’re sharing our findings of researching how companies like Slack, Zoom, GitHub, and Airtable handle upgrade and downgrade flows for their customers.
What are upgrades & downgrades in SaaS
Let’s start with some definitions.
Upgrade describes the process of a user switching to a higher-priced option. That can be the switch to a higher tier, a longer commitment (monthly to annually), buying more units (e.g. seats), buying add-ons or buying more quantities of an add-on.
Downgrade, on the contrary, is the switch to a lower-priced option, such as a lower tier, shorter commitment (annually to monthly), reducing the unit quantity (e.g. reducing seats), removing an add-on, or reducing the quantity of a specific add-on.
Proration refers to the technique of charging your customer accurately for the portion of your product or service they have used. This is a core element in “fair billing” in the SaaS buyer experience, taking into account a customer’s actions, i.e. upgrades /downgrades, to change the terms before a billing cycle ends.
A look at best practices: How Slack, and Co. handle their upgrades & downgrades
Building Stigg, we’ve done a lot of research on how the top 40 leading SaaS B2B companies define their upgrade/downgrade flows. Here is what we found:
So, a customer decides to upgrade their current plan. Great!! How do you bill that, though?
The vast majority of leading SaaS companies, like Zoom or Productboard, prorate upgrades immediately. This means, the customer gets access to their higher-priced option and will be charged the difference for the rest of the billing period immediately.
A few exceptions, like Loom, support a true-up model charging the difference at the end of the billing period, instead. This model is recommended if you expect your customers to make more frequent upgrades and you want to prevent multiple charges on the credit card within a billing period. Supporting a true-up model requires a separate look at annual plans. It is common practice and preferable for businesses to charge the difference for an upgrade within annual plans in the upcoming month instead of the end of the year.
Another special case you’ll need to define, if applicable, is conversions from a free trial. Charging those customers immediately creates commitment right away (= less time to regret) and gets money into your bank earlier. However, businesses like Airtable decide to let their trial users complete the trial period before charging for the plan they chose to commit to. It may appear as ‘more fair’ to your customers. On the downside, it gives your customers more time to regret and cancel the conversion before the first billing period starts.
It’s inevitable that some of your customers don’t find enough value in their current plan. While repackaging can mitigate some of those potential churn, you’ll need to give customers a simple way to downgrade, too. Or else, you risk losing them completely.
Also in downgrades, there are two main ways to choose from:
- Downgrade immediately and grant credits for the remaining time of the billing period, like Slack, or Notion
- Scheduling a downgrade to take place at the end of the current billing period, like Zoom, Trello, or GitHub
Allowing customers to downgrade immediately and granting them credits they can redeem in the upcoming invoice may be perceived better by your customers. Slack calls it ‘fair billing’. However, this option is much less favorable to your business as this is a loss in revenue.
We found that a slight majority of businesses chooses to apply downgrades only at the end of the billing period.
While better for the business, scheduling downgrades requires a much more advanced technical setup: you’ll need a mechanism to schedule the downgrade for the right account, to the right plan, at the right time, and communicate the scheduled downgrade to the customer in your self-service components, such as your customer portal.
A common workaround we saw in startups is to build an integration on top of Stripe. There are many good reasons why billing should be separated from entitlements, but we found that specifically when supporting downgrades to a lower tier as opposed to canceling the plan leads businesses into a webhooks-related nightmare.
Supporting one or multiple changes at a time
How many changes do you allow your customers to do for every update in their plan? The majority of companies limit their customers to one change at the time.
However, we have seen a couple of exceptions. Postman, for example, allows multiple changes at the same time and lets their customers decide to roll them out immediately or in the next billing period. This enables customers to, for example, downgrade to a lower tier and buy more seats at the same time. In this case, companies refrain from scheduling changes. These changes take effect immediately.
Edge cases to consider
Pricing is dynamic, things change. Let’s zoom in on a few edge cases your system might face when supporting different customers in their upgrade/downgrade journeys:
Edge case 1: Your customer requested to downgrade to a lower plan and then adds more seats, before the scheduled downgrade takes place.
You don’t want to tell a customer, who’s ready to buy more of a feature, that they cannot. In Stigg, we’ve solved this by making the seat change effective immediately, charging the prorated account until the next billing period, and modify the scheduled update to reflect the updated seat count. Note: If you’ve built your pricing exclusively on Stripe, unfortunately this is not supported. You’ll need to cancel the scheduled update and add a modified one.
Edge case 2: Your customer is scheduled to downgrade to a plan you want to change.
Will your customer get access to the plan that they saw during their downgrade request or will they get access to the latest version, instead? This is a strategic decision, but one your business can only make if you support plan versioning in your codebase in the first place.
Edge case 3: Your customer chose to downgrade, but then requests to cancel the scheduled downgrade.
This is something you’ll want to support. Imagine, your customer regrets their decision to downgrade to a cheaper plan, or cancel their account all together, and you can’t stop the scheduled downgrade… It will also allow you to create better, long-term oriented buying experiences, because you can easily support customers who regret their upgrade.
Special case: Usage-based pricing
Usage-based pricing allows your customers to pay only for what they consume of your product or service. This pricing model has been gaining popularity for the past few years and is still expected to grow in 2023.
A famous example is Stripe that charges per successful card charge, allowing smaller companies to start at a comparatively lower cost and pay in accordance to the value they extract from Stripe’s product.
If you support usage-based pricing, upgrade and downgrade behaviors are predefined, by nature. Changes will always be immediate, as a customer makes a change in their pricing plan.
Competition in SaaS is ever-growing. Buyers expect seamless experiences and maximum flexibility in changing their pricing plan, whenever they want.
The first step in providing this experience to your customers is to thoroughly define your company’s upgrade & downgrade flows.
Next, and not less complex, is to build the technical infrastructure to support your defined flows. We’ve spent an immense amount of time and effort enabling upgrades and downgrades out-of-the-box within Stigg. In part 2 of this series, our engineering team will share their 5 most crucial learnings, to help you build better upgrade & downgrade flows faster. Stay tuned!
*** *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** ***
If you can’t wait till the second part drops, or already know you don’t want to build the entire infrastructure yourself, start your free Stigg account here and define best-in-class upgrades & downgrades, with minimum engineering resources.