SaaS vs. Traditional Software Licensing Model

Global software vendors are starting to feel the disruptive effects of the software as a service business model (“SaaS”).  The SaaS model is growing at an annual rate of 15%-20% and will likely represent approximately 25% of the overall software market in the next 5 years. Although this trend is starting to call into question the viability of the traditional software business model, we are quickly reminded that today 95% of software businesses still earn most of their revenues and profits from traditional perpetual licenses and maintenance revenue streams that continue to experience year-over-year single digit growth.

For the large global vendors, it is difficult to transition from a traditional license to a subscription-based model. If you look at the largest 10 global enterprise software companies including Microsoft, IBM, Oracle, and SAP, less than 2% of their revenues are derived from SaaS.

Global Software Companies With Large Cash Positions Will Be Looking to Increase SaaS Penetration

Global Software Companies With Large Cash Positions Will Be Looking to Increase SaaS Penetration

Here are some of the reasons we believe the transition has been so difficult:

  1. It is hard to move away from the significant upfront fees earned through perpetual licenses to a much smaller recurring monthly fee.  This would decrease immediate earnings and negatively affect the valuations of the large public vendors.
  2. The SaaS business model has not yet proven itself in any meaningful way to be viable given the limited number of software businesses that have achieved scale and profitability.
  3. Most in-house development and implementation teams are not structured to build and deliver multi-tenant solutions through the web. This requires significant investment and time.
  4. Traditional sales teams have not educated their customers to accept monthly recurring fees and are not structured to facilitate a low touch sales approach.
  5. IT departments have been reluctant to share sensitive data through the web for security reasons.

However, the SaaS business model has some clear advantages that are compelling to its customers:

  1. There are no significant upfront fees.
  2. The client always has the most up-to-date version of the software.
  3. The software is easily configurable and takes less time to implement than on-premises solutions.
  4. Security has been less of a concern with the introduction of secure data sites and private clouds. Software is being audited to ensure it meets compliance guidelines.
  5. Employee workflow is much more efficient, the software is mobile friendly and can be accessed from anywhere.

There is no question that the SaaS delivery model is more efficient and compelling than an on-premises solution. Having said that, businesses have invested significant time and money in legacy software and in the foreseeable future these businesses will be reluctant to make a change.

As businesses gradually adapt to the SaaS model, it is taking a while for SaaS companies to reach meaningful scale. Selling licenses at thousands of dollars a month (and in some cases hundreds of dollars a month) and educating customers along the way is a difficult path. We estimate that there are only 50-100 private companies in Canada that have reached critical mass in excess of $5 million a year in recurring revenues.

We believe that the limited number of SaaS businesses of meaningful scale has created scarcity in the market, driving up valuations. The ten largest global enterprise software companies have in excess of $200 billion in cash and are looking for ways to increase their exposure to the SaaS market.  In June 2013 there were two significant acquisitions: SAP acquired Hybris for $1.3 billion and Salesforce.com acquired ExactTarget for $2.6 billion (8.1x LTM revenues). In 2013, seven companies went public and are currently valued in excess of 6x revenues. Additionally, the group of public SaaS businesses that we track currently trades in a range of 5.0-6.0x 2013 sales.

Software Companies Have Looked to Grow Through M&A And Will Continue To Do So

Software Companies Have Looked to Grow Through M&A And Will Continue To Do So

Although venture capital and private equity’s interest in the enterprise software space is at a historic high, the dollars invested in Q1 2013 is at one of the lowest points in the past 5 years. We believe that three factors are likely driving this decrease in activity:

  1. There are a limited number of SaaS businesses that have reached scale and are supported by experienced management teams.
  2. Most of the venture dollars have been sitting on the sidelines and have been raised by fewer funds that are not readily accessible.
  3. Valuation expectations of entrepreneurs are not in line with those of investors.

 

Enterprise SaaS Valuations Remain High

Enterprise SaaS Valuations Remain High

We are confident that the SaaS business model will continue to gain acceptance throughout the market and that we will see emerging Canadian SaaS businesses gain critical mass. In turn, these businesses will be well funded by both Canadian and US venture capitalists. In addition, there have been over twenty $1 billion strategic SaaS acquisitions since 2011 and we expect this pace to continue or accelerate as the larger enterprise software players seek to participate in this major market transition.

Your Funnel is a Finite State Machine

Editor’s note: This is a cross post by Joseph Fung (LinkedIn, @josephfung), the CEO of TribeHR (@tribehr). Joseph has recently raised $1MM from David Skok (@bostonVC) at Matrix Partners in Boston, MA. He is building and automating the SaaS metrics for TribeHR. He has a unique engineering view of sales and marketing that allows him to be nimble and correct his efforts based on real customer behaviour data. This post was orignially published on September 23, 2011

The Enigma Machine CC-BY-SA-20 Some rights reserved by Tim Gage
AttributionShare Alike Some rights reserved by Tim Gage

I’m of the opinion that the startup journey is really just the process of repeated work between “a-ha” moments of key insights. The faster we get to new insights, the better we are at ongoing improvement. I’m writing this post to describe an a-ha moment that happened early on (although earlier would have been better) in the lifecycle of TribeHR.


Figure 1: Exciting! An Arbitrary State Machine

To engineers turned entrepreneurs: your customer acquisition funnel is a finite state machine.

This statement implies three specific premises:

  • your funnel can and should be modeled as a Finite State Machine (FSM)
  • your funnel FSM should map to explicit in-app states
  • investors care about the funnel state as much as (if not more) than anything else in your app

Your Funnel Should be Modeled

This point is best described in terms of my experiences with TribeHR:

When designing features within TribeHR, it was intuitive to think about our software in terms of moving objects through a series of states: a review was “in-progress”, “completed”, then “filed”; a vacation request was “pending review”, then “approved” or “rejected”. Similarly, the users of the system would also be moved through states – “employee”, “manager” or “admin” for example. When I thought about the marketing process, however, I treated “sales and marketing” as the entry point into the state machine – I saw it as the entry arrow rather than a separate series of states.

Because we didn’t start by planning our marketing and sales states, it was easy to rely on 3rd party services for our definitions. Unfortunately, implementing multiple services led to confusion. Some customers subscribed using PayPal, others paid through our payment gateway, and others found us via third-party app stores – each system had a different way of defining the state of a customer, so simple numbers like “how many customers are active” was a difficult thing to determine. This was compounded by our shift from a freemium model to a free-trial model earlier this year.

If we had clearly defined and tracked our states from the start (which we have since done) it would have been easier to map third-party terminology to our own, making analyses and improvements much easier. You can see the results of subsequent mapping in the diagram below:


Figure 2: TribeHR Funnel as a Finite State Machine

As you can see, our entry state is “trialing”, thus the primary objective of our website is to convert visitors and leads into trialing users (our lead nurturing program is a state-machine still being designed). Once someone is trialling, they have two potential transitions: they can become either a paid “active” customer or an “abandoned” trial. Once someone becomes an active customer (and ideally remain one for a long time) they will exit the state only as a “cancelled” or “suspended” account. By clearly defining our states in the above format, we are now much better equipped to modify our messaging and features to optimize the experience. Before identifying the above state machine, we wasted a lot of time manually analyzing and identifying states, often on a case-by-case basis.

The “should” part of my assertion follows from my conversations with investors and advisors. I’d frequently be asked for information such as our conversion rate from trials to paid customers or our re-activation rate of suspended accounts – without a clear FSM, we’d have some accounts that occupied more than one state, which made answering these questions impossible. By defining our funnel/FSM we were then able to answer such questions with ease, which made a world of difference to our working relationship with investors and advisors.

If you haven’t defined your Funnel/FSM yet – do so. If you’re early-on in your startups, ot might not be perfect, but it will save you significant stress, time, and effort as you continue to work with mentors and investors. If it helps, put the model up on the wall at your office – it’ll keep it top of mind with your team.

Mapping to Explicit In-App States

Once you finalize your model, it’s critically important that you then track these states explicitly within you app. For example, if you offer a 15-day trial, during which users have to cancel or continue, it might be tempting to calculate “trialing” customers as those who are subscribed and whose date subscribed value is within the last 15 days. While this calculation might yield a correct result, formulating queries becomes significantly more complex when you can’t simply evaluate whether a field “state” is set to “trialing”.

These queries are important because as your company and customer base grow, you’ll need to generate reports and dashboards that highlight this information in near real-time. You’ll need to answer questions like what percentage of users that sign up for a trial convert to a paid customer, and how is it changing over time? As soon as you can answer that, you’ll then be asked to segment by lead source, user characteristic, or time window. For example how does that conversion rate over time vary according to lead source or engagement level?

To put it into an example, below are two examples of queries that would generate a summary of states of a single cohort from January 2011, assuming a 15-day trialing period. The first uses explicitly defined states, and the second assumes you calculate a real-time trial period, and simply delete records when they terminate their account.

Explicitly defined:

SELECT COUNT(state) AS total_users, state
  FROM users
    WHERE date_registered >= "2011-01-01" AND date_registered < "2011-02-01"
  GROUP BY state;

Calculated on the fly:

SELECT SELECT COUNT(state) AS total_users, IF(date_registered >
    DATE_SUB("2011-02-01" , INTERVAL 15 DAY); "TRIAL"; "ACTIVE") AS state
  FROM users
    WHERE date_registered >= "2011-01-01" AND date_registered < "2011-02-01"
  GROUP BY state;

As you can see, the query in the first is much easier to use and read, and it includes all states, whereas the second is challenging to use (even more challenging to modify if you have more states) and doesn’t track cancelled accounts.

By structuring your database such that the state is explicitly identifiable, you’ll be able to generate queries much more readily, which will then let you automate standard reports (like conversion and churn rates) for dash boarding, and will allow you to more easily connect business intelligence tools to your database. The ultimate goal is to let your business-oriented team members manipulate the data as readily as you can.

An added benefit of explicit states is that they act as assertions. Although it’s possible to determine that a customer is active by checking the date of their last successful payment, it’smuch better to have an explicit “active” state as you can then run automated tests to verify that your assertions are true. Having a recurring task that iterates through your customer base to confirm that accounts with a most recent payment made within the last month are correctly identified as “active”, is a good way to follow monitoring-driven-development approaches. Any assertion errors can help identify critical flaws in your system.

Investors Care About the Funnel State

Although this may seem obvious, it still needs stating. The platitude what get’s measured gets done has a corollary – what we care about gets measured. Technical founders often measure and know details like server load, traffic metrics, lines of code and number of commits or push requests. Because we innately care about those tasks, we tend to measure and follow them. What can’t be over-emphasized is how much investors, advisors and partners will care about your funnel states. Below is a representative subset of the metrics we’ve been asked to report at our board meetings – you’ll notice that none of them are related to in-app usage or infrastructure performance:

  • Total # Of Customers (overall and by customer segments)
  • Visitor-to-Trial Conversion Rate (overall, and by lead source)
  • Trials-to-Active Conversion Rate (overall, and by lead source and by segment)
  • Churn Rate (overall and by lead source)
  • Customer Acquisition Cost (overall and by lead source)
  • Average Revenue per User (overall and by lead source)
  • Life Time Value (overall and by lead source)

Most of these numbers depend on measuring our customers’ states as well as various additional segments. Because our segments will vary frequently as we experiment and optimize with marketing campaigns, if we don’t have explicit (and easily determined) states, rapid iterations on our reporting become exceptionally difficult.

Investors and advisors will assume that you have infrastructure running smoothly – you don’t need to hammer home evidence of it, so skip on reporting the infrastructure stats I mentioned earlier. For them to provide valuable advice, however, they need to be able to understand and trust the business metrics I listed. If you can speak as confidently about your Funnel/FSM as you do your application, and if you can deliver transparency into the funnel by automating reports and dashboards, you’ll build your investors confidence and trust in you as an entrepreneur.

Bonus Reasons

As a bonus, here are a few cool things you can then do once you have this funnel modelled and embedded within your software:

  1. More easily build dashboards with tools like Geckoboard
  2. Delegate data-mining and analysis to non-technical staff, by tacking on BI tools like Qlickview
  3. Automate segmentation and lists for automated email campaigns and lead nurturing using MailchimpPerformable, and others
  4. Simplify cohort analyses by customer segment

If you have a state machine for your funnel or customer base, especially if it deviates significantly from mine above, please share it in a comment or an email to me. It would be interesting to see what approaches others are taking.

Editor’s note: This is a cross post by Joseph Fung (LinkedIn, @josephfung), the CEO of TribeHR (@tribehr). Joseph has recently raised $1MM from David Skok (@bostonVC) at Matrix Partners in Boston, MA. He is building and automating the SaaS metrics for TribeHR. He has a unique engineering view of sales and marketing that allows him to be nimble and correct his efforts based on real customer behaviour data. This post was orignially published on September 23, 2011

A year in the life

GuestlistHappy 1st Birthday Guestlist!

Guestlist has had a couple of weeks. On July 12, 2010 they launched their paid service which finally allows the company to generate fees for the great service they provide. We started using Guestlist for events starting on September 24, 2009 for DemoCamp Toronto # 22 aka An Evening with Yossi Vardi.

“What began as a dare between three friends to actually finish a software product has turned into full-fledged web service that has helped hundreds of event organizers sell tickets online and keep tabs on their cash flow. Over that period we’ve collected half a million dollars on behalf of our users, a near-majority of which was delivered directly to charities. All powered by word of mouth.” – Ben Vinegar, Guestlistapp

It’s been a great year for Guestlist enabling over $500,000 in transaction revenue. This is great traction for the small team. Sure it’s only $10,000 using the 2% paid service fee. But this is fantastic traction given that this is a part time project with all 3 team members working other jobs. The demonstrated traction helped the team realize the potential of Guestlist as a business.

“That’s the story of what our team put together, part time, over one year. We can’t say it was easy; building and maintaining a quality application part-time requires a lot of dedication and free time. That’s why we’re excited to announce that 2/3s of our team has opted to work full-time on Guestlist going forward.”

If you’re planning an event and you want a great event application, I can highly recommend Guestlist.