Last week, Tim Bryan (CRO) and Brett Robbins (Head of BD) of Custora joined us in the Bowery Capital studio for another episode of the Startup Sales Podcast: “Choosing Your Scaling Units in SaaS Pricing.” In our podcast, we discussed a critical element of SaaS pricing: choosing the proper “unit” by which your SaaS pricing model should scale. Some example scaling units include: per employee (a model used by many HR tech businesses), per GB (used by many enterprise storage providers), per customer or contact (used by Custora and Hubspot, respectively), and many others (an interesting example is Amazon Lambda’s per millisecond model). Many SaaS pricing models include a layer on top of this scaling unit that breaks packages down into consumable, easy to understand “tiers.” In a series of articles to come, I’ll discuss tiers and many other aspects of SaaS pricing models you’ll want to think through. For the next few posts, however, we’ll focus squarely on the underlying scaling unit and how to choose the right one. In our recent episode, Tim, Brett and I broke the scaling unit issue down into 5 key considerations: (1) aligning with value; (2) aligning with product; (3) aligning with sector; (4) testing the model; and (5) evolving the model over time. This post will delve into the first of these considerations: Aligning with Value. In the next 4 posts, I’ll cover off on the remaining 4 and demonstrate how each ties into a framework you can use to help determine the scaling unit that’s best for your business.
(1) Aligning with Value
Most effective SaaS pricing models align cost with value delivered to the customer. In other words, as dollar pricing for the solution scales up, so too should the value the user company is receiving from the product. In our podcast, Tim and Brett shared a great example. Custora leverages historical purchase data from its customers (who mostly operate in the retail sector) to better help them predict lifetime value, including the likelihood of retention, future purchases, etc. The platform ingests large amounts of this data in order to provide accurate predictions and insights back to Custora users. There are many potential scaling units Custora could have chosen to underpin its pricing model. Let’s walk through a few of them: (a) $ / seat; (b) $ / GB; and (c) $ / customer.
(a) $ / seat: This is a pricing model quite common to SaaS businesses. In this case, however, it doesn’t align with value delivered to Custora’s customers. Only a few users may actually be responsible for interpreting Custora’s insights or directly logging into the platform, whether the customer business is doing $10MM or $100MM in revenue. But forecasting CLTV for the latter business is going to bring significantly more business value. (b) $ / GB: This unit might make sense for Custora because it’s likely that the scale of insights delivered would line up with the amount of historical customer data the platform is processing. So we’re getting closer. That said, more data is required for Custora to be able to deliver more accurate results, like many machine-learning driven software solutions. So choosing a per-GB scaling unit would in fact disincentivize a customer from uploading more data to the platform, and have an unintended negative consequence: penalizing the customer for using the product to its fullest extent. Add to the consideration set that more data means more learning for Custora’s data scientists, and you can see why (b) isn’t the right choice. (c) $ / customer: This unit would result in a SaaS pricing model that scales with the number of end-customers that Custora’s user accounts have. In other words, a retailer with 50k consumers purchasing each month would pay ~5x more than a smaller retailer with only 10k monthly buyers. Again, we’re getting closer. But let’s think about the value users are seeking to extract from Custora: oversimplified, this boils down to better predicting who will buy and how often. If the retail customer’s number of buyers decreased from one period to the next, they would be charged for a that higher number of customers despite the decline in top-line. For this reason, Custora realized that the best scaling unit for their SaaS pricing model was in fact active customer. A $ / active customer model ensured that if active customers (i.e. buyers) were increasing–Custora’s ultimate core value proposition and one tied to the overall revenue of its users–then the solution was delivering, and only then would the price increase.
To get a sneak peak on the other 4 steps, make sure to listen to last week’s podcast with Tim Bryan and Brett Robbins of Custora. Otherwise, keep an eye out for Parts II-V of “SaaS Pricing Models: Choosing Units,” each of which will cover a subsequent step in the framework we’ve introduced today, including:
(2) Aligning with Product
(3) Aligning with Sector
(4) Testing the Model
(5) Evolving the Model
