The Missing SaaS Metric – Customer Retention Cost

A few months ago, on a quiet Sunday, I was reading through some of my board decks getting prepared for the upcoming board meetings.

A common theme among all of those decks was a section on churn and the impact it was having – both positively and negatively – on my portfolio companies. Some of those companies, fortunately, are experiencing negative churn as their customers increase the footprint of the portfolio company’s technology.

I got to thinking about this issue.

We have a significant number of metrics we use to measure top of the funnel health for our companies that use a SaaS business model – Customer Acquisition Cost Ratio (CAC Ratio), Customer Lifetime Value, Churn, etc. These are tried, tested and proven metrics management teams and investors use to evaluate how well a company with a recurring revenue model is performing.

However, with churn  a critical component of the SaaS model, I asked myself, “Why don’t we have a common metric to measure the health of the bottom of the funnel?”

Key questions are:

  • Shouldn’t we know how much we are spending to retain a customer?
  • At what point should we “fire” a customer?
  • Should that point vary by industry or type of customer?
  • When should we parachute in our “customer success” teams?

It seemed to me that if we have a Customer Acquisition Cost metric, shouldn’t we have a Customer Retention Cost (CRC) metric and what would be the elements we would use to measure the CRC and CRC ratio?

So, I put together a bunch of thoughts on what should go into the calculation of such a metric and sent that over to one of our portfolio companies – Totango.

Totango provides a customer success platform. Software companies and others use their platform to determine whether or not a customer is deriving value from a software product. This enables customer success teams to “parachute in” and help a customer derive value from the vendor’s software product and mitigate a key issue associated with churn.

Given they are “in the business of reducing churn”, it seemed to me only natural that they take my initial concepts, flesh them out,  and launch the CRC  and CRC Ratio metrics into the industry as a whole.

I am happy to report they have done that with a fantastic white paper on the subject. I would encourage anyone dealing with churn/retention, to read this paper and add to the conversation.

The CRC and CRC Ratio are not metrics to be owned by any one individual or company. They need to be owned by the industry and your contributions are welcome.


The Corporate Organizational Structure of SaaS


Recently, I had someone ask me how they might think about the organizational structure of their SaaS startup.

Here are some lessons I learned over my 25 years working on the operating side in what started out as small, private start ups (Oracle and Siebel Systems ) but turned into large companies – along with my experience working with many early and mid stage SaaS companies as an investor.

  1. Who the CEO elects to have as direct reports tells customers, employees, business partners, and shareholders what matters to her/him and what she/he believes is critical to the company to succeed. So, choose your reports carefully as you are signaling to a lot of people what is important to you.
  2. More layers between the CEO and the people who execute the business model can slow down decision making and reduce the speed of execution of the company. I have found that lackluster execution is what usually kills most start ups. CEOs are usually CEOs because they have excellent intuition and the ability to analyze data and make good decisions quickly. Relying upon others to “interpret” data and report on it may slow down and introduce sub-optimal decision-making (subjective decisions by lower level staff that may not be as experienced as the CEO or have ‘political’ agendas).
  3. The people who are responsible for executing the business model should be direct reports to the CEO. For a SaaS business model, this means the following:
    1. VP Marketing – responsible for the initial creation of revenue through demand generation (top of the funnel) and “future” revenue; revenue from future sales periods.
    2. VP Sales – responsible for delivering “in period” revenue via direct sales – inside and field sales
    3. VP Support – responsible for ensuring the product works as marketed/sold
    4. VP Service – responsible for implementations – if critical to the success of converting “contracted” MRR to “realized” MRR as projects are delivered
    5. VP Products – responsible for specifying a complete product that meets market requirements
    6. VP Engineering – responsible for building and delivering a complete product
    7. VP Customer Success – a “new” exec position critical to the SaaS model responsible for the bottom of the business model funnel – I wrote about this role previously in my blog . This role is responsible for making sure customers are happy and using the product every day (1 customer success rep for every $1M ARR is best practice). New products such as Totango are this function’s new “system of record” and the CEO’s window on usage metrics which is critical for renewals and reduced churn. You spend a lot of $ to acquire customers (CAC ratio), you need to make sure they stay as customers or the SaaS model falls apart.
    8. VP Finance – among many things, responsible for the accounting and collection of revenue
    9. Optional – VP Alliances/BD – if you need to interface with many different ISVs to deliver a complete solution
    10. Optional – VP Channels – if indirect sales is a key part of your business model

In my experience, a CEO and/or a GM,  should be able to handle 7-10 direct reports if each of those reports are A players and run their organization effectively.

In terms of process, what worked best for me as a divisional GM – modeled after successful executive staff meetings I was a part of – was a weekly meeting where each of my direct reports was required to cover what was accomplished the prior week and what was expected to be accomplished the following week — along with the usual review of revenue forecasts and financials.

Typically, for the forecast, we covered key deals for the quarter, and a WEB (Worst, Expect, and Best) revenue number and the critical elements required to achieve the forecast. By having all the functional leads in the room, we could quickly surface issues – product, deal terms, support issues, etc. – and collectively put together a plan of action to resolve them.

During each weekly meeting, as issues materialized, we generated a “resolution plan”, assigned owners and due dates and then reviewed the issues captured in the plan each week until they were resolved.

Each week at the overall Exec Staff meeting I attended, I covered the major metrics generated from my division’s weekly staff meeting.

These things worked for me so perhaps they will be helpful to you as you think through the optimal structure for your organization and its decision-making.

Why “Organizational Behavior” Was My Most Important Collegiate Course

I didn’t know it at the time. In fact, when I took it, I thought it was a complete farce.

Maslow’s “Hierarchy of Needs”? Are you kidding me?

I was majoring in Engineering and taking calculus, physics, chemistry…you know, the serious stuff meant for serious students. But, to graduate within some reasonable amount of time (where “reasonable” was defined by my parents), I needed some additional elective units. So, I decided to take one of the only classes that wasn’t already filled and would satisfy the requirements for me to graduate; this turned out to be a class called,  “Organizational Behavior”.

I looked up the description of Organizational Behavior which read something like this:

“The study of the way people interact within groups. Normally this study is applied in an attempt to create more efficient business organizations. The central idea of the study of organizational behavior is that a scientific approach can be applied to the management of workers. Organizational behavior theories are used for human resource purposes to maximize the output from individual group members.” Source:

“Oh my god!”, I thought. “Is there any way I can get out of this boring, irrelevant class? Is this a legitimate/real subject?”.

Fusing Collaboration Into Enterprise Applications – Enabling the “Real” Social Enterprise

I, along with many of you, have been watching the evolution of enterprise internal collaboration products/companies such as Yammer, Chatter, Jive, and Cubetree over the years.

I was an early investor in Cubetree which was acquired by SuccessFactors and then became part of SAP when SAP acquired SuccessFactors a short time later. SAP has since renamed Cubetree to SAP Jam and it now serves as the backbone to SAPs collaboration strategy.

These products are supposed to mitigate – eliminate ? – the need for email within the enterprise and dramatically improve internal collaboration offering far easier and superior ways to capture and share information v. email/spreadsheets, etc.

However, if you can get the product managers and/or CEOs of these product/companies to speak candidly off the record, with rare exception, the adoption level of these products has been far less than the creators and the companies that purchased these solutions had hoped for.

Why? I have a simple thesis.

The Affordable Care Act – A Potential Solution to Assist Enrollment

Let me start off by stating that I find the Affordable Care Act (ACA) — known more commonly as Obamacare — to be objectionable.


Not because I disagree with some of its intentions; I am actually in favor of eliminating discrimination for pre-existing health conditions and the ability to keep children on the parent’s health plan until 25.

The problem I have with it is that healthcare isn’t currently a right granted by the Constitution. And, the ACA approaches healthcare from the standpoint that it is something we are all entitled to.