How Livestorm went from a license-based pricing model to a usage-based pricing model?
The full story about the various steps we went through to roll-out a new pricing offer when I was a Product Manager at Livestorm
Jul 19, 2024
Today I’m sharing an article with a new more “personal” format. I wanted to share a very important pricing project I worked on as a BtoB SaaS Product Manager.
This project significantly impacted Livestorm, the company I was working for at the time. Additionally, this project played a major role in sparking my passion for pricing topics.
To provide some context:
Before founding Roast My Pricing Page, I used to be a Product Manager in BtoB SaaS businesses. I notably worked at Livestorm, a BtoB SaaS to create and manage your webinars.
I was working as a Product Manager of the Dashboard squad: our team had the responsibility of handling the user experience that was not in the room. This meant all the user flows from account creation to payment with the user flows to create, modify, and analyze your webinars.
Here’s the full story of how we completely revamped our pricing model from a licence-based model to a usage-based model, with detailed descriptions of the steps we went through.
I hope this will help you when you want to run your own pricing page project revamp ;)
How we came up with the idea of a usage-based pricing model?
How does Livestorm’s historical pricing work?
Livestorm’s historical business model is quite standard in the SaaS industry. Customers subscribe to a monthly or yearly plan and the amount of their recurring payment depends on two parameters:
the number of licenses: the number of hosts the customers wants to have in their Livestorm’s workspace. A host is a user who can create, configure, start and end an event.
an add-on: depending on the number of live attendees, customers will pay a more or less expensive add-on (100, 250, or 1000 live attendees)
Self-served customers can subscribe, downgrade, upgrade or cancel by themselves at any time directly from the dashboard. Enterprise customers need to have at least one sales touchpoint for everything related to their subscription. This subscription model has proven to be very profitable for Livestorm since its creation, especially thanks to its very scalable self-served offer.
What issues did we point out with that pricing?
However, we’ve recently realized that this subscription model presented some caveats that we needed to solve:
Password sharing: Customers who had 1 license tended to share the password of their single host’s account. This enabled several employees of a company to create and organize events on Livestorm, despite paying for only 1 license
A deterring pricing offer for meeting use cases: Now that Livestorm supports all types of video use cases, we find ourselves in direct competition with the likes of Zoom or Whereby. These products have a price per license of around 6 to 10 euros, while our price per license starts at 79€/licence. Even for our Enterprise customers for whom the cost per license is way lower, it put us in a difficult position to stack up against the competition
A limited number of hosts per workspace: Because of a price per license that was more specifically tailored for webinar use cases, we ended up having on average around 3 hosts per workspace across our 5000+ customer base. Since Livestorm’s vision is to have everyone in a company using it for its video conference no matter the use case, this number of hosts was way too low to serve our vision.
How did we came up with the idea of a usage-based pricing?
We wanted our customers to be able to invite all of their colleagues as hosts in Livestorm so that everyone could organize events in Livestorm no matter their use case. To facilitate this, we wanted to remove the current friction of having to upgrade to more licenses when you wanted to add other colleagues as hosts on your Livestorm workspace.
And to remove this friction, what better way than simply making it free to have more hosts? This would also mean for us that no team members would share their passwords anymore because it would be free to add other hosts.
This led us to start thinking about switching our license-based pricing to a usage-based pricing model. This was also a trend in the SaaS world that was starting to emerge at the time we thought about it. As explained in this article from Techcrunch, it is predicted that the proportion of SaaS on a usage-based pricing model will be multiplied by 2 in 4 years.
Usage-based pricing is going mainstream
What metric for our usage-based pricing?
A usage-based pricing model is a pricing model that is based on a metric that represents the value your product is delivering to customers. Livestorm’s value is not only to bring people into the same virtual room as you. It also enables you to retrieve leads with qualified information on them (firmographic information, engagement data,…) even if they end up not participating in the live event. These people will maybe end up seeing the automated emails you can customize directly from Livestorm, watching your replay and visualizing your on-demand events. That’s why we came up with the notion of Active Contacts per month:
An Active Contact is a unique team member or an external registrant that interacted with a Livestorm event at least once during the calendar month (from the first day of the month to the last day of the month):
either they registered for an event
or joined a live event or visualized a replay (including an on-demand event)
This was important for us to compute them as “unique” so that 1 Active Contact would become all the less expensive as they participated in as many events as possible in the month. Ex: If the pricing plan cost 99€ and the workspace has 100 team members since all team members would be able to participate in as many events as possible (because we count Active Contact as unique), the price per license would go down to 0.99€ per license. This would put us in a much better position than the competition!
How did we come up with a pricing offer for this usage-based pricing?
Some usage-based pricing model work this way: you track the customer’s usage during a month in your invoicing tool, and then invoice them at the end of the month based on this usage. This is called metered billing, and Chargebee has a way of handling those pricing models.
We did not want to opt for this solution for the following reasons:
we were used to having customers pay us upfront meaning at the beginning of their billing cycle (either monthly or yearly)
we feared that some customers may complain about the way we tracked their usage if they deemed their invoices is too high at the end of the month or the year. We even feared they might end up refusing to pay their invoices.
since each customer would have a different amount on their invoices each month, we would steer away from a standard Saas-based business model where the ARPA takes fixed values.
That’s why we came up with this idea of having customers pay at the beginning of their billing cycle for a max number of Active Contacts per month.
However, this meant for the customer to predict their approximate number of Active Contacts each month. Would they be able to predict their consumption? That’s an assumption that would need to be tested once we have that new pricing offer in production
We started drafting various pricing grids with various unit prices for the Active Contact.
Our data team ran some simulations to iterate over the unit price order to make sure that we would not lower our MRR as well as retain or even improve our margin.
We came up with various proposals which took a lot of time. We wanted to look for the perfect solution. We were stuck because the perfect solution did not seem to exist in theory and we were losing time.
And now what?
That’s when we told ourselves that for this new pricing solution to come out quickly, we needed to build it alongside our customers. This meant coming up with a first perfectible solution that is easy to implement for our customers and iterating over this solution with the feedback from our customers. However, we wanted to keep the following criteria in mind:
no limits in terms of hosts and team members
a usage-based pricing based on the metric we came up with: the Active Contacts per month
a commitment to the maximum number of Active Contacts each month even if it meant for customers to predict their usage beforehand
make it possible to upgrade or downgrade their number of Active Contacts in case customers wanted to iterate over their predictions
How we implemented that new pricing offer for Enterprise customers?
Preparation for the launch
It took us a few weeks to prepare for the launch for Enterprise customers. As explained in the previous example, this first launch aimed to deploy a pricing offer that was not perfect, but that could enable us to verify two main assumptions:
customers could understand the value of this usage-based pricing and effectively subscribe to the offer despite having to predict their Active Contact consumption
customers who subscribed to the offer had on average much more hosts than customers on the former pricing
The sales team worked on a pricing grid specifically for Enterprise customers:
we wanted our customers to be able to choose the most adapted plan for their usage. This meant allowing full flexibility in terms of the number of Active Contacts they could opt for. We thus opted for a volume-based pricing: the customer could choose the exact amount of Active Contacts they wanted. No specific amounts of Active Contacts were imposed.
The only criteria was to have at least 500 Active Contacts. This roughly corresponded to a minimum of 500 MRR which was the minimum requested by the Sales managing team to close a deal
The unit price was fixed within a range to give enough flexibility for our sales team to negotiate. The unit price ranges decreased with the Active Contacts range. Ex: the instructed unit prices would be much higher in the 500–1000 range than for the unit prices in the 2500–5000 range
On the tech side, we worked on a solution to compute the number of Active Contacts per month. The computation needed to follow the exact definition we came up with for the number of Active Contacts. However, we found ways to ship a solution faster:
we decided to compute the number of Active Contacts for each calendar month (first day of the month to the end of the month). This avoided the complexity of taking into account the starting date of a subscription and the various edge cases that resulted.
we did not handle the computation of the number of Active Contacts in the past. It would have taken us too much time to compute historical information. These were not going to be directly used by new customers anyways! In other words, the computation of Active Contacts would start at the time we shipped this new computation process.
Official launch!
In November 2021, we announced that we were launching a new pricing offer only for Enterprise customers.
The official announcement
The sales team started to close customers on this new pricing offer. We needed to adapt quickly.
A lot of training and adaptation to our sales ops processes with our CRM needed to be done. This notably implied adapting the process to manually link a subscription from our invoicing tool (Chargebee) to our customer’s workspace
On the product side, here is what our minimum viable product consisted in:
Our CSM and AM team could monitor the Active Contacts consumption of workspaces on the new pricing directly inside our admin
Customers were not blocked even if they went over their limit. Our AM team just reached out to them to renegotiate their contract in case they went over their Active Contact limit
Our sales team used overrides in our admin to remove the standard limits that workspaces had with the former pricing: no limits in terms of event duration and the number of hosts. The only metric to monitor was the number of Active Contacts
Scaling our new pricing offer
As we had conversations with leads and customers on the new pricing offer, we could already start to validate our first assumption:
customers had to predict their consumption in advance, but it was not that difficult when they roughly knew the number of events and participants they planned to have
customers saw the value of this new pricing offer because there was no more mental load associated with the management of team members
they did not have to swap one license from one team member to another whenever they wanted to allocate the host rights to someone else
they could invite as many hosts as they wanted
We thus started to onboard more and more customers, and we were now faced with a new challenge: scaling our Enterprise offer so that the sales team could handle our growth.
By discussing with the sales teams, and notably the CSM team, here are the following problems that were raised:
Problem 1: customers reached out to ask where they stood in terms of Active Contacts. Indeed, they had no way of monitoring their consumption in the workspace so our customers reached out to our CSM team whenever they wanted which added some workload on the CSM team
Problem 2: Enterprise customers commit to yearly plans (sometimes for more than 1 year) for a given number of Active Contacts per month. However, they sometimes plan a bigger event for one specific month which would make them go way above their limit. They did not want to upgrade to more Active Contacts if the need for more Active Contacts was only for one specific month. It was a common question bubbled up by prospects to Account Executives, and this had an impact on our closing rate.
Problem 3: The sales team wanted to know what they should do in case the customers did not play by the rules and went way above their limit.
To answer these problems, we came up with the following features:
We implemented a gauge in the billing page to display the Active Contacts consumption directly from the workspace.
New billing dashboard
We also implemented banners and alerting emails whenever some milestones in terms of Active Contacts consumption were reached.
Example of banners used in-app to alert customers when they reach thresholds of consumption
We also added the notion of Extra Active Contacts to answer Problem 2. Extra Active Contacts are a “bucket” of Active Contacts available for a year that you can tap into whenever you reach your Active Contacts limit before the end of the month. This bucket of Active Contacts is refilled each year.
Extra Active Contacts
Finally, we implemented a button in the admin for the CSM to enable the blockage of customers whenever they reached their Active Contacts limit in case the customer went too often over their limit.
Implementing Active Contacts limits
Results
These improvements enabled our sales team to close and onboard 50+ Enterprise customers on this new pricing after a few months.
We also managed some very good results in terms of team member management for our customers:
customers on the new pricing have around 80% of their team members who are hosts as compared to 20% for customers on the former pricing
on average, there are more than 6 hosts per workspace on workspaces with the new pricing which is 3x times more than workspaces on the former pricing
This means that we were notably able to remove the barrier that was imposed by the license-based pricing which prevented customers from developing more use cases within Livestorm.
Now that we had verified this new pricing offer worked for Enterprise customers, we were more confident we could come up with a version of this pricing for our self-served customers.
How we implemented that new pricing offer for our Self-served customers
What objective did we set ourselves?
The roll-out of the new pricing for Enterprise customers was a success, even though we had a few challenges ahead of us:
At the time, our pricing page on the website displayed both our former license-based pricing for self-served customers and the new usage-based pricing for Enterprise customers. This led some prospects to opt for the self-served plan on the former pricing instead of the new Enterprise pricing plan because in some cases the self-served plan was simply cheaper. This “cannibalization” of the Enterprise plan by the self-served plan was noxious for our business because we wanted to drive as many customers as possible to the new pricing offer. Also, Enterprise customers commit to yearly plans which was positive for our churn rate.
We wanted to drive more conversion from self-served plans to Enterprise plans. This was strategic for us because Enterprise customers commit to yearly plans thus reducing our churn. True, some features were not available on a self-served plan like SSO-SAML or the Salesforce integration. So self-served customers who wanted at least one of these features had to reach out to the sales team to be converted into an Enterprise customer even with customers on the license-based pricing. However, we considered this was not enough to push a self-served customer to become Enterprise. Thus, we wanted to add a limit in terms of “usage” for our self-served customers. The idea was that self-served customers would subscribe to low usage of the platform, that is a low number of Active Contacts. Then, they would increase their usage with the various use cases customers can achieve with Livestorm and ultimately reach out to the sales team to become Enterprise when their usage limit was reached.
The new pricing enabled us to remove the barriers imposed by the license-based pricing, and we wanted to propagate this improvement to the biggest chunk of our customer base represented by our self-served customers
Thus, our objective was to roll out a new pricing offer for our self-served customers as fast as possible. We wanted to have new users subscribe to this offer, so the aim was to reach roughly the same conversion rates (sign-up to customers) as for the former pricing. We set ourselves to limit that new pricing offer only to new customers, even if it meant having our current customers on the former pricing for now. This would enable us to test that new pricing model to a smaller chunk of our user base.
What problems did we want to solve to achieve this objective?
As a reminder, self-served customers are users who have subscribed to a Livestorm plan without being in touch with our sales team. This means the customer can not rely on a CSM to help them subscribe, monitor their usage, or update their subscription,… Thus, the product needed to be improved in such a way that self-served customers on this new usage-based pricing offer could be autonomous in handling their subscriptions.
This meant answering the following challenges:
adapt the user flow that enables customers to subscribe, upgrade, downgrade and cancel their subscription by themselves to the new pricing offer. We came up with a flow that is very close to the one we had on the former pricing. Indeed, we believed it was not the right time to change the user flow for subscribing to a new plan.
New payment checkout flow
We needed to make the new pricing as easily understandable as possible to reduce the mental load to subscribe to a plan to the bare minimum.
This meant reducing the number of possible plans you could subscribe to. We decided that 3 different plans for self-served customers would be enough.
We also wanted to give enough flexibility to our customers in case they ended up using the platform more than they expected
We chose to opt for a stair-case plan with 3 possible plans: 100, 200, and 500. Free users would be limited to 30 Active Contacts. 30 seemed good enough for us to enable a free user to test out Livestorm’s value proposition. Bearing in mind that we would keep the limitations that we’ve always had on the free plan: no more than 10 registrants per event and a maximum duration of 20 min per event.
We opted for a maximum of 500 because Enterprise plans started at 500: we did not want to keep cannibalizing the Enterprise plan. This choice was also confirmed by our data analysis: based on the first 3 months of 2022, only 6% of our self-served customers on our license-based pricing had consumed more than 500 Active Contacts per month.
We finally ran some more simulations to come up with the precise amounts of the various plan to keep a consistent MRR and margin as compared to the former pricing.
We obviously needed to leverage the website to make this new pricing more understandable. The website team ended up with this pricing page that looks really neat! It uses the 3 key elements to add to a pricing page when you have a usage-based pricing.
New pricing page
We needed the dashboard to help those customers better monitor their usage:
reminding them when they approached their limits: this meant providing more warnings than what we already had for Enterprise customers
blocking customers when they reached their limit since we could not have CSM blocking them by hand like it can sometimes happen in the case of Enterprise customers.
What problems we did not want to solve?
We wanted to ship this first version as fast as possible which is why we needed to restrict ourselves:
we decided not to make it possible for customers on the former pricing to switch to the new pricing offer by themselves.
we wanted to keep the billing page of the dashboard as simple as possible even though we had ideas of how to optimize it in such a way that it would improve conversion. For instance, we thought about adding a gauge that would help the user choose the right plan according to the customer’s predicted usage of the platform. We ended up adding it to the website.
D-Day
The 13th of June was the big day for us. Starting this date, new users who created their workspace on Livestorm could only subscribe to this new pricing offer.
Internal announcement
We were on the alert waiting for our first customer to subscribe until this notification popped up around 1 hour after the release was in production:
First customer on the new pricing
After a bit less than 1 month, we’ve managed to acquire around 110 customers on a self-served plan. It is difficult to draw some conclusions after only 1 month but we can already start to witness some trends.
It is interesting to see that customers do manage to predict somehow their usage, even though a lot of them start on a 100 Active Contacts plan. This is one of the powers of usage-based pricing: it enables your customers to start small, capture quickly the value of the product and then upgrade their plan as usage increases. Indeed, a bit more than 15% of self-served customers have already upgraded their plan at least once.
We will keep monitoring this ratio of upgrades, notably customers who end up subscribing to an Enterprise plan because their usage goes above 500 Active Contacts. In that regard, we now consider our self-served plan as a “high qualification” tool for our sales team to close more Enterprise customers.
What we know for sure is that despite being perfectible our new pricing offer is ready to be spread out to all our customer base. This is why one of our current big initiatives for the current quarter is to propagate this new offer to customers on the now legacy pricing.
