I analyzed 250 SaaS pricing pages
thenextweb.com
thenextweb.com
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).
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 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).
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.
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.
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.
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.
If SpaceX posts pricing publicly [1], you really have no excuse as a tiny SaaS startup.
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.
"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"
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!
really useful insight thanks
> Enterprise customers just want to buy. Jason says
> that price doesn’t matter for enterprises. More than
> 80 percent of the time, they just want to get set up
> with a solution as efficiently as possible. Price
> comes after features.
Software is often not just purchased by an enterprise all at once. More frequently, some team with a small budget decides it would be useful to use tool X. Someone with a company card is put upon to purchase a license for the 5 people in the team. Other teams get interested, and start using it. Costs get to the point where it needs to be sent to procurement, at which point, it becomes an enterprise software deal. But it didn't start that way - it started with some small team who are price sensitive trialing it...
When a product like this begins to gain traction inside a large company it usually sparks a response from an internal immune system of champions for the entrenched software companies. These people are trained to explain why the new product cannot "scale" to enterprise needs and spread FUD about the new product.
From my experience if the new product can keep it's prices very low the price pressure can usually win out in the long run. Paying an army of salespeople to take everyone out for steaks can be expensive and in the end that cost is put back on the customer.
You can see the incumbents (IBM, CA etc) trying to figure out how to deal with disruption caused by companies spreading with this more viral model. (Amazon AWS, Atlassian etc).
Fun times out there it's interesting to see how the world is changing.
Deals at big companies always have more moving parts than just plopping down a credit card. There's some manager who wants to put people under him to manage the system. Someone else who wants to boost their status by pumping up their budget, etc...
As a consumer I often feel like contact-style "pricing" pages are a way of trapping customers into a hard-sell. Granted some pricing structures are complicated out of necessity, especially those where usage plays a significant role in the cost to the provider (substantial bandwidth transfer, hardware/setup, human resources). More often than not I immediately abandon any such service if contacting for pricing is the only option. It was surprising to see 80%+ (202/250) of companies didn't list their pricing because my personal real-world experience feels like the inverse.
The article discusses the reasons for the contact-only approach, which boil down to preventing biases for enterprise customers. While that's understandable in some situations, not all SaaS is intended to target enterprise customers. It goes on to consider pros/cons of the multifaceted concept that is tiered pricing. If read this much of my comment but not the article, go read it now!
(A couple typos for the author: "boost revenue"→"boosts revenue", "Abscense"→"Absence")
Edit: I've come to believe that enterprise customers are likely to have different, more strict requirements compared to SMB customers. This is probably why, for enterprise sales, it could make more sense to approach the pricing part in a more traditional way.
On the other hand, this hasn't slowed down our enterprise sales cycle at all; in fact, it seems to have sped it up, with five enterprise deals in the pipeline right now.
However, this approach is risky and it's really hard to get the balance right; companies that have raised rounds might have to answer to investors. Still, sometimes it's worth prioritizing long-term growth over short-term revenue.
My view is that we should always have something free or very cheap for the smaller technologist/hacker/startup. They tend to bring their favorite solutions to other larger companies. Goodwill is one of the best growth factors.
If you find yourself trying to "fix" a UI/UX in the browser itself, stop.
I don't care if you want 300ms faster clicks on mobile, or to force smooth scrolling in chrome, or to hijack right click for your sharing stuff, or whatever.
You are breaking stuff trying to do those things, and it's ruining my experience on your site.
If it's a clear win, they'll implement the behavior soon, and you'll be left with a broken site.
1. The loading animation. I did not wait for your page to load in order to wait for your page to load. Also, if I have JavaScript disabled or JavaScript breaks for some reason, all I can see is that loading animation - absolutely zero of your front page content.
2. The text scrolls up into the middle of the page. Nothing should move on your page without my permission.
3. The fading in/out red text. See 2.
4. The spastic dots/lines following the pointer around above the globe image. See 2.
5. As I scroll, the bar at the top hovers over the page content. This breaks PgUp/PgDn behavior, as it covers content, as the height of the page no longer matches the amount of the page that's actually legible. Also, the bar changes size and color. See 2.
6. You're using a custom font. Are the perfectly fine fonts already installed on my system not good enough? Must you really waste my bandwidth and slow down your page loading time for the sake of your brand? Fortunately, you're using one hosted by Google; I have `127.0.0.1 fonts.googleapis.com` in my hosts file, so it actually didn't effect me. I could still see it trying to happen when opening up Web Inspector, though.
7. I'm seeing your total front page weight as 1.82MB. global_map2.png is 512K. essentials.css is 468K - Jesus, that's a lot of CSS. Even the HTML file is 111K - apparently because you're inlining jQuery, on every page, forcing my browser to redownload it for every page load when it could just grab it from cache after the first one.
That's all I'll say for now. I need to get back to work. Hopefully this is of some help, though.
EDIT: Just to balance things out, here's a good thing - you're bouncing users to the HTTPS URL for your site, even when we're not logged in (or about to). Good!
#2-#4 - part of the animation effect.. agreed that it's annoying to some people.
#5 - I like the fixed menubar and find it useful, but maybe not everyone agrees!
#6 - Custom fonts are kind of a cool thing, but not 100% disagreed. Also, we've been trying to eliminate CDN material.
#7 - yeah, that's part of the site theme. :(
#8 :) thank you. We're using HSTS and passing lots of other good headers, too.
If you need a menubar, ok, write one. Just fix the pagination height so people can actually read your site.
Also the how-tos are too longwinded. You could probably reduce the quantity of prose by 50% or more. e.g. the very first paragraph "Getting logged in is easy and takes only a second..." is waffle and missing a vital opportunity to explain how the damn thing works!
(perhaps the link could be updated?)
> Even the most successful SaaS companies in the world don’t conform to the ‘best practices’ laid out by conversion specialists.
Not sure I agree with this conclusion. Obviously you should test to see what works for your audience but imo, the whole point of comparing how each company does X is to extract the most common patterns people can use as solid starting points.
The article would have been a lot of more useful if it listed at the end the most common elements SaaS pricing plans share like 63% offer a free trial. It's a waste of time to try to design from scratch instead of referencing what most of your peers are doing.
Also, just because some SaaS companies don't conform to the best practices, it doesn't mean that their way necessarily converts better. Maybe they would convert more if they did certain best practices.
As much as people love to blame vendors, this is mostly due to dysfunctional nature of the large enterprise buyers. They are addicted to discounts. First the buyer contacts you asks for one then after everything gets said and done done, procurement gets involved and ask for more discounts (seen as their job). Having listed pricing becomes a problem when going through such process, so most vendors either choose not to publish their prices, or have a tier for the enterprise that is not published.
1. ... Weed out non-serious prospects such as students, freelancers, small businesses, etc.
2. ... NOT deter serious prospects (enterprise users). They are used to this process and even expect it.
There certainly is, and it's a bigger problem than potentially turning away people who are uneasy about sharing contact info. Just to name one: A SaaS company may be willing to undercut a competitor's price for a sufficiently big prospect, but advertising a high price at the outset may turn that prospect away before you have a chance to talk to them.
On average there were 3.5 pricing options per company, with the highest priced option leading towards a "Contact Us" 38% of the time. I feel like the companies that published prices were not targeting enterprise level companies (just a hunch), so seeing the range of their prices could be a very interesting guide for pricing SaaS outside of enterprise sales.
For enterprise SaaS an analysis of the Lead Gen forms for the other 202 companies would be very interesting.
Seeing as how the services they provide will be so different, would it really be a relevant number?
Even then, how would you calculate it? The average of each company's lowest price plan, or the average of the average of each company's plans, or the average per-user price, or…?
> HubSpot’s fantastic article about decision fatigue included a study which showed customers who were presented with six options instead of 24 were 10 times more likely to buy.
> Sliding scales allow customers to be ultra-specific with their needs and pay for only exactly what they’re going to use. Plus, according to Peep Laja, giving users something to play around with will keep them sticking around for longer and subconsciously soaking in the details and pricing of your product.
Start with something that isn't awful. Get it up early. A/B test that crap out of out.
Keep it simple -- Only have one unit of measure (UoM) or feature differentiator at first. Having multiple points of differentiation or UoM leads to confounded experimentation. Try to add more " per's " over time :)
You can take forever debating this stuff. Data is the only guide.
Interesting. As a consumer I would like a slider, but as a company one wants to upsale the user a higher priced plan. Recently, I saw several new SaaS companies that have a slider.
If you're struggling with the how, you're probably not very happy with the what.