When Should Software be Sold Pay Per Use?
Part of defining your SaaS business is determining a pricing strategy. Two primary categories of pricing taxonomy in the SaaS space are pay per use (each time a user uses your software, you charge a well known amount. Much like buying beer at the bar) vs. fixed recurring pricing (much like paying for cable television, where you pay some periodic fee for generally unlimited access). As a SaaS ISV, when should you choose one vs the other?
The decision really boils down to understanding value acquisition from the customers perspective. In order to charge on a recurring basis, you need to be able to justify your pricing with a measure of the magnitude of value acquired by your customer along with value acquisition frequency. For example, if you’ve designed a very valuable piece of software that might be used once or twice a month by your customer in their business processes, odds are they would prefer to “pay per drink” rather than a recurring fee since theoretically you should be able to charge less in an absolute sense for that one time used instead of unlimited for a given month (they would generally be willing to pay a premium as long as total cost is lower than recurring fee models). However, if your offering has frequently recurring value acquisition from your customer’s perspective, odds are they’d prefer to pay a fixed fee at some frequency knowing that the firepower is available to them when needed and that cost is fixed but value acquisition has no ceiling.
Clearly, what I’ve described is a trivial rule of thumb. If you’ve ever encountered this decision or have thought about the differences in these models, what other components should be considered? Have you ever offered a SaaS service in one model and then switched, or ended up offering both?
Related Posts
Tags
Share This
SaaS vendors, such as BIW, in the UK construction collaboration technology market mainly deliver their solutions to customers on a fixed monthly or quarterly subscription. As the solutions are used to promote collaboration among a fragmented, multi-company supply chain, having a single paying customer (usually either the ultimate owner/operator of the built asset, or the main contractor or project manager) is simpler.
Moreover, in an incredibly cost-conscious industry like construction, this payment model (unlimited users, unlimited amount of data) also encourages take-up and use of the software. Paying on a per-seat or per-use basis could well lead to supply chain companies trying to avoid using the system (perhaps setting up parallel, unauditable systems), or sharing logins, with a resulting direct impact on the quality and integrity of the stored information and managed business processes.
Hello Sinclair,
Having been in the process of defining the pricing of a new SaaS Business Application, I went through the same kind of considerations.
My associate and I had the feeling that people should pay for what they get and use.
In our case, we deliver a Timesheet, Expense Management and Invoicing SaaS application. There is one particularity, which is that each feature can be used separately.
When it comes down to define a price per use, you need of course the price but also the unit you will use for your pricing.
Looking back at our example, you could imagine that the unit for timesheet is a timesheet record, the unit for expense is an expense record and the unit for invoicing is an invoice.
It makes sense to pay more if you are a call center company using intensively the timesheet application to keep track of all your calls for example.
But take a small company of 10 consultants in IT. They will probably have 20 timesheet records per person per month, 4 or 5 expenses per person per month and the company will probably have like 5 or 6 invoices per month.
So, when you start presenting your price per use, you will get something like a very small price per timesheet record, a middle price per expense record and a big price in comparisons with the 2 others for invoices.
The first conclusion was indeed that the “per use” model is quite difficult to apply when quantities are low. The difference between the numbers doesn’t give a “sexy” look to the global pricing and we thought to take Invoicing out of the per use model.
The second conclusion came by comparing this model with what the others do. (Usually a price per user/per month in packages). Again, it wasn’t giving some kind of “Wow!” effect.
The pricing should directly be attractive for the future customers. In a few seconds he needs to know if he will makes some profit or not.
If the web site visitor arrives on the pricing page and start counting how much his employees will enter timesheet records, how much expenses, … well he will probably be away before knowing the answer.
The conclusions was that it is difficult to apply the per use model if the competition doesn’t do it. People cannot compare easily then.
So, I have abandoned the idea of applying the per use model to the pricing for now but not completely.
My plan is to reintroduce it but not in the pricing page of the application but as a service to my customers.
If I discover that certain customers could pay less changing their pricing model to a per use model, I will propose them the switch.
It will makes less money at the end, but the benefit of having your users satisfied is priceless.
Of course this is still only on paper and future will tell me soon if we are on the right path.
Paul,
All good points – especially the fact that how cost-conscious your industry is important in the decision.
Yves,
Thanks for the rundown on your decision making process when it came to pricing. One comment you made is important
“It will makes less money at the end, but the benefit of having your users satisfied is priceless…”
This is very true from a revenue sense, but one benefit of the pay per use mechanism is that it generally carries higher margins, so your net income % could be healthier than when using a recurring model. Of course, this is not always the case, but the “a la carte” aspect can carry a premium.
We’ve also just been through a pricing overhaul and considered the per use model. We ended up sticking with a per user model though, mainly due to our users accessing the service on pretty much a daily basis.
The product is an online training/elearning system, that makes life easier for companies wanting to move their training online.
One big change that we have made recently is to do away with user bundle pricing and just charge a flat fee per user. This gives the customer more flexibility and they don’t get that feeling that they are paying for X amount of users but only using 75% of them.
Getting the revenue model right really can make or break a SaaS offering.
Sinclair,
My company uses a concurrent user subscription model. In a B2B world, some degree of cost certainty is necessary if the tool is a regularly used application (as ours is). Ultimately, there are a couple factors that need to be considered…
1) What is the customer willingness to pay. How much in total will they spend each period (day/week/month/quarter) – and consider it reasonable? That’s the magic number to understand. At that point, either method of dividing up the aggregation process (use/user) is probably ok – with the advantage going to whichever one is simplest to figure out the final period answer.
2) Understanding the dynamic of “whichever is least”. Sometimes a second billing method can be offered as a way to give the user some degree of power over controlling their cost profile. Pricing both ways and letting them choose could be effective – it helps them feel like they are getting a deal. In this case, you set up the situation of competing with yourself. (which is great because you win the business every time, or bad because you lose the better business every time.
Personally, I’ve been looking at marketing e-mail tools lately. Constant offers the period billing (which is nice because it gets the payment over quickly and frees me up to use the tool without hassle). Campaign Monitor offers a per e-mail option (I could pay less overall, but have to deal with payment every time I sent an e-mail).
Different methods appeal to different customer values.
Thanks for the nice information.
Best Regards
Arpit Kothari
Offshore Software Development
Hi all,
Great discussion.
I believe it comes down to getting out of the way of incremental revenue.
If your customer wants the flexibility to use your service beyond their pre-paid subscription – if they indeed have one – you don’t want to get in their way.
Customers will not want to incur additional usage based costs without knowing about and possibly getting internal approval. This is where functionality to give them complete visibility on usage and associated billing is important. Another option that is very popular is where all billing is pre-paid and if the customer hits the limit of their pre-paid subscription they simply purchase more, either by upgrading their monthly subscription or adding a single batch of additional units.
Jim Geishman of MarketShare (http://softwarepricing.com/) did a great webinar for us on software pricing for SaaS http://www.opsource.net/saas-resources.php?page=webinars
As we like to say – Your customers need to get what they pay for and pay for what they get.
Thanks,
Alan.
Good Post Sinclair. It definitely boils down to what you larger customer base wants and would ideally use it for. It becomes imperative that you have both models where pay-per-use comes at a slight premium in comparison to your monthly subscriptions.
Saba.
http://sdaas.wordpress.com
Whereas the 2 strategies you mention are definitely being used widely, as part of my job at Patni Computers, when I discuss SaaS strategies, architecture and implementation with ISVs, I think that a sound pricing strategy is based on a lot of different factors. We need a solid understanding of the customer base, their consumption patterns, the value derived (as you talk about in your post), what the competition is doing, what the market will bear and much more. Is your product a niche product? In that case, you probably want to go with a per transaction or usage pricing policy. Some ISVs also experiment with billing in arrears vs. in advance. How price sensitive is your target customer? When do you offer price discounts, to whom, under what conditions?
These are only some of the issues that I go over with my ISV customers before we arrive at some concrete idea on what the entire pricing package for their SaaS product should look like.
For more discussion on this topic and other SaaS related issues, I invite you to also stop by my blog:
http://sumanchaudhuri.wordpress.com
Suman
Suman, one key phrase you used is “pricing package.” One thing to identify is that regardless of model, there are generally various components to pricing and your sort of analytic approach should focus on extracting those components.
While reading Sinclair’s synopsis I wanted to share a story with you all
I am not going to mention any names BUT I have a customer that I am dealing with who is working somewhat backwards here.
Let me explain.
They have been a Very niche SAAS player in the telecom billing space for 5+ years now. They went to market with a “Pay Per Use” model and today their average customer pays them 5 figures per month to use their service. Sounds like a good problem to have right??
They are currently looking to combat churn… :-)
You can imagine that they work feverously to add modules & features to increase value of their SAAS offerings and are coming up with Client/Server application to retain their customers.
Now how is that for a Pricing decision that can hurt you at the end.
SAAS pricing models are utility based and should be well thought out before going to market.
My 2 cents,
Very interesting discussion indeed. Clearly there are a wide spectrum of options. The key for a SaaS company is revenue optimization. This may mean the use of a hybrid model which a base subscription fee and per use fee. Again this depends on the targeted market segement. Price sensitive market segments may want the pure per use and the corporate customers want a predictable price. eVapt is hosting a webinar on this very topic on July 30. Feel free to register with the link below.
https://cc.readytalk.com/registration/aa951g8fgr4o/577dl6nzb8tj
If you have difficulty with the link look in latest news section of http://www.evapt.com.
Great post Sinclair and great comments from everyone. My perspective is some what tainted by the fact that I’m a user (not a technologist, not a vendor) – as such I see SaaS as being all about the solution, speed and efficiency.
I agree that there are sometimes benefits in following a “pay for what you use” methodology. However I have to agree with Yves – SaaS buying decisions, being bottom up decisions (generally) should be quick and easy to make. A veritable menu of pricing options doesn’t allow for this speed and can be a barrier to the quick buying decision that SaaS vendors need.
I agree with Alan’s comment about primarily using a per user charging model but also allowing for some customisation in terms of a charging model. It would seem that this would offer the best of both worlds – allowing for a quick easy decision but also giving scope for the use cases that are outside of the norm
Hi
Our company has developed a SAAS solution some time ago that provides SCADA (Supervisory Control and Data Aquisition) on demand to water authorities pumping stations. Our pricing model has always been a fixed per site monthly fee. We don’t have the problem with shared seats because each pumping station has its own cellular address and we install the embedded device that is being monitored and controlled. With the economic downturn the once poor acceptance of our product is now showing signs of changing and we need to gear up for some big growth. My problem is making sure I have the right people in the right roles. If anyone has any views on what the must have skills/roles are I would love to hear.
Wayne,
Key roles are really dependent on your goals. Off the cuff, however, I’d say that any growing SaaS company should generally fill upper management positions dealing with SaaS/subscription based sales, a technologist role (CTO) with experience in hosted software, growth and risk management related to centralization.
Any details as to what your concerns are with the growth so we can give you better input?
Thanks Sinclair
One of the growth issues we have is to do with pricing a moving target. Our customers want predictable pricing. But we pay the telco for comms from these remote sites — they can and do change their rates. And as customers become more comfortable with the technology they start bringing more info back from each site – again up goes our telco costs. Costs that we have not factored in to the original contract so we are wearing the risk. The roles I thought I might need in this environ were more comms or network expertise? Thoughts?
Hello Sinclair,
Phil Wainewright is talking some feedbacks on the poay per use approach on PaaS.
Here : http://blogs.zdnet.com/SAAS/?p=559
Conclusions from Coghead’s CEO are going in the same direction than the current discussion even if PaaS had until now more of a pay per use model.
So are we condemned to the packaged approach ?
Hi Wayne,
It seems to me that you’d want a marketing person and finance person that understand price buffering on the sale side and a finance person that can help trend cost changes. You would also need to realize that price stabilization is good, but reserve the right to change price at discrete times (such as yearly).
From a price buffering perspective, the person filling your marketing role would have to be skilled in being able to gauge what your market could bear, and pricing at a high enough price point to help buffer against cost fluctuations coming from the telcos. Here is a fine example of where not competing on price and being able to sell your product at a justifiable premium offers you margin protection.
Second, someone with trending and analytic experience can help project cost fluctuations and coordinate your price changes (if necessary) to your customer base.
If you can get individuals with telco experience, even better, but most reasonably smart individuals with the above skills should be able to help regardless. Hope that helps!
Hi Yves,
To be honest, I don’t think we’re bouond to any particular approach. The Internet, unlike the cell phone industry mentioned in the comments of Wainewright’s post, has created the expectation that you can get what you want, when you want, and how you want. That said, I think the industry will always be a pricing “grab bag” with options to satisfy everyone. PaaS will more than likely drive this since PaaS can consolidate pricing mechanics down at the platform layer, allowing SaaS providers to take advantage of the variety of pricing mechanics offered by the PaaS offering with no effort.
Essentially, PaaS will and should drive toward allowing for a variety of monetization schemes that SaaS providers can take advantage of. Prior to PaaS, it was the responsibility of each SaaS provider to deal with pricing intricacies, and since most SaaS providers are resource strapped, they would generally focus on a primary pricing model and wait until the “next version” before offering other options.
Hi Wayne,
To add to Sinclair’s comment, one thing that you can (and to my opinion should) consider is that normally you can negotiate with the Telcos a hosting package where you should figure out what your average user cost is, this should be assuming average usage of your application. It will come a point in the lifecycle of the usage of a given customer that either because he has been a very long time client or because of heavy usage of the application where he is consuming considerable more resources than any average client. I would say that it is fair to charge that client an additional fee for the extra amount of resources that he consumes every month.
In essence your pricing would be something like $n a month per user for y number of resources and for every additional z number of resources used you would pay $m a month on top of the regular subscription fee. In a similar way you can be creative about this and say that you would price your application at $m a month (where $m = 10 x $n) for up to 10 users for x number of resources (where x = 10 x y), this helps you absorb costs a little better and you don’t have to bother the client with overage for each independent user. Further you don’t have to introduce the notion of resource utilization when exposing it to your customers to keep things simple but you would explain it as part of the contract that their usage is tied to the average number of resources consumed for the average client and that they should not have to incur additional expenses unless they go over the normal usage of the application.
The problem of not doing this is that as time goes on, depending on your acquisition rate of new customers the cost per client can increase when it should only increase for the certain number of customers that are using more resources than normal.
Hope this helps!
Abe
Thanks for the great advice – we can put most of those initiatives to work pretty quickly. However the one factor I still have to get my head around is pricing for comms from telcos supplying data access (rather than voice) who seem happy to provide second rate service because they are not focused on this part of the market.
I’ll have to agree that it’s very important for a customer to know in advance what he can expect on his next bill.
It will not only help when closing the deal so he can compare quickly with other solutions but will also help keeping your existing customers.
SLAs should also come into play in your pricing model. One example is the following model.
The customer will pay a per-usage fee. However the pricing model will have a maximum fee. When that max is reached the customer is switched over to another set of servers along with other customers that are going over their allowed usage. So what you are giving to your customers is that while they remain in the allowed usage they will have one SLA and when they go over another SLA. Some customers will want to leave with that to be sure that their cost is capped. Some others will accept the fact that their costs are not capped to always get the same SLA. In both cases the communication is very important and at least an email should be sent when they go over their limit. Another mechanism that can be implemented is an alarm when the customer goes over his past usage statistics. If the SaaS Company is doing correctly the metering, that information will easily be available and can be used to let customers know in advance that their next bill is likely to change.
A SaaS company should always charge on usage even when it might seem they are not. When a company charges a per-user license it is still charging per use behind the scene. It is constantly monitoring usage to get the average use per user to adjust the per-seat price based on that.
Usually the costs-usage graph of the SaaS Company is not linear but making small steps (e.g. when adding a new server) and your pricing model should also take that into account. Bottom line is that you should first study your own costs and then derive your pricing model from that.
This concept is new and innovative. I have seen many webmasters who provide such software service based on monthly subscription but this won’t be affordable all the time. I think this is very hot trend in internet marketing world where many big companies are in the business of various web/desktop based tool. I like the concept. Thanks for sharing.
Thanks,
Susan
custom software application development
Hi
Great article.
I am developing a product that is very niche and will be used by market research companies. It’s just me on my own, a lonely developer. Currently there are 3 companies using it just from word of mouth and no effort on my part. They pay ~£200 per month for the privilege. On average, it is used 0.7 times per month to create a new Project in the system, although It has only been running for about 11 months now. Now that i’m starting to take the project more serious and thinking of expanding, I’m wondering what I should be charging, or if I should be charging per use. Additionally, the client that each Project is created for (their client not mine) can log into the system at any point to look at the research done for them (their projects), so this is an incentive for my clients to keep paying their monthly fee so that their clients can log in to the system. Incidentally, their clients are literally some of the biggest brands that exist. Can anyone give me some advice on what I should do or what my next steps should be?
Regards
Chris