Tag Archives: upsell

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.

A Fresh Look at How to Measure SaaS Churn Rates

[Editor’s note:  revised 3/27/17 with changes to some definitions.]

It’s been nearly three years since my original post on calculating SaaS renewal rates and I’ve learned a lot and seen a lot of new situations since then.  In this post, I’ll provide a from-scratch overhaul on how to calculate churn in an enterprise SaaS company [1].

While we are going to need to “get dirty” in the detail here, I continue to believe that too many people are too macro and too sloppy in calculating these metrics.  The details matter because these rates compound over time, so the difference between a 10% and 20% churn rate turns into a 100% difference in cohort value after 7 years [2].  Don’t be too busy to figure out how to calculate them properly.

The Leaky Bucket Full of ARR

I conceptualize SaaS companies as leaky buckets full of annual recurring revenue (ARR).  Every time period, the sales organization pours more ARR into the bucket and the customer success (CS) organization tries to prevent water from leaking out [3].

This drives the leaky bucket equation, which I believe should always be the first four lines of any SaaS company’s financial statements:

Starting ARR + new ARR – churn ARR = ending ARR

Here’s an example, where I start with those four lines, and added two extra (one to show a year over year growth rate and another to show “net new ARR” which offsets new vs. churn ARR):

leaky

For more on how to present summary SaaS startup financials, go here.

Half-Full or Half-Empty:  Renewals or Churn?

Since the renewal rate is simply one minus the churn rate, the question is which we should calculate?  In the past, I favored splitting the difference [4], whereas I now believe it’s simpler just to talk about churn.  While this may be the half-empty perspective, it’s more consistent with what most people talk about and is more directly applicable, because a common use of a churn rate is as a discount rate in a net present value (NPV) formula.

Thus, I now define the world in terms of churn and churn rates, as opposed to renewals and renewal rates.

Terminology: Shrinkage and Expansion

For simplicity, I define the following two terms:

  • Shrinkage = anything that makes ARR decrease. For example, if the customer dropped seats or was given a discount in return for signing a multi-year renewal [5].
  • Expansion = anything that makes ARR increase, such as price increases, seat additions, upselling from a bronze to a gold edition, or cross-selling new products.

Key Questions to Consider

The good news is that any churn rate calculation is going to be some numerator over some denominator.  We can then start thinking about each in more detail.

Here are the key questions to consider for the numerator:

  • What should we count? Number of accounts, annual recurring revenue (ARR), or something else like renewal bookings?
  • If we’re counting ARR should we think at the product-level or account-level?
  • To what extent should we offset shrinkage with expansion in calculating churn ARR? [6]
  • When should we count what? What about early and late renewals?  What about along-the-way expansion?  What about churn notices or non-payment?

Here are the key questions to consider for the denominator:

  • Should we use the entire ARR pool, that portion of the ARR pool that is available to renew (ATR) in any given time period, or something else?
  • If using the ATR pool, for any given renewing contract, should we use its original value or its current value (e.g., if there has been upsell along the way)?

What Should We Count?  Logos and ARR

I believe the two metrics we should count in churn rates are

  • Logos (i.e., number of customers). This provides a gross indication of customer satisfaction [7] unweighted by ARR, so you can answer the question:  what percent of our customer base is turning over?
  • ARR.  This provides a very important indication on the value of our SaaS annuity.  What is happening to our ARR pool?

I would stay completely away from any SaaS metrics based on bookings (e.g., a bookings CAC, TCV, or bookings-based renewals rate).  These run counter to the point of SaaS unit economics.

Gross and Net Shrinkage; Account-Level Churn

Let’s look at a quick example to demonstrate how I now define gross and net shrinkage as well as account-level churn [8].

gross and net shrinkage

Gross shrinkage is the sum of all the shrinkage. In the example, 80 units.

Net shrinkage is the sum of the shrinkage minus the sum of the expansion. In the example, 80-70 = 10 units.

To calculate account-level churn, we proceed, account by account, and look at the change in contract value, separating upsell from the churn.  The idea is that while it’s OK to offset shrinkage with expansion within an account that we should not do so across accounts when working at the account level [9].  This has the effect of splitting expansion into offset (used to offset shrinkage within an account) and upsell (leftover expansion after all account-level shrinkage has been offset).  In the example, account-level churn is 30 units.

Make the important note here that how we calculate you churn – and specifically how we use expansion ARR to offset shrinkage—not only affects our churn rates, but our reported upsell rates as well.  Should we proudly claim 70 units of upsell (and less proudly 80 units of churn), 30 units of churn and 20 of upsell, or simply 10 units of churn?  I vote for the second.

While working at the account-level may seem odd, it is how most SaaS companies work operationally.  First, because they charter customer success managers (CSMs) to think at the account level, working account by account doing everything they can to preserve and/or increase the value of the account.  Second, because most systems work at and finance people think at the account level – e.g., “we had a customer worth 100 units last year, and they are worth 110 units this year so that means upsell of 10 units.  I don’t care how much is price increase vs. swapping some of product A for product B.” [11]

So, when a SaaS company reports “churn ARR,” in its leaky bucket analysis, I believe they should report neither gross churn nor net churn, but account-level churn ARR.

Timing Issues and the Available to Renew (ATR) Concept

Churn calculations bring some interesting challenges such as early/late renewals, churn notices, non-payment, and along-the-way expansion.

A renewals booking should always be taken in the period in which it is received.  If a contract expires on 6/30 and the renewal is received in on 6/15 it should show up in 2Q and if received on 7/15 it should up in 3Q.

For churn rate calculations, however, the customer success team needs to forecast what is going to happen for a late renewal.  For example, if we have a board meeting on 7/12 and a $150K ARR renewal due 6/30 has not yet been happened, we need to proceed based on what the customer has said.  If the customer is actively using the software, the CFO has promised a renewal but is tied up on a European vacation, I would mark the numbers “preliminary” and count the contract as renewed.  If, however, the customer has not used the software in months and will not return our phone calls, I would count the contract as churned.

Suppose we receive a churn notice on 5/1 for a contract that renews on 6/30.  When should we count the churn?  A Bessemer SaaS fanatic would point to their definition of committed monthly recurring revenue (CMRR) [12] and say we should remove the contact from the MRR base on 5/1.  While I agree with Bessemer’s views in general — and specifically on things like on preferring ARR/MRR to ACV and TCV — I get off the bus on the whole notion of “committed” ARR/MRR and the ensuing need to remove the contract on 5/1.  Why?

  • In point of fact the customer has licensed and paid for the service through 6/30.
  • The company will recognize revenue through 6/30 and it’s much easier to do so correctly when the ARR is still in the ARR base.
  • Operationally, it’s defeatist. I don’t want our company to give up and say “it’s over, take them out of the ARR base.” I want our reaction to be, “so they think they don’t want to renew – we’ve got 60 days to change their mind and keep them in.” [13]

We should use the churn notice (and, for that matter, every other communication with the customer) as a way of improving our quarterly churn forecast, but we should not count churn until the contract period has ended, the customer has not renewed, and the customer has maintained their intent not to renew in coming weeks.

Non-payment, while hopefully infrequent, is another tricky issue.  What do we do if a customer gives us a renewal order on 6/30, payable in 30 days, but hasn’t paid after 120?  While the idealist in me wants to match the churn ARR to the period in which the contract was available to renew, I would probably just show it as churn in the period in which we gave up hope on the receivable.

Expansion Along the Way (ATW)

Non-payment starts to introduce the idea of timing mismatches between ARR-changing events and renewals cohorts.  Let’s consider a hopefully more frequent case:  ARR expansion along the way (ATW).  Consider this example.

ATW expansion

To decide how to handle this, let’s think operationally, both about how our finance team works and, more importantly, about how we want our customer success managers (CSMs) to think.  Remember we want CSMs to each own a set of customers, we want them to not only protect the ARR of each customer but to expand it over time.  If we credit along-the-way upsell in our rate calculations at renewal time, we shooting ourselves in the foot.  Look at customer Charlie.  He started out with 100 units and bought 20 more in 4Q15, so as we approach renewal time, Charlie actually has 120 units available to renew (ATR), not 100 [14].  We want our CSMs basing their success on the 120, not the 100.  So the simple rule is to base everything not on the original cohort but on the available to renew (ATR) entering the period.

This begs two questions:

  • When do we count the along-the-way upsell bookings?
  • How can we reflect those 40 units in some sort of rate?

The answer to the first question is, as your finance team will invariably conclude, to count them as they happen (e.g., in 4Q15 in the above example).

The answer to the second question is to use a retention rate, not a churn rate.  Retention rates are cohort-based, so to calculate the net retention rate for the 2Q15 cohort, we divide its present value of 535 by its original value of 500 and get 107%.

Never, ever calculate a retention rate in reverse – i.e., starting a group of current customers and looking backwards at their ARR one year ago.  You will produce a survivor biased answer which, stunningly, I have seen some public companies publish.  Always run cohort analyses forwards to eliminate survivor bias.

Off-Cycle Activity

Finally, we need to consider how to address off-cycle (or extra-cohort) activity in calculating churn and related rates.  Let’s do this by using a big picture example that includes everything we’ve discussed thus far, plus off-cycle activity from two customers who are not in the 2Q16 ATR cohort:  (1) Foxtrot, who purchased in 3Q14, renewed in 3Q15, and who has not paid, and (2) George, who purchased in 3Q15, who is not yet up for renewal, but who purchased 50 units of upsell in 2Q16.

big picture

Foxtrot should count as churn in 2Q16, the period in which we either lost hope of collection (or our collections policy dictated that collection we needed to de-book the deal). [15]

George should count as expansion in 2Q16, the period in which the expansion booking was taken.

The trick is that neither Foxtrot nor George is on a 2Q renewal cycle, so neither is included in the 2Q16 ATR cohort.  I believe the correct way to handle this is:

  • Both should be factored into gross, net, account-level churn, and upsell.
  • For rates where we include them in the numerator, for consistency’s sake we must also include them in the denominator. That means putting the shrinkage in the numerator and adding the ATR of a shrinking (or lost) account in denominator of a rate calculation.  I’ll call this the “+” concept, and define ATR+ as inclusive of such additional logos or ARR resulting from off-cycle accounts [16].

Rate Calculations

We are now in the position to define and calculate the churn rates that I use and track:

  • Simple churn rate = net shrinkage / starting period ARR * 4.  Or, in English, the net change in ARR from existing customers divided by starting period ARR (multiplied by 4 to annualize the rate which is measured against the entire ARR base). As the name implies, this is the simplest churn rate to calculate. This rate will be negative whenever expansion is greater than shrinkage. Starting period ARR includes both ATR and non-ATR contracts (including potentially multi-year contracts) so this rate takes into account the positive effects of the non-cancellability of multi-year deals.  Because it takes literally everything into account, I think this is the best rate for valuing the annuity of your ARR base.
  • Logo churn rate = number of discontinuing logos / number of ATR+ logos. This rate tells us the percent of customers who, given the chance, chose to discontinue doing business with us.  As such, it provides an ARR-unweighted churn rate, providing the best sense of “how happy” our customers are, knowing that there is a somewhat loose correlation between happiness and renewal [16].  Remember that ATR+ means to include any discontinuing off-cycle logos, so the calculation is 1/16 = 6.3% in our example.
  • Retention rate = current ARR [time cohort] / time-ago ARR [time cohort]. In English, the current ARR from some time-based cohort (e.g., 2Q15) divided by the year-ago ARR from that same cohort.  Typically we do this for the one-year-ago or two-years-ago cohorts, but many companies track each quarter’s new customers as a cohort which they measure over time.  Like simple churn, this is a great macro metric that values the ARR annuity, all in.
  • Gross churn rate = gross shrinkage / ATR+. This churn rate is important because it reveals the difference between companies that have high shrinkage offset by high expansion and companies which simply have low shrinkage.  Gross churn is a great metric because it simply shows the glass half-empty view:  at what rate is ARR leaking out of your bucket before offset it with refills in the form of expansion ARR.
  • Account-level churn rate = account-level churn / ATR+. This churn rate foots to the reported churn ARR in our leaky bucket analysis (which uses account-level churn), partially offsets shrinkage with expansion at an account-level, and is how most SaaS companies actually calculate churn.  While perhaps counter-intuitive, it reflects a philosophy of examining, at an account basis, what happens to value of our each of our customers when we allow shrinkage to be offset by expansion (which is what we want our CSM reps doing) leaving any excess as upsell.  This should be our primary churn metric.
  • Net churn rate = net shrinkage / ATR+.  This churn rate offsets shrinkage with expansion not at the account level, but overall.  This is similar to the simple churn rate but with the disadvantage of looking only at ATR and not factoring in the positive effects of non-cancellability of multi-year deals.    Ergo, I prefer using the simple churn rate to the net churn rate in valuing the SaaS annuity.

# # #

Notes

[1] Replacing these posts in the process.

[2] The 10% churn group decays from 100 units to 53 in value after 7 years, while the 20% group decays to 26.

[3] We’ll sidestep the question of who is responsible for installed-based expansion in this post because companies answer it differently (e.g., sales, customer success, account management) and the good news is we don’t need to know who gets credited for expansion to calculate churn rates.

[4] Discussing churn in dollars and renewals in rates.

[5] For example, if a customer signed a one-year contract for 100 units and then was offered a 5% discount to sign a three-year renewal, you would generate 5 units of ARR churn.

[6] Or, as I said in a prior post, should I net first or sum first?

[7] And yes, sometimes unhappy customers do renew (e.g., if they’ve been too busy to replace you) and happy customers don’t (e.g., if they get a new key executive with different preferences) but counting logos still gives you a nice overall indication.

[8] Note that I have capitulated to the norm of saying “gross” churn means before offset and thus “net” churn means after netting out shrinkage and expansion.  (Beware confusion as this is the opposite of my prior position where I defined “net” to mean “net of expansion,” i.e., what I’d now call “gross.”)

[9] Otherwise, you can just look at net shrinkage which offsets all shrinkage by all expansion.  The idea of account-level churn is to restrict the ability to offset shrinkage with expansion across accounts, in effect, telling your customer success reps that their job is to, contract by contract, minimize shrinkage and ensure expansion.

[10] “Offset” meaning ARR used to offset shrinkage that ends up neither churn nor upsell.

[11] While this approach works fine for most (inherently single-product) SaaS startups it does not work as well for large multi-product SaaS vendors where the failure of product A might be totally or partially masked by the success of product B.  (In our example, I deliberately had all the shrinkage coming from downsell of product A to make that point.  The product or general manager for product A should own the churn number that product and be trying to find out why it churned 80 units.)

[12] MRR = monthly recurring revenue = 1/12th of ARR.  Because enterprise SaaS companies typically run on an annual business rhythm, I prefer ARR to MRR.

[13] Worse yet, if I churn them out on 5/1 and do succeed in changing their mind, I might need to recognize it as “new ARR” on 6/30, which would also be wrong.

[14] The more popular way of handling this would have been to try and extend the original contract and co-terminate with the upsell in 4Q16, but that doesn’t affect the underlying logic, so let’s just pretend we tried that and it didn’t work for the customer.

[15] Whether you call it a de-booking or bad receivable, Foxtrot was in the ARR base and needs to come out.  Unlike the case where the customer has paid for the period but is not using the software (where we should churn it at the end of the contract), in this case the 3Q15 renewal was effectively invalid and we need to remove Foxtrot from the ARR base at some defined number of days past due (e.g., 90) or when we lose hope of collection (e.g., bankruptcy).

[16] I think the smaller you are the more important this correction is to ensure the quality of your numbers.  As a company gets bigger, I’d just drop the “+” concept whenever it’s only changing things by a rounding error.

[17] Use NPS surveys for another, more precise, way of measuring happiness.  See [7] as well.