Market Segmentation & The 3-Axes of SaaS Pricing

Nov 23, 2010 by Sinclair Schuller

Warning: This is a long but fun post!

Fellow blogger Lincoln Murphy recently put up a blog post titled The Dangers of One-Size-Fits-All SaaS Pricing Pages. I have a lot of respect for Lincoln’s focus on SaaS pricing because its something that is so overlooked by both new and mature SaaS providers. In this particular post, Murphy rails on the notion that, if you have an offering that spans wildly varied market segments, you can define a single pricing page that caters to all segments. I absolutely agree with Murphy. I think all SaaS vendors really need to understand their audience and their intentions when determining pricing and presentation of pricing. Some approaches can be counterproductive. For example, if you do have an offering that satisfies the needs of both upmarket and downmarket segments, or the needs of prospects in different verticals, putting all pricing on one page and using “plans” to differentiate can lead to the general dilution of the pricing message and result in poor conversion; a blatant jack of all trades, master of none issue. A pricing page should set out to do a few things: (1) is that the page should clearly disseminate pricing information and how that pricing information relates to the product experience and (2) the page should shoot for extremely high conversion. A pricing page is part of your marketing mix, and like any landing page calling visitors to action, it should focus on getting as many people through the door as possible. If the door gets too cluttered, confusing, or unwieldy, fewer people will walk through and trying to cram a message for each market segment into one page will undoubtedly flatten conversion.

So what’s the right answer to pricing? We had to think a lot about this when creating SaaSGrid since pricing and subscriptions are intimately anchored into SaaSGrid’s SaaS and multi-tenancy injecting runtime. I think to start, we need to define a bit of a formal ontology. First, we need to agree on nomenclature and hierarchy to define the parts that make up a pricing structure (note that I’ve abandoned ‘page’. ‘Page’ is specifically a presentation format, and has no bearing on a SaaS offering’s pricing structure. Pricing can be presented in a number of ways, ranging from a ‘page’ to a phone call). Once we provide for elementary definitions, we want to understand which parts of a pricing structure are ‘load bearing’ with respect to buying decisions such that we can best define pricing to address market needs. In my experience, there are a few major moving parts to pricing structures, defined as follows:

1. Components - Discrete aspects of a SaaS offerings function and/or form that are activated through entitlements that must be purchased. These entitlements may carry with them specific configuration that will influence the general behavior of said discretized functionality. For example, if I have a CRM offering and I want to charge for reporting, I may have a ‘Reporting’ component in one or places of my overall pricing structure. Furthermore, I may provide quantities such as the number of reports that a user can generate should they have this entitlement.
2. Plans – Composite structures that capture baseline pricing mechanics (such as whether a pricing model is user across time based – e.g. per user per month – as well as actual cost per model) and couples those baseline mechanics with component configurations. Essentially, a plan is an aggregate of zero or more components coupled to a base pricing structure. Furthermore, a plan may go on to specify component inclusion rules such as whether a component is included in a plan for any charged base fees, or whether a given component carries additional charges. For example, my same CRM product may have two different plans; one includes 4 components and optionally offers 2 others for additional fees while a second plan may include all 6 components as part of some baseline charge. Plans are the pre-purchase constructs that yield subscriptions upon purchase, where a subscription defines an end user’s sum total entitlements in the SaaS offering.
3. Pricebooks – A pricebook is the next level up in the heirarchy; it is an aggregation of 1 or more plans. Specifically, a pricebook is a group of plans in a sequential structure that indicates some sort of plan inferiority/superiority relationship. Furthermore, a pricebook may abstract away cross-plan configuration, such as currency definitions, generalized information such as footnotes, etc. For example, I may have a pricebook that aggregates the plans”Starter”, “Professional”, and “Premium” in order, respectively. This logical ordering defines an  evolutionary path for an end users progression through a product usage maturity model, and organizes those plans in such a fashion ass to help an end user assess the direction and magnitude of said evolution. A pricebook is an abstract version of Murphy’s ‘pricing page’; that is, a pricing page is merely a way to visualize a pricebook.

I could definitely expandthis definition even further, and in fact, we’ve gone much further than this at Apprenda. I think for the purposes of this post, we have enough formal structure to continue. (Just to add some perspective to where we could go with this, other formal structures can be added to the mix such as discount matrices which are defined as pricing perturbations that can be projected onto plans and/or entire pricebooks.) Visually, we can think of the aforementioned structure as follows:

(bigger)

So now that we have a generalized structure for SaaS pricing, what next? Interestingly, our pricing structure helps us in expanding our Served Available Market (SAM), boost pricebook consumption to customer conversion, and increase overall Customer Lifetime Value (CLV). Components, plans and pricebooks each define an axis on  a 3-axis pricing architecture.

(bigger)

Let’s think about each of Components, Plans, and Pricebooks along their respective axis and discuss how they optimize key parts of a SaaS business:

1. Components - Let’s assume we have only 1 plan in 1 pricebook; that is, we offer only 1 general way to purchase access rights to a SaaS offering within a single market segment. Using components we can define a la carte items. We might include certain features and functions as part of paying a base fee for the plan. However, this is our opportunity to really boost the amount of revenue we extract from the customer. Typically speaking, in any offering, there are features and functions that customers see much value in, and would happily pay an upcharge for. As a SaaS provider, this is something you can capitalize on. Within a plan structure, you can use components to selectively carve out capabilities in your SaaS offering that will have a high propensity of being purchased, and attach a premium to those components. This will drive up gross account value, and tilt CLV calculations in your favor. Far too often, people simply “throw things in for ‘free’” in a plan in hopes to create appeal. In reality, understanding what your customers value and leveraging components to create clean up-sell models can positively impact your bottom line.
2. Plans - Within a given market segment, you may find differences in the constituents. For example, power users vs, non power users, or the “I get 80% of my value from 20% of the software” folks vs. the “that one time I need feature X is worth all the money I spent on having that functionality” folks. Plans give you an opportunity to aggregate components into groupings that best calibrate around different personas or demographic sub-segments. This gives a SaaS provider the ability to boost conversion by creating profiles that deviate slightly from one another but that show the prospects that you understand who they are and that your offering can be well tuned to their specific situation. This even goes so far as understanding budget cycles. For example, a non-power user plan might be offered monthly and in no other way since typically non-power users might not have high signing authority, while you offer yearly plans to power users who typically come from a profile within a market segment that can sign off on thousands of dollars. This boost in conversion will prove to create a better utilization of marketing dollars and cycles. Echoing Murphy, you shouldn’t use plans where deviations from plan to plan are drastic (such as making plans that focus on different verticals, say Logistics and Healthcare) because it creates extreme noise that will probably flat line conversion. Think marketing, messaging, and homogeneity in plans that are part of the same pricebook.
3. Pricebooks - A SaaS pricing strategy need not have just a single pricebook. Pricebooks can be used to capture slighted different but generally homogeneous plans into a single structure. However, if you need to target different verticals, different geographic regions, etc., you need multiple pricebooks so you can deliver a consistent experience within the target. By doing this, you can effectively offer prospects entitlement purchase rights that reconfigure your SaaS offering for different verticals. Multiple pricebooks help you tackle these cross-segment challenges such that you increase your effective SAM as a result.

Optimizing along each of these axis such that you maximize the results of each axis within whatever constraints you are working with will typically yield a revenue and profit maximizing pricing strategy. It’s critical to truly understand what to expect from certain changes in your pricing structure so you can properly set expectations and run pricing experiments. Depending on where you take certain optimizations, you can expect different results:

(bigger)

Clearly, we’d all love to reach (Cmax, Pmax, Bmax) to have the ultimate super pricing, but that isn’t always realizable or practical constraints get in the way. Each SaaS ISV needs to understand what they are working with and where they can get the most bang for their buck. Regardless of your particular situation, having a grasp of a formal structure can go a long way.

How have you tackled pricing experiments? Did you think about conversion, SAM and CLV, or did you take a more generalized approach looking for top line affect? Do you agree or disagree with this ontology? I’d love to get your feedback and input!

If you’d like to mingle with others in the SaaS space, the SaaSBlogs group on LinkedIn now has 3500+ members and is growing every day; make sure you’ re not missing out and join today!

read more

A Pricing Strategy for Your SaaS Offering

Jan 7, 2008 by Sinclair Schuller

Pricing strategy is a major component of any business, whether brick-and-mortar or bits-and-bytes. In addition to being an important strategy to hash out, it is also generally quite tricky to do correctly. Should pricing be value based or cost based? Should it focus on maximizing income per unit or volume? For all of the things our beloved SaaS delivery model does for us, it does not ease pricing strategy pains. I’d even venture to say that it makes pricing strategy even more complicated. After all, SaaS providers pride themselves in allowing tenants to pay a periodic base cost and tack on optional (and potentially intricately priced) bells and whistles. So how should a SaaS offering be priced? Clearly, this is something that should be considered on a case-by-case basis, however, I do feel there is a good framework to work from that focuses on boosting adoption rate and deferring creation of income and healthy margins to a path of least resistance.

From the provider’s standpoint, one of the beauties of SaaS is its predictability. Generally, this is discussed from the standpoint of revenue, but in reality, many things are measurable and predictable – including cost of service per user. Over time, it should be relatively easy for a provider to determine how much must be charged per some time period to recuperate this cost. From my point of view, a good framework is to build pricing with distinct cost based and value based components and focus this pricing strategy on supporting a sales strategy that relies on harvesting additional, high margin revenue from existing customers.

In business, you have two choices when it comes to generating revenue and income: sell to new customers and/or sell to existing customers. Selling to existing customers is generally easier than selling to new customers. Clearly, selling to new customers is the only way to grow revenue when existing customer sales have reached saturation (all those who would buy the finite set of additional existing products/services have bought them). In perpetual license models, high prices generally posed significant barriers to new customers whether it was directly because of the expense or indirectly because of things like requiring approval from purchasing, etc. SaaS has significantly reduced this barrier but brought its own problems: one single perpetual license sale generally equated to significant revenue while one single SaaS customer does not. Given the aforementioned, many providers strive to rapidly boost adoption to reach a pleasurable cash-flow position, and rightfully so.

The Framework

The above brief discussion defines certain requirements of a SaaS pricing strategy: boost adoption, cover costs, and generate an appropriate margin. Let’s tackle these one at a time:

1. Boost Adoption: Adoption is generally boosted by lowering the barrier to acquire your SaaS offerings functionality. In the Web 2.0/consumer space, we’ve seen the freemium model work well. Freemium may or may not work in the enterprise space, but I’d recommend staying away from it. Instead, offer a free trial. Next, price the base plan(s) for your product (the product without additional, for-charge bells and whistles) at cost or only slightly above. This reduces adoption resistance (assuming all other things are equal, like your offering is actually good and people see a need for it) and should optimize your ability to bring on new customers. If you price too high (which may happen if you focused on value based pricing), you may create a significant adoption barrier. If pricing is too low, adoption would be boosted but at a loss.
2. Cover Costs: Generally, you may not be interested in selling at a loss. As described in the ‘Boost Adoption’ point, price at cost to recoup. It would even be logical to price slightly above cost to absorb any sudden fluctuations. This is where predictability matters. You shouldn’t have too many operating surprises and given a good amount of time, your cost estimates should be quite accurate.
3. Generate Healthy Margins and Profit: This is the bread and butter of the bottom line. My suggestion is generate profit by selling the bells and whistle components of your SaaS offering to existing customers. If you can use cost oriented pricing to boost adoption through a low base cost, you should have a healthy market of existing customers that pose significantly lower resistance to spending more money. This is particularly true if your bells and whistles are actually valuable, giving you good justification to charge a value oriented price.

This seems obvious at first, but I see companies charging high prices for base use of their applications. This may be severely limiting in nature. Instead, hook new customers to your base product and then offer high margin value once they’re using it. Focus on getting as many paying customers on your base product, since this validates that they’re willing to pay and that they value your product. Figure out how to profit from that base afterwards. As I mentioned, this may not apply in all cases, but it seems to be a good starting point. The goal is to exploit the ease at which people can sign-up for SaaS offerings and get as many tenants into your easier to harvest tenant corral as possible.

Do you agree with this type of pricing strategy, or do you feel that something like a strict value based price is wiser? We’d love to know what has worked for you or where you are feeling the worst pains.

read more