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

Related Posts

Tags

Share This

A Future of Cloud Stacks or Cloud Silos?

May 11, 2010 by

When thinking of the cloud, there are two sides to the coin: those who build SaaS offerings and those who consume them. For those who build SaaS applications, we’ve seen a glut of tools crop up to help engineer, architect and deploy SaaS offerings. Some are “horizontally” aligned (think EC2 on the IaaS side, SaaSGrid on the application server side, etc.) while others are “vertically” aligned holistic silos (think Force.com on the PaaS side – even with the recent VMForce announcement) and some are in a mid-silo middle (think Google’s AppEngine and Microsoft’s Azure, both “up to the runtime” PaaS stacks).

Given that there is so much velocity, tumultuousness and general confusion (acronym hell coupled with taxonomical conflation – aka the “everything and everyone is a platform” syndrome), we’re bound to see some order evolve in the future where the evolution will be motivated by what people actually use and adopt rather than the current landscape which is driven by who can yell the loudest.

The big question is what will the future of cloud architecture look like: a stack of interchangeable layers that allow one to choose best of breed or a group of incompatible but highly specialized “holistic silos?”

Looking at the history of infrastructure middleware, the answer seems to be quite clear. Typically, the trend has been that layering functional best of breeds into stacks provides the best combination of “lowest common denominator” coupled with the necessary functional value to “get things done” and keep risk minimal. For example, I can choose servers made by HP, a Windows OS, Java and JBoss, and build a killer enterprise app. If I so decided, I could have swapped Windows for Linux and essentially had a compatible stack experience.  Why, then, are silos cropping up in the market?

Silos like Force.com have their appeal. They promise a world where all your needs, ranging from hosting and execution runtimes in the cloud all the way through development frameworks and distribution channels. The problem, however, is that the software market cannot be addressed as a broad stroke.

The needs of software companies vary wildly: ISVs in the healthcare space may care more about hosting certifications than someone in the CRM space, while those in business intelligence need low latency, high compute availability and the others who altogether care very little about the hosting and it’s all about what middleware they are going to use. The number of needs permutations is staggering.

To think that Platform as a Service vendors that own the full stack, from hosting through runtime and even UI components, can ever optimize for each of these scenarios is ludicrous.  Furthermore, the silo providers ask for something huge in return for a suboptimal solution:  control of the ISVs destiny in all regards. That’s a high price to pay for a promise that can’t be fulfilled.

Cloud Stack “Half Stack” Cloud Silo
Operations Management SaaSGrid Force.com, Quickbase
SaaS Middleware Microsoft Azure, Google AppEngine
On-Premises Runtimes .NET, Java, etc.
Cloud Infrastructure EC2, Rackspace Cloud,  GoGrid

I’m a firm believer that most if not all software will be delivered online. It’s the only way to achieve true ubiquity, and it requires superior delivery. Each ISV is going to have to make lots of decisions as they move to the SaaS delivery model. Those decisions are going to focus on how to best solve all the critical problems associated with becoming a service provider. The only logical conclusion is that each ISV will look for best of breed tiers in a stack form that would allow them to create an optimized outcome. I don’t see a grand future unfolding where thousands of ISVs worldwide commit to incompatible silos that require taking on relationships that amount to single points of failure and risk. As a stack becomes more vertically consolidated (i.e., more siloed), the higher the risk grows for an ISV. If ISVs take on piece-meal stacks composed of highly compatible tiers, the walk away with the best of both worlds.

What do you think? Do you think that the next generation of business applications will be split across walled silos, or will the market adopt levels of commonality by converging to a stack approach with solutions provided by a few key companies at each layer, allowing for a “composable” stack approach that we’ve grown accustomed to?

read more

Related Posts

Tags

Share This

A bit foggy on “cloud?”

Feb 24, 2010 by

One question that has popped up in some blog posts recently is whether the notion of “private cloud” is a misnomer or if it conceptually even makes sense. Some of the conversation started when Andrew Conry-Murray posted that the term “private cloud” is bunk and no such thing exists. I have to completely disagree with Conry-Murray. His dismissal of “private cloud” comes from using too narrow of a scope and too restrictive of an understanding of a “cloud’s” applicability, intent, and history.

It’s important to first understand where the term “cloud” originated, as it should really be used in a constructive approach to arriving at the definition of “private cloud” and the determination of how accurate of a term it really is. The term “cloud” originates from a scary place: network diagrams. Have you ever used Visio or a similar tool for modeling diagrams? If so, and if you’ve ever created diagrams that required some sort abstract network, you’ve undoubtedly used the “cloud icon” (which looks kind of like the dust-balls that the Road Runner would leave behind when being chased by Wiley Coyote). This icon was used to denote an abstract network at some responsibility boundary.

Ok, so the history of the term cloud is somewhat rooted in telephony, but we definitely adopted the icon for broader use in general network diagrams. Point being, the origins of the term “cloud”" had nothing to do with the public Internet, and I’d argue it still doesn’t. A cloud is simply an abstraction of network and resource responsibilities that one can leverage in support of some other functional tier or silo. The network diagrams that we’ve all created never restricted the use of the icon to the Internet, but rather remained open to use in any situation where you had to clump non-specific, potentially unidentifiable (but conceptually understood) resources into a dependency.

Given the history of the term and its typical usage, what makes the term “private cloud” so broken? Nothing. An enterprise can use Internet architectures to create internal, “private” resource abstractions. These are private clouds that can be used in a variety of capacities. Granted, larger enterprises are better positioned to leverage private clouds, but that doesn’t mean smaller enterprises won’t build them as well.

All this said, I do distinguish the Cloud, as a proper noun, from a general cloud. The proper noun Cloud should be used to identify the public internet.

How do you feel about the term private cloud? Does history not matter when it comes to best understanding the term? Let me know!

read more

Related Posts

Tags

Share This

The True Value of Cloud Computing

Jul 13, 2009 by

Two weeks ago I had the honor to be invited to participate at a small panel at Structure09 in San Francisco CA next to Matt Mullenberg founder of WordPress, Robert Miggins VP of Business Development at Peer1 and Geir Magnusson Jr. consulting architect at the Gilt Groupe.

The topic of the panel was about the effects of running Cloud Computing on commodity hardware, but somewhere along the conversation, somebody asked a question that prompted a bit more explanation  of the general effects of cloud computing.

See, most people are confused about the true benefits of cloud computing; often citing the cost of running a server from a cloud provider as being less than a traditional dedicated server from a traditional hosting company like Server Beach or alike. The fact of the matter is that running a server image from a cloud provider like EC2 is almost twice as expensive as it would be if you had a comparable dedicated server from a traditional hosting vendor.  The reason is because the true value of Cloud Computing, is not in the cost of running a particular server in comparison to its traditional counterpart, but in the flexibility and elasticity that one gets to instantly scale up or down an application at times of high or low demands.  For these capabilities, we gladly pay a premium.

The problem is that 95% of web applications (my personal estimate) are not designed to be able to take advantage of these properties and for a good reason. IT IS NOT TRIVIAL.  Having the power to instantly scale up or down an application to only consume and pay for the resources that are required at that point in time is an amazing capability and if done correctly it WILL be less expensive than running on regular hardware from a traditional hosting vendor since you don’t have to run at over capacity all the time only of those peak times, but taking advantage of that power is harder than most people think.

Careful design and planning is required when building the application to facilitate this elastic scaling, but that is why companies like my own exist. In my opinion (and thankfully I’m not alone on this one), the future of software is on the web, but this new breed of web applications or SaaS Applications have many particular requirements that are key for their success that truly complicate the requirements to building the applications. Things like a true multi-tenant application, customer provisioning, application metering and billing only to mention a few are a must in order to succeed and are not trivial to design.

Cloud Computing is extremely powerful on its own because when done right, it can provide great financial rewards as well as operational rewards but understand that the hardware layer alone is merely a tiny piece of the puzzle.  The true value of Cloud Computing will be much more appreciated when it is coupled with a platform layer like SaaSGrid that abstracts away the hardware layer and provides a unified foundation to enable the elastic properties at the application layer without the explicit interaction of the application developer.

What are your thoughts? Are you using Cloud Computing strictly for hosting or are you taking advantage of its elastic properties?  What do you think about SaaS Application Servers like SaaSGrid?

If you’d like to mingle with others in the SaaS space, the SaaSBlogs group on LinkedIn now has 2280+ members and is growing every day; make sure you’ re not missing out and join today!

read more

Related Posts

Tags

Share This

How does commodity hardware impact SaaS?

Jul 7, 2009 by

One topic that fascinates me is the discussion of commodity hardware. Recently, Abe Sultan, our VP of Engineering at Apprenda, spoke on a panel with a few other great folks regarding the topic of leveraging commodity hardware. People LOVE to talk about commodity hardware, but what does it really mean in the context of SaaS and SaaS enablement? Before understanding what it means, I think we really need to understand what the fuss over commodity hardware is, and what the landscape might look like.

First, let’s chat about commodity hardware in general. First, commodity hardware enables commodity computing. The basic idea is that we’ve moved away from supercomputers, or “scale-up” systems (i.e. throw more memory, CPU, and disk at a single physical box to make it better) and to a scenario where we can “scale-out” by adding more inexpensive physical units as a solution to scale problems. Normally, this is done as a reactive measure to a mounting scale problem. We see this in everything from plain old websites to SaaS architectures. As inbound load increases, we add hardware to resource pools thereby increasing capacity, we then load balance, and voila, all better! Interestingly, infrastructure as a service (dialing up raw resources like servers on EC2) makes this even more practical as a solution. It used to be that “commodity hardware” meant real iron, but now we can deal with this virtually and in an “elastic” fashion (the ‘E’ in ‘EC2′) We’ll categorize this reactive commodity-based measure as naïve scale-out. I don’t mean this in the pejorative, but rather in the formal sense; systematic scale-out of this type exploits coarse grained application level allocation and “bolts on” new capacity with the notion that any new capacity be only minimally aware (if at all) of the “old capacity” and the scale problem it is actually solving, hence the word naïve. Assuming that dynamic scale out needs are real enough to justify using cloud hardware (e.g. EC2, GoGrid), then we have an amazing tool to solve our problems.

Naïve commodity scale-out is amazingly powerful and has catalyzed web-scale operations, but is it the “end all” solution? Not even close. Commodity hardware, at least for most of computing, has allowed us to “back into” older software like RDBMS, traditional application servers (e.g. IIS, JBoss) and build certain types of software architectures in response to scale-problems. Realistically, however, it’s not terribly innovative on its own. What I find most intriguing is the “what’s next” discussion. If we look at the past few years, we should have good indication of what commodity hardware, and more specifically, commodity hardware in the cloud, is allowing us to do.

Let’s use Amazon as a focal point (for no particular reason other than they exemplify where some of the change is headed) When we first think of Amazon, we think of infrastructure as a service: raw servers via, EC2 and web scale storage via S3. But now, Amazon is starting to evolve. Recently, they announced Elastic Map Reduce, which is essentially a step up the stack to the algorithm layer made possible by the mass parallelization offered by commodity cloud hardware. In my opinion, we’re going to see a revolution where “the cloud” will no longer mean boring servers that can be “fired up” on command, but rather a whole array of tools like Elastic Map Reduce that are the software layers that expose commodity hardware’s real value. We even see this with our beloved SaaSGrid – rather than being a traditional “single server” or “single cluster” application server, SaaSGrid establishes a “fabric” across arrays of servers (commodity) and creates a unified hosting layer, allowing the applications it hosts to trivially leverage an expanse of servers. This is a great thing to see, given that the complexity of engineering software to actually leverage commodity hardware layers is a difficult thing to do correctly, and will open the door to a host of SaaS applications that weren’t physically or economically possible before.

read more

Related Posts

Tags

Share This