桉树CRM：如今各类企业尤其是互联网企业尤为关注获客成本回收问题，那么如何计算出获客成本，由此达到成本最小化的终极目标呢？除了获客成本，还有哪些与企业盈利相关的其他指标呢？从哪些方面关注此问题呢？既然测算指标已经随着客户需求的多元化逐渐复杂化，那么如何实现快速准确的测算？引入CRM系统无疑是一条绝佳的出路。

最受关注的软件即服务（SaaS）度量指标中有不少都与用户获取成本相关，例如获客成本（CAC）比率，这个指标能衡量新增年度经常性收入（ARR）中每获取1美元企业所需花费在销售上的成本。

相较于创造复合度量指标，我偏向于将简单SaaS指标结合起来分析。例如，为了计算出净新增年度经常性收入，我会分别观察新增年度经常性收入和流失年度经常性收入两个数据，而不是直接用前者减去后者。为何？因为从净新增年度经常性收入中得出100万美金的方法并不唯一。例如，流失额200万美金，销售额300万美金；或者是流失额10万美金，销售额110万美金。两者看似殊途同归。但从实操角度来说这两种方式情况迥异。这种用一个度量指标减去另一个形成的复合指标不仅无法简化事情，还很可能给本已模糊不清的状况再蒙上一层面纱。

也有一个例外，那就是用户生命周期总价值（LTV）/CAC比率，虽然它是个复合度量指标，包含获客成本和流失率的复合指标，但却很好用，我认为这是SaaS指标中最的一个。这个指标说明，既然您愿意为某样商品付钱，那自然说明它的价值所在——这正是LTV/CAC所起到的作用。

我知道的SaaS指标中，最易被误读的指标就是获客成本回收周期（CPP），它指的是为了回收获取单个客户的成本需要多少个月份的边际效益。贝塞麦是如此定义CPP的：

获客成本回收周期(月份数)= 上一季度销售费用成本÷（上一季度新增已承诺月循环收入×毛利率）

一般来说，尽管根据上述公式能得出正确平均数，但是我依然会质疑定义中的贝塞麦主义相关问题。例如，(1)大多数SaaS公司应当使用ARR而非MRR(月度经常性收入)，因为大多工作是按照年度划分而非月度，比如合同；（2）“准确”MRR概念无法达到，因为它包含着“预测”流失率，而要估算这个数据基本上是不可能的，于是通常都是未知的；（3）我不明白他们为何用上一时期的数据测算S&M成本和新增年度经常性收入。基于由上个季度S&M得出了这个季度的新增年度经常性收入这一理论，几乎其他所有人都用上一时期S&M数值进行CAC运算而非近期的ARR数据。

我转而融入ARR概念，加上处理数学问题的敏捷简单化思维方式，这就形成了我对CPP的如下理解：

获客成本回收周期(月份数)= 12×（CAC比率÷认购毛利率）

下面进行几组数字运算：

若公司CAC比率为1.5，认购毛利率为75%，那么CPP=24个月

若公司CAC比率为1.2，认购毛利率为80%，那么CPP=18个月

若公司CAC比率为0.8，认购毛利率为80%，那么CPP=12个月

运算是不是看似很简单？其实不然。在计算CPP时大家经常被两件事所迷惑。

一是忘了回收指标乃是风险指标而非回报指标

二是无法正确理解年度合同或多年合同对运算的影响

回收指标意味着风险而非回报

那么我们先来个基础的MBA问题：现有两个项目，各需100个投资组，而您总共只有100个投资组，那么你会投资哪个？

项目1：回收周期12个月

项目2：回收周期6个月

快选吧，投哪个？那就项目2吧。  如果我告诉你：

项目1的净现值（NPV）500

项目2的NPV110

那么，现在您是否觉得投项目2傻透了?

回收的全部意义在于，您的钱确定花在这里（所以不能用于其他项目），并处于风险中（表示可能无法收回），这种情况要维持多长时间。回收并不意味着一定有回报。在资本预算中，NPV谈的是回报。在SaaS公司，LTV谈的才是回报。

很多情况下需要测算CPP。比如，若您经营的SaaS公司以月费方式提供服务，并且流失率高，那么就得仔细思考资金处于风险状态下有多久了，因为您很有可能拿不回原先的CAC投资，更甭提回报获利了。想想看，一家以月费方式盈利的SaaS公司的获客成本是3500美元，认购毛利率是70%，月费是150美元，还有3%的月度流失率。据此，我将计算出比值，检测下表中100客户群的CAC回收情况。

计算得出CAC回收周期为33.3个月，这个周期已经算很长了，但是实际情况还更糟糕。这个CPP公式的问题在于，它并没有将流失率计算在内，没有考虑客户群的具体情况—在回收期，客户越是有机会不续约，您就越需要考虑计算中无法增加更新数据的可能性。在此例中，当适时考虑流失率时，您在30年后还有价值6美元的CAC要回收。说真的，您永远也收不完CAC。

评论：这又是个例证，表明运用模型分析要优于使用SaaS指标的模糊运算。若想了解一家SaaS公司的财务状况，可以创建一个基于驱动的模型并确定多样的参数。在这个案例中，分析失败是由细节的复杂性导致的，很多其他案例失败原因也是如此——相反，如果有一个良好有效的模型，就总是可以得出正确答案。

抛开这种情况不提，过于关注CAC回收周期的真正问题是，CPP属于风险指标，无关回报。而公司经营的目的在于回报盈利，而不仅仅是将风险最小化。因此，要分析SaaS公司状况，我们得关注回收和回报两方面。所以我认为如果只能选一个指标，那么LTV/CAC就是最佳的SaaS指标。

一年和多年合同对CAC回收周期的影响

这个CPP公式得出的是以月份计数的回收周期，但如今绝大多数SaaS企业运营是年度方式。即便有时定价还是以每个客户和每月的情况而定，但其实多年前SaaS公司便意识到客户偏向年度合同，并且很不喜欢月度计费方式。MRR运算就带着过去SaaS企业运用模式的影子，而以月度计算CAC回收周期也是如此。

如今所有人都选择年预付合同，那么这个CPP公式运算的结果应该是12的倍数，对大于12部分的价值系数就要四舍五入了。例如，一家公司的CAC回收周期理论上来说应该是13个月，但实际上成了24个月，这就是因为要等第24个月客户支付第二笔费用时才能收回成本中剩下的1/13。（而这还是基于客户选择续约的情况下才生成的，请见上述关于流失率的讨论）

在这个预付年费的世界，若CPP小于等于12个月，那么就应当约为1天，因为公司将一整年的费用合为一次性即刻预付。即便理论上来说通过公式运算得出的CPP是12个月，但在这个预付年费的世界CAC资金仅有1天处于风险中。

那么，就此情况而言，真实的CAC回收周期到底是什么？12个月还是1天？答案是1天。

回答12个月的人忘了这个指标的定义。回收周期是风险周期，测算收回投资需要的时间。若要观察销售效率，请查审CAC比率。若要了解经营SaaS公司的效率，则查阅认购毛利率。若想研究生命周期，请测算LTV/CAC。CAC回收周期属于风险指标，测算的是在回收前您的CAC投资运作了多久。以此为例，用这个公式得出的12个月并不正确，因为公式忽视了预付款问题，所以正确答案是1天。

许多聪明人也卡在这里。他们回答说：“对，很对，是一天——但是其实不是，就是12个月” 错，答案就是1天。

若想研究除了回收以外的其他问题，则要选择别的指标。但是CPP确实是1天。这回答的就是企业为了获取单个客户支出的费用需要多久收回来。由于人人选择预付年费，所以对于CPP等于或者少于12的，实际就是1天。

这种运算会变得更难。试想一家公司产品粘性强（比如说它的生命周期大概是10年），那么这就是一笔值得好好考虑的生意，在做决定前潜在客户会做深入评估了解（比如ERP产品）。所有这些事前评估筹划工作完成以后，客户往往愿意签长期的合同，所以公司只做3年期的预付合同。那我们来看看CAC回收周期吧。运用以上规则，由此公式得出的任何大于36个月的结果都应该四舍五入，直接算作36的倍数。同样，任何等于或者少于36个月的结果都应该约为1天。

再举个例子。假如CAC回收周期公式运算结果是33个月。那么现实情况下的CPP是33个月还是1天？这又是同样的争论点了。答案还是1天。公式的计算结果是33个月，可实际上CAC回收时间是1天。如果想要研究其他问题，则选择别的指标。

再把情况复杂化一些，运算难度又加大了。试想一家公司50%的合同是一年期的，另外50%是3年期的（基于ARR计算标准）。假设其CAC比率为1.5，认购毛利率75%，那么理论上的CAC回收周期则为24个月。那我们用个模型看看实际情况：

运用模型后会发现实际的CAC回收周期是1天。为何？我们需要收回150万的CAC。第一天记下入账200万，产生了150万的边际效益，那么就已经回收了全部CAC了。

尽管我尚未能制定针对这种情况的通用修约规则，但这个模型再次证明了一个关键点——一年期和三年期支付并存的结构让CPP公式运算更复杂了，造成了概念上的误解，以为CPC为24个月，而实际上还是1天。如果哪天要我制定修约规则，我的规则应由平均合同周期和CAC比率决定——不过我也没那么确定。

撇开这点不提，期望大家都明白本文的重点。那就是CAC回收周期经常被误读，因为人们总忘了回收指标反应的是风险而非回报，另一个原因是这些基本公式像其他许多SaaS指标一样，默认使用一个月度模型，但这种模型显然已经不适用于如今的SaaS软件了。

那么由此问题引发的思考是既然旧模型已无法满足需求，企业下一步采取什么措施才能优化管理，实现企业盈利最大化？引进一套CRM系统，能为企业构建一整套以客户为中心的完善数据库，帮助企业优化管理渠道和业务流程，进而促进企业利用数据系统进行深层次分析，挖掘最有价值客户，降低运营成本，提升转化率，提高客户回购率和销售额，完善企业管理。对于创始企业，CRM系统更将协助创业者实现企业高效运营管理，为企业的腾飞提供巨大动力。

编译 | 桉云科技，原文有删改，转载请注明出处桉云科技，并附文章地址

作者 | Dave Kellogg

来源 | https://www.enterpriseirregulars.com