It Might Be Time To Ditch The SaaS Monthly Subscription Model(techcrunch.com)
techcrunch.com
It Might Be Time To Ditch The SaaS Monthly Subscription Model
http://techcrunch.com/2012/11/24/is-it-time-to-ditch-the-saas-monthly-subscription-model/
2 comments
I think this depends on the kind of thing you are selling. If your product is tied to my sales in some way, I actually would much prefer to have pay-per-use, as it actually decreases my risks. If, however, your product is related to my R&D efforts, then it can become highly confusing to estimate the per-use costs, and something like per-seat or even per-month will be better.
As an example: I know that I sell this product for $4. I also know that PayPal charges me $0.30 per-use for the transaction, I know that Amazon S3 charges me $0.01 per-use for the download of the user manual, I know that AuthSMTP charges me $0.001 per-use to send you the receipt, I know that the product itself costs me "per-use" $2 wholesale, I know that UPS charges me $1 per-use to ship it.
If I put all of this together, I know what my profit margin is per-sale, and I therefore know how much money I can spend on things per-sale. If you then come to me with something and say "our service will cost you $1 per sale, but will make customers so happy that it will double the number of sales you make", I know right off the bat I can't afford it unless I raise my prices (which I hopefully also have some kind of model about the effects of): per-use, I simply don't have the margin to do something that costs $1 per sale in this model, no matter how much it increases my sales.
However, if you say "this costs $100,000 a month, and will double your sales", I start to have to think about it: if I currently make less than that, but it will double my sales, will I then be able to afford it? Maybe I can, and that's great! But... what if my sales slump a little next month? Will I still be able to afford it? Signing up for this service is now a liability, as I need to maintain a justification for the fixed per-month price: there is the irritating risk that the situation changes and I can no longer afford the fixed fee.
It starts getting somewhat complex with things like "support ticketing systems" (I am going to define this as something used "in house", not something that a customer directly accesses and thereby could DoS me with by filing an infinite number of tickets). I often think these should be charged per-incident, however there is a related argument for per-seat. Let's say that I know that 5% of my customers ask me a question, 50% of those can be answered with a form letter, most of the rest just need a manual refund, and the remaining 10% of those need more complex help and end up in a ticketing system.
If you say "per-incident, our support product costs $1", I can then rapidly work out that that costs me $0.10 per sale, which is within my budget as I can afford it with the margins in my example. Likewise, if you charge me $0.015 per minute of VoIP phone call connected to an IVR system, I can compare that to my other per-sale support costs to see whether that will be a net win or loss for me: if it decreases the number of e-mail support requests I will get by half, that decreases the cost of e-mails sent and received (and written/read) per sale, and I can compare.
However, let's say I am attempting to use GitHub to develop my product; well, I don't really have any business statistics on how I use git, my sample size will be tiny anyway as I only have a small number of developers who would be using it, and it really has nothing at all to do with my sales... it is more of a business overhead that allows me to replace other overheads (maybe time spent by employees, or entire employees); the risks associated with it have very little to do with my sales: either it saves my employees time or it doesn't. I can totally see this being great then "per-seat", and charging me per-use will get confusing and irritating.
Although, if your costs scale per-use (which they probably do) it should still be considered; on your end, though, you probably have great statistics on how people use git (as for you, this is now your analysis of your sales margin) that averages over all possible customers, and can come up with a more accurate picture of my usage. However, as it is a customer-facing usage, it might get scary for you to carry that risk that the playing field will change--maybe git 1.9 comes out with some crazy new feature that makes it use twice as much bandwidth to the server--and now your statistics are hosed in the same way mine would have been if I bought a customer-facing support system with a per-use fee and got DoS'd by an angry customer.
In a way, though, per-seat is just per-use for a different kind of use: it is related to how my employees use it, and forces me to think about how I will budget it differently based on my employees: instead of thinking how it affects my customers, or how it affects my product quality, I now think about how it will affect my employees. I can now start saying things like "I pay my employees $100k/year, and half their time is spent on support; if your product cuts the time they have to spend on support in half and costs less than $25k/seat/year, it is financially intelligent for me to purchase it".
Most of the pay-as-you-go plans, though, are really not just pay-per-user plans with weird usage caps organized into tiers. I will again argue that this is just increasing my risk: if tomorrow I had a "great day" and sold a hundred million products when I'd normally only sell a hundred, I would not sit around going "shit, my EC2 bill is going to be a million dollars this month... I should have had a cap"; instead, I'm going to go "awesome! I just made $30m, because I know that I make $0.30 per sale once you take into account all of my costs".
As an example: I know that I sell this product for $4. I also know that PayPal charges me $0.30 per-use for the transaction, I know that Amazon S3 charges me $0.01 per-use for the download of the user manual, I know that AuthSMTP charges me $0.001 per-use to send you the receipt, I know that the product itself costs me "per-use" $2 wholesale, I know that UPS charges me $1 per-use to ship it.
If I put all of this together, I know what my profit margin is per-sale, and I therefore know how much money I can spend on things per-sale. If you then come to me with something and say "our service will cost you $1 per sale, but will make customers so happy that it will double the number of sales you make", I know right off the bat I can't afford it unless I raise my prices (which I hopefully also have some kind of model about the effects of): per-use, I simply don't have the margin to do something that costs $1 per sale in this model, no matter how much it increases my sales.
However, if you say "this costs $100,000 a month, and will double your sales", I start to have to think about it: if I currently make less than that, but it will double my sales, will I then be able to afford it? Maybe I can, and that's great! But... what if my sales slump a little next month? Will I still be able to afford it? Signing up for this service is now a liability, as I need to maintain a justification for the fixed per-month price: there is the irritating risk that the situation changes and I can no longer afford the fixed fee.
It starts getting somewhat complex with things like "support ticketing systems" (I am going to define this as something used "in house", not something that a customer directly accesses and thereby could DoS me with by filing an infinite number of tickets). I often think these should be charged per-incident, however there is a related argument for per-seat. Let's say that I know that 5% of my customers ask me a question, 50% of those can be answered with a form letter, most of the rest just need a manual refund, and the remaining 10% of those need more complex help and end up in a ticketing system.
If you say "per-incident, our support product costs $1", I can then rapidly work out that that costs me $0.10 per sale, which is within my budget as I can afford it with the margins in my example. Likewise, if you charge me $0.015 per minute of VoIP phone call connected to an IVR system, I can compare that to my other per-sale support costs to see whether that will be a net win or loss for me: if it decreases the number of e-mail support requests I will get by half, that decreases the cost of e-mails sent and received (and written/read) per sale, and I can compare.
However, let's say I am attempting to use GitHub to develop my product; well, I don't really have any business statistics on how I use git, my sample size will be tiny anyway as I only have a small number of developers who would be using it, and it really has nothing at all to do with my sales... it is more of a business overhead that allows me to replace other overheads (maybe time spent by employees, or entire employees); the risks associated with it have very little to do with my sales: either it saves my employees time or it doesn't. I can totally see this being great then "per-seat", and charging me per-use will get confusing and irritating.
Although, if your costs scale per-use (which they probably do) it should still be considered; on your end, though, you probably have great statistics on how people use git (as for you, this is now your analysis of your sales margin) that averages over all possible customers, and can come up with a more accurate picture of my usage. However, as it is a customer-facing usage, it might get scary for you to carry that risk that the playing field will change--maybe git 1.9 comes out with some crazy new feature that makes it use twice as much bandwidth to the server--and now your statistics are hosed in the same way mine would have been if I bought a customer-facing support system with a per-use fee and got DoS'd by an angry customer.
In a way, though, per-seat is just per-use for a different kind of use: it is related to how my employees use it, and forces me to think about how I will budget it differently based on my employees: instead of thinking how it affects my customers, or how it affects my product quality, I now think about how it will affect my employees. I can now start saying things like "I pay my employees $100k/year, and half their time is spent on support; if your product cuts the time they have to spend on support in half and costs less than $25k/seat/year, it is financially intelligent for me to purchase it".
Most of the pay-as-you-go plans, though, are really not just pay-per-user plans with weird usage caps organized into tiers. I will again argue that this is just increasing my risk: if tomorrow I had a "great day" and sold a hundred million products when I'd normally only sell a hundred, I would not sit around going "shit, my EC2 bill is going to be a million dollars this month... I should have had a cap"; instead, I'm going to go "awesome! I just made $30m, because I know that I make $0.30 per sale once you take into account all of my costs".
1) they're risk averse and want to know what pricing they're signing up for (pay-per-use is often much more difficult to figure out what you'll wind up paying in the end)
2) most businesses operate within known budgets, and introducing new software on a pay-per-use basis may hurt their ability to accurately plan those budgets.