
Ask HN: How to decide on Enterprise pricing - throwaway321564
I have a saas app in the $12-$29&#x2F;month  range.<p>I&#x27;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.<p>I know it&#x27;s a &#x27;how long is a piece of string?&#x27; type question, but I was wondering if you had some advice with regard to pricing.<p>I would be providing a managed private server for this org. My raw costs for server and data would run about $100&#x2F;month.<p>Thanks.
======
taprun
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](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](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/](http://taprun.com/pricing/) ).

------
mindcrime
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](https://en.wikipedia.org/wiki/Applied_information_economics)

------
saluki
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.

------
outericky
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...

~~~
Gustomaximus
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.

