Category Archives: Metrics

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:

Rule of 40 Glideslope Planning

Enterprise SaaS companies need a lot of money to grow. The median company spends $1.32 to acquire $1.00 in annual recurring revenue (ARR) [1].  They need to make that investment for 14 years before getting to an IPO.  It all adds up to a median of $300M in capital raised prior to an IPO.

With such vast amounts of money in play, some say “it’s a growth at all costs” game.  But others hold to the Rule of 40 which attempts to balance growth and profitability with a simple rule:  grow as fast as you want as long as your revenue growth rate + your free cashflow margin >= 40%.

The Rule of 40 gets a lot of attention, but I think that companies are not asking the right question about it.  The right question is not “when should my growing startup be Rule of 40 compliant?” [2]

For more than half of all public SaaS companies, the answer to that question, by the way, is “not yet.”  Per multiple studies I’ve read the median Rule of 40 score for public SaaS companies is ~31%, meaning that more than half of public SaaS companies are not Rule of 40 compliant [3].

So, unless you’re an absolutely amazing company like Elastic (which had a Rule of 40 score of 87% at its IPO), you probably shouldn’t be unrealistically planning to become Rule of 40 compliant three years before your IPO [4].  If you do, especially if you’re well funded and don’t need additional expense constraints, you might well compromise growth with a premature focus on the Rule of 40, which could shoot off your corporate foot in terms of your eventual valuation.

If “when should we be Rule of 40 compliant” is the wrong question, then what’s the right one?

What should my company’s Rule of 40 glideslope be?

That is, over the next several years what is your eventual Rule of 40 score target and how do you want to evolve to it?  The big advantage of this question is that the answer isn’t “a year” and it doesn’t assume Rule of 40 compliance.  But it does get you to start thinking about and tracking your Rule of 40 score.

I built a little model to help do some what-if analysis around this question.  You can download it here.

r40-1

In our example, we’ve got a 5 year-old, $30M ARR SaaS company planning the next five years of its evolution, hopefully with an IPO in year 8 or 9.  The driver cells (orange) define how fast you want to grow and what you want your Rule of 40 glideslope to be.  Everything else is calculated.  At the bottom we have an overall efficiency analysis:  in each year how much more are we spending than the previous year, how much more revenue do we expect to get, and what’s the ratio between the two (i.e., which works like kind of an incremental revenue CAC).  As we improve the Rule of 40 score you can see that we need to improve efficiency by spending less for each incremental dollar of revenue.  You can use this as a sanity check on your results as we’ll see in a minute.

Let me demonstrate why I predict that 9 out 10 ten CFOs will love this modeling approach.  Let’s look at every CFO’s nightmare scenario.  Think:  “we can’t really control revenues but we can control expenses so my wake up in the middle of the night sweating outcome is that we build expenses per the plan and miss the revenues.”

r40-2

In the above (CFO nightmare) scenario, we hold expenses constant with the original plan and come in considerably lighter on revenue.  The drives us miles off our desired Rule of 40 glideslope (see red cells).  We end up needing to fund $42.4M more in operating losses than the original plan, all to generate a company that’s $30.5M smaller in revenue and generating much larger losses.  It’s no wonder why CFOs worry about this.  They should.

What would the CFO really like?  A Rule-of-40-driven autopilot.

As in, let’s agree to a Rule of 40 glideslope and then if revenues come up short, we have all pre-agreed to adjust expenses to fall in line with the new, reduced revenues and the desired Rule of 40 score.

r40-3

That’s what the third block shows above.  We hold to the reduced revenues of the middle scenario but reduce expenses to hold to the planned Rule of 40 glideslope.  Here’s the bad news:  in this scenario (and probably most real-life ones resembling it) you can’t actually do it — the required revenue-gathering efficiency more than doubles (see red cells).  You were spending $1.38 to get an incremental $1 of revenue and, to hold to the glideslope, you need to instantly jump to spending only $0.49.  That’s not going to happen.  While it’s probably impossible to hold to the original {-10%, 0%, 5%} glideslope, if you at least try (and, e.g., don’t build expenses fully to plan when other indicators don’t support it), then you will certainly do a lot better than the {-10%, -32%, -42%} glideslope in the second scenario.

In this post, we’ve talked about the Rule of 40 and why startups should think about it as a glideslope rather than a short- or mid-term destination.  We’ve provided you with a downloadable model where you can play with your Rule of 40 glideslope.  And we’ve shown why CFOs will inherently be drawn to the Rule of 40 as a long-term planning constraint, because in many ways it will help your company act like a self-righting ship.

# # #

Notes

[1] The 75th percentile spends $1.92.  And 25% spend more than that.  Per KeyBanc.

[2] Rule of 40 compliant means a company has an rule of 40 score >= 40%.  See next note.

[3] Rule of 40 score is generally defined as revenue growth rate + free cashflow (FCF) margin.  Sometimes operating margin or EBITDA margin is used instead because FCF margin can be somewhat harder to find.

[4] I’m trying to find data a good data set of Rule of 40 scores at IPO time but thus far haven’t found one.  Anecdotally, I can say that lots of successful high-growth SaaS IPOs (e.g., MongoDB, Anaplan, and Blackline) were not Rule of 40 compliant at IPO time — nor were they well after, e.g., as of Oct 2018 per JMP’s quarterly software review.  It seems that if growth is sufficiently there, that the profitability constraint can be somewhat deferred in the mind of the market.

An Update on the SaaS Rule of 40

Thanks to the folks at Piper Jaffray and their recently published 2018 Software Market Review, we can take a look at a recent chart that plots public software company enterprise value (EV) vs. Rule of 40 (R40) score = free cash-flow margin + revenue growth rate.

As a reminder, the Rule of 40 is an industry rule of thumb that says a high-growth SaaS company can burn as much cash as it likes in order to drive growth — as long as its growth rate is 40 percentage points higher than its free cashflow margin.  It’s an attempt at devising a simple rule to help software companies with the complex question of how to balance growth and profitability.

One past study showed that while Rule of 40 compliant software companies made up a little more than half of all public software companies that they captured more than 80% of all public market cap.

Let’s take a look at Piper’s chart which plots R40 score on the X axis and enterprise value (EV) divided by revenue on the Y axis.  It also plots a presumably least squares fit line through the data points.

newer rule of 40

Source: PJC Analysis and SAP Capital IQ as of 12/31/2018

Of note:

  • Less than half of all companies in this set are Rule of 40 compliant; the median R40 score was 31.7%.
  • The median multiple for companies in the set was 6.6x.
  • The slope of the line is 12, meaning that for each 10 percentage points of R40 score improvement, a company’s revenue multiple increases by 1.2x.
  • R^2 is 0.42 which, if I recall correctly, means that the R40 score explains 42% of the variability of the data.  So, while there’s lots it doesn’t explain, it’s still a useful indicator.

A few nerdier things of note:

  • Remember that the line is only valid in the data range presented; since no companies had a negative R40 score, it would be invalid extrapolation to simply continue the line down and to the left.
  • Early-stage startup executives often misapply these charts forgetting the selection bias within them. Every company on the chart did well enough at some point in terms of size and growth to become a public SaaS company.  Just because LivePerson (LPSN) has a 4x multiple with an R40 score of 10% doesn’t mean your $20M startup with the sames score is also worth 4x.   LPSN is a much bigger company (roughly $250M) and and already cleared many hurdles to get there.

The big question around the Rule of 40 is:  when should companies start to target it?   A superstar like Elastic had 76% growth and 8% FCF margin so a R40 score of 84% at its spectacular IPO.  However, Avalara had 26% growth and -28% FCF margin for an R40 score of -2% and its IPO went fine.  Ditto Anaplan.

I’ll be doing some work in the next few months to try and get better data on R40 trajectory into an IPO.  My instinct at this point is that many companies target R40 compliance too early, sacrifice growth in the process, and hurt their valuations because they fail to deliver high growth and don’t get the assumed customer acquisition cost efficiencies built in the financial models, which end up, as one friend called them, spreadsheet-induced hallucinations.

Video of my SaaStr 2018 Presentation: Ten Non-Obvious Things About Scaling SaaS

While I’ve blogged about this presentation before, I only recently stumbled into this full-length video of this very popular session — a 30-minute blaze through some subtle SaaS basics.  Enjoy!

I look forward to seeing everyone again at SaaStr Annual 2019.

The Big Mistake You Might Be Making In Calculating Churn: Failing to Annualize Multi-Year ATR Churn Rates

Most of the thinking, definitions, and formulas regarding SaaS unit economics is based on assumptions that no longer reflect the reality of the enterprise SaaS environment.  For example, thinking in terms of MRR (monthly recurring revenue) is outdated because most enterprise SaaS companies run on annual contracts and thus we should think in terms of ARR (annual recurring revenue) instead.

Most enterprise SaaS companies today do a minimum one-year contract and many do either prepaid or non-prepaid multi-year contracts beyond that. In the case of prepaid multi-year contracts, metrics like the CAC payback period break (or at the very least, get difficult to interpret).  In the case of multi-year contacts, calculating churn correctly gets a lot more complicated – and most people aren’t even aware of the issue, let alone analyze it correctly.

If your company does multi-year contracts and you are not either sidestepping this issue (by using only ARR-pool-based rates) or correcting for it in your available-to-renew (ATR) churn calculations, keep reading.  You are possibly making a mistake and overstating your churn rate.

A Multi-Year Churn Example
Let’s demonstrate my point with an example where Company A does 100% one-year deals and Company B does 100% three-year deals.  For simplicity’s sake, we are going to ignore price increases and upsell [1].  We’re also not going to argue the merits of one- vs. three-year contracts; our focus is simply how to calculate churn in a world of them.

In the example below, you can see that Company A has an available-to-renew-based (ATR-based) [2] churn rate of 10%.  Company B has a 27% ATR-based churn rate.  So we can quickly conclude that Company A’s a winner, and Company B is a loser, right?

Capture

Not so fast.

At the start of year 4, a cohort of Company A customers is worth 72.9 units, the exact same as a cohort of Company B customers.  In fact, if you look at lifetime value (LTV), the Company B cohort is worth nearly 10% more than the Company A cohort [3].

my churn1

Wait a minute!  How can a company with 27% churn rate be “better” than a company with 10% churn rate?

It’s All About Exposure:  How Often are Deals Exposed to the Churn Rate?
One big benefit of multi-year deals is that they are exposed to the churn rate less frequently than one-year deals.  When you exclude the noise (e.g., upsell, discounts, and price increases), and look at churn solely as a decay function, you see that the N-year retention rate [4] is (1-churn rate)^N.  With 10% churn, your 2-year retention rate is (1-0.1)^2 = 0.9^2 = 0.81.  Your 3-year retention rate is (1-0.1)^3 = 0.9^3 = 0.729, or a retention rate of 73%, equivalent to a churn rate of 27%.

Simply put, churn compounds so exposing a contract to the churn rate less often is a good thing:  multi-year deals do this by excluding contracts from the ATR pool, typically for one or two years, before they come up for renewal [5].  This also means that you cannot validly compare churn rates on contracts with different duration.

This is huge.  As we have just shown, a 10% churn rate on one-year deals is equivalent to a 27% churn rate on three-year deals, but few people I know recognize this fact.

I can imagine two VCs talking:

“Yo, Trey.”

“Yes.”

“You’re not going to believe it, I saw a company today with a 27% churn rate.”

“No way.”

“Yep, and it crushed their LTV/CAC — it was only 1.6.”

“Melting ice cube.  Run away.”

“I did.”

Quite sad, in fact, because with a correct (annualized) churn rate of 10% and holding the other assumptions constant [6], the LTV/CAC jumps to healthy 4.4.  But any attempt to explain a 27% churn rate is as likely to be seen as a lame excuse for a bad number as it is to be seen as valid analysis.

Best Alternative Option:  Calculate Churn Rates off the Entire ARR Pool
I’m going to define the 27% figure as the nominal ATR-based churn rate.  It’s what you get when you take churn ARR / ATR in any given period.  I call it a nominal rate because it’s not annualized and it doesn’t reflect the varying distribution of 1Y, 2Y, and 3Y deals that are mixed in the ATR pool in any given quarter.  I call it nominal because you can’t validly compare it to anything [7].

Because correcting this to a more meaningful rate is going to involve a lot of brute force math, I’ll first advise you to do two things:

  • Banish any notion from your mind that ATR rates are somehow “more real” than churn rates calculated against the entire ARR pool [8].
  • Then use churn rates calculated against the entire ARR pool and sidestep the mess we’re about to enter in the next section [9] where we correct ATR-based churn rates.

In a world of mixed-duration contracts calculating churn rates off the entire ARR pool effectively auto-corrects for the inability of some contracts to churn.  I have always believed that if you were going to use the churn rate in a math function (e.g., as the discount rate in an NPV calculation) that you should only use churn rates calculated against the entire ARR pool because, in a mixed multi-year contract world, only some of the contracts come up for renewal in any given period.  In one sense you can think of some contracts as “excluded from the available-to-churn (ATC) pool.”  In another, you can think of them as auto-renewing.  Either way, it doesn’t make sense in a mixed pool to apply the churn rate of those contracts up for renewal against the entire pool which includes contracts that are not.

If you want to persist in using ATR-based churn rates, then we must correct for two problems:  we need to annualize the multi-year rates, and we then need to calculate ATR churn using an ATR-weighted average of the annualized churn rates by contract duration.

Turning Nominal ATR Churn into Effective, Annualized ATR Churn
Here’s how to turn nominal ATR churn into an effective, annualized ATR churn rate [10] [11]:

Step 1:  categorize your ATR and churn ARR by contract duration.  Calculate a 1Y churn rate and nominal 2Y and 3Y ATR churn rates.

Step 2:  annualize the nominal multi-year (N-year) churn rates by flipping to retention rates and taking the Nth root of the retention rate.  For example, our 27% 3-year churn rate is equivalent to a 73% 3-year retention rate, so take the cube root of 0.73 to get 0.9.  Then flip back to churn rates and get 10%.

Step 3:  do an ATR-weighted average of the 1Y and annualized 2Y and 3Y churn rates.  Say your ATR was 50% 1Y, 25% 2Y, and 25% 3Y contracts and your annualized churn rates were 10%, 12%, and 9%.  Then the weighted average would be (0.5*0.10) + (0.25*0.12) + (0.25*0.09) = 10.25%, as your annualized, effective ATR churn rate.

That’s it.  You’ve now produced an ATR churn rate that is comparable to a one in a company that does only 1-year contracts.

Conclusion
If nothing else, I hope I have convinced that you it is invalid to compare churn rates on contracts of different duration and ergo that is simpler to generally calculate churn rates off the entire ARR pool.  If, however, you still want to see ATR-based churn rates, then I hope I’ve convinced you that you must do the math and calculate ATR churn as a weighted average of annualized one-, two-, and three-year ATR churn rates.

# # #

Notes
[1] In a world of zero upsell there is no difference between gross and net churn rates, thus I will simply say “churn rate” in this post.

[2] As soon as you start doing multi-year contracts then the entire ARR base is no longer up for renewal each year.  You therefore need a new concept, available to renew (ATR), which reflects only that ARR up for renewal in a given period.

[3] Thanks to its relatively flatter step-wise decay compared to Company A’s more linear decay.

[4] Retention rate = 1 – churn rate.

[5] If it helps, you can think of the ATR pool in a glass half-empty way as the available-to-churn pool.

[6] Assuming CAC ratio of 1.8 and subscription gross margins of 80%.

[7] Unless your company has a fixed distribution of deals by contract duration – e.g., a degenerate case being 100% 3Y deals.  For most companies the average contract duration in the inbound ATR pool is going to vary each quarter.  Ergo, you can’t even validly compare this rate to itself over time without factoring in the blending.

[8] Most people I meet seem to think ATR rates are more real than rates based on the entire ARR pool.  Sample conversation  — “what’s your churn rate?”  “6%.”  “Gross or net?  “Gross.”  “No, I mean your real churn rate – what gets churned divided only by what was up for renewal.”    The mistake here is in thinking that using ATR makes it comparable to a pure one-year churn rate – and it doesn’t.

[9] Gross churn = churn / starting period ARR.  Net churn = (gross churn – upsell) / starting period ARR.

[10] I thought about trying a less brute-force way using average contract duration (ACD) of the ATR pool, but decided against it because this method, while less elegant, is more systematic.

[11] Note that this method will still understate the LTV advantage of the more step-wise multi-year contract decay because it’s not integrating the area under the curve, but instead intersecting what’s left of the cohort after N years.  In our first example, the 1Y and 3Y cohorts both had 73 units of ARR, but because the multi-year cohort decayed more slowly it’s LTV to that point was about 10% higher.

The Use of Ramped Rep Equivalents (RREs) in Sales Analytics and Modeling

[Editor’s note:  revised 7/18, 6:00 PM to fix spreadsheet error and change numbers to make example easier to follow, if less realistic in terms of hiring patterns.]

How many times have you heard this conversation?

VC:  how many sales reps do you have? 

CEO:  Uh, 25.  But not really.

VC:  What do you mean, not really?

CEO:  Well, some of them are new and not fully productive yet.

VC:  How long does it take for them to fully ramp?

CEO:  Well, to full productivity, four quarters.

VC:  So how many fully-ramped reps do you have?

CEO:  9 fully ramped, but we have 15 in various stages of ramping, and 1 who’s brand new …

There’s a better way to have this conversion, to perform your sales analytics, and to build your bookings capacity waterfall model.  That better way involves creating a new metric called ramped rep equivalents (RREs). Let’s build up to talking about RREs by first looking at a classical sales bookings waterfall model.

ramped rep equivalents, picture 1, revised

I love building these models and they’re a lot of fun to play with, doing what-if analysis, varying the drivers (which are in the orange cells) and looking at the results.  This is a simplified version of what most sales VPs look at when trying to decide next year’s hiring, next year’s quotas [1], and next year’s targets.  This model assumes one type of salesrep [2]; a distribution of existing reps by tenure as 1 first-quarter, 3 second-quarter, 5 third-quarter, 7 fourth-quarter, and 9 steady-state reps; a hiring pattern of 1, 2, 4, 6 reps across the four quarters of 2019; and a salesrep productivity ramp whereby reps are expected to sell 0% of steady-state productivity in their first quarter with the company, and then 25%, 50%, 75% in quarters 2 through 4 and then become fully productive at quarter 5, selling at the steady-state productivity level of $1,000K in new ARR per year [3].

Using this model, a typical sales VP — provided they believed the productivity assumptions [4] and that they could realistically set quotas about 20% above the target productivity — would typically sign up for around a $22M new ARR bookings target for the coming year.

While these models work just fine, I have always felt like the second block (bookings capacity by tenure), while needed for intermediate calculations, is not terribly meaningful by itself.  The lost opportunity here is that we’re not creating any concept to more easily think about, discuss, and analyze the productivity we get from reps as they ramp.

Enter the Ramped Rep Equivalent (RRE)
Rather than thinking about the partial productivity of whole reps, we can think about partial reps against whole productivity — and build the model that way, instead.  This has the by-product of creating a very useful number, the RRE.  Then, to get bookings capacity just multiply the number of RREs times the steady-state productivity.  Let’s see an example below:

ramped rep equivalents, picture 2, revised

This provides a far more intuitive way of thinking about salesrep ramping.  In 1Q19, the company has 25 reps, only 9 of whom are fully ramped, and rest combine to give the productivity of 8.5 additional reps, resulting in an RRE total of 17.5.

“We have 25 reps on board, but thanks to ramping, we only have the capacity equivalent to 17.5 fully-ramped reps at this time.”

This also spits out three interesting metrics:

  • RRE/QCR ratio:  an effective vs. nominal capacity ratio — in 1Q19, nominally we have 25 reps, but we have only the effective capacity of 17.5 reps.  17.5/25 = 70%.
  • Capacity lost to ramping (dollars):  to make the prior figure more visceral, think of the sales capacity lost due to ramping (i.e., the delta between your nominal and effective capacity) expressed in dollars.  In this case, in 1Q19 we’re losing $1,875K of our bookings capacity due to ramping.
  • Capacity lost to ramping (percent):  the same concept as the prior metric, simply expressed in percentage terms.  In this case, in 1Q19 we’re losing 30% of our bookings capacity due to ramping.

Impacts and Cautions
If you want to move to an RRE mindset, here are a few tips:

  • RREs are useful for analytics, like sales productivity.  When looking at actuals you can measure sales productivity not just by starting-period or average-period reps, but by RRE.  It will provide a much more meaningful metric.
  • You can use RREs to measure sales effectiveness.  At the start of each quarter recalculate your theoretical capacity based on your actual staffing.  Then divide your actuals by that start-of-quarter theoretical capacity and you will get a measure of how well you are performing, i.e., the utilization of the quarterly starting capacity in your sales force.  When you’re missing sales targets it is typically for one of two reasons:  you don’t have enough capacity or you’re not making use of the capacity you have.  This helps you determine which.
  • Beware that if you have multiple types of reps (e.g., corporate and field), you be tempted to blend them in the same way you do whole reps today –i.e., when asked “how many reps do you have?” most people say “15” and not “9 enterprise plus 6 corporate.”  You have the same problem with RREs.  While it’s OK to present a blended RRE figure, just remember that it’s blended and if you want to calculate capacity from it, you should calculate RREs by rep type and then get capacity by multiplying the RRE for each rep type by their respective steady-state productivity.

I recommend moving to an RRE mindset for modeling and analyzing sales capacity.  If you want to play with the spreadsheet I made for this post, you can find it here.

Thanks to my friend Paul Albright for being the first person to introduce me to this idea.

# # #

Notes
[1] This is actually a productivity model, based on actual sales productivity — how much people have historically sold (and ergo should require little/no cushion before sales signs up for it).  Most people I know work with a productivity model and then uplift the desired productivity by 15 to 25% to set quotas.

[2] Most companies have two or three types (e.g., corporate vs. field), so you typically need to build a waterfall for each type of rep.

[3] To build this model, you also need to know the aging of your existing salesreps — i.e., how many second-, third-, fourth-, and steady-state-quarter reps you have at the start of the year.

[4] The glaring omission from this model is sales turnover.  In order to keep it simple, it’s not factored in here. While some people try to factor in sales turnover by using reduced sales productivity figures, I greatly prefer to model realistic sales productivity and explicitly model sales turnover in creating a sales bookings capacity model.

[5] This is one reason it’s so expensive to build an enterprise software sales force.  For several quarters you often get 100% of the cost and 50% of the sales capacity.

[6] Which should be an weighted average productivity by type of rep weighted by number of reps of each type.