Linking SaaS Software Pricing to Value
Linking the value that a product or service provides to a price is an art, rarely a science. Software pricing, in particular, has suffered from this being done poorly. The old licensed-software model does not cut it anymore. Businesses won't stand to pay for a large number of software licenses they may or may not use, and then pay for maintenance on top of that.
One increasingly popular method of pricing software (especially SaaS) is based on the number of registered users of the product per month. SalesForce uses this model for most of its offerings and has a different price for each level (Professional, Enterprise, etc.). GroupSwim, the company I work for, also uses this model for collaboration.
For software that serves enterprise employees, the number of registered users is a good indicator of the value that a group derives from the product. Companies need only add the employees who will actually use the software, not everyone in the company. Metrics based on internal users have potential, but the application would need to be very specific. (Zoho uses a number of invoices to price its invoice module, which makes perfect sense.)
One downside to counting the number of users of a product is that people usually don't "quit" or unregister themselves. The onus is on the business to remove users who don't use the service regularly or who leave the company. It would surprise you how much trouble companies have managing this process. Money flies out the window when they don't manage subscriptions or licenses efficiently.
The other school of thought is to base prices on some kind of usage or activity metric. Lithium and GroupSwim Community are products for large external customer and partner communities; both companies use page views to charge customers. In theory, this metric is a good indicator of value because it reflects how much users are actually using the product or visiting the website, especially if you have a large number of users who use the product infrequently.
But there are disadvantages to this method, too. First, how do you measure page view? With the advent of AJAX, video, and other technologies, the page view doesn't always reflect how much users are using a product.
Secondly, a high page view doesn't necessarily mean that the customer is benefiting from the product. For example, many users could very well be clicking all over a website trying in vain to find certain information. Has this person derived value from the website or are they merely a frustrated user who could not find anything they were looking for?
One reason the usage model could make sense is that research has proven that the proportion of users who consistently use an external website tends to be small, relative to the entire community. A software company could try to identify these frequent users and charge only for their usage. But this is a rat hole. Rather, if a lot of people are visiting the website often, they are likely deriving value, and the customer would be charged accordingly. If the website is rarely visited, then it isn't adding value, and the price thus drops. Another company that has adopted usage-based pricing is Vertical Response; it charges based on the number of emails sent, not the number of users or administrators.
As you can see, there are many models to follow for pricing, especially with SaaS. No doubt, things will evolve in the coming years. As reporting and metrics continue to improve, pricing models will likely better reflect value and usage. What do you think?
Sponsored by
-
French Government Chooses Mozilla To Replace IBM and Microsoft For 130,000 Desktop PC's
October 30, 2009 / 11 Comments -
Email + CRM + LinkedIn + Twitter = Hustler's Power Drill
October 28, 2009 / 21 Comments -
Is the Relational Database Doomed?
February 12, 2009 / 111 Comments -
Proton Media: The Most Advanced Collaboration Technology in the Market?
October 30, 2009 / 11 Comments -
Netvibes Goes From Web 2.0 To Enterprise 2.0 In Partnership With Sage Software
November 3, 2009 / 5 Comments
-
Can $890,000 Make MediaWiki Useful?
June 12, 2009 / 10 Comments -
Proton Media: The Most Advanced Collaboration Technology in the Market?
October 30, 2009 / 11 Comments -
Yammer Goes Deep: 50,000 Networks Up and Running
November 3, 2009 / 3 Comments -
Enterprise 2.0: Declaring War Does Not Work
November 3, 2009 / 4 Comments -
CubeTree: Drilling Comments Down to the Cell in a Spreadsheet
November 4, 2009 / 2 Comments
Comments
Subscribe to comments for this post OR Subscribe to comments for all ReadWriteEnterprise posts
What does Saas mean?
I just wrote about something similar. I think you will have to categorize what the application is versus the approach. Gmail gets a lot more users than http://projjex.com so how would you price these. Another interesting variable is what role will advertising or supplemental information play in pricing. For instance would business be willing to have their treasurer marketed to via their hosted financial system. Think Mint.com but at a corporate level. How should this impact my pricing? Then you have services that save you money like a ZIP+4 address normalization service versus ubiquitous services like email, IM, collaboration.
SaaS = Software as a Service. It's a subscription model. In a way it's like going to the gim, instead of buying the equipment.
Though different services have different price models, it's usually easy to calculate the spending upfront. In current economic conditions this only makes sense.
We lately stopped using Sharepoint on our intranet as a place to manage the projects, since we had to reduce our IT staff. Plus we could never could calculate the costs of running it (maintenance, hardware, man hours).
We moved our project management online, and chose 5pm (www.5pmweb.com) after shopping around. None of their plans worked for us, so they created a custom on our request.
Though it takes time to adjust, we, finally, don't have to bother with maintenance and can measure the spending.
Another good thing about SaaS - so far we got great service. Emails are responded within hours if not minutes. We had a totally different experience with Microsoft.
Though SaaS have a long way to go and some software is just better handled internally, there are areas where it definitely fits in. SaaS will only grow and improve the payment models, adjusting to the businesses, as they a much better connection with clients.
Unless I missed it in the article, another common strategy is tying price to features. Basecamp, Unfuddle, Freshbooks, and tons of other free-to-$50-ish SaaS vendors entice users with free, no-frills starting points, and start charging for not only more users, but more features.
This is a very interesting discussion. We priced Pelotonics as a per-project basis. That was the clearest way to go. We want to foster collaboration and I think that a user-based model steps on that guiding principle. Look at Salesforce, if you have ever used it, you know that you need to conserve licenses and as a result you don't get all the value out of the product. (unless you have buckets of $$ to throw at it)
We technically also charge on file storage, but our limits are now so high that this is RARELY a factor that prompts a user to upgrade.
The issue that I am grappling with is whether or not to charge for integrations. For instance, should we charge for our Google Docs or Evernote integrations? Or should those offerings just be part of the whole monthly subscription fee? My leanings are to bundle it all up...keep it simple and keep adding value to differentiate us from other offerings!
@troymalone
Pelotonics
effective pricepoints and how to price this new software is certainly the $64thousand question. indeed, zoho approaches this smartly. another potential price scheme could include a matrix or sliding-scale of usage...when usage is above a certain threshold, charge accordingly. likewise, when usage halts below a minimum threshold lower pricing accordingly. you can clock this from login to logout with auto logouts after 10 minutes of inactivity. just a thought?
At the risk of this sounding like Linkbait (sorry Jason and Richard) - more, much more on SaaS 9software as a service) at cloudave.com
Excellent article.
Saas or web services are based upon a subscription : OK.
However people and companies will only subscribe for a service delivered that adds to their business.
Thus the result of the service, and this is not the number of users.
In our case we sell the "number of leads":
The website visitors that users qualify as leads themselves, based upon the search terms used, pages visited, language, geographic location and additional information on the company.
The number of leads relates to the people who are going to pay: CEO or VP Sales.
Whereas the number of users and number of visitors to the company website has no value for generating revenue - leads do have a direct relation to the potential revenue.
We sell Leads.
All existing models are imperfect, because the value of each usage unit (user, contact, lead, project) to a company is different.
Some Relenta customers have two users who manage 20,000 contacts; some have 10 users who manage 1,000 contacts. Yet they pay the same price per user.
So what do you do if all available pricing models are inherently wrong? Make pricing irrelevant. Provide value that exceeds costs by orders of mangnitude.
At www.time59.com we have a very simple $49.95 annual rate for unlimited use. This works for us because Time59 (an online time and billing service) is desgined for solo professionals. It doesn't have multi-user features so the application inherently limits the utilization of the application by a single subscriber. So I think an important factor in the pricing model is to prevent over-use of the application by any given subcriber. This can be achieved by a combination of pricing and the design of the application.
Pricing per user or per use sounds great but it encourages bad behavior in the client. Now all of a sudden they have to decide who should be able to use and who shouldn't = fail. Which ideas are worthy or which aren't = fail. Plus it's a bitch to forecast usage unless you force people to use a tool they may not want to use or may be flawed = fail. Got be a better way.
Many software and information research vendors use the pricing method of 'registered seats'. That is often the closest metric to get to the value that the client is getting or has purchased. The problem even with that is registered user doesn't necessarily equate to 'active user' or the number of registered users that are actually using the product regularly. So even with the page views model, the number of people registered may not give the client or the SaaS vendor a good picture on how much value they are truly getting from the offering.
@Ben Strackany: Just wanted to let you know that FreshBooks doesn't limit features to paying customers. Our free model is only restricting insomuch as you can invoice only three clients. All features (and we are constantly implementing new ones) are available to all users.
Our pricing model is based on the number of clients a user has. So, when someone upgrades, they do so because they have gained clients! Which is good for any business, right?
Rayanne Langdon -- Marketing Coordinator, FreshBooks.com
Great comments. Several thoughts:
1. Pricing software in the coming years will be more art than science. As was pointed out by several people, there are many ways to do it; there is no silver bullet.
2. Old-school license pricing will eventually go the way of the sub-prime mortgage. Most companies aren't going to put up with it in the future. The won't pay the up-front costs or if they aren't getting value.
3. Reporting and identification of value will become more important. Software vendors will need to be prepared for this.
Per user pricing is a throwback to the old model of selling software, when there was no way for the vendor to monitor actual usage. It makes no sense in a SaaS world - it's like charging for electricity based on the number of people in the house.
SaaS vendors love to use the electricity analogy. They need to see this through to its logical conclusion - pricing based on usage. There are many ways to come up with a viable unit of measure. Few of us have a real understanding of the units of measure the utility companies use, or even think about it. We just know we are getting value for our money, and need to pay more the more we use the service.
Also, take a look at "Subscription pricing is hard to do" at http://www.powerinthecloud.com/blog/2009/1/11/subscription-pricing-is-hard-to-do.html
Bottom line, pricing for a SaaS application should generally be by usage. Exactly what that means is going to depend on the specifics of the application and the usage model: what measure of usage is delivering the client value (so your pricing is a proxy for how much value the client is receiving from the app), but also what usage measure is relatively straightforward for the software vendor to monitor.
Joanna
It can be a very difficult process to pin point the exact amount of value added. Every model not only has flaws, but usually at least one major discrepancy. Sure it's easy if your advertisers/etc. can gauge the value added through their ads on your site, but what about SaaS that's sole purpose is security related for example? If a financial institution can't justify a flat our purchase and wants to remain agile in its strategy, SaaS is probably the best way but difficult to value.
I often wonder if the SaaS trend will overlap further at the consumer level. The drawbacks there are similar, art of pricing, complexity of agreements, enforcement, etc.
I think it is also important to make a pricing model that makes sense to the customer based on the application being used.
A per employee, or blocks or employees, charging basis works very well for our payroll application flexitime.co.nz. The user only pays for active employees, this works because the user makes an employee inactive by updating the employee's finish date, something that fits with the way payroll works.
Charging our users based on how many hours of usage or disk space used would be ridiculous and would lead to a lot of work by our accounts department.
The worst model for pricing is the complex electricity usage model where you pay a fixed priced for line plus a variable rate based on time of day, it is overcomplicated and unnecessary for SaaS.
Years ago a mentor taught me a pricing rule that has held up for us in the transition from software to Saas.
Determine your cost, double it and then add 50%.
The trick with Sass is you have to throw out the initial license and price at a volume you believe you can achieve in a given period of time.
Pricing based on usage creates friction toward adoption. Friction is bad. Creating usage correctly should create viral usage and new viral customers.
Mostly free with one fee for a professional level package is working well for us.
Pricing for SaaS is always a tricky proposition.
It's a balance of finding out what works for you versus what works for your client and target industry.
We have a SaaS application for the Shipping Industry and we charge either by the Booking or by the Voyage - whichever the particular client prefers.
Mind you, when you link your revenues so closely to your client's it makes SaaS less appealing to the vendor in the current economic climate - however conversely more appealing to the customer.
Great points.
Jonathan's point is interesting. I don't think electricity is the right way to think about SaaS pricing, because electricity is a commodity and is undifferentiated. If the SaaS software solution is providing a commodity solution like hosting email servers or something, then it is a fair comparison.
Rob's comment on keeping pricing simple is spot on. If you try too hard to make some crazy scheme up, you run the risk of making the pricing scheme hard to understand and subsequently sell.
At GroupSwim, we use registered users for our collaboration product. The product has a wiki, discussions, file collaboration, etc.. We could have used some scheme that tracked these things to calculate a price, but that would be a nightmare. Instead, we went with registered users assuming companies or project teams wouldn't add members unless they really needed the information in the application or were active collaborators. Also, as the number of users goes up, the price goes down. We don't want to erect any barriers for growth as Duke pointed out.
For GroupSwim Community, which is our external community/forum product, we went with page views. Studies have shown that a small number of people actively engage in these public communities, and the vast majority either lurk or don't participate at all. So, we decided if a community was really dynamic, then the customer is getting value. We decided page views are the best proxy for this.
Many great insights in this post. Pricing must be based on a value metric that your potential customers agree provides value to them.
The example of the power company billing although as pointed out is a commodity is still an example of billing for consumption which is easy to understand and hard not to agree with
I see many SaaS companies that have adopted annual pay in advance pricing with very high limits on usage before you go to another level or they simply provide an all you can eat menu. The annual fee is set somewhere in the middle of where they think their sweet spot is.
My thoughts on that is that it prohibits adoption for the smaller companies and leaves money on the table for the larger ones.
Why not combine a reasonable per user or per something fee that allows all prospects to buy your product and then a metered fee that charges for value.
Whereas the power company model is simplistic, I think the classic mobile phone provides an example of a fairly complex plan (monthly recurring, metered services and even free sometimes depending on when you use it). It is also a plan that truly bills for services rendered.
You can buy almost any mobile plan from entry level for the low use consumer (Pay as you go) to high volume business plans, and at the end of the month when you get your bill, it is hard to dispute that you got billed based on the services and value delivered to you. At the same time their are no barriers to entry for and size of prospect.
If interested I wrote myy own blog last week on why I don't think anual in advance billing is a good idea in 2009, which can be viewed at this link. http://www.ipapplications.com/index.php/blog.html
Kevin Lennox
IP Applications
The utility model may not work well with SaaS. One is Jason's commodity point. There is another reason. Running water or electricity at our homes is a necessity and its value gain simple, and with that, we always try (or should) conserve. SaaS applications' value are more complex and value most likely increases over time (more data, expanded features, etc.). If SaaS was charged as a pure utility, then the boss would say, use it as little as you need to since every time you go in it costs us money. Rather, the enterprise should encourage use if there is really good value that can come out of it over time. My current preference is the per user seat model with the ability to add or remove seats over time.
Paul, by the same token, pricing based on users discourages the adding of more users, and actually encourages "cheating" by allowing multiple people to use the same user account.
@Rayanne - good to know about FreshBooks. I had thought that there were different features per price, but you're right, the only thing you don't get on the free account is unbranded emails. So while arguably that one feature isn't available to the free customers, that would be nitpicky of me. FWIW I really like FreshBooks, which is why it's top-of-mind for me when thinking of good & affordable SaaS.
Our SWM product (interestingly pronounced SWIM) will be following a fairly standard SaaS pricing model... a free plan, so users can evaluate the product and then tiered pricing to fit with their demands. Setting the pricing is tricky, but due to the number of other similar SaaS subscription models, it's based on the levels the industry has set.