Category Archives: Metrics

New ARR and CAC in Price-Ramped vs. Auto-Expanding Deals

In this post we’re going to look at the management accounting side of multi-year SaaS deals that grow in value over time.  I’ve been asked about this a few times lately, less because people value my accounting knowledge [1] but rather because people are curious about the CAC impact of such deals and how to compensate sales on them.

Say you sign a three-year deal with a customer that ramps in payment structure:  year 1 costs $1M, year 2 costs $2M, and year 3 costs $3M.  Let’s say in this example the customer is getting the exact same value in all 3 years (e.g., the right for 1,000 people to use a SaaS service) – so the payment structure is purely financial in nature and not related to customer value.

Equal Value:  The Price-Ramped Deal
The question on my mind is how do I look at this from a new ARR bookings, ending ARR, CAC, and sales compensation perspective?

GAAP rules define precisely how to take this from a GAAP revenue perspective – and with the adoption of ASC 606 even those rules are changing.  Let’s take an example from this KPMG data sheet on ASC 606 and SaaS.

(Price-Ramped) Year 1 Year 2 Year 3
Payment structure $1M $2M $3M
GAAP revenue $1M $2M $3M
GAAP unbilled deferred revenue $5M $3M $0M
ASC 606 revenue $2M $2M $2M
ASC 606 unbilled accounts receivable $1M $1M $0M
ASC 606 revenue backlog $4M $2M $0M

When I look at this is I see:

  • GAAP is being conservative and saying “no cash, no revenue.” For an early stage startup with no history of actually making these deals come true, that is not a bad position.  I like the concept of GAAP unbilled deferred revenue, but I don’t actually know anyone who tracks it, let alone discloses it.  Folks might release backlog in some sort of unbilled total contract value (TCV) metric which I suspect is similar [2].
  • ASC 606 is being aggressive and mathematical – “hey, if it’s a 3-year, $6M deal, then that’s $2M/year, let’s just smooth it all out [3]”. While “unbilled A/R” strikes me as (another) oxymoron I see why they need it and I do like the idea of ASC 606 revenue backlog [4].  I think the ASC 606 approach makes a lot of sense for more mature companies, which have a history of making these deals work [5].

Now, from an internal, management accounting perspective, what do you want to do with this deal in terms of new ARR bookings, ending ARR balance, CAC ratio, and sales comp?  We could say:

  • It’s $2M in new ARR today
  • Ergo calculate this quarter’s CAC with it counted as $2M
  • Add $2M in ending ARR
  • Pay the salesrep on a $2M ARR deal – and let our intelligently designed compensation plan protect us in terms of the delayed cash collections [6] [6A]

And I’d be OK with that treatment.  Moreover, it jibes with my definition of ARR which is:

End-of-quarter ARR / 4 = next-quarter subscription revenue, if nothing changes [7]

That’s because ASC 606 also flattens out the uneven cash flows into a flat revenue stream.

Now, personally, I don’t want to be financing my customers when I’m at a high-burn startup, so I’m going to try and avoid deals like this.  But if I have to do one, and we’re a mature enough business to be quite sure that years 2 and 3 are really coming, then I’m OK to treat it this way.  If I’m not sure we’ll get paid in years 2 and 3 – say it’s for a brand-new product that has never been used at this scale – then I might revert to the more GAAP-oriented, 1-2-3 approach, effectively treating the deal not as a price ramp, but as an auto-expander.

Increasing Value:  The Auto-Expanding Deal
Let’s say we have a different use-case.  We sell a SaaS platform and year 1 will be exclusively focused on developing a custom SaaS app, we will roll it to 500 users day 1 of year 2, and we will roll it to 500 more users on day 1 of year 3.  Further assume that the customer gets the same value from each of these phases and each phase continues until the end of the contract [8].  Also assume the customer expects that going forward, they will be paying $3M/year plus annual inflation adjustments.

Oy veh.  Now it’s much harder.  The ramped shape of the curve is not about financing at all.  It’s about the value received by the customer and the ramped shape of the payments perfectly reflects the ramped shape of the value received.  Moreover, not all application development projects succeed and if they fall behind on building the customized application they will likely delay the planned roll-outs and try to delay the payments along with them.  Moreover, since we’re an early-stage startup we don’t have enough history to know if they’ll succeed at all.

This needs to be seen as an auto-expanding deal:  $1M of new-business ARR in year 1, $1M of pre-sold upsell ARR in year 2, and another $1M of pre-sold upsell ARR in year 3.

When you celebrate it at the company kickoff you can say the customer has made a $6M commitment (total contract value, or TCV [9]) to the company and when you tier your customers for customer support/success purposes you might do so by TCV as opposed to ARR [10].  When you talk to investors you can say that $1M of next year’s and $1M of the subsequent year’s upsell is already under contract, ergo increasing your confidence in your three-year plan.  Or you could roll it all together into a statement about backlog or RPO [11].  That part’s relatively easy.

The hard part is figuring out sales compensation and CAC.  While your rep will surely argue this is a $2M ARR deal (if not a $3M ARR deal) and that he/she should be paid accordingly, hopefully you have an ARR-driven (and not a total bookings-driven) compensation plan and we’ve already established that we can’t see this as $2M or $3M ARR deal.  Not yet, at least.

This deal is a layer cake:  it’s a three-year $1M ARR deal [12] that has a one-year-delayed, two-year $1M ARR deal layered atop it, and a two-year-delayed, one-year $1M ARR deal atop that.  And that, in my opinion, is how you should pay it out [13].  Think:  “hey, if you wanted to get paid on a three-year $3M ARR deal, then you should have brought me one of those [14].”

Finally, what to do about the CAC?  One might argue that the full cost of sale for the eventual $3M in ARR was born up-front.  Another might argue that, no, plenty of account management will be required to ensure we actually get the pre-sold upsell.  The easiest and most consistent thing to do is to treat the ARR as we mentioned (1+1+1) and calculate the CAC, as you normally would, using the ARR that we put in the pool.

If you do a lot of these deals, then you would see a high new-business CAC ratio that is easily explained by stellar net-dollar expansion rates (173% if these were all you did).  Think:  “yes, we spend a lot up-front to get a customer, but after we hook them, they triple by year three.”

Personally, I think any investor would quickly understand (and fall in love with) those numbers.  If you disagree, then you could always calculate some supplemental CAC ratio designed to better amortize the cost of sale across the total ARR [14].  Since you can’t have your cake and eat it too, this will make the initial CAC look better but your upsell CAC and net-dollar expansion rates worse.

As always, I think the right answer is to stick with the fundamental metrics and let them tell the story, rather than invent new metrics or worse yet, new definitions for standard metrics, which can sow the seeds of complexity and potential distrust.

# # #

Notes

For more information on ASC 606 adoption, I suggest this podcast and this web page which outlines the five core principles.

[1] I am not an accountant.  I’m a former CEO and strategic marketer who’s pretty good at finance.

[2] And which I like better as “unbilled deferred revenue” is somewhat oxymoronical to me.  (Deferred revenue is revenue that you’ve billed, but you have not yet earned.)

[3] I know in some cases, e.g., prepaid, flat multi-year deals, ASC 606 can actually decide there is a material financing event and kind of separate that from the core deal.  While pure in spirit, it strikes me as complex and the last time I looked closely at it, it actually inflated revenue as opposed to deflating it.

[4] Which I define as all the future revenue over time if every contract played out until its end.

[5] Ergo, you have high empirical confidence that you are going to get all the revenue in the contract over time.

[6] Good comp plans pay only a portion of large commissions on receipt of the order and defer the balance until the collection of cash.  If you call this a $2M ARR deal, you do the comp math as if it’s $2M, but pay out the cash as dictated by the terms in your comp plan.  (That is, make it equivalent to a $2M ARR deal with crazy-delayed payment terms.)  You also retire $2M of quota, in terms of triggering accelerators and qualifying for club.

[6A] This then begs the question of how to comp the $1M in pre-sold upsell in Year 3.  As with any of the cases of pre-sold upsell in this post, my inclination is to pay the rep on it when we get the cash but not on the terms/rates of the Year 1 comp plan, but to “build it in” into their comp plan in year 3, either directly into the structure (which I don’t like because I want reps primarily focused on new ARR) or as a bonus on top of a normal OTE.  You get a reward for pre-sold upsell, but you need to stay here to get it and you don’t year 1 comp plan rates.

[7] That is, if all your contracts are signed on the last day of the quarter, and you don’t sign any new ones, or churn any existing ones until the last day of the quarter, and no one does a mid-quarter expansion, and you don’t have to worry about any effects due to delayed start dates, then the ARR balance on the last day of the quarter / 4 = next quarter’s subscription revenue.

[8] Development is not “over” and that value released – assume they continue to fully exploit all the development environments as they continue to build out their app.

[9] Note that TCV can be seen as an “evil” metric in SaaS and rightfully so when you try to pretend that TCV is ARR (e.g., calling a three-year $100K deal “a $300K deal,” kind of implying the $300K is ARR when it’s not).  In this usage, where you’re trying to express total commitment made to the company to emphasize the importance of the customer, I think it’s fine to talk about TCV – particularly because it also indirectly highlights the built-in upsell yet to come.

[10] Or perhaps some intelligent mix thereof.  In this case, I’d want to weight towards TCV because if they are not successful in year 1, then I fail to collect 5/6th of the deal.  While I’d never tell an investor this was a $6M ARR deal (because it’s not true), I’d happily tell my Customer Success team that this a $6M TCV customer who we better take care of.  (And yes, you should probably give equal care to a $2M ARR customer who buys on one-year contracts – in reality, either way, they’d both end up “Tier 1” and that should be all that matters.)

[11] Or you could of the ASC 606 revenue backlog and/or Remaining Performance Obligation (RPO) – and frankly, I’d have trouble distinguishing between the two at this point.  I think RPO includes deferred revenue whereas ASC 606 revenue backlog doesn’t.

[12] In the event your compensation plan offers a kicker for multi-year contracts.

[13] And while you should factor in the pre-committed upsell in setting the reps targets in years 2 and 3, you shouldn’t go so far as to give them a normal upsell target with the committed upsell atop it.  There is surely middle ground to be had.  My inclination is to give the rep a “normal” comp plan and build in collecting the $1M as a bonus on top — but, not of course at regular new ARR rates.  The alternative is to build (all or some of) it into the quota which will possibly demotivate the rep by raising targets and reducing rates, especially if you just pile $1M on top of a $1M quota.

[14] This ain’t one – e.g., it has $6M of TCV as opposed to $9M.

The Rule of 40 — Down, But Not Out!

Neeraj Agrawal and Logan Bartlett of Battery Ventures recently published the 2019 version of its outstanding annual software round-up report.  I highly recommend this report — it’s 78-pages chock full of great data about topics like:

  • Why Battery is long software overall
  • The four eras of software evolution
  • The five forces driving software’s accelerating growth
  • Key trends in 2018, including setting records in three areas:  (1) public company revenue multiples, (2) IPO volume (by over 2x), and (3) M&A volume (by over 2x).
  • Key trends from their 2017 report that are still alive, well, and driving software businesses.

But, most of all, it has some great charts on the Rule of 40 [1] that I want to present and discuss here.  Before doing that, I must note that I drank today’s morning coffee reading Alex Clayton’s CloudStrike IPO breakdown, a great post about a cloud security company with absolutely stunning growth at scale — 121% growth to $312M in Ending ARR in FY19.  And, despite my headline, well in compliance with the Rule of 40.  110% revenue growth + -26% free cashflow margin = 84%, one of the highest Rule of 40 scores that I’ve ever seen [2].  Keep an eye on this company, I expect it should have a strong IPO [3].

However, finding one superstar neither proves nor disproves the rule.  Let’s turn to the Battery data to do that.

When discussing the Rule of 40, most financial analysts make one of two plots.

  • They do a scatter plot with revenue growth on the X-axis and FCF margin on the Y-axis.  The Rule of 40 then becomes a line that separates the chart into two zones (compliant and non-compliant).  Note that a minority of public companies actually comply suggesting the rule of 40 is a pretty high bar [4].
  • Or, more interestingly, they do a linear regression of Rule of 40 score vs. enterprise-value/revenue (EV) multiple.  This puts focus on the question:  what’s the relationship between Rule of 40 score and company value? [5]

But that thing has always bugged me is that nobody does the linear regression against both the Rule of 40 score and revenue growth.  Nobody, until Battery.  Here’s what it shows.

First, let’s look at the classic Rule of 40 regression.  Recall that R-squared is a statistical measure that explains the dependence of the dependent variable (in this case, EV multiple) on the independent variable (Rule of 40 score).  Here you can see that about 58% of the variation in enterprise value multiple is explained by Rule of 40 score.  You can intuit that by looking at the dots relative to the line — while there is clearly some linear correlation between the data, it’s a long way from perfect (i.e., lots of dots are pretty far from the line).  [6]

rule of 40-4

Now, the fun part.  Let’s see the same regression against revenue growth alone.  R-squared here is 51%.  So the explanatory power of the Rule of 40 is only 7% higher than revenue growth alone.  Probably still worth looking at, but it sure gets a lot of PR for explaining only an incremental 7%.  It could be worse, I suppose.  Rule of 40 could have a lower R-squared than revenue growth alone — in fact, it did back in 2008 and in 2012.

rule of 40-3

In the vein, for some real fun let’s look at how this relationship has changed over time.  The first thing you’ll notice is that pre-2012 both last twelve month (LTM) revenue growth and the Rule of 40 had far weaker explanatory power, I suspect because profitability played a more important role in the equation.  In 2012, the explanatory power of both metrics doubled.  In 2015 and 2016 the Rule of 40 explained nearly 20% more than revenue growth alone.  In 2017 and 2018, however, that’s dropped to 7 to 8%.

rule of 40-2

I still think the Rule of 40 is a nice way to think about balancing growth vs. profit and Rule of 40 compliant companies still command a disproportionate share of market value.  But remember, its explanatory power has dropped in recent years and, if you’re running an early or mid-stage startup, there is very little comparative data available on the Rule of 40 scores of today’s giants when they were at early- or mid-stage scale.  That’s why I think early- and mid-stage startups need to think about the Rule of 40 in terms of glideslope planning.

Thanks to the folks at Battery for producing and sharing this great report. [7]

# # #

Notes
[1] Rule of 40 score = typically calculated as revenue growth + free cashflow (FCF) margin.  When FCF margin is not available, I typically use operating margin.   Using GAAP operating margin here would result in 110% + -55% = 55%, much lower, but still in rule of 40 compliance.

[2] If calculated using subscription revenue growth, it’s 137% + -26% = 111%, even more amazing.  One thing I don’t like about the fluidity of Rule of 40 calculations, as you can see here, is that depending what might seem small nuances in calculations, you can produce a very broad range of scores.   Here, from 55% to 137%.

[3] To me, this means ending day 1 with a strong valuation.  The degree to which that is up or down from the opening price is really about how the bankers priced the offer.  I am not a financial analyst and do not make buy or sell recommendations.  See my disclaimers, here.

[4] In fact, it’s actually a double bar — first you need to have been successful enough to go public, and second you need to clear the Rule of 40.  Despite a minority of public companies actually clearing this bar, financial analysts are quick to point out the minority who do command a disproportionate share of market cap.

[5] And via the resultant R-squared score, to what extent does the Rule of 40 score explain (or drive) the EV/R multiple?

[6] If R-squared were 1.0 all the dots would fall on the least-squares fit line.

[7] Which continues with further analysis, breaking the Rule of 40 into 4 zones.

Speaking at Host Perform 2019

hostperform

Just a quick post to plug the fact that the kind folks at Host Analytics have invited me to speak at Host Perform 2019 in Las Vegas on May 20-22nd, and I’ll be looking forward to seeing many old friends, colleagues, customers, and partners on my trip out.

I’ll be speaking on the “mega-track” on Wednesday, May 22nd at 9:00 AM on one of my favorite topics:  how EPM, planning, and metrics all look from the board and C-level perspectives.  My official session description follows:

session

The Perform 2019 conference website is here and the overall conference agenda is here.  If you’re interested in coming and you’ve not yet registered yet, it’s not too late!  You can do so here.

I look forward to another great Perform conference this year and should be both tweeting (hashtag #HostPerform) and blogging from the conference.  I look forward to seeing everyone there.  And attend my session if you want to get more insight into how boards and C-level executives view reporting, planning, EPM, KPIs, benchmarks, and metrics.

What's the "Cause of Death" in Your Churn Reporting?

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:
Uncontrollable:

  • Got acquired
  • Went bankrupt
  • Corporate edict
  • New sponsor

Controllable:

  • Failed implementation
  • Product functionality
  • 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?
Physicians have been in the “churn” business much longer than SaaS companies and I think they’ve arrived at a superior system.  Here’s an excerpt from the CDC’s Physicians’ Handbook on Medical Certification of Death — not a publication, I’d add, linked to by most SaaS bloggers:
chain of death
For example, when my dear father passed away from a stroke several years ago, I remember the form said:
example cod
(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
  • Partner training

Or, another:

  • Churned, due to
  • Corporate edict, due to
  • M&A, due to
  • Product dissatisfaction, due to
  • Oversold, due to
  • Sales training

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.
 

What’s the “Cause of Death” in Your Churn Reporting?

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:

Uncontrollable:

  • Got acquired
  • Went bankrupt
  • Corporate edict
  • New sponsor

Controllable:

  • Failed implementation
  • Product functionality
  • 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?

Physicians have been in the “churn” business much longer than SaaS companies and I think they’ve arrived at a superior system.  Here’s an excerpt from the CDC’s Physicians’ Handbook on Medical Certification of Death — not a publication, I’d add, linked to by most SaaS bloggers:

chain of death

For example, when my dear father passed away from a stroke several years ago, I remember the form said:

example cod

(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
  • Partner training

Or, another:

  • Churned, due to
  • Corporate edict, due to
  • M&A, due to
  • Product dissatisfaction, due to
  • Oversold, due to
  • Sales training

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.

 

Are You Counting Payments as Renewals?

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 [1].  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 [2].)

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. [3]

But let’s be clear, regardless of the process you use to manage them [4], 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%?

payment renewal

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 [5].  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. 

Because of prepaid multi-year deals, I have always calculated retention rates two ways:  ATR-based and ARR-based.  The former is supposed to give you an idea of how often, given the chance, people want to renew their contacts.  The latter is supposed to show you, mathematically, what’s happening to your ARR pool [6].

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.

# # #

Notes

[1] Over 2 years you get 190 units versus an expected 185.  (Not counting any expansion.)

[2] 0.75 > 0.9^3 = 0.73 – you need to compound annual rates to compare them to multi-year ones.

[3] Or, really, Accounts Receivable but that doesn’t sound as funny.

[4] 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.

[5] While payment does not necessarily indicate satisfaction, it probably does indicate the absence of intense dissatisfaction.

[6] e.g., I’d use the the churn rate (1 minus the retention rate) as the discount rate in a present value calculation.

What It Takes to Make a Great SaaS Company

I’ve been making a few presentations lately, so I thought I’d share the slides to this deck which I presented earlier this week at the All Hands meeting of a high-growth SaaS company as part of their external speaker series.

This one’s kind of a romp — it starts with some background on Kellblog (in response to some specific up-front questions they had), takes a brief look back at the “good old days” of on-premises software, introduces my leaky bucket concept of a SaaS company, and then discusses why I need to know only two things to value your SaaS company:  the water level of your bucket and how fast it’s increasing.

It kind of runs backwards building into the conclusion that a great SaaS company needs four things.

  1. An efficient sales model.  SaaS companies effectively buy customers, so you need to figure out how to do it efficiently.
  2. A customer-centric culture.  Once you’ve acquired a customer your whole culture should be focused on keeping them.  (It’s usually far cheaper than finding a new one to back-fill.)
  3. A product that gets the job done.  I like Clayton Christensen’s notion that customers “hire products to do jobs for them.”  Do yours?  How can you do it better?
  4. A vision that leaves the competition one step behind.  Done correctly, the competition is chasing your current reality while you’re out marketing the next level of vision.

Here are the slides: