If SpaceX posts pricing publicly [1], you really have no excuse as a tiny SaaS startup.
"It costs $10,000" ...if they don't balk: "per month" ...if they don't balk: "per user" ...if they don't balk: "per CPU"
IMHO, there's pro's/con's to publicly listed pricing. There's definitely no hard and fast rule. Some con's to consider: [1] It anchors prospects at certain price points (can be good and bad), [2] It might scare people off before you can value sell them and justify your pricing.
With enterprise SaaS, it entirely depends on: [1] what you're selling, [2] who you're selling to, and [3] the buyers' journey you're looking to accommodate / create.
I did not know they did this. But that is awesome. When trying to buy things even with a substantial budget in research, "contact us" was the most irritating thing - I don't need the damn up sell, but I do need to know whether you're thinking 10k or 50k.
If you had given me even a ballpark price up front I wouldn't have wasted your salesman's time!
When something is low enough to experiment with and still fall into the "petty cash" area, an employee can buy a little (or for a month) and test it out. If they're somewhat successful, they can expand it out to their immediate team, still with a tiny budget. As they prove out usefulness/value and expand their users/usage, obviously the cost goes up.
But by the time they have to "Get Approval" from someone really high up - like a VP or procurement group - they have X users or Y months of success. Selling it to the higher ups then becomes easier and a more likely sale.
We NEVER provide pricing upfront. This is despite the fact that our software vendors have their prices listed clearly on their pricesheets. We know the price of a user license. But the first time our clients see the price is after we've performed our due diligence, learned the ins and outs of their business, and are sitting in front of their C-level people presenting the final proposal along with the Scope of Work document that outlines implementation details.
The reason we don't provide prices upfront is because it commoditizes the software and therefore our skills and services. It encourages clients to do an extremely shallow feature-by-feature comparison of the competing products. Doing that makes sense when purchasing commodities such as toothpaste or laundry detergent. You can look at two products at the shelf, compare their features, and go with the one that you think is better based on the messaging on the package ("25% more whitening power!"). But enterprise software is not like that. It is very complex and the price of the software is often only a small part of the final price, which is frankly unknown at the start of the engagement. That's why me giving you pricing information wouldn't help you one bit (in fact it could make you look bad to your superiors when the final price is several times higher than what you gave them originally).
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.
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.
I am not sure which side of that interaction to hold in more contempt ...
LOL.
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.
Professional services and a single SaaS product are very different.
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.
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.
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.
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.
Most are not calling to get a price, they're calling to learn more about the software to make sure it's a fit.
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?
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.
Thats surprising - In my state (NV) someone would be fired for that as it would be considered collusion.
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).
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.
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.
really useful insight thanks
On the other hand you give me up front on your website 1 user pricing I can take that public information and multiply it by the number we need, send it up the chain, make a convincing argument for sole sourcing, and then you will suddenly look like heroes with procurement because they were able to get it "so much cheaper" because I just multiplied what it cost for 1 * 30,000 (e.x.: number of students).