Ask HN: How to decide on Enterprise pricing | Hacker News Reader

Ask HN: How to decide on Enterprise pricing

I have a saas app in the $12-$29/month range.

I've been approached by a large enterprise org for pricing on a private server instance. The company is very large, in the hundreds of millions revenue per year.

I know it's a 'how long is a piece of string?' type question, but I was wondering if you had some advice with regard to pricing.

I would be providing a managed private server for this org. My raw costs for server and data would run about $100/month.

Thanks.

View on HN

This is a complete over-simplification, but...

I'd start by thinking about how much your product is worth to the company. How much money will it save/make them? Don't just look at the functionality that you provide, but also at risk reduction. Charging based on value is called value pricing ( https://en.wikipedia.org/wiki/Value-based_pricing ). You'll want to charge less than what your customer has to gain (otherwise they won't buy). This is the number you should be working from (using out-of-pocket costs to determine pricing is called time and materials pricing and is a great way to go broke https://en.wikipedia.org/wiki/Time_and_materials).

Your original app pricing has little to do with what you can charge enterprise customers, because the product that you're offering is different. Yes, your old pricing will act as a bit of a psychological anchor, but if they've contacted you for a custom plan, they are probably willing to spend quite a bit.

Source: I write a blog on the subject of product pricing (and wrote a book specifically about software pricing - http://taprun.com/pricing/ ).

Pricing is a complicated topic (or can be), and I don't claim to have mastered it myself. In fact, I'll freely admit that I'm still struggling to figure out all of the details of our pricing model for Fogbeam. There are literally dozens (or more) books written specifically on pricing, so don't feel bad if it all seems challenging.

That said, here are some thoughts based on my own experience and research.

Keep the model as simple as possible (but no simpler?). Nobody wants a complicated pricing model with per-core charges mixed with CAL (client access license) charges, mixed with varying discounts and floating license servers and blah, blah, blah.

The challenge, of course, is how to balance having a simple pricing model, with your desire to charge companies based on the value you provide them. That is, a larger company with more users is (presumably) getting more value from your software and should pay more. So charging per user is a valid option, but it's not the only one. You could charge based on the customer's revenue, or scale the pricing based on the hardware (physical or virtual) required to run the software for their needs.

There's some really interesting stuff in Douglas Hubbard's work on "Applied Information Economics", although I don't really have time to try and explain it all here. But the key of his approach is to try and actually quantify the value of an information system by figuring out a way to measure the factors the system will impact, and then figure out the economic value of improving those factors. That's a little bit of an over simplification, but it's an interesting approach built on calibrated estimation, monte carlo simulations, and elements of modern portfolio theory.

I'd recommend reading the book How to Measure Anything by Hubbard, and/or read the Wikipedia article on AIE[1] and see if you can think of a way to apply this with your customer(s). Ideally, if you get them to buy into the model you create, you have very solid footing for establishing the price of your software, since you can actually put a number to the value it adds.

There's probably a heck of a lot more to be said about all this, but it's bedtime here. :-)

[1]: https://en.wikipedia.org/wiki/Applied_information_economics

I would setup enterprise private server pricing tiers on your website so you can scale the price based on their use/data. And you can just send them a link to sign up and recommend a plan that would fit their needs initially. They might be less likely to try to negotiate if it looks like standard pricing.

This way you can show private server instance pricing on your site and allow the price to scale up based on use/data so you don't make less if they are using it more and you can scale up the price as they use it more.

Maybe show three tiers and have the last tier be variable based on their users/data or other relevant item.

If you're just looking for a price my initial thought is go for $999/mo.

Don't forget, no matter what you quote them, procurement will want to bring the price down 40-50%, just because that's what they do...

Also don't forget, if a budget line owner wants this product they don't care what procurement negotiated down, just that they got their tool.

For me the big questions are; 1) what are the user numbers. If they have 1,000+ people going on the app I'd discount the app price reasonably and maybe throw in the dedicated server. If they have 15 people using the app I'd hold the price, charge for the dedicated server. And 2) Would this be a almost guaranteed springboard for future deals?

Do you have much alternate competition? If it's not a tender bid type scenario I'd in my limited information be inclined to set initial pricing at appstore levels (or a small bulk discount) plus a dedicated server fee. They'll likely comeback and say they want a discount, but if not great. You may as well start high unless there is the chance they will walk and not return without an initial discount. If they don't like it then you can ask them how much, and you've anchored the expectation of full price.

If relevant I'd also put on the initial offer some X hours of customisation work type offer @ full price. It's better to do this as you might roll the work into the wider app, so it's possibly 'free' anyway. It gives you another negotiation lever if they look to discount as you can take this away. It's something to make them feel like a win, plus it will look as a higher perceived value than the cost to you if the agreed hours are set right.

There's always a bazillion variables. I know nothing. Good luck.

Reply on news.ycombinator.com