Discuss Home · Bootstrapped Podcast · Scribbleton Personal Wiki · HelpSpot Customer Service Software · Thermostat NPS

Pricing page examples and discussion


#1

Any good examples of pricing pages where there is one price/one tier? I really have a single tier with three different demographics. There’s only one option for any one customer.

More than happy for the discussion to evolve in regards to pricing and designing a pricing page.


#2

Is it specifically the design you are looking for?

Is a better question not “any good examples of businesses where there is one price/one tier?”. i.e. is it even a good idea in the first place?

Apologies if I missed discussion beforehand.


#3

I think we’d be remiss if we didn’t include Snappy! They don’t seem to have a pricing page per se, but you can click on the pricing link at the top of this page to see their pricing pop up.


#4

If you like. Technically, it’s not one price to rule them all because there will be a nonprofit, small business, and premium business prices. The feature set is the same, however, and the majority of accounts will likely be nonprofit and small business.

In my head I was thinking of focusing on the small business price with footnotes for nonprofits and premium business accounts.


#5

I recently redesigned our pricing page: http://restaurantengine.com/pricing but I could use some feedback cause I’m still re-thinking things here.

We have a single, up-front setup fee. Then we have a couple plans. Then there are some optional “add-ons”.

But I’m considering doing away with our plans and making just one core plan, with a few optional add-ons, which customers can mix and match based on their needs.

I still think a 3-tier is the simplest, most effective (price anchoring and all that) but sometimes that model doesn’t fit the product, even in SaaS.

Hmmm…


#6

Alas the CSS isn’t all there but our original setup had some kinda cool ideas to do ‘tiers’ for our one tier product by comparing it to alternatives.

http://web.archive.org/web/20130821004601/http://www.besnappy.com/

Near the bottom. It actually worked pretty well. Working on a new site for Snappy and I might bring it back in some fashion.


#7

I remember seeing the old design and wondered why you changed it.

In my case, there aren’t really any alternatives. None that can be compared based on features, anyhow.

I just can’t make it work. I really have a single tier with three different demographics. There’s only one option for any one customer.


#8

In the end, you know the most about the particulars of your situation, so if you feel you’ve done the research and talked to your customers and they all fall into this one value level, I say go with the one tier.

While googling around a bit I came across this consultancy that does pricing for SaaS businesses, and they have some very harsh things to say about using a single price point.

On the other hand, Ian and the team working on Snappy have actual experience with it, and it’s working for them. So we know it can work in the real world. @ian: honest question, have you had any regrets about going with one price point? From what I’ve heard previously, it sounds like you’re really happy with that decision.

In regards to your original question @Lewis, the Price Intelligently ebook says that only 5% of the 270 SaaS’s they surveyed use a single price point, so finding additional examples might be a little tricky. But I suppose you know that and that’s why you posted here. Maybe you could email the Price Intelligently people and ask them for the list of single price SaaS’s? The only email I saw on their site is speakwith@priceintelligently.com. They’re on Twitter @priceintel.


#9

That was very helpful. Helped me create three plans based primarily on # of users and branded vs unbranded. Cheers!


#10

Not really, but in my case the decision is basically made for me. Every other support product uses per user pricing. I had strongly considered some other models, but I think it just gets a little funky when you’re the outlier and we didn’t have a good reason to be really.

We are making some more plans for larger businesses now though. So if you want yearly pricing and the option to pay by check there are now plans for 15, 20 and 30 users. So with those you have to pay yearly and you can also be invoiced.

You’re also welcome to have 20 users just on monthly also, but you don’t get the yearly discount and invoice option.


#11

Our pricing sounds similar to what your asking about… it’s based on community demographics and there is really only one option available to a given customer. See pricing page.

For us, we didn’t want to use per user pricing or per transaction pricing for several reasons:

  1. per user: Just difficult to manage…our customers use lots of part-time/seasonal help

  2. per tran: Doesn’t allow customer to budget for service effectively/with confidence (municipalities want a definitive line-item on the budget) - and is more difficult to manage in that most of our customers are invoiced rather than automatically hitting a credit card monthly

  3. The by community population model is a nice differentiator for RecDesk that allows us to compete for business at high and low end of space - and is pretty good indicator of customer usage in terms of compute resources and customer support


#12

If you are building a B2B product I highly recommend considering per user pricing. I know some people prefer tiered pricing based on data/project size or similar, but per user pricing has many benefits for customers and vendors. We have been using per user pricing since the beginning and it has been working great. The nice thing about per user pricing is that it’s a) very easy to understand, b) predictable for customers, c) scales well with the value customers get and d) your revenue growths automatically (without customers having to switch plans) when your customers expand usage of your product.

You can still offer discounts for larger teams. We have various pricing packages for different number of users that makes it easy for customers to know the price in advance even if they change user numbers slightly every month.

It might not work well for all products, especially if you have a lot of temporary users, but I think per user pricing is a good fit for many B2B apps.