SaaS – There’s No Such Thing as a Free Trial

Mar 2, 2011 by

As the popular adage goes: “There’s no such thing as a free lunch.” In SaaS – there’s no such thing as a free trial – there just isn’t.

As a SaaS provider, you pay for it one way or another, it’s a known, sunk cost of doing business and a part of your Customer Acquisition Cost (CAC). However, how large a part of your CAC it is depends on a variety of architectural and operational factors, as well as your maturity level in both areas.

Operationally

At a high level, a free trial process will typically look something like the following:

Now, let’s briefly break-down typical approaches in each of the three high-level operational phases:

Processing Trial Request

Manual – A prospect places a request with a sales rep or submits a request form via a SaaS provider’s website, which is then emailed to someone to process and pass along for provisioning.

Automated – A prospect submits a request form via a website, which is then automatically validated and the prospect receives some form of confirmation of their access (either the actual access, or a follow up email shortly thereafter).

Provisioning Trial Account

Manual – After the request is processed, someone (or worse yet, multiple people) are responsible for provisioning the trial account access. This can range from as manual as people coordinating with one another to setup a new machine or image, to someone clicking a few buttons to provision the account, and everything in between.

Automated – After the request is processed, the account is provisioned automatically, without any intervention. This could mean automatically spinning up a new VM image, creating their username, password, new DB and account, or simply granting them a subscription with proper entitlements to the application (same single DB as production customers … same everything).

Now, I know there will be people that say, “My application is far too complex to provide automated provisioning.” For a great breakdown of why automated provisioning will work in almost all scenarios, check out this post from Sinclair.

Transitioning Free Trial to Paid Account (with data if necessary)

Manual – The trial period is up and the customer wants to move to a paid account. They somehow communicate that to their SaaS provider, and in the worst-case-scenario they need to provision a brand new account, via one of the manual provisioning approaches listed above. Then, if the customer would like to keep their existing account data, customizations they’ve made, etc., their provider will need to migrate those to the newly provisioned account, as well.

Automated – The trial period is up, and best-case, the customer has been reminded a few times in advance of the trial period coming to a close (either via email, or somewhere in the product itself). They’ve decided they want to move to a paid account, so they simply choose the paid plan of their choice from a screen, input and submit their payment information, and they’re back in and using the product – same account, same data, same everything.

Of course, the entire process is much more costly if the end result is a negative outcome – where the user wants to shut their trial down, and isn’t interested in purchasing!

Architecturally

Depending on what level of resource allocation you have for each free trial account, this will, of course, factor into the cost of providing free trials to your users as well.

Physical Machine and Stack Per-Trial Customer – This extreme option entails setting up a physical box with a full application stack, associated licenses, etc., per trial account. This is the courses grained resource allocation.

Virtual Machine and Stack Per-Trial Customer – This entails spinning up a virtual machine image with a full application stack, associated licenses, etc., per trial account. In this option, there is hardware resource sharing, but each trial account requires its own virtual machine, and licensing costs.

Separate Database Per-Trial Customer – Here, there is hardware resource sharing, sharing of the application instance itself, but each trial account requires its own separate database.

Subscription to Single Instance, Co-mingled Data Application – Here, there is fine grained resource sharing, with each individual trial account having little to no incremental resource cost.

Once again, if the outcome of your free trial is not a customer win, having to manually reclaim physical hardware resources (in the most extreme case), each time a free trial ends is that much more costly.

Free trials are a great way to get the product you so lovingly promote in the hands of your potential customers and, if done right, gives them an experience that they can’t live without when the trial is about to end. Making this process as frictionless for you and your prospective customers, and cost effective as possible is a must. It won’t be “free,” but it CAN be pretty close.

I’d love to hear what others have done, and how they’ve managed to implement free trials successfully.

Jesse is responsible for the creation and execution of Apprenda’s strategic marketing initiatives, generating demand and awareness, and evolving the company’s brand. Jesse draws from a strong background in Software as a Service, having served as Community Evangelist and Product Manager at SaaS ISV Autotask before joining Apprenda. Prior to Autotask, Jesse served as Director of Marketing at Eden Communications (acquired by Unicom Systems). Jesse holds a Bachelor’s Degree in Information Technology, with a focus in Neuroscience from Rensselaer Polytechnic Institute.
read more

Great Interview on the Benefits of Multi-tenancy

Feb 5, 2010 by

This is a very good podcast of Phil Wainewright from The Connected Web interviewing Rick Nucci, CTO of SaaS integration vendor Boomi on the impact of multi-tenant architecture on the operational cost of delivering software in a SaaS fashion.

Two choice excerpts:

SuccessFactors recently gave a speech, [by CEO] Lars [Dalgaard], talking about their architecture and their approach. They have something like over a thousand customers per physical server when you net it all out and aggregate it. Andthat‘s the marginal utility, that’s the scale that you need to get to — because you need that op-ex in your business as a SaaS ISV to be in the five percent type of range. And it’s not going to happen if you’re doing a per-customer expenditure.”

“And that‘s the marginal utility, that’s the scale that you need to get to — because you need that op-ex in your business as a SaaS ISV to be in the five percent type of range. And it’s not going to happen if you’re doing a per-customer expenditure.”

Continue reading the transcript or listen to the podcast here.

read more

A retrospective from someone familiar with the SaaS ISV trenches

Mar 24, 2008 by

This post simply serves to provide a link to a post on another site, but I felt it very appropriate to shine the spotlight on a brilliant post by Ben Yoskovitz on Instigatorblog.com entitled ‘Lessons Learned Running A SaaS Business‘. While we tend to focus on the relative “newness” of SaaS, it’s always important to remember that there are people who have been approaching, solving, re-approaching, and re-solving the challenges associated with SaaS for some time now. Ben outlines some key points from a “looking back” perspective. Give it a good read, there are tons of gems throughout – especially for those building go-to-market strategies for SaaS products.

read more

Impending DST Disruption Highlights the Benefits of One-to-Many Software Delivery

Mar 6, 2007 by

Here’s another spotlight article from Phil Wainewright on ZDNet – DST spells disaster for shrinkwrap software.

The article zeroes in on the impending daylight savings time change (it’s this weekend in case you didn’t know – a date earlier than any prior year), and the havoc that it has wreaked on on-premise, aka ‘shrinkwrap’, software end users who must now navigate through patches and updates to accomodate the change.

The DST implications definitely illustrate an end user benefit derived from the SaaS delivery model.  Software built to support one-to-many delivery requires major patches or upgrades – planned or unexpected – be made only to the one running instance of the application core.  We often highlight the key economical benefits of SaaS for the vendors and end users alike – but it’s incidents like this that make us take a closer look at how SaaS might smooth out technological operations when they might otherwise become a disruptive nuisance.

What are some of the other, perhaps lesser known, ancillary benefits that SaaS end users have experienced since making the move from on-premise to hosted enterprise software? What other headaches have you avoided by using SaaS apps? We’d love to know your thoughts!

read more

Does the SaaS Ecosystem Concept Lean Toward Natural Oligopoly?

Mar 2, 2007 by

Rare is the day where using the phrase “SaaS Platform” doesn’t invoke the usage of “SaaS Ecosystem.” Heck, it even found its way to the title of the keynote panel I’m part of at April’s SaaSCon: Understanding SaaS Platforms and Ecosystems. The reason for this “two peas in a pod” syndrome is pretty easy to explain: SaaS platforms aggregate vendors, offerings, and end users in a pseudo-closed system which creates a huge amount of long-term value potential in exercising this network of relationships. This network is what we call an ecosystem and the value that can be created by commanding successful relationships is important to all parties involved.

I was discussing the future ecosystem landscape with someone, and inevitably the question of “How many ecosystems do you think will exist in a few years?” came up. Trying to quantify something like that this early definitely requires painting with broad strokes, but looking at the dynamics my answer is that a handful of ecosystems – a veritable oligopoly – will account for almost all ecosystem participants. In this scenario the oligopoly would not be forced or created through regulation, but would in fact be a natural oligopoly – the result of convergence due to economic factors. Why? Because ecosystems are networks.

A SaaS ecosystem’s value is very much defined by the size of its network, which is composed of three types of members: vendors, applications, and users. Looking at the trivial case, an ecosystem with zero participants of any type is valueless, as is the case of an ecosystem consisting only of suppliers and supply. As a mix of members from the three aforementioned groups start to enter a specific ecosystem, the value of the ecosystem increases. End users have the ability to gain value from relationships defined by participating vendors or deployed applications, vendors themselves can experience synergies by creating relationships with other vendors in the ecosystem. What this does is create a positive feedback loop.

If there are no costly or threatening barriers to joining an ecosystem, non-participants will measure the value of the ecosystem by the number of links it offers – the larger the network, the more valuable (i.e. Metcalfe’s Law). This is the reason why instant messaging, for example, is a natural oligopoly. If you had to choose a messaging service, what would you choose GTalk or AOL Instant Messenger? If you chose GTalk, you probably won’t be chatting with too many people. With AIM, you’re almost guaranteed to be able to chat with anyone you want. Any growth within the instant messaging realm generally gets absorbed by the few players that dominate the market because people want to join the networks that their friends are on. Ecosystems, by nature, are capable of harnessing the same network effect. A largely fragmented system with dozens or hundreds of ecosystems presents very little value to any participant. A few ecosystems that aggregate huge numbers of participants and value, however, benefits most everyone (as long as the oligopoly remains as such, offering market choice and fostering continued competition).

Right now, we’re very early in terms of the SaaS platform and ecosystem space, so I’ll be brave and attempt to be an oracle. In these early stages, value focus will not be on the value of the ecosystem; participants will choose platforms that offer the most immediate value in terms of technical merit, application offerings, etc. As the participant numbers of the early platforms and ecosystems grow, value focus will shift to the network value of each ecosystem. A market shake-out will most likely follow due to the rapid growth of some ecosystems, leaving that golden handful as clear leaders and many, many participants that can benefit from the huge amount of value that these networks can provide them.

Do you agree with this notion, or do you see a situation where many more ecosystems exist? If this was the scenario, do you think the aggregation of value is worth having an oligopoly?

read more