Kellblog covers topics related to starting, managing, leading, and scaling enterprise software startups. My favorite topics include strategy, marketing, sales, SaaS metrics, and management. I also provide commentary on Silicon Valley, venture capital, and the business of software.
In looking at this issue across several companies, I’ve noticed a disturbing trend / missed opportunity in how many SaaS companies classify the reason for customer churn. Roughly speaking, if companies were hospitals, they’d too frequently be reporting the cause of death as “stopped breathing.”
Yes, the patient who died stopped breathing; the question is why did they stop breathing. In churn-speak, “yes, the customer who churned issued a churn notice and chose not to renew.” The question is why did they choose not to renew?
Many people have written great posts on reasons customers churn and how to prevent them. These reasons often look like hierarchies:
Product ease of use
Oversold / poor fit
These hierarchies aren’t a bad start, but they aren’t good enough, either. A new sponsor isn’t an automatic death sentence for a SaaS product. He or she might be, however, if the team using it had a rough implementation and was only half-satisfied with the product. Similarly, a failed implementation will certainly reduce the odds of renewal, but sometimes people do have the will to start over — and why did the implementation fail in the first place?
(And, at the time, literally observing that it was a better way to classify churn.)
The rule above spells it out quite clearly — “DO NOT enter terminal events such as respiratory arrest […] without showing the etiology.” That is, “stopped breathing” by itself isn’t good enough. Just like “sent churn notice” or “decided not to renew.”
I have not built out a full taxonomy here; classifying churn in this way remained a future item on my to-do list at the time we sold my last company. Nevertheless, while I know it’s not easy, I believe that companies should start trying to find a way to richly encode churn reasons using this “chain” concept so as to not lose critical information in encoding their data. Otherwise, we risk believing that all our customers churned because they sent us a churn notice (or some easily blamed “uncontrollable” event).
As one example:
Churned, due to
New sponsor, due to
Failed implementation, due to
Partner problem, due to
Churned, due to
Corporate edict, due to
M&A, due to
Product dissatisfaction, due to
Oversold, due to
These aren’t perfect, but I’m trying quickly demonstrate the real complexity behind why customers churn. For example, happy customers might challenge a corporate edict issued after an acquisition — so you can’t just blame the edict. You have to look more deeply. If you knew that the customer fought the edict and failed, you might stop the chain there. But if you knew they were never terribly happy with the system because they were overpromised capabilities at the start, then you should code that into the chain, too.
# # #
For more information on the warning signs and symptoms of a stroke, go here.
Enterprise SaaS has drifted to a model where many, if not most, companies do multi-year contracts on annual payment terms. How did we get here?
Most enterprise SaaS products are high-consideration purchases. Buyers typically perform a thorough evaluation process before purchasing and are quite sure that the software will meet their needs when they deploy. These are not try-and-buy or wing-it purchases.
Most SaaS vendors will jump at the opportunity to lock in a longer subscription term. For example, with an 85% gross retention rate you can offer a 5% discount for a two-year contract and end up mathematically ahead . Moreover, with a default annual increase of 5 to 10% built into your standard contact, you can offer a “price lock” without any discount at all (i.e., the customer locks in the price for two years in exchange for a two-year commitment).
When you combine the vendor’s desire to lock in the longer term with the customer’s belief that the solution is going work, you find a fertile ground for doing two- or three-year contracts. But these multi-year deals are almost always done on annual payment terms.
Most SaaS vendors don’t want to take the next step and ask for a multi-year prepayment. The upside for the vendor would be to eliminate the need for collections in years 2 and 3, and eliminate the chance that the customer — even if unhappy — won’t make the out-year payments. But most vendors refrain from this because:
It’s seen as an unusual practice that’s frowned upon by investors
Most investors believe you could better maximize ARR by simply raising more capital and sticking with annual payments
It can lead to lumpy renewals and cash flows that are both hard to manage and understand
It can lead to large long-term deferred revenues which can hinder certain M&A discussions. (Think: large balance of cashless revenue from suitor’s perspective.)
It complicates the calculation of SaaS metrics, sometimes confusing investors into believing that good metrics are bad ones. (I think I am literally the only person in Silicon Valley who is quick to point out that a 75% three-year retention rate is better than a 90% one-year one .)
Thus, we end up in a situation where the norm has become a two- or three-year contract with annual payments. This begs a seemingly simple “if a tree falls in the forest and no one hears it, did it make any noise” kind of question:
Quick, what’s the difference between a one-year contract that’s renewing for the first time and a three-year contract that’s coming up for its first downstream annual payment?
I’ve often quipped that they’re both “renewals,” but in the former case they’re handled Customer Success and in the latter they’re handled by Legal. 
But let’s be clear, regardless of the process you use to manage them , they are not the same, and should not automatically be treated as such for the purposes of calculating SaaS metrics. One is the voluntary renewal of a subscription contract; the other is the payment of a contractual commitment.
If you don’t want to renew your subscription, there’s nothing I can do to force you. If you don’t want to make a contractually committed payment I can sue you.
Let’s consider an example. We have six customers, Alpha through Foxtrot. The first three did one-year deals, the second three did three-years deals. The simple question is: what’s your gross dollar retention? A merely acceptable 83% or a very healthy 95%?
If you calculate on an available-to-renew (ATR) basis, the rate is 83%. There were 300 units up for renewal and you renewed 250 of them. If you include the payments, the rate is 95%. 1,050 units were up for renewal or payment, and you invoiced 1,000.
This is a case that feels a little bit wrong both ways. Including the payments uplifts the rate by mixing involuntary payments with voluntary renewals; to the extent you want to use the rate as a satisfaction indicator, it will be over-stated . However, excluding the payments seems to fail to credit the company with the auto-renewing nature of multi-year deals.
One thing is clear: payments certainly cannot be included in any ATR-based rate. You cannot view making a contractually required payment as the same thing as voluntarily renewing a contract.
I have an issue, which is highly subjective, when it comes to out-payments on non-prepaid, multi-year deals:
On one hand, I can argue they are contractual commitments that the vast majority of customers will honor and thus are effectively – save for a few rare cases – identical to prepaid multi-year deals. Think: the money’s good as in the bank.
On the other hand, I can argue that a dissatisfied customer – particularly one who blames the vendor and/or the software for their failure – will not want to pay, even if the contract says they’re supposed to. Think: it’s a toothless contract that the vendor will not likely not enforce against an angry customer.
Philosophically, I can argue that these out-year payments are either “good as in the bank” or I can argue that they’re “basically renewals that will ‘churn’ if the customer is not happy.” The first argument says to treat them like prepaid multi-year deals and put them in ARR-based retention rates. The second argument says they’re effectively voluntary renewals and should be counted as such.
In reality, you need to know what happens at your business.
I believe for the vast majority of businesses, customers honor the contracts and we should treat them like prepaid, multi-year deals in ARR-based rates — and you should always publish in parallel ATR-based rates, so people can see both. However, if your company is an outlier and 10% of those payments are never collected, you’re going to need to look at them differently – perhaps like renewals because that’s how they’re behaving. Or get better lawyers. Or stop doing non-prepaid, multi-year deals because, for whatever reason, your customers are not honoring the commitment they made in exchange for you to give them a price lock.
# # #
 Over 2 years you get 190 units versus an expected 185. (Not counting any expansion.)
 Or, really, Accounts Receivable but that doesn’t sound as funny.
 I’d argue that when you define your customer success process that you should treat these two customers identically. Whether it’s a payment or a renewal, in a good customer success process you should constantly monitor customer progress with the hope that the renewal (or the payment) is not some big decision, but merely incidental. (“Yes, of course, we want to keep using the software – is it just a payment year or do we need to renew the contract?”) This might increase your cost to renew a bit – because you’ll be paying CSMs or renewals reps to do collection work that could theoretically have been done by Accounts Receivable – but it’s still the right answer if you want to maximize ARR.
 While payment does not necessarily indicate satisfaction, it probably does indicate the absence of intense dissatisfaction.
 e.g., I’d use the the churn rate (1 minus the retention rate) as the discount rate in a present value calculation.
Since we’re now officially in 2019 planning season, I’ve been thinking about — among other things — our Customer Success model for next year and talking with friends in my network about that. Since Customer Success is (sadly, perhaps) still a relatively new discipline in enterprise software companies, I’d say the whole field is evolving quickly, so it’s important to keep up with the changes.
In this post, I won’t approach things from a Customer Success Model perspective and how Customer Success interfaces to Sales (e.g., hunter/farmer, hunter-in-zoo, farmer-with-shotgun, account manager) . Instead, I’m going to look bottom-up at the three basic types of customer success manager (CSM). While they may share a common job title, CSMs are often cut from very different cloth. Regardless of which model you implement, I believe you’ll be working with individuals who fall into one of three basic types to staff it.
In order to characterize the three types clearly and concretely, I’m going to use a template — first, I’ll show how each type introduces themselves to a customer, then I’ll present fragments of typical conversations they like to have with customers.
Note here that I’m talking about people, not roles. In defining Customer Success Models you map people to roles and roles to duties . In this post I’m really writing about the nature of the CSMs themselves because — all other complexity aside — I think the people pretty naturally drift to one of three types.
The art of setting up the right Customer Success Model is to clearly map out the sales and CSM roles (who does what), define the appropriate frequencies (how often do they do it), and then put the right people in the right roles — both to maximize job satisfaction as well as performance  .
The Product-Oriented CSM
Introduction: “Hi, I’m Jane, and my job is to ensure you get best use of our products. I’ll be here to keep an eye on your implementation process and to answer any technical questions that go beyond normal technical support. I’ll also perform periodic, proactive ‘health checks’ to ensure that you are using the system properly and making best use of new features. I’m an expert in our products and previously worked at a consulting shop helping people implement it. I’m here if you need me.”
Conversations they like to have:
“How’s that report working that I helped you build?”
“Yes, there are two ways of solving that problem in the product, let me help you pick the right one.”
“So you’re having some issues with performance, let me get in a take a look.”
The Process-Oriented CSM
Introduction: “Hi, I’m Joe, and my job is to make sure you are happy with our service and renewing your contract every year. I’ll drive the renewal process (which, you should note, starts about 4-6 months before the subscription end date), monitor your adoption of the service, ask you to complete our ongoing customer satisfaction surveys, inform you about local user community events, and proactively call you about once a month to check-in. Should we hit a rough patch, I’ll also serve as your escalation manager and pull together the right resources across the company to get you successfully through it. I’m a very organized person — I was a project manager in my prior job — and I can manage 10,000 things at once, so don’t hesitate to call — I’m here if you need me.”
Conversations they like to have:
“Have you guys budgeted for next year’s renewal — and by the way don’t forget to leave room for the annual price increase?”
“I see you hired a new CFO, do you think that’s going to have an impact on our renewal process and can we setup a time to meet her?”
“We’re having a training class on new features in the November release and wanted to make sure you knew about it.”
“You’ve got two tickets stuck in technical support? Let me swing over there and find out what’s going on.”
The Sales-Oriented CSM
Introduction: “Hi, I’m Kelly, and my job is to make sure your company gets maximum benefit from, and makes maximum use of, our software. I’ll be managing your account from here forward, taking care of the renewal, and working to find other areas of your company that can benefit from our solutions . Of course, I know you won’t be expanding usage if you’re not successful, so a big part of my job is to keep you happy as well — towards that end I’ll be keeping an eye on your implementation and your ongoing satisfaction surveys, and setting up periodic health checks with our ace technical team. For routine technical or services questions, you should call those departments, but if you find yourself getting stuck do not hesitate to call me. And, well, not to get ahead of myself, but I was wondering if you could introduce me to the CFO of the XYZ division, because I’d love to see if we could get in there and help them experience the same benefits that you’re going to be getting. In my prior job, I worked as as sales development rep (SDR) and was promoted into this position 2 years ago.’
Conversations they like to have:
“Do you see any reason why you wouldn’t be renewing the subscription in February?”
“I’d love to come in next week and demonstrate our new Modeling product; I think it could help you with the inventory problem your CFO told me about.”
“I see you hired a new finance VP; can the three of us get together next week to discuss her goals for the team and our history working with you as a supplier?
I’ve exaggerated the types to make them clear. What kind of CSM are you? What other types have you seen? I’d love to hear.
In the end, it’s all about getting the right Sales and Customer Success Models working side by side, with the duties clearly mapped, and with the right people in the right roles. I think the best way to do that is a mix of top-down planning and bottom-up assessment. How do we want to break up these duties? And who do we have on our team.
# # #
 The way to define your Customer Success model is to define which duties (e.g., adoption, upsell, renewal) are mapped to which Customer Success and Sales roles in your company. I won’t dive into Customer Success models in this post (because I can think of 3-5 pretty quickly) and each of those models will have a different duty mapping; so the post would get long fast. Instead, I’m focusing on people because in many ways it’s simpler — I think CSMs come with different, built-in orientations and its important that you put the right CSM into the right role.
 I *love* characterizing jobs in this way. It’s so much more concrete than long job descriptions or formal mission statements. Think: if a customer asks you what your job is, what do you say?
 As well as map duties to frequencies — e.g., a tier-one CSM may perform monthly outreach calls and setup quarterly health checks, whereas a tier-three CSM may perform quarterly outreach calls and setup annual health checks.
 You can make a product-oriented CSM responsible for renewals, but they probably won’t like it. You could even make them responsible for upsell — but you won’t get much.
 To keep things simple here, I’m omitting the Customer Success Architect (CSA) role from the discussion. Many companies, particularly as they grow, break product-oriented CSMs out of the CSM team, and move them into more of an advanced technical support and consulting role (CSA). While I think this is generally a good idea, once broken out, they are no longer technically CSMs and out of scope for this post.
 One of my favorite quotes from a sales VP I know: “I always put ‘sales’ on my business card — and not account executive or such — because I don’t want anyone to be surprised when I ask for money.” This introduction preserves that spirit.
Most of the thinking, definitions, and formulas regarding SaaS unit economics is based on assumptions that no longer reflect the reality of the enterprise SaaS environment. For example, thinking in terms of MRR (monthly recurring revenue) is outdated because most enterprise SaaS companies run on annual contracts and thus we should think in terms of ARR (annual recurring revenue) instead.
Most enterprise SaaS companies today do a minimum one-year contract and many do either prepaid or non-prepaid multi-year contracts beyond that. In the case of prepaid multi-year contracts, metrics like the CAC payback period break (or at the very least, get difficult to interpret). In the case of multi-year contracts, calculating churn correctly gets a lot more complicated – and most people aren’t even aware of the issue, let alone analyze it correctly.
If your company does multi-year contracts and you are not either sidestepping this issue (by using only ARR-pool-based rates) or correcting for it in your available-to-renew (ATR) churn calculations, keep reading. You are possibly making a mistake and overstating your churn rate.
A Multi-Year Churn Example
Let’s demonstrate my point with an example where Company A does 100% one-year deals and Company B does 100% three-year deals. For simplicity’s sake, we are going to ignore price increases and upsell . We’re also not going to argue the merits of one- vs. three-year contracts; our focus is simply how to calculate churn in a world of them.
In the example below, you can see that Company A has an available-to-renew-based (ATR-based)  churn rate of 10%. Company B has a 27% ATR-based churn rate. So we can quickly conclude that Company A’s a winner, and Company B is a loser, right?
Not so fast.
At the start of year 4, a cohort of Company A customers is worth 72.9 units, the exact same as a cohort of Company B customers. In fact, if you look at lifetime value (LTV), the Company B cohort is worth nearly 10% more than the Company A cohort .
Wait a minute! How can a company with 27% churn rate be “better” than a company with 10% churn rate?
It’s All About Exposure: How Often are Deals Exposed to the Churn Rate?
One big benefit of multi-year deals is that they are exposed to the churn rate less frequently than one-year deals. When you exclude the noise (e.g., upsell, discounts, and price increases), and look at churn solely as a decay function, you see that the N-year retention rate  is (1-churn rate)^N. With 10% churn, your 2-year retention rate is (1-0.1)^2 = 0.9^2 = 0.81. Your 3-year retention rate is (1-0.1)^3 = 0.9^3 = 0.729, or a retention rate of 73%, equivalent to a churn rate of 27%.
Simply put, churn compoundssoexposing a contract to the churn rate less often is a good thing: multi-year deals do this by excluding contracts from the ATR pool, typically for one or two years, before they come up for renewal . Thisalso means that you cannot validly compare churn rates on contracts with different duration.
This is huge. As we have just shown, a 10% churn rate on one-year deals is equivalent to a 27% churn rate on three-year deals, but few people I know recognize this fact.
I can imagine two VCs talking:
“You’re not going to believe it, I saw a company today with a 27% churn rate.”
“Yep, and it crushed their LTV/CAC — it was only 1.6.”
“Melting ice cube. Run away.”
Quite sad, in fact, because with a correct (annualized) churn rate of 10% and holding the other assumptions constant , the LTV/CAC jumps to healthy 4.4. But any attempt to explain a 27% churn rate is as likely to be seen as a lame excuse for a bad number as it is to be seen as valid analysis.
Best Alternative Option: Calculate Churn Rates off the Entire ARR Pool
I’m going to define the 27% figure as the nominal ATR-based churn rate. It’s what you get when you take churn ARR / ATR in any given period. I call it a nominal rate because it’s not annualized and it doesn’t reflect the varying distribution of 1Y, 2Y, and 3Y deals that are mixed in the ATR pool in any given quarter. I call it nominal because you can’t validly compare it to anything .
Because correcting this to a more meaningful rate is going to involve a lot of brute force math, I’ll first advise you to do two things:
Banish any notion from your mind that ATR rates are somehow “more real” than churn rates calculated against the entire ARR pool .
Then use churn rates calculated against the entire ARR pool and sidestep the mess we’re about to enter in the next section  where we correct ATR-based churn rates.
In a world of mixed-duration contracts calculating churn rates off the entire ARR pool effectively auto-corrects for the inability of some contracts to churn. I have always believed that if you were going to use the churn rate in a math function (e.g., as the discount rate in an NPV calculation) that you should only use churn rates calculated against the entire ARR pool because, in a mixed multi-year contract world, only some of the contracts come up for renewal in any given period. In one sense you can think of some contracts as “excluded from the available-to-churn (ATC) pool.” In another, you can think of them as auto-renewing. Either way, it doesn’t make sense in a mixed pool to apply the churn rate of those contracts up for renewal against the entire pool which includes contracts that are not.
If you want to persist in using ATR-based churn rates, then we must correct for two problems: we need to annualize the multi-year rates, and we then need to calculate ATR churn using an ATR-weighted average of the annualized churn rates by contract duration.
Turning Nominal ATR Churn into Effective, Annualized ATR Churn
Here’s how to turn nominal ATR churn into an effective, annualized ATR churn rate  :
Step 1: categorize your ATR and churn ARR by contract duration. Calculate a 1Y churn rate and nominal 2Y and 3Y ATR churn rates.
Step 2: annualize the nominal multi-year (N-year) churn rates by flipping to retention rates and taking the Nth root of the retention rate. For example, our 27% 3-year churn rate is equivalent to a 73% 3-year retention rate, so take the cube root of 0.73 to get 0.9. Then flip back to churn rates and get 10%.
Step 3: do an ATR-weighted average of the 1Y and annualized 2Y and 3Y churn rates. Say your ATR was 50% 1Y, 25% 2Y, and 25% 3Y contracts and your annualized churn rates were 10%, 12%, and 9%. Then the weighted average would be (0.5*0.10) + (0.25*0.12) + (0.25*0.09) = 10.25%, as your annualized, effective ATR churn rate.
That’s it. You’ve now produced an ATR churn rate that is comparable to a one in a company that does only 1-year contracts.
If nothing else, I hope I have convinced that you it is invalid to compare churn rates on contracts of different duration and ergo that is simpler to generally calculate churn rates off the entire ARR pool. If, however, you still want to see ATR-based churn rates, then I hope I’ve convinced you that you must do the math and calculate ATR churn as a weighted average of annualized one-, two-, and three-year ATR churn rates.
# # #
 In a world of zero upsell there is no difference between gross and net churn rates, thus I will simply say “churn rate” in this post.
 As soon as you start doing multi-year contracts then the entire ARR base is no longer up for renewal each year. You therefore need a new concept, available to renew (ATR), which reflects only that ARR up for renewal in a given period.
 Thanks to its relatively flatter step-wise decay compared to Company A’s more linear decay.
 Retention rate = 1 – churn rate.
 If it helps, you can think of the ATR pool in a glass half-empty way as the available-to-churn pool.
 Assuming CAC ratio of 1.8 and subscription gross margins of 80%.
 Unless your company has a fixed distribution of deals by contract duration – e.g., a degenerate case being 100% 3Y deals. For most companies the average contract duration in the inbound ATR pool is going to vary each quarter. Ergo, you can’t even validly compare this rate to itself over time without factoring in the blending.
 Most people I meet seem to think ATR rates are more real than rates based on the entire ARR pool. Sample conversation — “what’s your churn rate?” “6%.” “Gross or net? “Gross.” “No, I mean your real churn rate – what gets churned divided only by what was up for renewal.” The mistake here is in thinking that using ATR makes it comparable to a pure one-year churn rate – and it doesn’t.
 Gross churn = churn / starting period ARR. Net churn = (gross churn – upsell) / starting period ARR.
 I thought about trying a less brute-force way using average contract duration (ACD) of the ATR pool, but decided against it because this method, while less elegant, is more systematic.
 Note that this method will still understate the LTV advantage of the more step-wise multi-year contract decay because it’s not integrating the area under the curve, but instead intersecting what’s left of the cohort after N years. In our first example, the 1Y and 3Y cohorts both had 73 units of ARR, but because the multi-year cohort decayed more slowly it’s LTV to that point was about 10% higher.
This post won’t save your life, or your company. But it might save you a few precious hours at 2:00 AM if you’re working on your company’s SaaS metrics and can’t foot your quarterly and annual churn rates while preparing a board or investor deck.
The generic issue is a lot of SaaS metrics gurus define metrics in a generic way using “periods” without paying attention to some subtleties that can arise in calculating these metrics for a quarter vs. a year. The specific issue is, if you do what many people do, that your quarterly and annual churn rates won’t foot — i.e., the sum of your quarterly churn rates won’t equal your annual churn rate.
Here’s an example to show why.
If I asked you to calculate the annual churn rate in the above example, virtually everyone would get it correct. You’d look at the rightmost column, see that 2018 started with 10,000 in ARR, see that there were 1,250 dollars of churn on the year, divide 1,250 by 10,000 and get 12.5%. Simple, huh?
However, if I hid the last column, and then asked you to calculate quarterly churn rates, you might come up with churn rate 1, thinking churn rate = period churn / starting period ARR. You might then multiply by 4 to annualize the quarterly rates and make them more meaningful. Then, if I asked you to add an annual column, you’d sum the quarterly (non-annualized) rates for the annual churn and either average the annualized quarterly rates or simply gray-out the box as I did because it’s redundant .
You’d then pause, swear, and double-check the sheet for errors because the sum of your quarterly rates (10.2%) doesn’t equal your annual rate (12.5%).
What’s going on? The trap is thinking churn rate = period churn / starting period ARR.
That works in a world of one-year contracts when you look at churn on an annual basis (every contract in the starting ARR base of 10,000 faces renewal at some point during the year), but it breaks on a quarterly basis. Why? Because starting ARR is increasing every quarter due to new sales that aren’t in the renewal base for the year. This depresses your churn rates relative to churn rate 2, which defines quarterly churn as churn in the quarter divided by starting-year ARR. When you use churn rate 2, the sum of the quarterly rates equals the annual rate, so you can mail out that board deck and go back to bed .
Available to Renew (ATR-based) Churn Rates
While we’re warmed up, let’s have some more fun. If you’ve worked in enterprise software for more than a year, you’ll know that the 10,000 dollars of starting ARR is most certainly not distributed evenly across quarters: enterprise software sales are almost always backloaded, ergo enterprise software renewals follow the same pattern.
So if we want more accurate  quarterly churn rates, shouldn’t we do the extra work, figure out how much ARR we have available to renew (ATR) in each quarter, and then measure churn rates on an ATR basis? Why not!
Let’s first look at an example, that shows available to renew (ATR) split in a realistic, backloaded way across quarters .
In some sense, ATR churn rates are cleaner because you’re making fewer implicit assumptions: here’s what was up for renewal and here’s what we got (or lost). While ATR rates get complicated fast in a world of multi-year deals, for today, we’ll stay in a world of purely one-year contracts.
Even in that world, however, a potential footing issue emerges. If I calculate annual ATR churn by looking at annual churn vs. starting ARR, I get the correct answer of 12.5%. However, if I try to average my quarterly rates, I get a different answer of 13.7%, which I put in red because it’s incorrect.
Quiz: what’s going on?
Hint: let me show the ATR distributed in a crazy way to demonstrate the problem more clearly.
The issue is you can’t get the annual rate by averaging the quarterly ATR rates because the ATR is not evenly distributed. By using the crazy distribution above, you can see this more clearly because the (unweighted) average of the four quarterly rates is 53.6%, pulled way up by the two quarters with 100% churn rates. The correct way to foot this is to instead use a weighted average, weighting on an ATR basis. When you do that (supporting calculations in grey), the average then foots to the correct annual number.
# # #
 The sum of the quarterly rates (A, B, C, D) will always equal the average of the annualized quarterly rates because (4A+4B+4C+4D)/4 = A+B+C+D.
 I won’t go so far as to say that churn rate 1 is “incorrect” while churn rate 2 is “correct.” Churn rate 1 is simple and gives you what you asked for “period churn / starting period ARR.” (You just need to realize that the your quarterly rates will only sum to your annual rate if you have zero new sales and ergo you should calculate the annual rate off the yearly churn and starting ARR.) Churn rate 2 is somewhat more complicated. If you live in a world of purely one-year contracts, I’d recommend churn rate 2. But in a world of mixed one- and multi-year contracts, then lots of contracts are in starting period ARR aren’t in the renewal base for the year, so why would I exclude only some of them (i.e,. those signed in the year) as opposed to others.
 Dividing by the whole ARR base basically assumes that the base renews evenly across quarters. Showing churn rates based on available-to-renew (ATR) is more accurate but becomes complicated quickly in a world of mixed, multi-year contracts of different duration (where you will need to annualize the rates on multi-year contracts and then blend the average to get a single, meaningful, annualized rate). In this post, we’ll assume a world of exclusively one-year contracts, which sidesteps that issue.
 ATR is normally backloaded because enterprise sales are normally backloaded. Here the linearity is 15%, 17.5%, 25%, 42.5% or a 32.5/67.5 split across the first vs. second half of the year (which is pretty backloaded even for enterprise software).
 The spreadsheet I used is available here if you want to play with it.
My ears always perk up when I hear someone say “net new ARR” — because I’m trying to figure out which, of typically two, ways they are using the term:
To mean ARR from net new customers, in which case, I don’t know why they need the word “net” in there. I call this new business ARR (sometimes abbreviated to newbiz ARR), and we’ll discuss this more down below.
To mean net change in ARR during a period, meaning for example, if you sold $2,000K of new ARR and churned $400K during a given quarter, that net new ARR would be $1,600K. This is the correct way to use this term.
Let’s do a quick review of what I call leaky bucket analysis. Think of a SaaS company as a leaky bucket full of ARR.
Every quarter, sales dumps new ARR into the bucket.
Every quarter, customer success does its best to keep water from leaking out.
Net new ARR is the change in the water level of the bucket. Is it a useful metric? Yes and no. On the yes side:
Sometimes it’s all you get. For public companies that either release (or where analysts impute) ARR, it’s all you get. You can’t see the full leaky bucket analysis.
It’s useful for measuring overall growth efficiency with metrics like cash burn per dollar of net new ARR or S&M expense per dollar of net new ARR. Recall that customer acquisition cost (CAC) focuses only on sales efficiency and won’t detect the situation where it’s cheap to add new ARR only to have it immediately leak out.
If I were to define an overall SaaS growth efficiency index (GEI), I wouldn’t do it the way Zuora does (which is effectively an extra-loaded CAC), I would define it as:
Growth efficiency index = -1 * (cashflow from operations) / (net new ARR)
In English, how much cash are you burning to generate a dollar of net new ARR. I like this because it’s very macro. I don’t care if you’re burning cash as a result of inefficient sales, high churn, big professional services losses, or high R&D investment. I just want to know how much cash you’re burning to make the water level move up by one dollar.
So we can see already that net new ARR is already a useful metric, if a sometimes confused term. However, on the no side, here’s what I don’t like about it.
Like any compound metric, as they say at French railroad crossings, un train peut en cacher un autre (one train can hide another). This means that while net new ARR can highlight a problem you won’t immediately know where to go fix it — is weak net new ARR driven by a sales problem (poor new ARR), a product-driven churn problem, a customer-success-driven churn problem, or all three?
For example, above, you can quickly see that a massive 167% year-over-year increase in churn ARR was the cause for weak 1Q17 net new ARR. While this format is clear and simple, one disadvantage of this simpler format is that it hides the difference between new ARR from new customers (newbiz ARR) and new ARR from existing customers (upsell ARR). Since that can be an important distinction (as struggling sales teams often over-rely on sales to existing customers), this slightly more complex form breaks that out as well.
In addition to breaking out new ARR into its two sub-types, this format adds three rows of percentages, the most important of which is upsell % of new ARR, which shows to what extent your new ARR is coming from existing versus new customers. While the “correct” value will vary as a function of your market, your business model, and your evolutionary phase, I generally believe that figures below 20% indicate that you may be failing to adequately monetize your installed base and figures above 40% indicate that you are not getting enough new business and the sales force may be too huddled around existing customers.
I’m Dave Kellogg, consultant, independent director, advisor, and blogger focused on enterprise software startups.
I bring a unique perspective to startup challenges having 10 years’ experience at each of the CEO, CMO, and independent director levels across 10+ companies ranging in size from zero to over $1B in revenues.
From 2012 to 2018, I was CEO of cloud enterprise performance management vendor Host Analytics, where we quintupled ARR while halving customer acquisition costs in a competitive market, ultimately selling the company in a private equity transaction.
Previously, I was SVP/GM of Service Cloud at Salesforce and CEO at NoSQL database provider MarkLogic, which we grew from zero to $80M in run-rate revenues during my tenure. Before that, I was CMO at Business Objects for nearly a decade as we grew from $30M to over $1B. I started my career in technical and product marketing positions at Ingres and Versant.
I love disruption, startups, and Silicon Valley and have had the pleasure of working in varied capacities with companies including Cyral, FloQast, GainSight, Kelda, MongoDB, Plannuh, Recorded Future, and Tableau. I currently sit on the boards of Alation (data catalogs), Nuxeo (content management) and Profisee (master data management). I previously sat on the boards of agtech leader Granular (acquired by DuPont for $300M) and big data leader Aster Data (acquired by Teradata for $325M).
I periodically speak to strategy and entrepreneurship classes at the Haas School of Business (UC Berkeley) and Hautes Études Commerciales de Paris (HEC).