Leave a comment
Get the GH Bookmarklet

Ask GH

I'm working at SaaS company with ~1500 paying customers. We've been thinking about our pricing plans. At the moment, we have one free plan and 5 paid plans + one enterprise plan. The product is a project management tool, so we price based on users + projects. I've thought about pricing based on value, but I can't think of a metric other than users + projects that would be a good fit for pricing, so I'm sticking with it. I've analyzed our user base, and I've found that our plans aren't very well adjusted to our user base. In fact, 75% of our customers fit within the second lowest plan in terms of usage. That means that very few customers ever need to upgrade even after 4 years +. Therefore, my approach was to create the plan "buckets" based on quartiles. The lowest plan would correspond to the 25th quartile, the second plan to the median company, the third to the 75th quartile and the maximum excluding outliers would be our highest non-enterprise plan. Finally, the enterprise plan would be for companies needing custom solutions. Question: do you see any problems with creating buckets according to these quartiles? I haven't found any articles suggesting pricing based on this model online. The other approach we were considering was simply doubling prices, because our prices are too low based on the market. Intuitively, just changing the pricing "buckets" based on quantile seems a very "fair" approach to pricing. Thoughts?

  • DM

    David Meyer

    over 4 years ago #

    Creative idea, I like it. The only problem I see is that your 25th quartile, median, and 75th quartile will shift over time. This is okay, but you'll need to decide how to handle this. Are you going to:

    a) fix the user/project limits based on current 25th/median/75th marks, even as the true marks shift over time. You could readjust every few months/years/whatever?
    b) create a dynamic system that changes constantly based on new/growing users.

    While b) seems like the way more fun option for a growth hacker, and potentially more profitable, my instinct would be to go with A. It will be easier to implement and will avoid any confusion among customers. With option B, you could have two companies with the exact same number of users/projects in different tiers (paying different rates) based on when they signed up. That could piss people off.

    Keep us posted - cool idea.

  • NL

    Nathan Lippi

    over 4 years ago #

    I'd agree with David that simpler is probably better.

    You mentioned wondering if you should test doubling your prices, as well.

    In other words, should you optimize your pricing *model/scheme* first, or your pricing *prices/amounts* first?

    I would assume that optimizing *prices* first would keep things simpler. You could find the "local maximum" of your current model, and then try something totally different.

    I don't have much real-world experience with pricing but I would think that a disadvantage of a 'tiered' model for something collaborative is that your customers will hesitate to add new team members because it will bump them up to the next bracket.

  • LL

    Lasse Lumiaho

    over 4 years ago #

    What if your current pricing model is built so that people try to optimize the number of projects to save money? Have you tested what happens when you lift/remove the limit?

SHARE
7
7