I'd like to offer my opinion as someone who LOATHES the SaaS model.<p>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.<p>They make power systems that need to be reliable and last for fifty years or more.<p>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.<p>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.<p>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.<p>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.<p>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.
<i>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).</i><p>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.)<p>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, <i>and</i> 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 seems especially difficult for a web-based model, and I've personally questioned why anyone would want SaaS when:<p>1. The company already pays for and supports infrastructure.<p>2. The company already has a development/IT department that can support an installed product.<p>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.<p>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.<p>To me, a better SaaS sales pitch would include a few key points:<p>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.")<p>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.")<p>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.")<p>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.
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:<p>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.<p>That sound quite insulting, so - just to point out again: Boundary case! I don't think you actually <i>are</i> 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?<p>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.<p>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.
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.<p>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<p>Doesn't look expensive at all to me. These are values I imagine spending on toilet paper.<p><pre><code> $2k / 10 years
$10k / 50 years
$20k / 100 years</code></pre>
Same manager is probably leasing their $50k car and will just get another when the lease is up.<p>People have a hard time putting value on what they cannot touch.
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.<p>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.
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:<p>- 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.<p>- 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.<p>- 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?<p>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.<p>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".<p>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.<p>Recurring monthly charges by no means need to be the default and customers <i>should</i> 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?<p>"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.<p>- 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.<p>- 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.<p>- 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: <a href="http://www.followsteph.com/2012/04/19/what-are-the-risks-of-cloud-services/" rel="nofollow">http://www.followsteph.com/2012/04/19/what-are-the-risks-of-...</a><p>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.<p>Regardless:<p>A customer wants to pay an exorbitant fee up front, and you're fretting? Why? Take their money.
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.<p>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.<p>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.<p>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.<p>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)?
<i>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.<p>You may just find the pitch that works for both you and your customers.</i><p>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:<p>* 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.<p>* 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).<p>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.<p>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.<p>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.<p>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.
You can offer:<p>A. Limited to say 5 years. The world will have changed by then.<p>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.