I can certainly understand why this might be; most early stage entrepreneurs are subject matter experts in their domain and have a strong point of view with respect to what their application/product should do.  In addition, quantitative analysis can take time and money – something that is in short supply at an early stage startup.

That said, even the best product team can get it wrong — delivering a product that may not be exactly what the market wants, or is priced and/or positioned incorrectly. And, unlike larger software companies, a mistake in an early stage software company can be fatal – or at least cause the company to have to take in more capital and require more time to get into market.

So, I am surprised that more start up software companies (and big software companies, for that matter) don’t incorporate more quantative analysis to help them make critical product, market, features, pricing, and positioning decisions.

I took over the CRMOnDemand division in early 2004 after returning to the company after a 20 month hiatus. The CRMOnDemand division had been created by Tom Siebel to go after Salesforce.com and the SMB market – a market Siebel hadn’t really participated in until that point.

The CRMOnDemand division had two products to offer: UpShot’s “on demand” CRM products as well as our own internally-developed ”on demand” CRM products  (Note: Upshot was a SaaS-based CRM provider that Siebel acquired to gain access to its personnel who had demonstrated they knew how to compete against Salesforce in the “on demand” market).

Unfortunately, the CRMOnDemand division had been struggling since its initial launch 6 months prior to my return and had achieved very little traction with customers and Siebel’s own internal sales organization.

In my first weeks, I sat down with the product, marketing and sales organizations and listened to what the teams thought about UpShot v our internally-developed on demand product, key product features, market positioning, sales strategy, etc. As a result, it didn’t surprise me why we were getting our clock cleaned; we were competing against a strong competitor in its market of strength with a confusing 2-product, ”me, too” message and we were primarily using Siebel’s enterprise sales organization to go after small (SMB) accounts.

I decided to engage a small research firm (Incyte Group) to help us reach out to prospects and customers to better understand how they perceived our “on demand” products, pricing and messages.

From these surveys, we captured a significant amount of data that drove our conjoint analysis. We were able to identify many different issues that were not necessarily obvious going into the study. This data enabled us to quantitatively understand specifically what our engineers should be building, what our marketers should be saying and what our sales organization should be selling.

Consequently, the long and heated debates inside Siebel changed from subjective opinons regarding what should we build, how should we price it, how we should sell it, etc. to instead focusing on solving all the issues surfaced from the surveys. Engineering and Products were now working in alignment. Sales was confident we were building the right product and could sell with confidence. Marketing had a solid messaging platform to work from. And, I personally felt I had the data to show Siebel’s senior executive staff and the Board what we needed to do in order to win in the market.

The result: in 18 months, from relatively little revenues, we were able to grow the organization into an $80M annual bookings business.

While the study certainly wasn’t cheap (it took about 4 months and $100,000+ ), I think about how much it would have cost us had we not done it at all. And, today, with my own early stage start ups, I consider the risk associated with not doing conjoint analysis; how much time/capital will we spend if we get the product, market, pricing, go to market model wrong?

I recently read an interesting article on conjoint analysis by Brett Jarvis at Sawtooth Consulting. I think he makes a powerful case for why each of us involved in developing and/or investing in new product offerings – SaaS or otherwise – would be well served by using conjoint analysis to verify and/or refute our plans.

So, the next time you are faced with a critical product, pricing, messaging, go to market decision, rather than relying solely upon ”gut feel”,  I would suggest you initiate a little conjoint analysis. It doesn’t have to be perfect, take a long time, or a lot of money – and, there are a lot of small consulting firms that can help you do it. I think you will find it illuminating, clarifying, uniting and it might well be one of the single most important decisions you can make as a start up.

I remember the mid 80’s when Unix entered its hype phase. Traditional proprietary OS companies, seemingly overnight, developed competitive offerings for the Unix market. As a hardware vendor, if you didn’t have a Unix-based solution to offer – even if it was weak – you were toast. Similarly, today, if you’re a high tech vendor it is highly likely you have some sort of Cloud-based offering – even if you’re an incumbent and even if it’s weak.

It hit me last week at the Cloud Connect Conference in San Jose that Cloud Computing may have officially reached its hype phase.  What was my epiphany? When I received an invitation to form a group to discuss “Optical Character Reading In the Cloud”. Seriously? OCR in the Cloud?

I’m sure it was a legitimate invitation to a legitimate discussion but I just had to laugh. It reminded me when my kids were younger and they demanded my wife and me to add the words “in bed” at the end of reading our paper fortune inside our Chinese Fortune cookies. I’m sure it was amusing at first but after repeated readings, it grew a little tiring – at least for the grownups.

With every company adding the words “in the Cloud” to their every marketing pitch and product position it is beginning, for me at least, to feel the same as adding those words “in bed” at the end of those fortunes in the cookies; somewhat wearisome.

Cloud Computing is a great evolutionary business model and technology transformation. It provides an innovative way to deliver new solutions at a much reduced price for consumers/businesses. However, I hope the hype starts to get dialed back soon…just a little…in bed.

It rears its ugly head when a start up CEO comes into our office to take us through their business, introduces the management team and describes one of the executives as the “VP Sales & Marketing”.

At that point, I stop listening and start thinking about how I can end the meeting on a professional note. Like the mythical Unicorn, I don’t believe in the mythical VP Sales & Marketing. Actually, I am more likely to believe in Unicorns than a VP Sales & Marketing.

Why? Simple. Sales and Marketing are vastly different functions that require substantially different personalities, skills, and decades of experience to master. In my 30 years of operating experience, I have found very few people - I mean less than a handful – who are experts at both functions. And, for that rare individual, in my experience I do not believe it is possible to head up both functions simultaneously.

A CEO who doesn’t understand this basic fact, or doesn’t believe it, is not a CEO I want to invest in. Here is why.

Someone who is a head of Sales must have an in depth understanding of current key deals in the sales pipeline,  a deep sense of the probability of whether those deals will close, and what it will take for them to close. This is a 1:1, short-term focus game and success is predicated upon a career of working closely with buyers. In many cases, it also requires someone to travel and meet with prospects to gauge for themselves whether or not a deal is really a deal. It is the realm of oral communicators.

The head of Marketing, on the other hand, must develop and maintain an in depth understanding of the overall market and the company’s brand in that market. To do this, he/she must constantly work with industry analysts, the media, execute tradeshows, keynotes, and the web. Perhaps even more importantly, today’s head of Marketing must be an excellent demand creator (the “owner” of future revenue) through sales-ready leads.

Marketers must know how to generate those sale-ready leads for the lowest acquisition cost and ultimately nurture any sales-ready leads that fall out of the sales pipeline. This is a 1:many game and requires constant refinement through analyzing campaign, market and customer data. It requires continuous meetings with internal staff including the CEO, Product Marketing, Sales, etc. It is the realm of verbal/written communicators.

A CEO who has combined the Sales and Marketing functions, indirectly but undeniably, telegraphs me that he/she does not truly understand the diverse nature of these positions and the fact that it is impossible to execute both functions simultaneously with excellence. In most instances, I have found that the CEO who makes this serious mistake hasn’t worked with someone who is an excellent Marketer and therefore discounts the role it plays.

So, if you ever come and present to me and think you are going to show me a “real” VP Sales & Marketing,  don’t be surprised when I look at you as though you’re trying to convince me there are Unicorns and excuse myself early from the meeting.

At the time, many of the metrics that those who currently run or invest in SaaS businesses now take for granted were then relatively new concepts and not necessarily a part of a traditional software business  - Annual/Total Contract Value, Monthly Recurring Revenue, Cost of Customer Acquistion Ratio, LTV Customer, etc.

A few days into the job, I received my first set of waterfall charts and I remember poring over the numbers trying to cull out the critical information. The first numbers I noticed were “Bookings” and “Monthly/Annual Contract Value”. These were straightforward enough but the second number that popped out at me was “Churn Rate”. It didn’t take a rocket scientist to figure out that a large Churn Rate is an awfully large hole to plug in the bottom of this business model. Our Churn Rate at the time wasn’t outrageous but the trend was concerning.

As a result, I realized there were three critical areas to making this business model work:

1. Number and cost of prospects acquired
2. Velocity rate and conversion costs of turning prospects into customers
3. Churn Rate

I had a function in place responsible for the first (Head of Marketing) and the second (Head of Sales) but no one specific function in charge of number 3. In my experience, if there is a critical business function where there is no single individual/team who wakes up every morning concerned about achieving the objectives of that function, it is unlikely to get done — or at least not as well as it could be done.

As a result, I held a number of discussions with the sales, products, support and services organizations. We elected to create a function called “Customer Success”,  put in place a team and team lead responsible for achieving its objectives and had that lead report directly to me, as the GM of the division. This, I felt, would demonstrate to our employees and customers just how important this role was.

We determined the key metrics of success for this group would include:

• Onboarding rate
• Adoption rates
• Usage rates
• Renewal rates
• Customer satisfaction scores

The result of this decision took our then-current Churn Rate and lowered it by 2/3rds. And, it served as a direct conduit to our Products team in terms of prioritized feature sets for future releases.

Consequently, I have become a firm believer that a SaaS company that does not have a senior executive in charge of Customer Success is one that doesn’t understand its business model and not one I am likely to invest in.

Recently, I’ve had a few conversations with people regarding my version of the Customer Acquisition Cost (CAC) ratio. As a reminder, my version of the CAC ratio is: [($Total Sales + $Total Marketing)/$First Year Contract Value]. The objective is to make the CAC ratio less than 1 which implies a customer acquisition payback of a year or less. This is the ratio I recommend companies use to measure their sales/marketing effectiveness. I discussed this a year or so ago in this blog in a post titled “The Capital Needed to Create a SaaS Company”.

.

Will Price when he was with Hummer Winblad and Phillipe Botteri at Bessemer Ventures suggest slightly different approaches and put the Sales and Marketing costs in the denominator with FCV on top of the equation. This makes sense if you’re looking at a company from an investor’s view but I come at things more from an operational perspective and developed my approach in 2004 when I was running Siebel’s CRMOnDemand division. I found that my approach allowed me to easily determine whether or not my Sales and Marketing teams were paying back our customer acquisition costs within 1 year and to track the trend. With the other mathematical approaches, in my opinion, it’s a little harder for the operational executive to determine what’s going on. All approaches are mathematically sound; it’s just a matter of preference.

One of the common issues I’ve been debating is why not use Total Contract Value v only First Year Contract Value so that Sales and Marketing get complete credit for multi-year deals.

Here is how I like to think about the issue.

With early stage companies that use a SaaS business model, companies should be primarily concerned with the preservation of cash not necessarily revenue.  The CAC ratio as I have proposed it focuses on actual Sales and Marketing expenses – which takes real cash – and the First Year Contract Value which represents actual first year cash inflows.

For early stage companies, I feel this is the most appropriate way to look at the CAC ratio because it measures ‘real’ cash inflows v ‘potential’ cash inflows. As the company matures and revenue becomes increasingly more important and cash less so you may want to adjust this ratio to give at least partial credit for multi-year deals.

I want to also comment a little further on the “$Total Marketing” in the CAC ratio. To really maximize effectiveness here, companies must hold the marketing function accountable for accurately creating and predicting future revenue for the company. Rather than just being responsible for managing corporate brand, marketing must be transformed and own the lead generation function and held accountable for accurately predicting out of period, future revenue.

Asking the sales organization to predict future revenue is like asking a sprinter to run a marathon. Sales is incented to predict and close in period revenue. They are terrible at predicting out of period revenue – just take a look at the garbage your CRM system contains in terms of future pipeline coverage. And, many companies make guidance statements based upon this highly subjective data – no wonder so many companies miss their forecasts.

As the former head of marketing for a multi-billion dollar software company, I am all too familiar with the pressure of delivering leads and generating statistically relevant data for Wall Street predictions. Consequently, I firmly believe the marketing function as we have known it must be transformed. Instead of just a brand organization, Marketing must become accountable for accurately predicting  Q+1…Q+N revenue by building a lead generation and lead nurturing function that monitors, tracks and predicts lead conversions and conversion rates.

That’s why I am a big believer and an investor in Marketo. They are building applications for Marketing and Sales that enable those groups to minimize CAC costs and accurately predict and maximize future revenue. And, whether you choose to use Marketo or another similar application, your company must transform its marketing function and hold it accountable for creating and accurately predicting future revenue: only then can you expect to truly minimize your CAC ratio. ]]> http://www.interwest.com/software-as-a-service/brand/minimizing-the-customer-acquistion-cost-cac-ratio/feed/ 3 http://www.interwest.com/software-as-a-service/on-demand/the-case-for-revenue-performance-management-in-the-front-office/ http://www.interwest.com/software-as-a-service/on-demand/the-case-for-revenue-performance-management-in-the-front-office/#comments Sun, 11 Oct 2009 18:49:54 +0000 Bruce Cleveland http://www.interwest.com/software-as-a-service/?p=313 In March of this year, I posted a blog titled “Process Work v. Knowledge Work – The Emergence of Performance Management“.

At the end of that blog post, I committed to commenting in much more detail on the topic of Performance Management and the role of predictive analytics in a future blog.

There are various labels applied to the current Performance Management market such as: Enterprise Performance Management [EPM], Corporate Performance Management [CPM] and Business Performance Management [BPM]. For clarity and simplicity sake, I am going to use the acronym “EPM” to represent the category going forward.

Two of the application leaders in the EPM market are Oracle and SAP and they define EPM accordingly:

Oracle. EPM applications are a “broad range of strategic and financial performance management processes …[sic] that drive profitable growth by delivering predictable results, improving transparency and compliance, and increasing business alignment.”

SAP. “Enterprise performance management starts with aligning operational plans, budgets, and resources to strategic objectives. It involves providing every information worker with contextual access to data they need to make faster, wiser decisions.

While the goal may be for EPM to involve “every information worker”, the reality is that EPM applications are primarily process-oriented and targeted to relatively small operations teams who are tasked with planning, modeling, budgeting and measuring the business. With few exceptions, EPM solutions are not designed for the Front Office LOB.

Directionally, though, applying Back Office-like performance management techniques to the Front Office to enable better business decisions by LOB is a tremendous opportunity. Using advanced mathematical modeling and statistical analysis with historical, current and forecast data rather than relying upon qualitative assessments just intuitively makes sense.

For example, here are some common business decisions that are typically made by individuals in the LOB using ‘best guess’ practices:

• Sales Rep – What is the price I should quote and negotiate that is most likely to be approved by the customer and simultaneously maximize revenue for my company and my commission check?
• Sales Manager – What forecast should I submit for my team based upon the current deals in the pipeline and the historical close rates of my sales reps?
• Marketing Manager – What is the best price I for my product line based upon the overall market forecast?
• Customer Support Representative - How long should I remain on the phone with this customer to address their concern?

To better address these business issues, a new class of realtime, analytical applications that use predictive analytics and statistical modeling techniques are beginning to appear in the Front Office.

These solutions use the data created through business and market transactions (e.g. SAP, Oracle) and enable the LOB organization to make much better business decisions that align with overall corporate objectives. To distinguish these revenue-oriented applications from their Back Office EPM brethren, I apply the label “Revenue Performance Management” or RPM.

Below are six primary areas of difference between EPM and RPM application requirements.

F&A/IT v. Line of Business

In the Back Office, F&A and IT own the resources and make the decisions that affect how the company manages and reports the business. Traditionally, these organizations have the people with the technical skills, domain expertise to use development tools to configure and customize and manage the systems and applications, and the budgets they need to run business systems such as: accounting, order management, payroll, tax, etc.

In the Front Office, Line of Business managers are in charge but in many cases neither they nor their organizations have access to capital budgets nor the technical personnel and/or expertise required to design, deliver and manage the applications they need to run their organizations. For example, Front Office groups such as Marketing, although potentially responsible for millions of $ in demand generation investment, have for years had to rely upon arcane tools such as email/spreadsheets to manage their function.

Cost Centers v. Revenue Centers

In the Back Office, the primary objective is cost containment. Every business process is analyzed to identify and remove overhead. Once an optimal method is determined by F&A/IT for a corporate business process (e.g. Create Purchase Order and Secure Approvals), an “internal policy” is generated and a corporate-wide mandate issued to drive compliance. Few, if any, are allowed to deviate from the policy.

In contrast, the Front Office is primarily focused on revenue generation. Since most companies can’t mandate revenue from their prospects/customers, they must incent the Front Office organization to identify and capture as much revenue as it possibly can. “Incentive Compensation” plans, bonuses, SPIFFs, etc. must be designed with the intent to find, secure, optimize and reward revenue production.

Static v. Dynamic

In the Back Office, every effort is made to stabilize business processes so that they don’t change and generate unnecessary overhead and errors. In the Front Office, change is the operative word. Customers change. Competitors change. Markets change. Territories change. The Front Office of a company must be able to quickly adapt and adjust to change. To address this side of the organization, applications must be easy to implement and manage and be extremely flexible. Relying upon an over tasked or in the case of small companies, a non-existent, IT organization is a non-starter.

As I stated in a previous post, I believe the primary reason Salesforce.com has become so successful is that it was the first company to recognize that with “internet-based computing”, the term used at the time, you could virtually eliminate IT. They pioneered the concept with SMBs and as their products have matured – enduring skeptics – they have gradually worked their way into the LOB organizations of large enterprises.

It is indisputable that Tom Siebel and Pat House, co-founders of Siebel Systems, identified and created what we now all know as the CRM market. However, Marc Benioff was shrewd enough to recognize that his delivery and business model was a better way to deliver CRM solutions to SMBs that have minimal IT support and LOBs inside larger companies who are tired of waiting on IT.

As described in Clayton Christensen’s book “The Innovator’s Dilemma”, Salesforce.com may not have created the CRM market but its disruptive innovation has exploited it.

Realtime v. Batch

The Business Intelligence market emerged out of the requirement for operational teams to be able to use transactional data to generate better business insight. Where online transactional processing (OLTP) was optimized to enable applications to quickly capture and view transactions, for reporting and analysis a different database structure/format was required. This led to the formation of online analytical processing (OLAP) and formed the basis of the Business Intelligence market.

The EPM market emerged in the Back Office out of OLTP/OLAP applications as companies realized they needed new applications that enable them to better plan, model and set budget targets for the business.

In a similar way, the RPM market is emerging in the Front Office. However, there is one very big difference between EPM and RPM.

With EPM, applications are designed more often around batched data.  While response time is important, if a report takes a while to run it may be inconvenient but it isn’t usually catastrophic to the business. Not so, with RPM applications. Here, the interactions can be in realtime and application performance is always critical. For example, if a customer asks a sales rep a question on the phone, the sales rep needs to be able to reply quickly. He can’t wait on the application .

Since the Front Office has few IT resources, RPM applications can’t rely upon IT to configure, manage and maintain them. They must be highly flexible, configurable; they must be SaaS-based. Consequently, the database and analytical architecture for RPM applications must be completely different than their EPM counterparts.

Voluntary v. Involuntary

If you perform a Back Office and/or operations function it is likely you must use an application to accomplish many, if not all, aspects of your job. For example; processing payroll, generating a purchase order, configuring an order, identifying a performance issue on a network, doing an audit, etc. These all require you to engage with an application to accomplish your task.

In the Front Office, other than a few applications (e.g. email), you may only interact occasionally with an application to accomplish your functional objectives. As a result, it is critical that Front Office applications are easy to interact with and generate easy to identify advantages to the individual using them. Otherwise, they won’t be used. RPM solutions, while needing to be quite sophisticated underneath, must have a very simple User Interface and must be able to be administered and managed by the Front Office organization on its own.

Subjective Data v. Objective Data

By far, here is what I believe is the biggest difference between the Back Office and the Front Office.

With relatively few exceptions, the Back Office is driven by objective data. A Purchase Order is either approved and signed or it isn’t. An entry into the General Ledger has either been made or it hasn’t. Revenue is either recognizable or it isn’t. And, these decisions can be made at a relatively slower rate than the Front Office.

In contrast, the Front Office is largely driven by subjective data and the decisions must be made much more rapidly to respond to immediate customer and/or market demands. What should the sales forecast be? How many widgets should I build? Are my sales territories optimized to maximize revenue? Am I spending too much/little money on support? Today, the answers to these questions are determined by largely by human judgment.

The CFO abhors “guesses” and wants to make decisions based purely upon facts. The CSO (Chief Sales Officer) lives in a world of ambiguity and must rely upon a series of educated guesses. If the CFO of a public company certifies the S-1 is correct and it isn’t, she might go to jail. If the head of Sales gets the forecast wrong, she might lose her job but isn’t likely to go to jail.

Therefore, the goal of RPM is to enable the Front Office to convert what has been primarily been subjective data into objective data so that the Back Office and the company overall can make better business decisions.

I have put my money where my mouth is with respect to Revenue Performance Management. I have made several investments to date in companies that have built realtime, analytically-based solutions targeted at the Front Office:

• Marketo (www.marketo.com)
• Cloud9Analytics (www.cloud9analytics.com)
• SignalDemand (www.signaldemand.com).

Each of these companies has designed and is currently delivering SaaS-based Revenue Performance Management solutions. Each is using analytics to help LOB organizations make better business decisions by converting what has been highly subjective data into objective data.

My underlying going-in thesis is that the world doesn’t necessarily need more transactional applications or business intelligence (reports/dashboards) for operational teams. Those markets are defined and owned by well-known incumbent brands.

The big market opportunity is in Revenue Performance Management; using applications that utilize data created by OLTP/OLAP that enable LOB organizations to make better decisions. By definition, these must be SaaS-based. Therefore, for the reasons I’ve discussed in previous blogs, it’s not going to be the incumbent brands that can capitalize upon this opportunity.

Only time will tell if I am right.

The HCIT market is very large and comprised of many large sub-markets. Overall, Piper Jaffray estimates the total HCIT market  to be $15.7B comprised of clinical and non-clinical HCIT systems and they break it into the following submarkets:

• Hospital IT
• Ambulatory IT
• Hospital Revenue Cycle Management
• Physician Revenue Cycle Management
• Connectivity/Interoperability
• EDI
• Payor IT
• Outsourced Services
• Drug Development

Within each one of these markets, there are literally dozens of private and public companies. Many of them have been around a long time.

There are many drivers behind the HCIT market but recently the key ones seem to be: shifting payment for procedure to payment based upon clinical outcome, multi-provider/payor access to patient data, and radical reduction of overall healthcare costs in all areas for all participants – patients, physicians, hospitals, insurance companies and government.

As I took a fresh look at the current major application software providers in each submarket, unsurprisingly I found that virtually all of them use a traditional enterprise software model. However, I can’t think of a industry better suited for the SaaS model than HCIT.

Hospitals – IT staff is under tremendous pressure to reduce costs while simultaneously improving service levels; using SaaS-based solutions the hospitals can substantially reduce their capital  and operational requirements. And, unlike corporate entities where competitive differentiation may lie in unique business processes and therefore require highly customized applications to support those processes, hospitals gain little by differentiating themselves this way. Instead, hospitals and all healthcare constituents benefit from economies of scale if the data and the processes are standardized. What about security? Yes, HIPAA/patient data is critical to secure but no more critical than financial data and SaaS has overcome this issue with flying colors in the traditional corporate world.

Physicians - Physicians don’t typically have IT staff and their concerns are far more about providing great patient care, not maintaining and operating patient management systems, EMRs, HIEs, etc. The SaaS model transfers the burden of managing and operating these systems (e.g. Patient Management, Lab, Prescriptions, Billing) onto the shoulders of the SaaS vendor thereby freeing the physician’s office to focus on patient care and outcomes.

Patients - Patients are becoming more and more interested in managing their own healthcare. High deductible plans, rising costs and looming tax legislation are forcing patients to better understand where and how they are investing their valuable health dollars. Having access to web-based applications that enable patients to consolidate and manage their interaction between insurance companies, physicians, hospitals and other healthcare providers will become increasingly more important. However, forcing a patient to interact with cumbersome master/detail list form-based applications is out of the question. By incorporating familiar UI (e.g. Facebook, Twitter, Blogger, etc.) into healthcare applications, users are far more likely to need little training and willing to use the applications thereby reducing support and operational expense for the providers. SaaS providers can easily provide role-based UI that shields the patient from the complexities of the application while providing other users (e.g. the physician’s office) with much more sophisticated UI for their needs.

Insurance Companies – Insurance companies also benefit from the SaaS model since it facilitates online connectivity and interaction between hospitals, providers and patients. Any time the process has to move from electronic to paper, which it does regularly now, there is operational overhead expense and the potential for error introduced into the process. If all participants are willing and able to participate electronically, costs and errors can be dramatically reduced.

While crowded, the HCIT market feels a lot like when we started Siebel Systems back in 1993. A lot of vendors – there were 300+ SFA vendors at the time. A very fragmented market – different companies solving different problems (e.g. SFA, Service, Support, Service, Marketing, etc.). No industry thought leader. Poorly-written applications without a comprehensive and extensible data model and application vision to address all functional business areas.

The Health 2.0 Conference reminded me of the SFA conferences held back in 1993 — lots of tiny booths staffed with people desperate to engage and sell their products. Keynotes and panels staffed with ‘experts’ who are well meaning and have domain expertise but without the experience and knowledge to create a multi-billion dollar industry, consolidate it and own it.

Based upon my recent observations, I think in spite of the hundreds of current HCIT companies there still exists an opportunity for an applications software company to emerge and own the HCIT market; one with a grand products vision yet with laser focus on solving a few key initial pain points using a SaaS-based model.

Since you need to be a member to read the full post, I have included the article in its entirety at the end of this blog post for your reading enjoyment.

I will wait for you while you read the article.

Welcome back.

Savinay makes several good points in his article. For example, I, too, believe that Cloud Computing will ultimately transform the way IT delivers computational and application services within the enterprise. And, one of the key drivers of this transformation – as with previous IT transformations  – is directly related to cost.

However, to make his point, he uses the analogy that Cloud Computing is similar to buying v. leasing a car and that this is a compelling reason for why IT will incorporate Cloud Computing into its operations. This is where he and I disagree.

Rather than buying/leasing a car, I believe that Cloud Computing is, instead, more analogous to hiring a taxi where the taxi driver/company is responsible for driving the car, managing the car as well as getting you from point A to point B. In exchange, you pay an agreed upon ‘rate’ for that service.

Whether you buy or lease a car, you (the customer) are still responsible for driving the car and managing the car (e.g. insurance, gas, mtce). However, when you hire a taxi you have transferred the burden of service delivery from your shoulders onto the shoulders of the taxi driver/company.

In fact, you will pay more (e.g. $ per mile) for the taxi service than if you drove yourself. However, by outsourcing the driving, you potentially derive multiple benefits: the driver may know a faster way to get to your destination, you don’t need to find parking, you don’t need to navigate traffic, and you are free to focus on getting other more valuable work accomplished during the amount of time you are in the taxi. And, it is a variable cost — you only pay for what you need.

Similarly, with Cloud Computing, you are transferring the burden of IT service delivery onto the shoulders of the Cloud Computing vendor such that the enterprise IT organization can focus on other more value-added issues. The Cloud Computing vendor is compelled to deliver a great product/application under an SLA with 4-5 9’s reliability, disaster recovery, 24/7/365 support. With IT departments shrinking daily, many are incapable of delivering comparable services at comparable (and variable) costs.

The fact that IT must increasingly do more with less resources and provide equal or better service at all layers – platform, infrastructure and application -  will ultimately be the driving force behind the Cloud Computing transformation. Yes, this normalizes out to ‘direct cost’ but the simple fact is that Cloud Computing vendors will live or die by their ability to deliver a compelling service that many enterprises have been simply ill-equipped to provide irrespective of the amount of $$ available in their budget.

*********************************************************************************************

Cloud Computing – Hype or Reality?

Guest Column by Savinay Berry, VP, Granite Ventures – PrivateEquityCentral.net

September 8, 2009

Cloud computing is the new “Web 2.0” of today’s tech world. Any company that remotely provided services associated with enterprise software now has products which have a “cloud” moniker attached to them – a phenomena seen not too long ago with Web 2.0, when a whole generation of companies doing fairly traditional Web-content development started calling themselves Web 2.0 companies. Given that both of these terms represent a set of related concepts spreading across software and hardware, the terminology has helped to guide a conversation in the right direction. Beyond that, many wonder whether the cloud is yet another tech trend caught up in a whirlwind of investment and media hype, or is it a model with real opportunity for market growth and success? What does cloud really mean? What are the components? And finally, where are the opportunities to invest? In this article, I will attempt to address some of these questions from an investor’s viewpoint, rather than from a technologist or management perspective.

To Buy or to Lease Is Really the Question….

One analogy to describe cloud computing is buying versus leasing a car. The first option (buying) is similar to the traditional license-based model of buying software, requiring a large lump-sum payment up front to cover the cost of the purchase and then running it on hardware that you own. The second option (leasing) is similar to running software on-demand on leased hardware. While the end-result of using the car is the same, the means to acquiring it are different. Consequently, the workflow and processes associated with leasing a car are different from that of buying a car (mileage constraints, geo constraints, payments, etc.). This analogy can be extended to cloud computing as well, where the end result of running applications with defined SLAs is the same, but the means to get to the application are different. Hence the workflow needed to access the application in a cloud computing paradigm is different – leading to the potential opportunity for innovation and investment.

To further illustrate this point, consider TurboTax, the tax preparation software from Intuit. Traditionally, over the last few years, if you wanted to use TurboTax, you went to the store, bought the CD, installed it on your desktop or laptop’s hard drive and then prepared your taxes. Cloud computing enabled Intuit to develop TurboTax.com, where users could easily log-in to the site, enter their information and file their taxes – without having to purchase any CD/software. Let’s walk through the costs associated with both of these workflows.

In the first case, the company (Intuit) will incur the cost of making the CDs, packaging them and finally shipping them to retailers. The retailers will markup the costs to make their margins, and finally you – the end user – will buy the software package at the store. In the second case, the company will setup TurboTax.com, and enable enough servers on the back-end (possibly by leasing them) to support peak load given the seasonal demand for filing taxes and establish monitoring software to ensure that the site is up and running all the time. Given the current access costs for leasing servers ($0.08 – $0.15/hour) and the relatively low amount of data that needs to be accessed (there are no video or pictures in a tax filing), the company (Intuit) will incur much less costs-per-user to serve the customer. In turn, Intuit will pass this cost savings to the customer, which clearly shows in the pricing – a CD-boxed version of TurboTax costs anywhere from $49 and up, while the online version costs $35 and up. This savings for the end user creates an opportunity for companies to capitalize on specific aspects of cloud computing.  One caveat to this example is the potential growth in the internal cloud – which is a concentrated collection of servers either managed by a third party or operated as a separate business within a company. An internal cloud does not follow the lease model, since the hardware is owned by the enterprise, but it does follow the re-use tenets defined by the external cloud, which leads to similar or better efficiencies. Investors are paying attention to this sector for both internal and external clouds, as explicit consumer interest has a direct impact on driving new markets.

An Evolution in Computing: Lower Cost and Less Time Leads to Market Change

Before going further, it is helpful to review the evolution of enterprise infrastructure over the last several decades and how that innovation has helped both enterprises and consumers. The earliest implementation of computing was in a mainframe environment, which gave way to client-server. Client-server continues to be dominant today, but several evolutions on top of the client-server architecture created more efficiencies. For example, SOA and virtualization created opportunities to re-use both software and hardware resources more efficiently. Finally, the extension of the data center directly led into the cloud, which provides a way to utilize the best aspects of both virtualization and SOA, as well as take efficiency and reuse to the next level.

Within this entire evolution, two attributes were catalysts of change: cost and time to deployment. It turns out that these are the two most important tenets of IT managers as they grapple with the increasing number of choices for implementing enterprise infrastructure. Given the rise of cloud service providers like Amazon, Google and Rackspace, the IT departments within enterprises will be challenged to stay relevant and will try to turn themselves into service-delivery platforms, rather than pure cost centers purchasing hardware. Thus, from an enterprise’s perspective, the cloud is essentially providing an impetus for IT managers to re-evaluate their infrastructure and invest in proactive changes, which forms a credible opportunity for innovative startups in this space. To provide a perspective on the size of the market, in 2008, $870 million were spent on server management software alone, with the spend on this market expected to increase to $2.3 billion by 2013, according to the 2009 IDC report on cloud computing.

The Architecture and Opportunity behind the Cloud

Now that we have established the cloud computing impact from both a consumer and an enterprise standpoint, let’s go into more detail on the architecture of cloud computing and where some interesting opportunities for investing may lie. At the core, cloud computing can be divided into three layers: infrastructure-as-a-service, platform-as-a-service and software-as-a -service.

Infrastructure-as-a-service (e.g., hardware services like the ones from Amazon, Rackspace, GoGrid) will eventually get commoditized and platform-as-a-service is an area that will need the most work from established companies like Google, Microsoft and Amazon. However, the area of software-as-a-service will be ripe for innovation.

Specifically, as applications like Google documents, mobile apps, Salesforce.com, and others shift into the cloud, services driving these applications will be essential. Some examples of these services are databases, billing, analytics and security. Broader adoption of cloud computing within the production environments of companies like Pfizer and ING – where data security is critical – will not happen unless a robust end-to-end security solution exists in the market. Such opportunities will help to create a large and growing market for potential investments in the cloud computing sector.

Since I expect that the future IT environments will be a hybrid implementation of both internal data centers/cloud and external cloud, various tools will be required to ensure that applications, images and databases can be transferred from one resource to another without losing context, policies and security. The need for this “cloud brokerage” will create a category of companies for these management tools. Fundamentally, these tools will adapt existing functions in data centers, like resource planning, provisioning, applications management and transaction profiling, into services catering to the distributed and flexible nature of the cloud.

Finally, due to the potential commoditization of cloud infrastructure (e.g., Amazon Web Services, Google, Rackspace), companies may want to get the best pricing structure depending on time-of-day use, similar to the concept of energy usage on a time-of-day use in states like California. A third-party marketplace providing an arbitrage opportunity for enterprises to shift images from one cloud to another could be an interesting opportunity; however, this vision will not materialize until enterprise adoption of the cloud architecture reaches a critical mass.

By now you can probably establish that while the term “cloud” has a certain amount of hype associated with it, once you peel away the layers and dive in, opportunity is waiting.  The cloud represents investment opportunities and a potentially robust market positioned to change the way enterprises conduct business. The only question remaining is when this market will ripen, rather than if it will ever come to be.

Savinay Berry is a vice president at Granite Ventures (www.granitevc.com), an early-stage venture-capital firm that invests in innovative software, services and communications companies. He received his M.B.A. from the Kellogg School of Management and a Master’s in Engineering Management degree from the McCormick School of Engineering & Applied Sciences, Northwestern University. He holds a Master’s of Science degree in Electrical Engineering from Michigan State University and a B.S. degree from the University of Pune, India.

While at the application level, it’s easy to view Salesforce.com as the star of that sector, it gets a little murky as you move to other functional areas of the front and back office as well as down the overall cloud ’stack’. As with most nascent markets,  the market is highly fragmented: CoLo/Managed Services (e.g. Rackspace, OpSource, many others),  Infrastructure/Platform (e.g. Amazon, Salesforce.com, VMWare, many others), Tools (e.g. Salesforce.com, Corent, Serena, SAP/Coghead, many others), and some a mixture of 2 or more areas (e.g. Salesforce.com).

To make some sense of the trends, I attended a presentation last year by Bill McNee who is an industry analyst with Saugatech. I thought he did a particularly good job breaking the market down into sectors, segments and strategies. Here were some of his observations and predictions he shared with respect to the growth of cloud computing and SaaS at that time:

1. Core systems of record (e.g. Finance, HR and BI/EPM) are growing rapidly – both SMB & Enterprise are adopting.
2. International is beginning to grow.
3. Standalone applications is Wave 1, International is Wave 2, Workflow/Collaboration is Wave 3 and Measured/Monitored/Managed business processes are Wave 4.
4. Platforms are beginning to proliferate.
5. M&A will accelerate.
6. Customer satisfaction is generally quite high with high annual renewal rates.

Bill went on to say that their data showed that 70% of the companies with >100 employees would deploy at least 1 SaaS-based application by 2012. And, he believed that one of the biggest market opportunities would be SaaS-based BI/CPM which in 2008 represented about 17.3% market share and would grow to 40.7% by the end of 2010.

He also predicted that SaaS-enablement would lead to cloud development — which indeed is occurring. Salesforce.com’s announcement of Force.com last year and its latest quarter’s growth from that business is proving this out. In addition,  with acquisitions by companies such as SAP with Coghead last year and VMWare with SpringSource this quarter, we are now beginning to gain a sense for how this may play out.

For traditional software companies in the fight for ‘cloud’ leadership, the overriding issue that remains is the hostile business model that SaaS/cloud computing presents. Wall Street measures these companies by in-quarter revenue growth and margins. Deferred revenue and in-quarter expense are antithetical to those models. With Salesforce.com, they have been successful in selling to the Line of Business and primarily SMB’s (that’s where 90%+ of their business still resides). Selling a Platform/Tools to IT and larger companies is a big departure from that success. However, they recently hired some big sales hitters from Siebel Systems to help address that issue.

Here is some other data Bill shared with us based upon their market research polls:

1. 40% of large enterprises will seriously consider SaaS-based ERP, HR, order management, and procurement solutions.
2. 30% will choose a new next gen SaaS solution provider
3. By 2012, only 20%-40% of software will be sold under traditional perpetual license model

In support of this data, I  think we are beginning to see SaaS break into the back office — initially in SMB — just as Salesforce.com did with its CRM applications. Companies such as Host Analytics, SmartTurn, and Adaptive Planning are beginning to make  progress in an area that has traditionally gone unserved by the large enterprise ERP suppliers such as SAP, Oracle and Manhattan Associates.

However, even though we are beginning to see where companies are picking their spots to compete in the cloud/SaaS space, identifying the future master brand(s) out of this fragmented market is challenging. I would say, though, that the comments I made in a blog I wrote early last year titled “Global Market Leadership” are still germane to becoming the next ‘master brand’.  It may be one of the existing competitors we know about today or, in fact, it may come from a new entrant we have not yet seen.

That’s what makes this market so exciting.

I really enjoyed working with Cary because he acted as a member of my management team; he first focused on the business objectives I wanted to accomplish and then applied law to help me accomplish those objectives. He also helped me negotiate through a minefield of sticky issues like Vendor Specific Objective Evidence (VSOE) for revenue recognition and managing SLA issues.

Cary now has his own legal practice, Platkin Law,  and one of his specialities is helping SaaS startups. I asked Cary if he wouldn’t mind addressing a number of common legal issues that SaaS companies are faced with and he was kind enough to oblige.

Bruce:  What key terms should a SaaS Agreement contain?

Cary: SaaS agreements are typically subscription services agreements that address key customer concerns with service levels, security, privacy, and ultimately performance.   

More detailed SaaS-specific issues include: how mid-term add-on user subscriptions are handled; the details of the renewal process; whether support is bundled in or extra; what usage rules apply to your users; and how third party services are made available through your service.

There are many ways to address these issues depending on your particular business, but one thing is clear – SaaS providers need to ensure their hosting and other services vendors are providing “back-to-back” terms for the terms being offered to customers. 

If you use outside vendors to provision your service, it is critical that you secure the same or better terms from your hosting vendors than your customers will seek from you.   If your vendor doesn’t back you up on the commitments you’ll need to make, you’re really out on a limb.  On one hand, you might choose to manage your risk tightly by seeking a one-off exception from the hosting vendor, but this can slow the sales cycle.  On the other hand, you might choose to accept the risk, close your sale quickly, and make contract commitments that your hosting vendor cannot or will not back up.

Sometimes the risk is merely a matter of numbers that you can easily analyze.  For example, say your SLA is 99.9% with one day of credit for each one hour of downtime.  Your vendor has agreed to provide you the same basic SLA and credit, so you feel comfortable with that arrangement.  But what if a good handful of customers demand 99.99% and two days of credit for each one hour of downtime?  Your risk is merely the delta between the coverage you have from your vendor and the commitment your customers want you to make. 

Crunch the numbers and cross your fingers.

Sometimes the risk is more cut and dry.  For example, say your customer insists it must be permitted physical access to the hosting facilities and full access to the detailed SAS 70 Type II security audit reports on the hosting facilities.  If your hosting vendor limits physical access to its facilities and restricts your right to distribute the revealing audit reports (both common security measures), then promising these things to your customer is simply not possible without an exception from the hosting vendor.

So as you develop your contract terms early on, anticipate your customers’ demands, think through the details, and insist that your vendors get on board with your business and your customers’ needs.

Bruce: Speaking of SLAs, should a SaaS company offer a Service Level Agreement, and if so, what are the key terms they should spell out in the SLA?

Cary: Whether to provide an SLA or not is a business decision based on customer demands and competitive landscape.  Obviously, if you can avoid making a commitment, most lawyers will tell you that’s a good thing.

However,  I think SLAs are a critical element to successfully market a SaaS offering, and more and more, SLAs are required to adequately compete with both on-demand and on-premise alternatives.  If your SLA is world-class and you can make your current performance metrics constantly available to customers, your customers will appreciate it, even if your system goes down from time to time.

There are many types of SLAs, so the first question is what are you going to measure and commit to?  Support levels (response times for support tickets) and system availability are minimum requirements for today’s SaaS offerings.  You might also offer SLAs around reliability — number of outages or time between outages — or response time for your system’s ability to turn around input and output.  Beyond that, I think it can be a bit difficult to offer accessibility, performance or scalability SLAs because there are so many factors that contribute to these issues. 

In any event, most customers want the availability SLA and the performance warranty to run in parallel, so if the system is down for an extended period of time, the customer can max out its SLA credits, and still terminate the contract for breach of warranty if you are ultimately unable to fix the system.

When drafting your SLA, describe in great detail:

• the definition of metric being measured (availability, reliability, etc.); 
• how the SLA percentage is calculated;
• the permitted exclusions to performance, including scheduled maintenance, customer-caused problems, and other issues outside of your control; and
• how credits (or refunds) are calculated and applied to customer accounts.

One tip about credits:  don’t over-do it.  The biggest and best SaaS providers experience downtime events on a regular basis.  No one expects dial-tone availability, and you probably only marginally better than the customers’ own internal IT staff.  You don’t want one or two events to wipe out your business.  One day of credit for each hour of downtime is typical, but only after the system has already fallen below your target availability level and only for use with renewal terms.

Bruce: What terms do you feel should never be in SaaS Agreements?

Cary: I have been encouraging my clients to hold the line on accepting unlimited liability for confidentiality breaches. 

While security of the system and privacy of the customer data are critical customer concerns, you are not Fort Knox.  You can and should use the same type of security measures that other vendors in the industry use.  But if a hacker gets in despite these measures, is it really fair to hold you fully responsible for the damages?  If you said “yes,” then you agree that your monthly subscription fee is adequate to cover not only software and hosting services, but unlimited insurance against this common business risk.  Assuming you were able to buy insurance for this risk, how much do you think unlimited coverage would cost you?   Some multiplier of fees paid, up to a comfortable cap in the high 6 or low 7 figures, is probably adequate to close most transactions – why accept more and put your entire business at risk for something no one can absolutely guarantee?

You might be surprised to learn that other terms that might not be necessary in your SaaS subscription agreement are traditional software license terms.  If your offering is a pure multi-tenant hosted offering without any local client for the customer to use, then you are merely providing access and use of a service.  You are not licensing software in the manner most customers are accustomed to.  This is a subtle but important distinction for your template subscription agreement – SaaS is easier to sell when you continually reinforce the notion that this is not a software license plus associated hosting and managed services.  Rather, it’s a subscription service that is offered the same way to every subscriber.  There’s no delivery of software, no need for source code escrow, and most importantly for the multi-tenant solution, no custom hosting services terms often found in ASP or managed services agreements.  

Bruce: How should a SaaS company set up its Agreements from the beginning so it can avoid revenue recognition problems downstream?

Cary: I am not an accountant so I can only speak to the kinds of terms clients have told me are important to them.  First, SaaS providers know that revenue recognition is one of the great barriers-to-entry for publicly-traded enterprise software companies.  This is because subscription services revenue is recognized ratably over the life of the agreement as the services are performed, which runs contrary to the up-front revenue recognition model of traditional  software license deals.

Pure play SaaS providers build stable annual revenue streams that end up being more predictable.  So, the key to success with subscription agreements is to do all you can to keep the revenue flowing and renewing.    

Although revenue is recognized differently, accountants tend to care about the same issues that arise with standard software and services:  

• Acceptance terms should be avoided (the free 30-day trial and smaller up-front start-up costs have made this easier for customers to bear);
• Payment terms should not be extended too far into the future;
• SLAs should be achievable and warranties should be “documentation” based; 
• remedies for breach of these commitments should be credits on future services only, no refunds of fees paid;
• termination for any reason should result in refund of unused prepaid fees only, not fees for services rendered prior to the date of termination.
• future product commitments should be avoided. 

Bruce: What about multi-year Agreements? Should companies execute multi-year Agreements? If so, for how long?

Cary: Multi-year agreements are great for business — I haven’t met a person selling SaaS yet who preferred short-term subscriptions.  Multi-year contracts are typically procured through the use of higher discounts on fee that are paid annually in advance (or for unconvinced customers, quarterly in advance for the first year and annually thereafter). 

Customers being customers, they love discounts, but hate commitments.  So, I usually recommend terms that require the customer to pay the delta between the discounted multi-year rate and the higher short-term rate in the event it terminates the subscription mid-term or at the end of the shorter term.  SaaS providers with better leverage might even suggest some percentage of terminated subscription fees (up to 20%) as an early termination fee.

Bruce: If a SaaS company is planning to handle customers/data from the U.K./Europe/Asia, will they need make any special provisions?

Cary: This is a very complicated question that depends on many factors including where your company is incorporated, where your data centers and support staff are, where your customer is, where their end users are, what kind of customers they are, what kind of data they are uploading to your system, etc.

The easy answer is if you are a US company that has been selling to US customers, and you are suddenly selling into international markets, you should probably seek knowledgeable US or local counsel to work with your finance team to iron out required terms.

The most common issue that US SaaS providers face early on is Safe Harbor certification.  Many EU customers will not do business with a US company holding personally identifiable information unless it warrants that it complies with the UE-EU Safe Harbor framework.  Participation in this program requires annual self-certification that your company complies with security and privacy standards set forth by the US Department of Commerce at www.export.gov/safeharbor.  I do caution clients not to over-commit to the customer here – EU customers have their own requirements to comply with privacy regulations.  When you are holding and processing data on behalf of your EU customer, you can only really commit to security terms, but issues related to the direct relationship between your customer and its individual end customers can only be managed by your customer.  A simple example:  if privacy regulations provide that the individual should have the ability to “opt out” of marketing programs that use their personal information, only your customer can manage this obligation, so it is not likely that you are in a position to help or hurt their compliance with this regulation.

Bruce: Are there simple things  a SaaS company can do develop a easy, scalable contracting process?

Cary: Perfecting the contracting process is often overlooked, but it can have such an important impact on close rates, cash flow, and customer satisfaction.  From a legal perspective, the easiest thing you can do to close contracts quickly is to use fair, industry standard terms that meet or exceed your customers’ expectations.  For each term in your subscription agreement, you should know not only the industry standard and your customers’ expectations, but also how much risk you are willing to tolerate.  Your law firm’s standard software or services agreement probably won’t do here.  You really need to think through each of the issues, or you’ll learn the hard way as customers begin to question certain provisions with each new deal.

 From an operational perspective, you’ll want to use an automated contract management system that integrates with all of your company’s workflows.  As such, you should solicit input from all of the company functions that touch this important process:  sales, sales operations, finance, legal, provisioning, and support.

If the offering is marketed to the low-end of the SMB market, then an online transaction system with a posted click-to-accept subscription agreement is ideal for an easy, scalable solution.  However, this is rarely sufficient for my clients – even if they can use an ecommerce system, there are always clients who want to negotiate terms or even use their own agreements.  So there has to be an exception process, and an 80-20 goal (or better) of closing as many deals as possible without business or legal exceptions.

I find that the best contracting structure for most SaaS companies is a simple page or two order form generated out of a sales order processing system.  The order form should contain all the applicable customer information, products and pricing being purchased, and a space for one-off terms applicable to the deal (future discount provisions, early termination rights, etc.).  And most importantly from a legal perspective, it should state that acceptance of the order form (by signing the form, emailing acceptance, or issuing a PO) constitutes acceptance of your posted subscription agreement (including the URL).  The posted subscription agreement can in turn reference other posted policies such as support policy, SLA, security policy, etc.  You should have a Word version of the subscription agreement and the related policies available for prospects that request the ability to redline.

Finally, your lawyer can help you minimize legal fees for negotiations by helping you prepare tools that empower non-lawyers to close deals with standard exceptions.  These tools may include:

• a list of regularly-used alternative business and legal terms,
• a “playbook” that describes the purpose of the various clauses in your contracts and provides alternatives,
• an approval matrix to ensure that the right people around the company are approving exceptions to standard terms.

* * *

Legal Disclaimer.  The materials available at this web site are for informational purposes only and not for the purpose of providing legal advice. You should contact your attorney to obtain advice with respect to any particular issue or problem. Use of and access to this Web site or any of the e-mail links contained within the site do not create an attorney-client relationship between Platkin Law Offices and the user or browser.