
Our Recurring Payment Pricing Was Rejected - jdwhit2
http://jerviswhitley.com/why-should-i-pay-for-your-saas/
======
valdiorn
I'd like to offer my opinion as someone who LOATHES the SaaS model.

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.

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

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

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

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

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

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

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

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

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

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

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

~~~
6d0debc071
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.

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

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

    
    
        $2k  / 10 years
        $10k / 50 years
        $20k / 100 years

~~~
keithpeter
I 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...

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

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

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

~~~
ams6110
"Forever" meaning "as long as 37signals exists" ?

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

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

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

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

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

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

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

------
FollowSteph3
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-...](http://www.followsteph.com/2012/04/19/what-are-the-risks-of-cloud-
services/)

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

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

~~~
jasonwocky
_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.

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

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

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

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

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

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

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

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

~~~
StavrosK
"<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.

~~~
wnight
No, this is the reasoning behind thinking someone is full of shit if they're
pushing you to do something, supposedly for _your_ sake.

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

~~~
DenisM
Have you actually done B? It does sound sneaky, as you said, so makes me
worried.

