Category Archives: Churn

Lazy NRR is Not NRR. Accept No Imitations or Subtitutes.

Posted on October 5, 2022 | 1 comment

The other day I was looking at an ARR bridge [1] with a young finance ace. He made a few comments and concluded with, “and net revenue retention (NRR) is thus 112%, not bad.”

I thought, “Wait, stop! You can’t calculate NRR from an ARR bridge [2].” It’s a cohort-based measure. You need to look at the year-ago cohort of customers, get their year-ago ARR, get that same group’s current ARR, and then divide the current ARR by the year-ago.

“Yes, you can,” he said. “Just take starting ARR, add net expansion, and divide by starting ARR. Voila.”

Expecto patronum! Protect me from this dark magic. I don’t know what that is, I thought, but that’s not NRR.

Then I stewed on it for a bit. In some ways, we were both right.

Under the right circumstances, I think you can calculate NRR using an ARR bridge [3]. But the whole beauty of the metric is to float over that definitional swamp and just divide two numbers — so I inherently don’t want to.
My friend’s definition, one I suspect is common in finance whiz circles, was indeed one shortcut too short. But, under the right circumstances, you can improve it to work better in certain cases.

The Trouble with Churn Rates
For a long time, I’ve been skeptical of calculations related to churn rates. While my primary problems with churn rates were in the denominator [4], there are also potential problems with the numerator [5]. Worse yet, once churn rates get polluted, all downstream metrics get polluted along with them – e.g., customer lifetime (LT), lifetime value (LTV), and ergo LTV/CAC. Those are key metrics to measure the value of the installed base — but they rely on churn rates which are easily gamed and polluted.

What if there were a better way to measure the value of the installed base?

There is. That’s why my SaaStr 2019 session title was Churn is Dead, Long Live Net Dollar Retention [6]. The beauty of NRR is that it tells you want you want to know – once you acquire customers, what happens to them? – and you don’t have to care which of four churn rates were used. Or how churn ARR itself was defined. Or if mistakes were made in tracking flows.

You just need to know two things: ARR-now and ARR-then for “then” cohort of customers [7].

A Traditional ARR Bridge
To make our point, let’s review a traditional ARR bridge.

Nothing fancy here. Starting ARR plus new ARR of two types: new logo customers (aka, new logo ARR) and existing customers (aka, expansion ARR). We could have broken churn ARR into two types as well (shrinkage and lost), but we didn’t need that breakout for this exercise.

Now, let’s add my four favorite rows to put beneath an ARR bridge [8]:

Here’s a description:

Net new ARR = New ARR – churn ARR. How much the water level increased in the SaaS leaky bucket of ARR. Here in 1Q21, imagine we spent $2,250K in S&M in the prior quarter. Our CAC ratio would be a healthy 1.0 on a new ARR basis, but a far less healthy 2.1 on a net new ARR basis. That’s due to our quarterly churn of 8%, which when annualized to 32%, flies off the charts.
Expansion as a percent of new ARR = expansion ARR / new ARR. My sense is 30% is a magic number for an established growth-phase startup. If you’re only at 10%, you’re likely missing the chance to expand your customers (which will also show up in NRR). If you’re at 50%, I wonder why you can’t sell more new logo customers. Has something changed in the market or the salesforce?
Net expansion = expansion ARR – churn ARR. Shows the net expansion or contraction of the customer base during the quarter. How much of the bucket increase was due to existing (as opposed to new) customers?
Churn rate, quarterly. I included this primarily because it raises a point we’ll hit when discussing lazy NRR. Many people calculate this as = churn ARR / starting ARR (quarter). That’s what I call “simple quarterly,” and you’ll note that it’s always lower than just “quarterly,” which I define as = churn ARR / starting ARR (year) [9]. The trace-precedents arrows below show the difference.

Lazy NRR vs. Cohort-Based NRR
With that as a rather extensive warm-up, let’s discuss what I call lazy NRR.

Lazy NRR is calculated as described above = (starting ARR + net expansion) / starting ARR. Lazy NRR is a quarterly expansion metric.

Let’s look at a detailed example to see what’s really being measured.

This example shows the difference between cohort-based NRR and Lazy NRR:

Cohort-based NRR, a year-over-year metric that shows expansion of the two year-ago customers (customers 1 and 2). This is, in my book, “real NRR.”
Lazy NRR, simple quarterly, which compares net expansion within the current quarter to starting ARR for that quarter.

The point of the trace-precendents arrows shows you that while the result coincidentally might be similiar (and in this case it is not), that they are measuring two completely different things.

Let’s talk about the last row, lazy NRR, cohort-based approximation, which takes starting ARR from year-ago customers, then adds (all) net expansion over the year and divides by the year-ago starting ARR. The problem? Customer 3. They are not in the year-ago cohort, but contribute expansion to the numerator because, with only an ARR bridge, you can’t separate year-ago cohort net expansion from new-customer net expansion. To do that, you’d need to have ARR by customer [10].

Lazy NRR is not NRR. NRR is defined as snapshot- and cohort-based. Accept no substitutes or imitations. Always calculate NRR using snapshots and cohorts and you’ll never go wrong.

Layer Cakes Tell No Lies
While I’m usually quite comfortable with tables of numbers and generally prefer receiving them in board reports, this is one area where I love charts, such as this layer cake that stacks annual cohorts atop each other. I like these layer cakes for several reasons:

They’re visual and show you what’s happening with annual cohorts.
Like snapshot- and cohort-based NRR, they leave little to no room for gaming. (They’re even harder to survivor bias as you’d have to omit the prior-period ARR.)
Given my now-distant geophysics background, they sometimes remind me of sedimentary rock. (Hopefully yours don’t look like that, as unmetamorphized, sedimentary rock represents an NRR of only 100%!)

The spreadsheet for this post is available here.

(The post was revised a few times after initial publication to fix mistakes and clarify points related to the cohort-based approximation. In the end, the resultant confusion only convinced me more to only and always calcuate NRR using cohorts and snapshots.)

# # #

Notes
Edited 10/8/22 to replace screenshots and fix spreadsheet bug in prior version.

[1] Starting ARR + new ARR (from new logo and expansion) – churn ARR (from shrinkage and lost) = ending ARR

[2] I probably should have said “shouldn’t.” Turns out, I think you can, but I know you shouldn’t. We’ll elaborate on both in this post.

[3] Those conditions include a world where customers expand or contract only on an annual basis (as you are unable to exclude expansion or contraction from customers signed during the year since they’re not sepearated in an ARR bridge) and, of course, a clear and consistent definition of churn, playing fairly with no gaming designed understate churn or overstate expansion, and avoidance of mistakes in calculations.

[4] Churn rates based off the whole ARR pool can halve (or more than halve) those based on the available to renew (ATR) pool, for example if a company’s mean contract duration is 2 or 3 years. ARR churn rates are probably better for financial calculations, but ATR churn rates are a better indicator of customer satisfaction

[5] Examples of potential problems, not all strictly related to calculation of churn ARR, but presented for convenience.

Expansion along the way. Consider a customer who buys 100-unit contract, expands to 140 the next quarter (without signing a new one-year agreement that extends the contract), and then at the annual renewal renews for 130. The VP of CS wants to penalize the account’s CSM for 10 units of churn whereas the CFO wants to tell investors its 30 units of expansion. Which is it? Best answer IMHO is 40 units of expansion in the second quarter and 10 units of churn at the renewal, but I’ve seen people/systems that don’t do it that way. NRR sees 130% rate regardless of how you count expansion and churn.

Potential offsets and the definition of customer – division 1 has 100 units and shrinks to 80 at renewal while a small 40-unit new project starts at division 2. Is that two customers, one with 20 units of churn and one new 40-unit customer or is it one customer with 20 units of expansion? NRR sees either 80% rate or 120% rate as function of customer definition, but I’d hope the NRR framing would make you challenge yourself to ask: was division 2 really a customer and ergo belong in the year-ago cohort?

Potential offsets and the definition of product – a customer has 100 units of product A, is unhappy, and shrinks to A to 60 units while buying your new product B for 40. Did any churn happen? In most systems, the answer is no because churn is calculated at the account level. Unless you’re also tracking product-level churn, you might have trouble seeing that your new product is simply being given away to placate customers unhappy with your first one. NRR is inherently account-level and doesn’t solve this problem – unless you decide to calculate product-level NRR, to see which products are expanding and which are shrinking.

Adjustments. International companies need to adjust ARR for fluctuations in exchange rates. Some companies adjust ARR for bad debt or non-standard contracts. Any and all of these adjustments complicate the calculation of churn ARR and churn rates.

Gaming. Counting trials as new customers and new ARR, but excluding customers <$5K from churn ARR calculations (things won’t foot but few people check). Renewing would-be churning customers at $1 for two years to delay count-based churn reporting (ARR churn rates and NRR will see through this). Survivor biasing calculations by excluding discontinuing customers. Deferring ARR churn by renewing would-be churning customers with net 360 payables and a handshake (e.g., side letter) to not collect unless thing XYZ can be addressed (NRR won’t see through this, but cash and revenue won’t align).

[6] Since I now work frequently with Europe as part of my EIR job with Balderton Capital, I increasingly say “NRR” instead of “NDR” (net dollar retention), because for many of the companies I work with it’s actually net Euro retention. The intent of “dollar” was never to indicate a currency, but instead to say: “ARR-based, not count-based.” NRR accomplishes that.

[7] Some companies survivor bias their NRR calculation by using the now-value and then-value of the now cohort, eliminating discontinuing customers from the calculation. Think: of the mutual funds we didn’t shut down, the average annual return was 12%.

[8] If you download the spreadsheet and expand the data groups you can see some other interesting rows as well.

[9] The flaw in “simple quarterly” churn is that, in a world that assumes pure annual contracts, you’re including people who were not customers at the start of the year and ergo cannot possibly churn in the calculations. While you use the same numerator in each case, you’re using an increasing denominator and with no valid reason for doing so. See here for more.

[10] In which case you might as well calculate NRR as defined, using the current and year-ago snapshots.

1 Comment

Posted in Churn, Customer Success, Metrics, NDR, SaaS, Startups

SaaStr 2020 Session Preview: Churn is Dead, Long Live Net Dollar Retention!

Posted on August 30, 2020 | Leave a comment

Reunited with old friend Tracy Eiler on the speaker page

The SaaStr Annual conference was delayed this year, but Jason & crew know that the show must go on. So this year’s event has been rechristened SaaStr Annual @ Home and is being held in virtual, online format on September 2nd and 3rd. The team at SaaStr have assembled a strong, diverse line-up of speakers to provide what should be another simply amazing program.

The purpose of this post is to provide a teaser to entice you to attend my session, Churn is Dead, Long Live Net Dollar Retention Rate, bright and early on Wednesday, September 2nd at 8:00 AM.

“I eat SaaS metrics for breakfast,” he thinks. Or at least, “with.”

In this session, we’ll cover:

Separating a SaaS business into its two component parts
What makes SaaS companies so interesting for PE buyers
The SaaS leaky bucket of ARR
SaaS unit economics 101: CAC, LTV, LTV/CAC, and CAC payback period
The three, fairly lethal problems with churn rates
Why “ARR is a fact and churn is an opinion”
Cohort analysis basics and survivor bias
Net dollar retention (NDR) rate definition and benchmarks
Explanatory power of NDR vs. ARR growth and the Rule of 40 in determining valuation multiples
The NDR implications of Goodhart’s Law
Applying Goodhart’s Law to NDR
The next frontier: remaining performance obligation (RPO)

While the topic might seem a little dry, the content is critically important to any SaaS executive, and I can assure you the presentation will be fast-paced, fun, and anything but dry.

I hope you can attend and I look forward to seeing you there.

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

Posted on May 11, 2019 | 3 comments

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:

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

(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.

3 Comments

Posted in Churn, Metrics, SaaS, Uncategorized

Are You Counting Payments as Renewals?

Posted on March 6, 2019 | 15 comments

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%?

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.

15 Comments

Posted in Churn, Metrics, SaaS, Startups, Uncategorized, VC

The Three Types of Customer Success Manager

Posted on September 1, 2018 | 2 comments

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

Product-oriented
Process-oriented
Sales-oriented

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

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 [6]. 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?

Conclusion
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.

# # #

Notes

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

[2] 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?

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

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

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

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

2 Comments

Posted in Churn, Customer Success, SaaS, Sales Model, Uncategorized