Our Recurring Payment Pricing Was Rejected

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.

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.

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.

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.

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.

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 years

People have a hard time putting value on what they cannot touch.

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.

- 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.

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.

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.).

- 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.

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...

Regardless:

A customer wants to pay an exorbitant fee up front, and you're fretting? Why? Take their money.

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)?

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.

* 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.

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.

Also, charge for support separately on a deal like this as you are unable to calculate their support needs on a longer time horizon.

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.

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.