This is part II in this series. Part I is here and covers the basics of management education, employee communications, and simple steps to help slow virus transmission while keeping the business moving forward.
In this part, we’ll provide:
A short list of links to what other companies are doing, largely when it comes to travel and in-office work policies.
A discussion of financial planning and scenario analysis to help you financially navigate these tricky waters.
I have broken out the list of useful information links and resources (that was formerly in this post) to a separate, part III of this series.
What Other Companies are Saying and Doing
Relatively few companies have made public statements about their response policies. Here are a few of the ones who have:
Financial Planning and Scenario Analysis: Extending the Runway
It’s also time to break out your driver-based financial model, and if you don’t have one, then it’s time to have your head of finance (or financial planning & analysis) build one.
Cash is oxygen for startups and if there are going to be some rough times before this threat clears, your job is to make absolutely sure you have the cash to get through it. Remember one of my favorite all-time startup quotes from Sequoia founder Don Valentine: “all companies go out of business for the same reason. They run out of money.”
In my opinion you should model three scenarios for three years, that look roughly like:
No impact. You execute your current 2020 operating plan. Then think about the odds of that happening. They’re probably pretty low unless you’re in a counter-cyclical business like videoconferencing (in which case you probably increase targets) or a semi-counter-cyclical one like analytics/BI (in which case maybe you hold them flat).
20% bookings impact in 2020. You miss plan bookings targets by 20%. Decide if you should apply this 20% miss to new bookings (from new customers), expansion bookings (new sales to existing customers), renewal bookings — or all three. Or model a different percent miss on each of those targets as it makes sense for your business. The point here is to take a moderately severe scenario and then determine how much shorter this makes your cash runway. Then think about steps you can take to get that lost runway back, such as holding costs flat, reducing costs, raising debt, or — if you’re lucky and/or have strong insiders — raising equity.
40% bookings impact in 2020. Do the same analysis as in the prior paragraph but with a truly major bookings miss. Again, decide whether and to what extent that miss hits new bookings, expansion bookings, and renewal bookings. Then go look at your cash runway. If you have debt make sure you have all covenant compliance tests built into your model that display green/red — you shouldn’t have to notice a broken covenant, it should light up in big letters (YES/NO) in a good model. Then, as in the prior step, think about how to get that lost runway back.
Once you have looked at and internalized these models, it’s time for you and your CFO to call your lead investors to discuss your findings. And then schedule a discussion of the scenario analysis at your next board meeting.
Please note that it’s not lost on me that accelerating out of the turn when things improve can be an excellent way to grab share in your market. But in order to so, you need to have lots of cash ready to spend in, say, 6-12 months when that happens. Coming out of the corner on fumes isn’t going to let you do that. And, as many once-prodigal, now-thrifty founders have told me: “the shitty thing is that once you’ve spent the money you can’t get it back.” Without dilution. With debt. Maybe without undesirable structure and terms.
Now is the time to think realistically about how much fuel you have in the tank, if you can get more, how long should it last, and how much you want in the tank 6-12 months out.
I’ve seen numerous startups try numerous ways to calculate their sales capacity. Most are too back-of-the-envelope and too top-down for my taste. Such models are, in my humble opinion, dangerous because the combination of relatively small errors in ramping, sales productivity, and sales turnover (with associated ramp resets) can result in a relatively big mistake in setting an operating plan. Building off quota, instead of productivity, is another mistake for many reasons [1].
Thus, to me, everything needs to begin with a sales productivity model that is Einsteinian in the sense that it is as simple as possible but no simpler.
What does such a model need to take into account?
Sales productivity, measured in ARR/rep, and at steady state (i.e., after a rep is fully ramped). This is not quota (what you ask them to sell), this is productivity (what you actually expect them to sell) and it should be based on historical reality, with perhaps incremental, well justified, annual improvement.
Rep hiring plans, measured by new hires per quarter, which should be realistic in terms of your ability to recruit and close new reps.
Rep ramping, typically a vector that has percentage of steady-state productivity in the rep’s first, second, third, and fourth quarters [2]. This should be based in historical data as well.
Rep turnover, the annual rate at which sales reps leave the company for either voluntary or involuntary reasons.
Judgment, the model should have the built-in ability to let the CEO and/or sales VP manually adjust the output and provide analytical support for so doing [3].
Quota over-assignment, the extent to which you assign more quota at the “street” level (i.e., sum of the reps) beyond the operating plan targets
For extra credit and to help maintain organizational alignment — while you’re making a bookings model, with a little bit of extra math you can set pipeline goals for the company’s core pipeline generation sources [4], so I recommend doing so.
If your company is large or complex you will probably need to create an overall bookings model that aggregates models for the various pieces of your business. For example, inside sales reps tend to have lower quotas and faster ramps than their external counterparts, so you’d want to make one model for inside sales, another for field sales, and then sum them together for the company model.
In this post, I’ll do two things: I’ll walk you through what I view as a simple-yet-comprehensive productivity model and then I’ll show you two important and arguably clever ways in which to use it.
Walking Through the Model
Let’s take a quick walk through the model. Cells in Excel “input” format (orange and blue) are either data or drivers that need to be entered; uncolored cells are either working calculations or outputs of the model.
You need to enter data into the model for 1Q20 (let’s pretend we’re making the model in December 2019) by entering what we expect to start the year with in terms of sales reps by tenure (column D). The “first/hired quarter” row represents our hiring plans for the year. The rest of this block is a waterfall that ages the rep downward as we move across quarters. Next to the block ramp assumption, which expresses, as a percentage of steady-state productivity, how much we expect a rep to sell as their tenure increases with the company. I’ve modeled a pretty slow ramp that takes five quarters to get to 100% productivity.
To the right of that we have more assumptions:
Annual turnover, the annual rate at which sales reps leave the company for any reason. This drives attriting reps in row 12 which silently assumes that every departing rep was at steady state, a tacit fairly conservative assumption in the model.
Steady-state productivity, how much we expect a rep to actually sell per year once they are fully ramped.
Quota over-assignment. I believe it’s best to start with a productivity model and uplift it to generate quotas [5].
The next block down calculates ramped rep equivalents (RREs), a very handy concept that far too few organizations use to convert the ramp-state to a single number equivalent to the number of fully ramped reps. The steady-state row shows the number of fully ramped reps, a row that board members and investors will frequently ask about, particularly if you’re not proactively showing them RREs.
After that we calculate “productivity capacity,” which is a mouthful, but I want to disambiguate it from quota capacity, so it’s worth the extra syllables. After that, I add a critical row called judgment, which allows the Sales VP or CEO to play with the model so that they’re not potentially signing up for targets that are straight model output, but instead also informed by their knowledge of the state of the deals and the pipeline. Judgment can be negative (reducing targets), positive (increasing targets) or zero-sum where you have the same annual target but allocate it differently across quarters.
The section in italics, linearity and growth analysis, is there to help the Sales VP analyze the results of using the judgment row. After changing targets, he/she can quickly see how the target is spread out across quarters and halves, and how any modifications affect both sequential and quarterly growth rates. I have spent many hours tweaking an operating plan using this part of the sheet, before presenting it to the board.
The next row shows quota capacity, which uplifts productivity capacity by the over-assignment percentage assumption higher up in the model. This represents the minimum quota the Sales VP should assign at street level to have the assumed level of over-assignment. Ideally this figure dovetails into a quota-assignment model.
Finally, while we’re at it, we’re only a few clicks away from generating the day-one pipeline coverage / contribution goals from our major pipeline sources: marketing, alliances, and outbound SDRs. In this model, I start by assuming that sales or customer success managers (CSMs) generate the pipeline for upsell (i.e., sales to existing customers). Therefore, when we’re looking at coverage, we really mean to say coverage of the newbiz ARR target (i.e., new ARR from new customers). So, we first reduce the ARR goal by a percentage and then multiple it by the desired pipeline coverage ratio and then allocate the result across the pipeline-sources by presumably agreed-to percentages [6].
Building the next-level models to support pipeline generation goals is beyond the scope of this post, but I have a few relevant posts on the subject including this three-part series, here, here, and here.
Two Clever Ways to Use the Model
The sad reality is that this kind of model gets a lot attention at the end of a fiscal year (while you’re making the plan for next year) and then typically gets thrown in the closet and ignored until it’s planning season again.
That’s too bad because this model can be used both as an evaluation tool and a predictive tool throughout the year.
Let’s show that via an all-too-common example. Let’s say we start 2020 with a new VP of Sales we just hired in November 2019 with hiring and performance targets in our original model (above) but with judgment set to zero so plan is equal to the capacity model.
Our “world-class” VP immediately proceeds to drive out a large number of salespeople. While he hires 3 “all-star” reps during 1Q20, all 5 reps hired by his predecessor in the past 6 months leave the company along with, worse yet, two fully ramped reps. Thus, instead of ending the quarter with 20 reps, we end with 12. Worse yet, the VP delivers new ARR of $2,000K vs. a target of $3,125K, 64% of plan. Realizing she has a disaster on her hands, the CEO “fails fast” and fires the newly hired VP of sales after 5 months. She then appoints the RVP of Central, Joe, to acting VP of Sales on 4/2. Joe proceeds to deliver 59%, 67%, and 75% of plan in 2Q20, 3Q20, and 4Q20.
Our question: is Joe doing a good job?
At first blush, he appears more zero than hero: 59%, 67%, and 75% of plan is no way to go through life.
But to really answer this question we cannot reasonably evaluate Joe relative to the original operating plan. He was handed a demoralized organization that was about 60% of its target size on 4/2. In order to evaluate Joe’s performance, we need to compare it not to the original operating plan, but to the capacity model re-run with the actual rep hiring and aging at the start of each quarter.
When you do this you see, for example, that while Joe is constantly underperforming plan, he is also constantly outperforming the capacity model, delivering 101%, 103%, and 109% of model capacity in 2Q through 4Q.
If you looked at Joe the way most companies look at key metrics, he’d be fired. But if you read this chart to the bottom you finally get the complete picture. Joe is running a significantly smaller sales organization at above-model efficiency. While Joe got handed an organization that was 8 heads under plan, he did more than double the organization to 26 heads and consistently outperformed the capacity model. Joe is a hero, not a zero. But you’d never know if you didn’t look at his performance relative to the actual sales capacity he was managing.
Second, I’ll say the other clever way to use a capacity model is as a forecasting tool. I have found a good capacity model, re-run at the start of the quarter with then-current sales hiring/aging is a very valuable predictive tool, often predicting the quarterly sales result better than my VP of Sales. Along with rep-level, manager-level, and VP-level forecasts and stage-weighted and forecast-category-weighted expected pipeline values, you can use the re-run sales capacity model as a great tool to triangulate on the sales forecast.
You can download the four-tab spreadsheet model I built for this post, here.
# # #
Notes
[1] Starting with quota starts you in the wrong mental place — what you want people to do, as opposed to productivity (what they have historically done). Additionally, there are clear instances where quotas get assigned against which we have little to no actual productivity assumption (e.g., a second-quarter rep typically has zero productivity but will nevertheless be assigned some partial quota). Sales most certainly has a quota-allocation problem, but that should be a separate, second exercise after building a corporate sales productivity model on which to base the operating plan.
[2] A typically such vector might be (0%, 25%, 50%, 100%) or (0%, 33%, 66%, 100%) reflecting the percentage of steady-state productivity they are expected to achieve in their first, second, third, and fourth quarters of employment.
[3] Without such a row, the plan is either de-linked from the model or the plan is the pure output of the model without any human judgement attached. This row is typically used to re-balance the annual number across quarters and/or to either add or subtract cushion relative to the model.
[4] Back in the day at Salesforce, we called pipeline generation sources “horsemen” I think (in a rather bad joke) because there were four of them (marketing, alliances, sales, and SDRs/outbound). That term was later dropped probably both because of the apocalypse reference and its non gender-neutrality. However, I’ve never known what to call them since, other than the rather sterile, “pipeline sources.”
[5] Many salesops people do it the reverse way — I think because they see the problem as allocating quota whereas I see the the problem as building an achievable operating plan. Starting with quota poses several problems, from the semantic (lopping 20% off quota is not 20% over-assignment, it’s actually 25% because over-assignment is relative to the smaller number) to the mathematical (first-quarter reps get assigned quota but we can realistically expect a 0% yield) to the procedural (quotas should be custom-tailored based on known state of the territory and this cannot really be built into a productivity model).
[6] One advantages of having those percentages here is they are placed front-and-center in the company’s bookings model which will force discussion and agreement. Otherwise, if not documented centrally, they will end up in different models across the organization with no real idea of whether they either foot to the bookings model or even sum to 100% across sources.
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 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:
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.
[1] I am not an accountant. I’m a former CEO and strategic marketer who’s pretty good at finance.
[2] And which I like better as “unbilled deferred revenue” is somewhat oxymoronical to me. (Deferred revenue is revenue that you’ve billed, but you have not yet earned.)
[3] I know in some cases, e.g., prepaid, flat multi-year deals, ASC 606 can actually decide there is a material financing event and kind of separate that from the core deal. While pure in spirit, it strikes me as complex and the last time I looked closely at it, it actually inflated revenue as opposed to deflating it.
[4] Which I define as all the future revenue over time if every contract played out until its end.
[5] Ergo, you have high empirical confidence that you are going to get all the revenue in the contract over time.
[6] Good comp plans pay only a portion of large commissions on receipt of the order and defer the balance until the collection of cash. If you call this a $2M ARR deal, you do the comp math as if it’s $2M, but pay out the cash as dictated by the terms in your comp plan. (That is, make it equivalent to a $2M ARR deal with crazy-delayed payment terms.) You also retire $2M of quota, in terms of triggering accelerators and qualifying for club.
[6A] This then begs the question of how to comp the $1M in pre-sold upsell in Year 3. As with any of the cases of pre-sold upsell in this post, my inclination is to pay the rep on it when we get the cash but not on the terms/rates of the Year 1 comp plan, but to “build it in” into their comp plan in year 3, either directly into the structure (which I don’t like because I want reps primarily focused on new ARR) or as a bonus on top of a normal OTE. You get a reward for pre-sold upsell, but you need to stay here to get it and you don’t year 1 comp plan rates.
[7] That is, if all your contracts are signed on the last day of the quarter, and you don’t sign any new ones, or churn any existing ones until the last day of the quarter, and no one does a mid-quarter expansion, and you don’t have to worry about any effects due to delayed start dates, then the ARR balance on the last day of the quarter / 4 = next quarter’s subscription revenue.
[8] Development is not “over” and that value released – assume they continue to fully exploit all the development environments as they continue to build out their app.
[9] Note that TCV can be seen as an “evil” metric in SaaS and rightfully so when you try to pretend that TCV is ARR (e.g., calling a three-year $100K deal “a $300K deal,” kind of implying the $300K is ARR when it’s not). In this usage, where you’re trying to express total commitment made to the company to emphasize the importance of the customer, I think it’s fine to talk about TCV – particularly because it also indirectly highlights the built-in upsell yet to come.
[10] Or perhaps some intelligent mix thereof. In this case, I’d want to weight towards TCV because if they are not successful in year 1, then I fail to collect 5/6th of the deal. While I’d never tell an investor this was a $6M ARR deal (because it’s not true), I’d happily tell my Customer Success team that this a $6M TCV customer who we better take care of. (And yes, you should probably give equal care to a $2M ARR customer who buys on one-year contracts – in reality, either way, they’d both end up “Tier 1” and that should be all that matters.)
[11] Or you could of the ASC 606 revenue backlog and/or Remaining Performance Obligation (RPO) – and frankly, I’d have trouble distinguishing between the two at this point. I think RPO includes deferred revenue whereas ASC 606 revenue backlog doesn’t.
[12] In the event your compensation plan offers a kicker for multi-year contracts.
[13] And while you should factor in the pre-committed upsell in setting the reps targets in years 2 and 3, you shouldn’t go so far as to give them a normal upsell target with the committed upsell atop it. There is surely middle ground to be had. My inclination is to give the rep a “normal” comp plan and build in collecting the $1M as a bonus on top — but, not of course at regular new ARR rates. The alternative is to build (all or some of) it into the quota which will possibly demotivate the rep by raising targets and reducing rates, especially if you just pile $1M on top of a $1M quota.
[14] This ain’t one – e.g., it has $6M of TCV as opposed to $9M.
The single most misunderstood software-as-a-service (SaaS) metric I’ve encountered is the CAC Payback Period (CPP), a compound metric that is generally defined as the months of contribution margin to pay back the cost of acquiring a customer. Bessemer defines the CPP as:
I quibble with some of the Bessemerisms in the definition. For example, (1) most enterprise SaaS companies should use annual recurring revenue (ARR), not monthly recurring revenue (MRR), because most enterprise companies are doing annual, not monthly, contracts, (2) the “committed” MRR concept is an overreach because it includes “anticipated” churn which is basically impossible to measure and often unknown, and (3) I don’t know why they use the prior period for both S&M costs and new ARR – almost everybody else uses prior-period S&M divided by current-period ARR in customer acquisition cost (CAC) calculations on the theory that last quarter’s S&M generated this quarter’s new ARR.
Switching to ARR nomenclature, and with a quick sleight of mathematical hand for simplification, I define the CAC Payback Period (CPP) as follows:
Let’s run some numbers.
If your company has a CAC ratio of 1.5 and subscription gross margins of 75%, then your CPP = 24 months.
If your company has a CAC ratio of 1.2 and subscription gross margins of 80%, then your CPP = 18 months.
If you company has a CAC ratio of 0.8 and subscription gross margins of 80%, then your CPP = 12 months.
All seems pretty simple, right? Not so fast. There are two things that constantly confound people when looking at CAC Payback Period (CPP).
They forget payback metrics are risk metrics, not return metrics
They fail to correctly interpret the impact of annual or multi-year contracts
Payback Metrics are for Risk, Not Return
Quick, basic MBA question: you have two projects, both require an investment of 100 units, and you have only 100 units to invest. Which do you pick?
Project A: which has a payback period of 12 months
Project B: which has a payback period of 6 months
Quick, which do you pick? Well, project B. Duh. But wait — now I tell you this:
Payback is all about how long your money is committed (so it can’t be used for other projects) and at risk (meaning you might not get it back). Payback doesn’t tell you anything about return. In capital budgeting, NPV tells you about return. In a SaaS business, customer lifetime value (LTV) tells you about return.
There are situations where it makes a lot of sense to look at CPP. For example, if you’re running a monthly SaaS service with a high churn rate then you need to look closely how long you’re putting your money at risk because there is a very real chance you won’t recoup your CAC investment, let alone get any return on it. Consider a monthly SaaS company with a $3500 customer acquisition cost, subscription gross margin of 70%, a monthly fee of $150, and 3% monthly churn. I’ll calculate the ratios and examine the CAC recovery of a 100 customer cohort.
While the CPP formula outputs a long 33.3 month CAC Payback Period, reality is far, far worse. One problem with the CPP formula is that it does not factor in churn and how exposed a cohort is to it — the more chances customers have to not renew during the payback period, the more you need to consider the possibility of non-renewal in your math [1]. In this example, when you properly account for churn, you still have $6 worth of CAC to recover after 30 years! You literally never get back your CAC.
Soapbox: this is another case where using a model is infinitely preferable to back-of-the-envelope (BOTE) analysis using SaaS metrics. If you want to understand the financials of a SaaS company, then build a driver-based model and vary the drivers. In this case and many others, BOTE analysis fails due to subtle complexity, whereas a well-built model will always produce correct answers, even if they are counter-intuitive.
Such cases aside, the real problem with being too focused on CAC Payback Period is that CPP is a risk metric that tells you nothing about returns. Companies are in business to get returns, not simply to minimize risk, so to properly analyze a SaaS business we need to look at both.
The Impact of Annual and Multi-Year Prepaid Contracts on CAC Payback Period
The CPP formula outputs a payback period in months, but most enterprise SaaS businesses today run on an annual rhythm. Despite pricing that is sometimes still stated per-user, per-month, SaaS companies realized years ago that enterprise customers preferred annual contracts and actually disliked monthly invoicing. Just as MRR is a bit of a relic from the old SaaS days, so is a CAC Payback Period stated in months.
In a one-hundred-percent annual prepaid contract world, the CPP formula should output in multiples of 12, rounding up for all values greater than 12. For example, if a company’s CAC Payback Period is notionally 13 months, in reality it is 24 months because the leftover 1/13 of the cost isn’t collected until the a customer’s second payment at month 24. (And that’s only if the customer chooses to renew — see above discussion of churn.)
In an annual prepaid world, if your CAC Payback Period is less than or equal to 12 months, then it should be rounded down to one day because you are invoicing the entire year up-front and at-once. Even if the formula says the CPP is notionally 12.0 months, in an annual prepaid world your CAC investment money is at risk for just one day.
So, wait a minute. What is the actual CAC Payback Period in this case? 12.0 months or 1 day? It’s 1 day.
Anyone who argues 12.0 months is forgetting the point of the metric. Payback periods are risk metrics and measured by the amount of time it takes to get your investment back [2]. If you want to look at S&M efficiency, look at the CAC ratio. If you want to know about the efficiency of running the SaaS service, look at subscription gross margins. If you want to talk about lifetime value, then look at LTV/CAC. CAC Payback Period is a risk metric that measures how long your CAC investment is “on the table” before getting paid back. In this instance the 12 months generated by the standard formula is incorrect because the formula misses the prepayment and the correct answer is 1 day.
A lot of very smart people get stuck here. They say, “yes, sure, it’s 1 day – but really, it’s not. It’s 12 months.” No. It’s 1 day.
If you want to look at something other than payback, then pick another metric. But the CPP is 1 day. You asked how long it takes for the company to recoup the money it spends to acquire a customer. For CPPs less than or equal to 12 in a one-hundred percent annual prepaid world, the answer is one day.
It gets harder. Imagine a company that sells in a sticky category (e.g., where typical lifetimes may be 10 years) and thus is a high-consideration purchase where prospective customers do deep evaluations before making a decision (e.g., ERP). As a result of all that homework, customers are happy to sign long contracts and thus the company does only 3-year prepaid contracts. Now, let’s look at CAC Payback Period. Adapting our rules above, any output from the formula greater than 36 months should be rounded up in multiples of 36 months and, similarly, any output less than or equal to 36 months should be rounded down to 1 day.
Here we go again. Say the CAC Payback Period formula outputs 33 months. Is the real CPP 33 months or 1 day? Same argument. It’s 1 day. But the formula outputs 33 months. Yes, but the CAC recovery time is 1 day. If you want to look at something else, then pick another metric.
It gets even harder. Now imagine a company that does half 1-year deals and half 3-year deals (on an ARR-weighted basis). Let’s assume it has a CAC ratio of 1.5, 75% subscription gross margins, and thus a notional CAC Payback Period of 24 months. Let’s see what really happens using a model:
Using this model, you can see that the actual CAC Payback Period is 1 day. Why? We need to recoup $1.5M in CAC. On day 1 we invoice $2.0M, resulting in $1.5M in contribution margin, and thus leaving $0 in CAC that needs to be recovered.
While I have not yet devised general rounding rules for this situation, the model again demonstrates the key point – that the mix of 1-year and 3-year payment structure confounds the CPP formula resulting in a notional CPP of 24 months, when in reality it is again 1 day. If you want to make rounding rules beware the temptation to treat the average contract duration (ACD) as a rounding multiple because it’s incorrect — while the ACD is 2 years in the above example, not a single customer is paying you at two-year intervals: half are paying you every year while half are paying you every three. That complexity, combined with the reality that the mix is pretty unlikely to be 50/50, suggests it’s just easier to use a model than devise a generalized rounding formula.
But pulling back up, let’s make sure we drive the key point home. The CAC Payback Period is the single most often misunderstood SaaS metric because people forget that payback metrics are about risk, not return, and because the basic formulas – like those for many SaaS metrics – assume a monthly model that simply does not apply in today’s enterprise SaaS world, and fail to handle common cases like annual or multi-year prepaid contracts.
# # #
Notes
[1] This is a huge omission for a metric that was defined in terms of MRR and which thus assumes a monthly business model. As the example shows, the formula (which fails to account for churn) outputs a CAC payback of 33 months, but in reality it’s never. Quite a difference!
[2] If I wanted to be even more rigorous, I would argue that you should not include subscription gross margin in the calculation of CAC Payback Period. If your CAC ratio is 1.0 and you do annual prepaid contracts, then you immediately recoup 100% of your CAC investment on day 1. Yes, a new customer comes with a future liability attached (you need to bear the costs of running the service for them for one year), but if you’re looking at a payback metric that shouldn’t matter. You got your money back. Yes, going forward, you need to spend about 30% (a typical subscription COGS figure) of that money over the next year to pay for operating the service, but you got your money back in one day. Payback is 1 day, not 1/0.7 = 17 months as the formula calculates.
While driver-based planning is a bit of an old buzzword (the first two Google hits date to 2009 and 2011 respectively), I am nevertheless a huge fan of driver-based planning not because the concept was sexy back in the day, but because it’s incredibly useful. In this post, I’ll explain why.
When I talk to finance people, I tend to see two different definitions of driver-based planning:
Heavy in detail, one where you build a pretty complete bottom-up budget for an organization and play around with certain drivers, typically with a strong bias towards what they have historically been. I would call this driver-based budgeting.
Light in detail where you struggle to find the minimum set of key drivers around which you can pretty accurately model the business and where drivers tend to be figures you can benchmark in the industry. I call this driver-based modeling.
While driver-based budgeting can be an important step in building an operating plan, I am actually bigger fan of driver-based modeling. Budgets are very important, no doubt. We need them to run plan our business, align our team, hold ourselves accountable for spending, drive compensation, and make our targets for the year. Yes, a good CEO cares about that as a sine qua non.
But a great CEO is really all about two things:
Financial outcomes (and how they create shareholder value)
The future (and not just next year, but the next few)
The ultimate purpose of driver-based models is to be able answer questions like what happens to key financial outcomes like revenue growth, operating margins, and cashflow given set of driver values.
I believe some CEOs are disappointed with driver-based planning because their finance team have been showing them driver-based budgets when they should have been showing them driver-based models.
The fun part of driver-based modeling is trying to figure out the minimum set of drivers you need to successfully build a complete P&L for a business. As a concrete example I can build a complete, useful model of a SaaS software company off the following minimum set of drivers
Number and type of salesreps
Quota/productivity for each type
Hiring plans for each type
Deal bookings mix for each (e.g., duration, prepayments, services)
Intra-quarter bookings linearity
Services margins
Subscription margins
Sales employee types and ratios (e.g., 1 SE per 2 salesreps)
Marketing as % of sales or via a set of funnel conversion assumptions (e.g., responses, MQLs, oppties, win rate, ASP)
R&D as % of sales
G&A as % of sales
Renewal rate
AR and AP terms
With just those drivers, I believe I can model almost any SaaS company. In fact, without the more detailed assumptions (rep types, marketing funnel), I can pretty accurately model most.
Finance types sometimes forget that the point of driver-based modeling is not to build a budget, so it doesn’t have to be perfect. In fact, the more perfect you make it, the heavier and more complex it gets. For example, intra-quarter bookings linearity (i.e., % of quarterly bookings by month) makes a model more accurate in terms of cash collections and monthly cash balances, but it also makes it heavier and more complex.
Like each link in Marley’s chains, each driver adds to the weight of the model, making it less suited to its ultimate purpose. Thus, with the additional of each driver, you need to ask yourself — for the purposes of this model, does it add value? If not, throw it out.
One of the most useful models I ever built assumed that all orders came in on the last day of quarter. That made building the model much simpler and any sales before the last day of the quarter — of which we hope there are many — become upside to the conservative model.
Often you don’t know in advance how much impact a given driver will make. For example, sticking with intra-quarter bookings linearity, it doesn’t actually change much when you’re looking at quarter granularity a few years out. However, if your company has a low cash balance and you need to model months, then you should probably keep it in. If not, throw it out.
This process makes model-building highly iterative. Because the quest is not to build the most accurate model but the simplest, you should start out with a broad set of drivers, build the model, and then play with it. If the financial outcomes with which you’re concerned (and it’s always a good idea to check with the CEO on which these are — you can be surprised) are relatively insensitive to a given driver, throw it out.
Finance people often hate this both because they tend to have “precision DNA” which runs counter to simplicity, and because they have to first write and then discard pieces of their model, which feels wasteful. But if you remember the point — to find the minimum set of drivers that matter and to build the simplest possible model to show how those key drivers affect financial outcomes — then you should discard pieces of the model with joy, not regret.
The best driver-based models end up with drivers that are easily benchmarked in the industry. Thus, the exercise becomes: if we can converge to a value of X on industry benchmark Y over the next 3 years, what will it do to growth and margins? And then you need to think about how realistic converging to X is — what about your specific business means you should converge to a value above or below the benchmark?
At Host Analytics we do a lot of driver-based modeling and planning internally. I can say it helps me enormously as CEO think about industry benchmarks, future scenarios, and how we create value for the shareholders. In fact, all my models don’t stop at P&L, they go onto implied valuation given growth/profit and ultimately calculate a range of share prices on the bottom line.
The other reason I love driver-based planning is more subtle. Much as number theory helps you understand the guts of numbers in mathematics, so does driver-based modeling help you understand the guts of your business — which levers really matter, and how much.
I’m Dave Kellogg, advisor, director, consultant, angel investor, and blogger focused on enterprise software startups. I am an executive-in-residence (EIR) at Balderton Capital and principal of my own eponymous consulting business.
I bring an uncommon perspective to startup challenges having 10 years’ experience at each of the CEO, CMO, and independent director levels across 10+ companies ranging in size from zero to over $1B in revenues.
From 2012 to 2018, I was CEO of cloud EPM vendor Host Analytics, where we quintupled ARR while halving customer acquisition costs in a competitive market, ultimately selling the company in a private equity transaction.
Previously, I was SVP/GM of the $500M Service Cloud business at Salesforce; CEO of NoSQL database provider MarkLogic, which we grew from zero to $80M over 6 years; and CMO at Business Objects for nearly a decade as we grew from $30M to over $1B in revenues. I started my career in technical and product marketing positions at Ingres and Versant.
I love disruption, startups, and Silicon Valley and have had the pleasure of working in varied capacities with companies including Bluecore, FloQast, GainSight, Hex, MongoDB, Pigment, Recorded Future, and Tableau.
I currently serve on the boards of Cyber Guru (cybersecurity training), Jiminny (conversation intelligence), and Scoro (work management).
I previously served on the boards of Alation (data intelligence), Aster Data (big data), Granular (agtech), Nuxeo (content services), Profisee (MDM), and SMA Technologies (workload automation).
I periodically speak to strategy and entrepreneurship classes at the Haas School of Business (UC Berkeley) and Hautes Études Commerciales de Paris (HEC).
Privacy & Cookies: This site uses cookies. By continuing to use this website, you agree to their use.
To find out more, including how to control cookies, see here:
Cookie Policy
