What We Learned About Tiered Pricing vs Pay-As-You-Go | Hacker News Reader

What We Learned About Tiered Pricing vs Pay-As-You-Go

blog.framebase.io

76 pointsvu0tran21 comments

I have a proposal that's in one sense the best of both worlds: auto-canceling subscriptions. Like where you automatically stop charging the user if they stop using your service.

I take it that the cognitive overhead of perennially re-evaluating whether you're getting your money's worth is a big reason developers like pay-as-you-go. And the biggest reason you wouldn't be getting your money's worth is that you're not using the service at all.

That's how my startup does our tiered pricing and I just wrote a blog post trying to convince other startups to do the same: http://blog.beeminder.com/autocancel

EDIT: I thought I'd try spinning off a separate discussion on auto-canceling subscriptions if folks are interested: https://news.ycombinator.com/item?id=5664998

Here are two good examples of successful SaaS apps that use both tiered pricing and pay-as-you-go:

1. Mailchimp - http://mailchimp.com/pricing/

2. Campaign Monitor - http://www.campaignmonitor.com/pricing/

I'm guessing that they do this to serve both markets: developers and B2B customers.

Why not offer both? In a manner similar to AWS, let me have the option to pay for a fixed amount at a slightly lower cost and pay for additional "as I go" at a slightly higher cost?

If I have no way to predict my baseline usage, I'll just stick to using the no-guarantee price. But once I have an understanding of a baseline usage amount, I'll commit to paying you in advance for a certain amount in exchange for a slightly lower rate. If I don't meet my goal/quota, I lose it. If I go over, I can buy more at the variable price.

Why does it have to be either/or?

This is a pretty awesome article on the topic, and I tend to agree that it pretty strongly depends on who you're targeting as a market. In my experience, developers like pay-as-you-go, but management of most stripes seem to prefer tiering, even if it isn't a company you'd necessarily call "enterprise". Tiering might cost more money, but is less hassle--especially if you've got a yearly subscription option.

Speaking to prospective customers I have found that many want fixed pricing. It's easier for them to get budget for $x than to get budget for $y and then have to ask for $z because they used more data than expected.

So it really depends on the audience - if you have both audiences then you need to have two plans - tiered and pay as you go.

Can you comment on how you handle the fact that PAYG could be open to abuse with customers running up large bills with API usage and then not paying them ?

I understand that if you're Amazon you can chase them down, but I'm assuming most small startups wouldn't have the manpower to do this.

Some pay-as-you-go services are prepaid and thus don't have that problem (e.g. NearlyFreeSpeech.net, DiamondCard.us, I think Skype). I'm curious about collecting from postpaid customers too, both for pay-as-you-go and fixed per-month models (unless paid-per-month Internet services are always prepaid?).

Twilio is an example of this and so are some mail delivery services. Basically, you set up an auto-load so they get something like $20 up front and charge your account down as you use the service.

Seems like a nice middle ground.

Couldn't you just deny further access to the service?

Typically services set an internal "comfort" limit. When a client passes that limit, it is flagged internally for review. You can then risk-assess: look at who the customer is, what are they doing with it, do they have an incentive to pay a large bill (i.e. would it kill their service if you cut them off for not paying). You can then decide to let them continue, contact them for an interim payment, or suspend their service if the risk is too high. While you're risk-assessing them, they can continue to use the service (it's not automatically suspended) so the customer need not know what is happening.

And of course, its usually wise to factor in a level of non/tardy payment into your cash flow projections, as a realistic cost of doing business.

Thanks - this is a really nice approach as it doesn't interfere with customer usage, plus you don't end up with runaway costs.

> Enterprise companies generally don’t like surprises. They plan their budget well in advance and having a service with a wide variable cost isn’t ideal when budgeting.

Possible solution: have pay-as-you-go pricing to begin with, and as soon as your active marketing pings to enterprise customers go from "no, stop bothering us" to "well, I'll bring it up to my boss", open up tiered pricing for enterprises (branded clearly as such), but priced way higher than you need to charge for each tier.

Argument: "enterprise" branding makes it clear to pay-as-you-go customers that these are not the droids they're looking for. high-priced tiers let you plow income back into R&D, but enterprises don't mind paying up (as much as pay-as-you-go customers) because the person agreeing to pay is not paying with his own money but the enterprise's [0]. Pricing the tiers high also gives you wiggle room for when your own operational costs unexpectedly increase, so you don't necessarily have to renegotiate a bunch of enterprise contracts right away.

[0] I can't remember who made this observation or I would cite the blog link. If somebody remembers and mentions it, I'll edit.

You're probably thinking about this:

http://www.kalzumeus.com/2013/04/24/marketing-for-people-who...

Did you run A/B tests? I'd love read some more about the metrics! Also, wHy not do both pay-as-you-go and tiered pricing?

My thoughts exactly. Why not both?

Minor nitpick:

So, I'm reading your article, digesting the information, and generally nodding along with what's being said. About 2/3 the way through the page, a static top navbar peeks its head down to remind me I'm on Framebase.

Now, the banner at the top of the page says, I'm on Framebase. The logo at the top of the article says, I'm on Framebase. So, why is it necessary to have a navbar pop out of nowhere to remind me that hey, angersock, you're on Framebase?

You don't even have any links on it--it just comes out of nowhere unbidden. If you insist on having it, why not just always have it at the beginning of the page--why must it pop out and annoy me in the middle of your article?

This is a design trend I've noticed on a few blogs recently. It does link you back to the homepage of Framebase which is somewhat useful but I honestly am not sure what the purpose of this effect is either.

Came here to say this. Also, as I tend to keep the point where I'm reading at the top of the page while I'm scrolling, it covered over where I was reading. Really annoyed.

Same issue for me. It kept blocking the line of text I was reading.

Here is what I think it it. The Tumblr theme that Frambase uses assumes that there will be a header navigation. The theme designer assumes that people would be better off with the navigation always there handy (designers, not always). Now that framebase didn't setup the menu or decides to remove it - the theme script kicks in showing the whole header floating around.

I'm assuming there should be a setting to turn that off.

It seems a little weird to me to approach pricing models from a "which does the customer prefer?" angle. Tiers are just an arbitrary way for businesses to set higher prices without being as obvious about it, so of course non-enterprise customers are going to prefer usage-based pricing. Other things being equal, customers want to pay less.

Reply on news.ycombinator.com