Our Recurring Payment Pricing Was Rejected(jerviswhitley.com)
jerviswhitley.com
Our Recurring Payment Pricing Was Rejected
http://jerviswhitley.com/why-should-i-pay-for-your-saas/
80 comments
This is a valid argument. SaaS is a step in the wrong direction for use cases where continued access to the service is crucial.
I do not trust LastPass or similar third party systems with my passwords. Passwords are too important a part of my identity that I should have complete and exclusive control over it. (I use a mix of Text files+TrueCrypt+Timemachine and Dropbox for sync).
Same goes for email. I use IMAP to keep a local storage of my emails. But that is not a complete solution - my email address is still owned by a third party (Google) and they can lock me out of my identity any time they choose.
I'm currently cobbling together a couple of scripts to backup my pictures and media, mostly WORM (http://git-annex.branchable.com/backends/) data, onto multiple harddisks. The 1 TB storage of Flickr is enticing, but I'm not ready to exclusively trust a part of my identity which I want to indefinitely preserve, to yet another third party.
I do not trust LastPass or similar third party systems with my passwords. Passwords are too important a part of my identity that I should have complete and exclusive control over it. (I use a mix of Text files+TrueCrypt+Timemachine and Dropbox for sync).
Same goes for email. I use IMAP to keep a local storage of my emails. But that is not a complete solution - my email address is still owned by a third party (Google) and they can lock me out of my identity any time they choose.
I'm currently cobbling together a couple of scripts to backup my pictures and media, mostly WORM (http://git-annex.branchable.com/backends/) data, onto multiple harddisks. The 1 TB storage of Flickr is enticing, but I'm not ready to exclusively trust a part of my identity which I want to indefinitely preserve, to yet another third party.
>my email address is still owned by a third party (Google) and they can lock me out of my identity any time
They can lock you out of your past emails, but they can't take your identity away if you use Google Apps for custom domains or MSN Live Domains. You'll still have access to your email address which would probably be "[email protected]" or something. Actually, if you make it a habit to schedule a weekly outlook download of your emails I don't think they can even lock you out of your email. I've taken steps to do the first part but I'm being lazy and not downloading all my mails onto my computer yet. [Effort vs. Payoff doesn't seem worth it yet]
They can lock you out of your past emails, but they can't take your identity away if you use Google Apps for custom domains or MSN Live Domains. You'll still have access to your email address which would probably be "[email protected]" or something. Actually, if you make it a habit to schedule a weekly outlook download of your emails I don't think they can even lock you out of your email. I've taken steps to do the first part but I'm being lazy and not downloading all my mails onto my computer yet. [Effort vs. Payoff doesn't seem worth it yet]
Gmvault + cron makes the second part pretty easy: http://gmvault.org/
Holy sweet jesus batman! That is exactly what I want, and the Effort vs. Payoff has drastically reduced. I know what my computer's going to be doing for the next few nights.
Thank you!
Thank you!
>Same goes for power and manufacturing industries, they have old control systems that rarely break, because failures are very expensive.
Out of curiosity, how much experience do you have selling to the manufacturing industry? I have no problems drumming up interest for my sales and marketing SaaS product for manufacturing industry. If you found otherwise we should compare notes.
Out of curiosity, how much experience do you have selling to the manufacturing industry? I have no problems drumming up interest for my sales and marketing SaaS product for manufacturing industry. If you found otherwise we should compare notes.
I don't know about the power and manufacturing industries, but for insurance, I have seen firsthand a company lose a multimillion dollar contract because they pushed a SaaS offering, even though their solution was very good.
Would your position on vendor stability be mitigated if the SAAS was implemented as an appliance that can be imaged, which is placed under software escrow? If the vendor goes out of business, then you know that you will receive a discrete snapshot of what delivered the service (from the appliance, and the image can be dropped into a VM in your infrastructure), and you would receive all the code that the vendor created to implement the appliance.
You are no worse off than buying off the shelf software from closed-source companies, even large ones like Microsoft/IBM/Oracle that can be counted upon to be around in ten years. I see clients of mine get stranded by those companies all the time on just old versions of products that simply go out of support. In fact, if you get the appliance and the developed source code, you're in a better position because at least then you have the option to explore the feasibility of modifying the code to make it continue to work for your needs.
You are no worse off than buying off the shelf software from closed-source companies, even large ones like Microsoft/IBM/Oracle that can be counted upon to be around in ten years. I see clients of mine get stranded by those companies all the time on just old versions of products that simply go out of support. In fact, if you get the appliance and the developed source code, you're in a better position because at least then you have the option to explore the feasibility of modifying the code to make it continue to work for your needs.
The reason those companies are still running the old versions is because even if they're out of support, they're known quantities. Implementing new versions will require development and testing to put in to place along with the possibility of additional upgrades (OS, other apps/libraries, etc.). Unless you have resources to handle that aspect in addition to any of your actual business, you're going to want to stay on a version for as long as possible instead of being on the upgrade treadmill that Microsoft/IBM/Oracle try to place you on.
[deleted]
We get IP ownership, but we don’t bill for our time at all. Instead they become our first customer to use the new tool for a lower yearly fee (including maintenance).
You're taking on market and execution risk here, for which you are not receiving compensation. (Presumably you set your consulting rates high enough such that engagements are a win for you. The SaaSification option is at a discount to your rate, which you only make up if you sell it to other people. "Selling it to other people" is often much, much more difficult than writing working software.)
Any consultants in the room who happen to have an engagement which would create usable IP could consider the following alternative: "You pay our normal rates, and you pay for hosting/maintenance, and we own all the IP." This is actually very common, because most customers of software do not want to get into the software business and hence they don't give a fig nutton about commercial exploitation of this system they want to buy from you. No purchasing manager at the US federal government is going to nail his promotion to GSWhatever if he preserves the government's call option on starting a SaaS starttup.
You're taking on market and execution risk here, for which you are not receiving compensation. (Presumably you set your consulting rates high enough such that engagements are a win for you. The SaaSification option is at a discount to your rate, which you only make up if you sell it to other people. "Selling it to other people" is often much, much more difficult than writing working software.)
Any consultants in the room who happen to have an engagement which would create usable IP could consider the following alternative: "You pay our normal rates, and you pay for hosting/maintenance, and we own all the IP." This is actually very common, because most customers of software do not want to get into the software business and hence they don't give a fig nutton about commercial exploitation of this system they want to buy from you. No purchasing manager at the US federal government is going to nail his promotion to GSWhatever if he preserves the government's call option on starting a SaaS starttup.
This is a common scenario for me. My contract generally includes the following provision.
"Client shall have a perpetual, irrevocable, nontransferable license to use and copy the materials and deliverables created, discovered, invented, developed or prepared in the course of this agreement (“Deliverables”) and prepare derivative works based on the Deliverables for its internal use. All other rights in the Deliverables remain in and/or are assigned to Consultant."
"Client shall have a perpetual, irrevocable, nontransferable license to use and copy the materials and deliverables created, discovered, invented, developed or prepared in the course of this agreement (“Deliverables”) and prepare derivative works based on the Deliverables for its internal use. All other rights in the Deliverables remain in and/or are assigned to Consultant."
Thank you - going to get that UK-law-ified and stick it all over the place
Cheers !
Cheers !
While this certainly happens, there are companies that do not want their codified knowledge to leak to competitors. So they lock down the IP not because they want to sell it, but just in case code happens to contain trade secrets.
My terms of service account for that. You need to separate the business specific from the underlying technology in different deliverables and keep the IP for the underlying technologies yours.
I tend to reuse a lot of code from previous projects in new ones, so this is essential.
I tend to reuse a lot of code from previous projects in new ones, so this is essential.
That is true, but would cost orders of magnitude more to do that.
Agreed. I've worked at a company that owned the IP to a CRM-type system fully bought and paid for by a major car maker. The car maker paid my employer millions to develop the system over several years, and then willingly gave up the IP for it at the end of the process.
My employer was then able to go and sell other similar businesses on the same software. It's surprising, but common.
My employer was then able to go and sell other similar businesses on the same software. It's surprising, but common.
This is a common arrangement for consultants in the ERP sector. It's a nice way to start a software business. Your customers provide you with seed capital, user requirements and a reference site. I've seen a couple of people start multi-million dollar businesses with this approach.
It can work particularly well for public sector customers, because they generally are not worried about "trade secrets" or other IP being later sold to a competitor.
This seems especially difficult for a web-based model, and I've personally questioned why anyone would want SaaS when:
1. The company already pays for and supports infrastructure.
2. The company already has a development/IT department that can support an installed product.
3. Viable Open Source alternatives (often using open standards) exist and can be tailored specifically to the company's business needs, either by the in-house team or by eager contractors.
It seems to me that the majority of SaaS providers don't have a way to make their data interoperable with their competitors' products and don't have a way to tailor their product to the specific needs of the business. Worse, there is an impression that SaaS services will offer support better than having someone internal to the company learn an installed or custom tool, when the reality is that many SaaS companies throw up a Get Satisfaction page and call it a day.
To me, a better SaaS sales pitch would include a few key points:
1. Describe the way that the company's data can be taken elsewhere and how well it will work. ("If you decide to cancel, you can push this button and drop the downloaded data directly into X-competitor's product, but we hope to impress you enough with our offering that you never need to do that.")
2. Describe the concrete benefits of a recurring payment over a one-time or per-upgrade fee. ("We are constantly making improvements and refinements to the product based on real client use. Here is a list of the last two iterations of updates, which happened on our regularly scheduled update cycle of X weeks/months.")
3. Describe the specific support and technical infrastructure that the SaaS provides that the company would have trouble or lag time implementing themselves. ("We constantly adjust our infrastructure to your needs, implementing load balancing, reporting, localization, etc. Our techs are on-call via phone/VoIP for your support issues during our regular business hours if there are any issues.")
I'm not suggesting that SaaS isn't a viable business model. I merely posit that the real and valid objections purchasers may have to locking themselves into a perpetual SaaS contract have not been addressed within this post, and are quite common with SaaS products in general. Rephrasing how you present the contract may sell better, but it doesn't change what you're offering.
1. The company already pays for and supports infrastructure.
2. The company already has a development/IT department that can support an installed product.
3. Viable Open Source alternatives (often using open standards) exist and can be tailored specifically to the company's business needs, either by the in-house team or by eager contractors.
It seems to me that the majority of SaaS providers don't have a way to make their data interoperable with their competitors' products and don't have a way to tailor their product to the specific needs of the business. Worse, there is an impression that SaaS services will offer support better than having someone internal to the company learn an installed or custom tool, when the reality is that many SaaS companies throw up a Get Satisfaction page and call it a day.
To me, a better SaaS sales pitch would include a few key points:
1. Describe the way that the company's data can be taken elsewhere and how well it will work. ("If you decide to cancel, you can push this button and drop the downloaded data directly into X-competitor's product, but we hope to impress you enough with our offering that you never need to do that.")
2. Describe the concrete benefits of a recurring payment over a one-time or per-upgrade fee. ("We are constantly making improvements and refinements to the product based on real client use. Here is a list of the last two iterations of updates, which happened on our regularly scheduled update cycle of X weeks/months.")
3. Describe the specific support and technical infrastructure that the SaaS provides that the company would have trouble or lag time implementing themselves. ("We constantly adjust our infrastructure to your needs, implementing load balancing, reporting, localization, etc. Our techs are on-call via phone/VoIP for your support issues during our regular business hours if there are any issues.")
I'm not suggesting that SaaS isn't a viable business model. I merely posit that the real and valid objections purchasers may have to locking themselves into a perpetual SaaS contract have not been addressed within this post, and are quite common with SaaS products in general. Rephrasing how you present the contract may sell better, but it doesn't change what you're offering.
I used to work in a large company with internal IT that also used quite a few SaaS providers. To your point #1, yes the providers had to provide up front how they would get our data out if we wanted to switch. They didn't have to switch it, but provide the data in a typical format (CSV, tab delimited, etc...).
Why we used SaaS was a mix of we didn't want to find and internalize the knowledge of having to do it ourselves (think payroll complexities) and we liked the flexibility of easily scaling up and down the users.
What SaaS allowed us to do was focus our IT on items that added direct business value and not commodity items like payroll.
Why we used SaaS was a mix of we didn't want to find and internalize the knowledge of having to do it ourselves (think payroll complexities) and we liked the flexibility of easily scaling up and down the users.
What SaaS allowed us to do was focus our IT on items that added direct business value and not commodity items like payroll.
This is exactly what I was wondering. If your SaaS pitch fails because people are multiplying costs out as if they were fixed and are worried about existential risk/switching costs then either don't sell to them or sell up exactly (1-3).
I—for one—love this line when you can afford it: "we have n engineers full time on this project so you can't possibly have an internal product that grows as quickly".
Comparative advantage is an incredible force.
I—for one—love this line when you can afford it: "we have n engineers full time on this project so you can't possibly have an internal product that grows as quickly".
Comparative advantage is an incredible force.
> I've personally questioned why anyone would want SaaS when:
> 1. The company already pays for and supports infrastructure.
> 2. The company already has a development/IT department that can support an installed product.
Because adopting a SaaS offering instead means the company can greatly reduce the need for (or entirely get rid of) the infrastructure and staff which both cost exponentially more.
> 1. The company already pays for and supports infrastructure.
> 2. The company already has a development/IT department that can support an installed product.
Because adopting a SaaS offering instead means the company can greatly reduce the need for (or entirely get rid of) the infrastructure and staff which both cost exponentially more.
Be careful about making this argument - the people whose job you're trying to eliminate might be the people who are making the decision. A better argument, if it applies, is that you offering reduces non-core work, allowing staff and resources to be focused on core work. Any company that has IT staff will likely benefit from continuing to have that staff, just focused more on value-add activities rather than chores.
Sometimes the IT department has more important things to work on. If the company makes "widgets", then it's usually better for their IT department to be working on something to make their widget making more competitive (faster, cheaper, better, whatever). So they "outsource" payroll, other HR and whatever else doesn't directly benefit "widget" making.
[deleted]
[deleted]
[deleted]
There are many considerations. For example, buyer may capitalize the expense and amortize it sooner: on their schedule, not yours schedule of payments, and get it off tax base sooner. The budgets for R&D (your contracting rate) may be different than budget for software purchases. Depending ob legislation, they may get tax credits for R&D work (even though done by a contractor). They may have budget now, but are not sure about later, but still want software to work, no matter what
Something I'm not sure that you've thought of that might be one way to think about how some people assess part of the value:
Just as a hypothetical boundary case: Why should I pay you to do nothing forever? That's effectively the question that gets run in my head when I look at SAAS.
That sound quite insulting, so - just to point out again: Boundary case! I don't think you actually are doing nothing forever. However, if they're effectively employing you, and perhaps have a fairly static need. What do they need to employ you to do?
For a lot of new software it's meanest competitor is its last version. The version that comes out four years down the line is not that much better, generally speaking. People talk about companies upgrading, but a lot of them don't - at least not on the sort of time-table that would justify SAAS. In that sense you'd have to sell me on the future of the software or on the idea that my needs are going to change rapidly so I'll need software to change rapidly with them. If you're going to be making it significantly better year on year then I'd probably go with SAAS. If I'd pay for the software on a SAAS plan, before I'd upgrade normally though, then it seems like a bad deal.
It strikes me that in a relatively static environment the thing to talk up is going to be what you can do for them in terms of support. And they're going to have to compare the costs of supporting the software themselves to the risk that they take on in using your solution (your company going under, etc.) Much of which is very difficult to quantify and is made a greater concern by our tendency to be fairly risk-averse.
Just as a hypothetical boundary case: Why should I pay you to do nothing forever? That's effectively the question that gets run in my head when I look at SAAS.
That sound quite insulting, so - just to point out again: Boundary case! I don't think you actually are doing nothing forever. However, if they're effectively employing you, and perhaps have a fairly static need. What do they need to employ you to do?
For a lot of new software it's meanest competitor is its last version. The version that comes out four years down the line is not that much better, generally speaking. People talk about companies upgrading, but a lot of them don't - at least not on the sort of time-table that would justify SAAS. In that sense you'd have to sell me on the future of the software or on the idea that my needs are going to change rapidly so I'll need software to change rapidly with them. If you're going to be making it significantly better year on year then I'd probably go with SAAS. If I'd pay for the software on a SAAS plan, before I'd upgrade normally though, then it seems like a bad deal.
It strikes me that in a relatively static environment the thing to talk up is going to be what you can do for them in terms of support. And they're going to have to compare the costs of supporting the software themselves to the risk that they take on in using your solution (your company going under, etc.) Much of which is very difficult to quantify and is made a greater concern by our tendency to be fairly risk-averse.
We provide annual subscription for our software (http://www.infocaptor.com) but the price for subscription is significantly lower than if the customer decides to go the perpetual route with optional upgrade path. Some do ask for perpetual license and most of them are happy with the annual subscription as it behaves like an installment plan.
In either case, the customer hosts the software internally within their intranet/firewall.
So offering two price points perpetual and subscription will let the customer see the value and help them make better decision. You have to constantly make an effort to show value in your software at the pricing you offer.
In either case, the customer hosts the software internally within their intranet/firewall.
So offering two price points perpetual and subscription will let the customer see the value and help them make better decision. You have to constantly make an effort to show value in your software at the pricing you offer.
I don't see what that has to do with what I said.
Assessing it on its own merits however:
The software just is worth X to me - what I can do with it - and you're trying to guess the price, and perhaps more importantly the surrounding conditions on which I'll accept. What it's worth to me is the upper boundary, I ought never to pay more than that - what it's worth to you is the lower boundary, you ought never to accept less than that (probably what it cost you to get vs your leverage advantage - most likely scarcity) - and what's in between we can deal over. If you have two estimates, one really large and one really low, for what's essentially the same thing, that implies to me that you just don't know what a fair price for what your software does is.
If I know that you consider something to be absolutely cheaper then I also know that your bargaining position is likely dramatically wider than you might like to convince me it is. I know you can go much lower than you do.
As a strategy, having two prices wouldn't work on me. It's too fishy. Perpetual being bad doesn't make subscription good. It just means you value someone choosing sub and are prepared to offer them a substantial discount to get them to do it. Or to put it another way: Why are the permanent terms so much less advantageous to you that you're prepared to charge 'significantly [more]' for them before you agree? My instinct says there's a trick there - you wouldn't be trying to get me to go with the cheaper option so strongly unless there was some long-term advantage for you in doing so, data lock-in perhaps, or the knowledge that people don't, in practice, upgrade as much as you hope.
Why do you value someone choosing sub? If you're trying to get the best of a cost/risk balance in doing so, then it seems like your interests are inherently opposed to theirs.
Assessing it on its own merits however:
The software just is worth X to me - what I can do with it - and you're trying to guess the price, and perhaps more importantly the surrounding conditions on which I'll accept. What it's worth to me is the upper boundary, I ought never to pay more than that - what it's worth to you is the lower boundary, you ought never to accept less than that (probably what it cost you to get vs your leverage advantage - most likely scarcity) - and what's in between we can deal over. If you have two estimates, one really large and one really low, for what's essentially the same thing, that implies to me that you just don't know what a fair price for what your software does is.
If I know that you consider something to be absolutely cheaper then I also know that your bargaining position is likely dramatically wider than you might like to convince me it is. I know you can go much lower than you do.
As a strategy, having two prices wouldn't work on me. It's too fishy. Perpetual being bad doesn't make subscription good. It just means you value someone choosing sub and are prepared to offer them a substantial discount to get them to do it. Or to put it another way: Why are the permanent terms so much less advantageous to you that you're prepared to charge 'significantly [more]' for them before you agree? My instinct says there's a trick there - you wouldn't be trying to get me to go with the cheaper option so strongly unless there was some long-term advantage for you in doing so, data lock-in perhaps, or the knowledge that people don't, in practice, upgrade as much as you hope.
Why do you value someone choosing sub? If you're trying to get the best of a cost/risk balance in doing so, then it seems like your interests are inherently opposed to theirs.
Unless you have an excellent track record with a more compelling UX/workflow that works better than existing non-hosted competitors selling a SaaS subscription to a business and expecting them to feel their data is safe will be a hard sell.
One way to get an established track record to sell as a SaaS is to initially start out as a non-SaaS like Adobe did. Once users have confidence in using your product then transitioning to a SaaS model will be easier.
One way to get an established track record to sell as a SaaS is to initially start out as a non-SaaS like Adobe did. Once users have confidence in using your product then transitioning to a SaaS model will be easier.
> Suddenly your $20 per month product looks very expensive once it has been multiplied by 10, 50 or 100 years
Doesn't look expensive at all to me. These are values I imagine spending on toilet paper.
Doesn't look expensive at all to me. These are values I imagine spending on toilet paper.
$2k / 10 years
$10k / 50 years
$20k / 100 yearsI like the analogy but that is expensive toilet roll you have there.
I think part of the issue is data migration after the SaaS contract is cancelled. To pursue your analogy further, if you decided to go 'natural' and use leaves you would still be able to defecate...
I think part of the issue is data migration after the SaaS contract is cancelled. To pursue your analogy further, if you decided to go 'natural' and use leaves you would still be able to defecate...
Same manager is probably leasing their $50k car and will just get another when the lease is up.
People have a hard time putting value on what they cannot touch.
People have a hard time putting value on what they cannot touch.
Not sure I understand this sentiment. This same manager would likely be buying a 15k used car outright if he's worried about paying for software over time.
The problem that I have with SaaS is that most companies pursuing it's business model fail at the value option. Take Freshbooks for instance - I started using their service 3 years ago for 9$ per month. This got bumped to 14$ per month. I now have to pay 20$ per month for the same service I got 3 years ago (very little has been added of value to me). I could have bought a stand alone invoicing solution for $100 once and been far better off (I'm now trying to find a good one).
SaaS is often a really crummy deal for the customer and we all know it.
The problem that I have with SaaS is that most companies pursuing it's business model fail at the value option. Take Freshbooks for instance - I started using their service 3 years ago for 9$ per month. This got bumped to 14$ per month. I now have to pay 20$ per month for the same service I got 3 years ago (very little has been added of value to me). I could have bought a stand alone invoicing solution for $100 once and been far better off (I'm now trying to find a good one).
SaaS is often a really crummy deal for the customer and we all know it.
You're making the mistake of assuming everyone has the same problem as you do.
Pre-SaaS most companies would have paid upfront for a piece of software (before knowing if it works for them) and then upgraded ever few years in any case. For multi-user software they would have needed to pay for servers, ops staff, etc. on an on-going basis in any case.
When companies are evaluating a SaaS solution versus a boxed solution price is not typically a major deciding factor.
Pre-SaaS most companies would have paid upfront for a piece of software (before knowing if it works for them) and then upgraded ever few years in any case. For multi-user software they would have needed to pay for servers, ops staff, etc. on an on-going basis in any case.
When companies are evaluating a SaaS solution versus a boxed solution price is not typically a major deciding factor.
> SaaS is often a really crummy deal for the customer and we all know it.
Which is why no company will make very much money with the SaaS model...since we all know it is a crummy deal, we'd never support companies doing SaaS (or PaaS or IaaS). I remember a small startup Sales-something trying to do a CRM as SaaS a few years ago. I'm sure they are gone by now.
Which is why no company will make very much money with the SaaS model...since we all know it is a crummy deal, we'd never support companies doing SaaS (or PaaS or IaaS). I remember a small startup Sales-something trying to do a CRM as SaaS a few years ago. I'm sure they are gone by now.
What about the new SaaS that 37signals' Basecamp Breeze is trying to put forward? Pay one fee of X$ and have access to it forever. I guess this applies more to single purpose laser focused services that are not expected to change in the foreseeable future.
"Forever" meaning "as long as 37signals exists" ?
Actually only as long as they are interested in selling the service. There's nothing to stop from discontinuing it at any time in the future.
well...depends on how much growth your org has seen in 3 years. If your people are still using Windows XP with IE 7...sure what you say makes sense. But if your org has seen major growth, lots of new employees requiring all kinds of new platforms and form factors then its a slightly different story.
My org is just me. My revenue has remained fairly flat over that period. But the cost to access my data has risen rather steeply over that period. Had I purchased a stand alone application to start with, I would have saved 50% of the cost.
I'm not talking about large installs for big organizations - I was speaking directly to the value options for small organizations. Most SaaS are designed to funnel end customers into higher profit services for no real reason other then higher profit. Value wise it's not a good deal for the customer.
I'm not talking about large installs for big organizations - I was speaking directly to the value options for small organizations. Most SaaS are designed to funnel end customers into higher profit services for no real reason other then higher profit. Value wise it's not a good deal for the customer.
Not always true is all I'm saying. From a business perspective, it makes sense to target higher margin customers .
Would you rather pay a percentage of the payment you receive or a monthly fee like Freshbooks charges?
Leasing a car is not a good analogy because the difficulty and cost to switch cars at the end of the lease is zero (or at least well defined). Leasing a car is a fixed duration, fixed amount payment with both the costs and the duration fixed by contract. Leasing is attractive to people and organizations that want the benefit of lower monthly/yearly payments in exchange for a higher total cost of "ownership."
SaaS is not a fixed amount nor a fixed duration. This is custom software with no alternatives, so escaping the "lease" is going to be more costly than purchasing up front.
If I were the manager in the story, I would see the choice as
1) Pay $5,000 per year for 10 years (with substantial cost risk due to the lock-in with the sourcing company) and then have to pay $100,000-200,000 to replace the software or
2) Pay $50,000-100,000 up front without the lock-in of the sourcing company.
Since the OP says "power systems engineering" in a "government type organization", it is not surprising that the organization is not terribly price sensitive ($50,000-$100,000 is peanuts to the power industry) and the SaaS is only offering a lower yearly payment in exchange for a substantial amount of risk and a substantially higher total cost.
He's pitching the wrong angle for this company / industry.
SaaS is not a fixed amount nor a fixed duration. This is custom software with no alternatives, so escaping the "lease" is going to be more costly than purchasing up front.
If I were the manager in the story, I would see the choice as
1) Pay $5,000 per year for 10 years (with substantial cost risk due to the lock-in with the sourcing company) and then have to pay $100,000-200,000 to replace the software or
2) Pay $50,000-100,000 up front without the lock-in of the sourcing company.
Since the OP says "power systems engineering" in a "government type organization", it is not surprising that the organization is not terribly price sensitive ($50,000-$100,000 is peanuts to the power industry) and the SaaS is only offering a lower yearly payment in exchange for a substantial amount of risk and a substantially higher total cost.
He's pitching the wrong angle for this company / industry.
1) is an expense and is usually easier to deal with, even put in an expense report
2) is a write off ad usually need multi-level approval. There is still lock-in as switching provider usually end up in a time consuming operation.
But I agree that the saas pitch for this type of industry might not have been the right choice.
2) is a write off ad usually need multi-level approval. There is still lock-in as switching provider usually end up in a time consuming operation.
But I agree that the saas pitch for this type of industry might not have been the right choice.
Cars degraded over time, software does not. Get in a 10 year old car and it isnt as good as it was 10 years ago. Its loose and worn. Fire up 10 year old software and its as good as the day you bought it. Yeas the market would have changed around both, but if I have both a car and a piece of software in my hand, as it were, I can see the difference. There for leasing something the clearly degrades makes sense. Leasing something that does not degrade, does not.
Software does indeed degrade over time - platform support (gee, do your Windows 3.1 apps run?), security flaws, etc.
It's true for software that's completely standalone, a virtual island. But very little useful software qualifies. Most software interacts with other components, whether hardware, operating systems, external formats, etc., and when those change over time, the software effectively becomes worse, even though it's technically the same as it was before.
Well there a lot of tax advantages to leasing compared to buying out right
Sure, but there can also be tax advantages to buying outright. Germaine to the discussion of SaaS is the fact that, in the case of packaged software, I can either elect to deduct 100% of the purchase price immediately (up to a certain annual dollar limit) or depreciate it over three years. All other things being equal, a $3,000 deduction this year beats a $1,000/year deduction for the next three years.
Well in a lot of places you can discount interest payment against profits - which is why those ghastly debt back buyouts that make money for the banks sort term but saddle a company with unmanageable debt are so popular.
There is a serious disconnect here. Listen to the howls if someone suggests you should rent your media but have no problem telling you to rent your software.
Hmm ... you cannot compare media and software. Very little of the media produced is worth experiencing second time. So rental is natural there.
Software is meant to be used continuously forever and ever. I have some exchanges that I programmed that are 15 years old now - still working peacefully ( the benefit of using PICs - they last forever). The company is no longer in business but with a soldering gun they manage to keep them operational.
So the real question is not only why should I pay you, but what happens when your company goes the way of a cockroach treated with raid. And don't tell me you are market leader - we see them raise and fall 5 times in a decade.
Software is meant to be used continuously forever and ever. I have some exchanges that I programmed that are 15 years old now - still working peacefully ( the benefit of using PICs - they last forever). The company is no longer in business but with a soldering gun they manage to keep them operational.
So the real question is not only why should I pay you, but what happens when your company goes the way of a cockroach treated with raid. And don't tell me you are market leader - we see them raise and fall 5 times in a decade.
Do you not have favorite songs and movies? Also your post may sound like a rebuttal but it only reinforces my point. I want to own my software not have it hold me hostage later, but it may be more profitable to you to rent it to me with the added bonus that you can claim anything digital deserves no copyright.
Except for music, I personally prefer to rent media. There are very few movies I will watch more than once. Of course, music is a huge exception.
Another aspect is the utterly strange way internal accounting is done at large companies. When you have lots of department heads trying to optimize for their departments local optima without incentive to consider the companies global optima, you often get seemingly irrational behavior.
Sometimes it simply makes sense for a department to spend a whole lot of money right now as opposed to a little each month, since when money is spent affects which budget it ends up on, which in turn affects things like bonuses and raises.
Sometimes it simply makes sense for a department to spend a whole lot of money right now as opposed to a little each month, since when money is spent affects which budget it ends up on, which in turn affects things like bonuses and raises.
Most software projects are capital expenditure ("capex"). Often the capex budget is set annually, and the investments are depreciated over subsequent years. Recurring monthly fees seem more like an expense than a capital investment. Hence, SaaS may not work with the budget allocated.
It's not just the total price, and it's not just the risk that you may disappear, it's also that the client will likely get a different product under the two pricing structures. In the flat-fee case, objectives are defined solely by the needs of the client; in the SaaS model, they're split between what the client needs and what you want for your future product. The split incentives can go bad for the client in all kinds of ways:
- they get a product that is kind of what they wanted but not really, because you built it to cover what you see as the general use case (i.e., the one that you might be able to sell widely), while they wanted you to cover their specific needs.
- alternately, they insist that it cover their specific needs (they started this process after all), and you end up fighting with them over design and over who should cover the costs of customization.
- maybe you were lucky and there weren't any of these conflicts with the first round of development, but now they want a second round that will take the product in a direction that isn't consistent with your plans for it. What then? Do you go to a hybrid pricing model, where the monthly fee covers the "base" product and they have to pay a one-time fee for their extensions? Do you tell them to take a hike and start all over again with a new dev, because you're not interested in their unmarketable extensions?
As others have said, we charge on T&M and make sure first and foremost that our client is happy. AND we retain a right to the code. If we think there might be a broader use for the tool, then AFTER we've made the client happy, we'll branch and adapt it to our sense of what is marketable.
- they get a product that is kind of what they wanted but not really, because you built it to cover what you see as the general use case (i.e., the one that you might be able to sell widely), while they wanted you to cover their specific needs.
- alternately, they insist that it cover their specific needs (they started this process after all), and you end up fighting with them over design and over who should cover the costs of customization.
- maybe you were lucky and there weren't any of these conflicts with the first round of development, but now they want a second round that will take the product in a direction that isn't consistent with your plans for it. What then? Do you go to a hybrid pricing model, where the monthly fee covers the "base" product and they have to pay a one-time fee for their extensions? Do you tell them to take a hike and start all over again with a new dev, because you're not interested in their unmarketable extensions?
As others have said, we charge on T&M and make sure first and foremost that our client is happy. AND we retain a right to the code. If we think there might be a broader use for the tool, then AFTER we've made the client happy, we'll branch and adapt it to our sense of what is marketable.
This is relevant to my interests. As I develop my own enterprise SaaS product, my first-pass solution was to develop first as SaaS (to reduce my time to market), and later make an "enterprise" version that they could install themselves, on their own hardware, using a more traditional pricing model. I was dreading this because it sounds like a lot of work and support, but then my target market is businesses that have pretty severely broken internal processes, so they're probably backwards about pricing as well.
I brought this up with a friend who works in enterprise sales and he cautioned me against it. His company did the same thing - for a while. They found it so problematic to support the "enterprise" version that it wasn't worth it, and now they're a pure SaaS play. They find it easier to solve the problem on the sales side (convince customers to go SaaS, and skip the ones that won't), than to "give the customer what they want".
I suppose this is a case of choosing your customers.
I brought this up with a friend who works in enterprise sales and he cautioned me against it. His company did the same thing - for a while. They found it so problematic to support the "enterprise" version that it wasn't worth it, and now they're a pure SaaS play. They find it easier to solve the problem on the sales side (convince customers to go SaaS, and skip the ones that won't), than to "give the customer what they want".
I suppose this is a case of choosing your customers.
Obviously, not all SaaS is created equally and a recurring fee isn't always the best idea. Especially for SaaS or PaaS offerings that people aren't used to paying for in the first place or are trying to disrupt services that are free.
Recurring monthly charges by no means need to be the default and customers should be wary. What if they don't like it? Is there a cancellation fee? How is the time billed - is it hourly or monthly? How much does it cost to upgrade to a better tier of service (if one exists)? If they work in a company, will they need to get monthly approval to continue the service, or (speaking from experience here) will they be bugged by their forgetful accountant every month for the charge on the company account? Probably most of all, what happens when I don't pay (mentioned in the article) - does my service suspend, is it limited, am I forwarded to a collections agency?
"Buy-to-own" or "Buy-to-access" is a much simpler model - far fewer questions need to occur on the path to payment. There's less value that needs to be determined to justify the expense, even if the initial expense is higher. Some of the same questions above still apply, like, "what if they don't like it?" - but the answers tend to be simpler ("You get a full refund" vs. "You're S.O.L. and still owe us for 72 hours of processing time", etc.).
Recurring monthly charges by no means need to be the default and customers should be wary. What if they don't like it? Is there a cancellation fee? How is the time billed - is it hourly or monthly? How much does it cost to upgrade to a better tier of service (if one exists)? If they work in a company, will they need to get monthly approval to continue the service, or (speaking from experience here) will they be bugged by their forgetful accountant every month for the charge on the company account? Probably most of all, what happens when I don't pay (mentioned in the article) - does my service suspend, is it limited, am I forwarded to a collections agency?
"Buy-to-own" or "Buy-to-access" is a much simpler model - far fewer questions need to occur on the path to payment. There's less value that needs to be determined to justify the expense, even if the initial expense is higher. Some of the same questions above still apply, like, "what if they don't like it?" - but the answers tend to be simpler ("You get a full refund" vs. "You're S.O.L. and still owe us for 72 hours of processing time", etc.).
Reading many of the comments below it's clear to me that most commentators have never worked in the enterprise.
Anyone who has purchased enterprise software knows full well that you never pay "once". Far from it.
- For most organizations, using software without a support & maintenance contract is not a viable option, and yearly support & maintenance cost is typically ~20% of the product "list" price of the product. Many customers of large enterprise vendors typically see these costs go up every year. There has been revolts over this but often customer does not have much leverage.
- Unlike SaaS, companies who buy software products, have to pay for implementation and ongoing operations of the software as well. Enterprise products can be quite complex and require one or more people to operate it. Implementation costs alone can be hefty (often higher than software cost itself) and make SaaS a much much better option for the customer.
- Enterprise is littered with products that purchased but never used or no longer used. What looks like a good solution does not work, or requirements change, etc. In short, unlike SaaS where customer has almost no risk, customers take a lot of risk by buying software products outright.
- For most organizations, using software without a support & maintenance contract is not a viable option, and yearly support & maintenance cost is typically ~20% of the product "list" price of the product. Many customers of large enterprise vendors typically see these costs go up every year. There has been revolts over this but often customer does not have much leverage.
- Unlike SaaS, companies who buy software products, have to pay for implementation and ongoing operations of the software as well. Enterprise products can be quite complex and require one or more people to operate it. Implementation costs alone can be hefty (often higher than software cost itself) and make SaaS a much much better option for the customer.
- Enterprise is littered with products that purchased but never used or no longer used. What looks like a good solution does not work, or requirements change, etc. In short, unlike SaaS where customer has almost no risk, customers take a lot of risk by buying software products outright.
It's not just straight up costs, there are a number of other risks associated: http://www.followsteph.com/2012/04/19/what-are-the-risks-of-...
Some include: what if the business of the SaaS collapses? Will they be acquired, change business models, and so on. Does the price stay the same? Is the quality going to be consistent? And so on...
Some include: what if the business of the SaaS collapses? Will they be acquired, change business models, and so on. Does the price stay the same? Is the quality going to be consistent? And so on...
In the example situation the choice wasn't quite so clear, as IP was on the line too.
Regardless:
A customer wants to pay an exorbitant fee up front, and you're fretting? Why? Take their money.
Regardless:
A customer wants to pay an exorbitant fee up front, and you're fretting? Why? Take their money.
A customer wants to pay an exorbitant fee up front, and you're fretting? Why? Take their money.
I agree. If you're bummed about the result, then I suspect that you priced at least one of the options incorrectly.
First pricing rule: price so that no matter what your customer selects, even if it's to not do business with you, you're indifferent.
I agree. If you're bummed about the result, then I suspect that you priced at least one of the options incorrectly.
First pricing rule: price so that no matter what your customer selects, even if it's to not do business with you, you're indifferent.
It boils down to TCO (Total cost of ownership). Paying a one-time cost of X doesn't equate to X being TCO for that product/service.
In a functional business environment, any business related software you buy, will need at least three things: hardware, other software (e.g. operating systems, databases, etc) and support engineer(s). All these have recurring costs; ranging from monthly (engineers) to a few years (hardware). To know how must a software truly costs, you'll have to work out all these costs first.
Put another way, SaaS demystifies the whole TCO to a single recurring figure which you can compare to value/benefit you derive from the software.
Two other considerations for SaaS which the OP didn't discuss: i) Wise investment. Is it wise for a startup/SME to invest $XXXXXX upfront in purchasing a software while they could pay $X (a fraction of the XXXXX) for a few months/years while studying the business and pivoting if necessary.
ii) Core business. If the software is not actual core to the startup/SME line of business i.e. it is just support system, shouldn't the startup/SME let someone else make sure that it works and just use it when needed (pay for when it's needed)?
In a functional business environment, any business related software you buy, will need at least three things: hardware, other software (e.g. operating systems, databases, etc) and support engineer(s). All these have recurring costs; ranging from monthly (engineers) to a few years (hardware). To know how must a software truly costs, you'll have to work out all these costs first.
Put another way, SaaS demystifies the whole TCO to a single recurring figure which you can compare to value/benefit you derive from the software.
Two other considerations for SaaS which the OP didn't discuss: i) Wise investment. Is it wise for a startup/SME to invest $XXXXXX upfront in purchasing a software while they could pay $X (a fraction of the XXXXX) for a few months/years while studying the business and pivoting if necessary.
ii) Core business. If the software is not actual core to the startup/SME line of business i.e. it is just support system, shouldn't the startup/SME let someone else make sure that it works and just use it when needed (pay for when it's needed)?
Next time you are asked Why should I pay for your SaaS every month. Consider what they are thinking, how they’ve multiplied your monthly cost to arrive at the total cost. And what they are comparing your offering against.
You may just find the pitch that works for both you and your customers.
Better yet, make sure that before you try pitching a SaaS model that you're actually planning to deliver $20/month in value to the customer.
You may just find the pitch that works for both you and your customers.
Better yet, make sure that before you try pitching a SaaS model that you're actually planning to deliver $20/month in value to the customer.
Recurring pricing is more acceptable when:
* Larger amounts can be made monthly instead of annual with similarly short contract length. E.g. $39.95/mo not only seems less than $479.40/yr, but if they are unsure about dropping $479.40 on an unproven service, then being able to drop out after 1 month with a loss of only $39.95 is important.
* The value of the maintenance/support provided is something of obvious value to the customer and perceived to be commensurate to the recurring charge. E.g. if you are just hosting a free open-source platform that they could host themselves, choose from many others to host, some of which might be free, then even if you as the vendor are paying for the domain, bandwidth, storage, etc., all of that which has real cost to you may not be perceived to be as much value to the customer. But, if you wrote the product, it is awesome and multifaceted, no one else does anything like it, and the customer perceives your expertise in the product to be something necessary to their future success, then they may be happier making larger recurring payments.
* Larger amounts can be made monthly instead of annual with similarly short contract length. E.g. $39.95/mo not only seems less than $479.40/yr, but if they are unsure about dropping $479.40 on an unproven service, then being able to drop out after 1 month with a loss of only $39.95 is important.
* The value of the maintenance/support provided is something of obvious value to the customer and perceived to be commensurate to the recurring charge. E.g. if you are just hosting a free open-source platform that they could host themselves, choose from many others to host, some of which might be free, then even if you as the vendor are paying for the domain, bandwidth, storage, etc., all of that which has real cost to you may not be perceived to be as much value to the customer. But, if you wrote the product, it is awesome and multifaceted, no one else does anything like it, and the customer perceives your expertise in the product to be something necessary to their future success, then they may be happier making larger recurring payments.
i think the pitch here could be made more enticing. With SaaS you are not only paying for the current product but also for the implied updates and improvements that will follow. So a comparable model would be how much would a box software cost and what would its upgrades cost (as well as how often are they upgraded).
If the saas cost is being imagined for n years than they should also take into account the inevitable upgrades they would have to pay for with boxed software to keep the software productive.
for example we could take adobe creative suite and its upgrades together for a comparable saas offer.
If the saas cost is being imagined for n years than they should also take into account the inevitable upgrades they would have to pay for with boxed software to keep the software productive.
for example we could take adobe creative suite and its upgrades together for a comparable saas offer.
The answer is "Yes, and the flip side of that is that I have to continue maintaining, supporting, and upgrading the application as long as you are paying for it, too."
Why not do both? All depends on how large the market is for each of those options. We offer our product (online appointment scheduling) both as Software to be downloaded and as SaaS. Two in three people prefer to download and install the Software but there are enough who have no problems paying a monthly fee that saves them the hassle of installing and maintaining the Software.
Here's an easy fix... charge them a yearly or longer fixed duration license fee. Like say 1, 3, or 5 years. Make it expensive enough that monthly pricing makes some sense.
Also, charge for support separately on a deal like this as you are unable to calculate their support needs on a longer time horizon.
Also, charge for support separately on a deal like this as you are unable to calculate their support needs on a longer time horizon.
A supplier who wants to switch from pay-once to pay-monthly is either going to be charging me less or charging me more.
If they claim they'll be charging me less, that leaves me confused as to why they think the change is in their interests, unless they actually anticipate charging me more.
If they claim they'll be charging me less, that leaves me confused as to why they think the change is in their interests, unless they actually anticipate charging me more.
"<Anyone> who wants to switch from <anything to anything> is either going to be charging me less or charging me more."
This is just an argument against change.
This is just an argument against change.
No, this is the reasoning behind thinking someone is full of shit if they're pushing you to do something, supposedly for your sake.
Or charging you less but reducing their costs (eg support, testing, whatever) by more than the difference
You can offer:
A. Limited to say 5 years. The world will have changed by then.
B. $200k License Fee with 20% Annual Maintenance. Then in a burst of generosity you can waive the License Fee but keep to the Annual Mtce. This is pretty standard, sounds a bit sneaky but focusses customer attention on value.
A. Limited to say 5 years. The world will have changed by then.
B. $200k License Fee with 20% Annual Maintenance. Then in a burst of generosity you can waive the License Fee but keep to the Annual Mtce. This is pretty standard, sounds a bit sneaky but focusses customer attention on value.
Have you actually done B? It does sound sneaky, as you said, so makes me worried.
The first and only thing you need to consider is who you're selling to (power systems engineering businesses, as you said) and what they do.
They make power systems that need to be reliable and last for fifty years or more.
You probably know banks use 30 year old COBOL software to make the world tick. Why? Because it's reliable and rarely breaks. When it breaks, they have people there to fix it. Same goes for power and manufacturing industries, they have old control systems that rarely break, because failures are very expensive.
So now you come along trying to sell them software as a service. Can you GUARANTEE that your service will be available for the next ten years? Of course you can't, you can almost guarantee that is WON'T.
So now maybe you understand why they want to BUY the product and maintain ownership of it; because that means they can manage the risk, they don't have to trust you.
And this is why I never, ever buy SaaS, because I don't trust that whoever is providing me that service is going to be there next year, or even next month (the only exception is recreation, because if Netflix shuts down tomorrow, I don't lose any value). That's why I don't use an online album to store all my photos, why I don't use SkyDrive to store all my personal documents, because I can't TRUST them.
tl;dr: SAAS == No trust (in my opinion). Either you don't trust your client (like Adobe are doing with Creative Suite) and the client can't trust you, because despite your best intentions you just can't guarantee that you'll stay in business for the next fifty years.