Hacker News Reader

Totally understand and agree with your observations as a pro services firm. That is the funniest part of the university I work at - say your company implements a solution for us like Product X. Well then all the sudden we can explore your ENTIRE product/service catalog with you without consequence because we have an agreement with you (for whatever). So even though you sold us product X we can also look into service Y where I'm not as concerned with cost but getting the right one. To say however they LIKE not discussing price upfront seems a bit disingenuous - yes I would want to discuss the service first but I am going to want an idea of what its going to cost to put that into my budget/grant/etc to see if it fits, especially if funded by the state. My university may be different though as I've found out many times over.

I imagine getting that first contract though wasn't easy - as that initial connection had to likely come through an RFP? and what is the ratio of RFP submission to actual customer?

>>yes I would want to discuss the service first but I am going to want an idea of what its going to cost to put that into my budget/grant/etc to see if it fits

That's the thing though: it's an extremely wide range. For example, anywhere from $25,000 to over $1,000,000. It's impossible to say upfront whether it will fit your budget.

The reason we take a consultative approach (as opposed to a traditional sales approach and leading with the price) is because we want you, the customer, to control the scope of the project. We work with you to understand your requirements, then prepare a preliminary proposal and SOW with the price. You can then say, "well, this is a bit out of our budget, but maybe we can postpone features X and Y until the next phase" and we go back and forth until the final scope and associated price are acceptable to you.

I can't disclose our ratio of RFP submission to customer. But the thing about RFPs is that they are rarely objective. In the vast majority of cases, the client's preferred vendor helps the client write the RFP. And in a lot of cases we end up being that vendor, because the clients trust us after seeing our methodology.

>>In the vast majority of cases, the client's preferred vendor helps the client write the RFP

Thats surprising - In my state (NV) someone would be fired for that as it would be considered collusion.

That's what many people think, but it's actually not true (at least not in the states I've worked in). There's a cottage industry that provides advice on how to navigate through the RFP process, and a lot of the advice is based on controlling what goes into the RFP when it is written. Take a look at this set of slides:

http://www.slideshare.net/pmcloughlin1/how-to-help-your-cust...

The most important thing to understand about RFPs is that they aren't designed for making the "most fair" selection. They are designed for making the "safest" selection. An RFP is basically a CYA (cover your ass) mechanism for the procurement team. That's why collaborating with preferred vendors when the RFP is being written is a very common practice. Teams writing the RFPs rarely have the subject matter expertise necessary. So they receive help (which is a good thing).

The bottom line is that companies who provide price upfront end up competing on price. And history has shown us that that's a race to the bottom.

As a counterpoint to this, my cofounder and I have been very successful with our own security consulting firm with the opposite philosophy. We have not found transparent pricing to be an obstacle in landing lucrative clients. I also haven't seen any race to the bottom of "commiditization" in our industry. One of our closest competitors also publicly lists weekly rates.

I don't know that they care one way or another. It's not as though we champion transparent pricing in our sales pitch - it's simply one more available piece of information on our website. Potential clients still need to contact us, they just know what to expect. We haven't found that we have pressure to reduce our prices or compete on price as a result. Granted, we cater to more YC companies than we do Fortune 500s, but we still serve both, and the firm does very well.

The vast majority of our work comes in through referrals, which probably changes things a bit. I think there is merit in either approach, enough that it's not fair to say one definitively causes this or that as a result.

I'm not sure this is a great comparison.

Consulting rates and enterprise software pricing are two different beasts, especially when hosting infrastructure is involved...

On top of this, enterprise buyers are not always going to be sophisticated enough to determine whether their business requirement means they need module a or b or feature x vs. y from a random enterprise suite.

Commoditization is not going to be an issue in highly technical fields such as security consulting, which is why your approach works for you.

In our field though, there are a lot of competing products, and a lot of them are either free or very cheap. And at a high level, they have similar "features" and "benefits". But once you get down to the nitty-gritty, there are tons of differences. That's why we spend a lot of time and effort educating our clients on those differences. We have to demonstrate the value first before providing the price in order to avoid sticker-shock.

That's a fair point. I misunderstood you, I thought your firm was also providing technical consulting, not SaaS products.

"Here's the thing: most of our clients LIKE the fact that we don't discuss price upfront. They understand that software is a different beast, and its value is dependent upon how well it fits into and/or can be molded into the needs of the business. Only very inexperienced purchasers push us for price, and over the years we've found ways of disarming or at least sidestepping them."

I am not sure which side of that interaction to hold in more contempt ...

Not sure I understand. Can you elaborate?

This carrot peeler has a variable value to customer, dependent on how much the customer will use it. We won't put the price out there until we know how valuable it is to our customer.

LOL.

Nope.

A better analogy is a toolbox. That's our combined product and service offerings. While each toolbox has ~50 different tools, most customers end up needing only a subset. Furthermore, they need each tool to be customized to their specific use case. So we use our technical skills and knowledge to modify those tools, package them and offer them as a customized solution.

That's why it would be silly for us to say "each toolbox costs X dollars." Each solution has a different price depending on what the customer wants to get out of it.

By the sound of it, your pricing strategy makes sense for the kind of product or service you sell. By comparison, a company selling a single product should (in my opinion) have pricing available for at least their smaller tiers.

Professional services and a single SaaS product are very different.

http://www.amazon.com/gp/aw/s?k=Tool+sets

Perfect

Your arguments are against providing exact pricing, that are rather obvious. The discussion seems to be about ballpark estimates. I'm not sure how to display this, but something along the lines seems reasonable: "Moderate installation at local high-school should fall under 1M, while a state University might get basic feature-set for 10M". Large enterprises have whole departments for price-bargaining, but the smaller ones and especially public ones want to know the ballpark before issuing an RFP

After a few interactions with enterprise "call us" pricing that went crazy and one where the quote went from £10k per seat to £1.5k per seat (for the exact same fit out), I always feel like I'm about to get screwed when I pick up the phone.

I wonder if withholding pricing information is simply a negotiation tactic that exploits the sunk cost fallacy. If not, funnel conversion rates should be invariant of the stage at which pricing is disclosed, right?

>Here's the thing: most of our clients LIKE the fact that we don't discuss price upfront.

Sorry, but absent reliable data, I'm calling BS here: I've never, ever met someone who likes having to call some random salesman to get a price and figure out if the service is even within a order of magnitude of their budget.

In fact, most people I know detest those kinds of games.

My experiences mirror the OP, in fact I even had a prospect tell me recently they were thrilled I didn't jump right into pricing/licenses.

Most are not calling to get a price, they're calling to learn more about the software to make sure it's a fit.

Have you considered that your customer might have just been telling you what you wanted to hear in the hopes of getting a discount?

or the customers that just skip them to a supplier with less contempt for their users

I'm bugged if I have to hop on the phone to talk to someone about something I saw on their website. That's about as un-Internet as you can get. You might as well ask me to send you a postcard.

> But enterprise software is not like that. It is very complex.

That's exactly why SaaS disrupt traditional enterprise on-premises software - too complex (installation, user interface), too expensive upfront.

If the software requires no 3 weeks installation phase, no handbook nor training and costs a fraction of the usual 100k to 1m, like $200/host/month, then there is often a clear winner.

I work for an SaaS startup selling into the financial sector. We started out with a different kind of pricing model, based on volume; a simple formula based on data throughput. It didn't survive our first sale.

Selling to large entities, even SaaS, still involves negotiation. Often the large customer wants some key features; sometimes it's a checkbox feature, sometimes it's to disarm antibodies inside the organization, sometimes it's something they actually need for a business requirement. That work needs to be priced in.

And there's the other side of it: different organizations get different amounts of value from our software. If we don't charge organizations who get more value more money, we're leaving profit on the table. Even shrinkwrapped software back in the day had segmented offerings to capture more value. And when you're selling to large organizations, which will necessarily involve multiple salespeople and a bunch of meetings (i.e. scope for fine-grained segmentation without confusing proliferation of products), if you don't charge different prices to different organizations, you're an idiot.

If anything, this way of selling is better for smaller organizations than the segmented approach. Even if we can't charge more, all customers at least get the same product.

That's not to say that volume and data throughput doesn't form a part of the price calculation. But it's a multiplier where the base price is based on the value delivered, which is business dependent.