来源/微信公众号：ToBeSaaS
作者：戴珂
文章已获授权
找人 找项目 找商机 上“软交会”——B2B连接平台1. 导言
ToB既然是门生意，长期不盈利就要关闭。好在对于SaaS来说还有另一条出路：如果目前还看不到能盈利，那你就必须有高增长。
现在业界到处都在谈论增长，国外SaaS公司的增长故事被传为业界神话，更有增长黑客等各种增长秘笈听起来都很有道理，SaaS的增长似乎是一件水到渠成之事。
只有经历了才会明白，无论对于ToB的成功企业还是创业公司，增长从来就不是一件容易的事。
事实上，国内大部分ToB创业公司还没有做好增长的准备。为增长所做的努力，看起来更像是在挣扎。
2. ToB SaaS的增长真相
没有增长或陷入衰退的ToB SaaS公司，大都走入了一个误区：自觉或不自觉地把SaaS做成了一个软件生意。这从一开始就阻断了自己的增长空间，ARR基本是个定数或者表现为下降趋势。
我们先比较一下二者的营销漏斗-收入模型有何不同：
不难看出，传统软件的营销漏斗-收入模型为一个漏斗形，一次营销的收入截止点在漏斗底部，要想增长就得做更多新客户。而SaaS的营销漏斗-收入模型为一个沙漏形，除了一次收入之外，在客户生命周期内的营销和服务并没有停止，因此会产生持续的收入。除了订阅续费外，持续收入项还包括增购、加购和交叉销售等多种收入内容，甚至还可以包括转介绍产生的新客户收入。
很显然，ToB SaaS比传统软件业务本质上有更强的增长能力。
既然如此，为啥SaaS公司的增长还干不过软件公司？是因为如下几个原因（包括但不限于），对SaaS增长形成明显的限制：
•
SMB客户占比太大，客单价低而生命周期短。
•
高客单价的大客户并不容易开拓和交付，数量少而效率低。
•
客户流失率太高，流失原因包括弃用和公司倒闭。
再用ToB SaaS的沙漏模型，从revenue的流失角度，分析混乱为什么使增长不会发生。
举个栗子：假设每个月的客户留存率是90%，你认为这已经相当好了？但这意味着每月的客户流失率是10%，就是说用不了一年时间，这些客户都将离你而去！为了维持增长和营收，不得不做更多新客户来弥补这个损失。而这又需要投入更多费用，猛砸市场和招聘更多销售人员，以获得足够的MQL和SQL。但是从MQL到SQL，再到取得第一次收入的转化率并不稳定，收入流失速度可能会快于新增。这种情况下老客户流失造成了沙漏下半部分的收入损失（这是SaaS收入中最重要的部分），拓展新客推高了市场成本和人力成本，而新增收入主要补偿流失损失。这一顿操作下来，对于增长来说还是原地踏步。
如果不幸陷入这个增长怪圈，说明公司已经脱离了SaaS的增长轨道；SaaS的收入模型也不再成立，实现增长就变得遥遥无期。
最后再回到上述制约增长的三个主要问题，靠谱的增长策略应该是：
•
增加大客户的占比，毕竟靠SMB成就不了大生意和高增长。选择优质的SMB，增加其LTV（理论上是这样，实际销售很难控制，大家都懂个中原因）。
•
坚持开拓大客户，相信如果搞定一家行业龙头客户，就有可能会获得五家甚至十家大客户。值得一提的是：一旦拥有一定数量的行业大客户，增长自然进入加速期（从1到N），有关内容可参考我另一篇公众号文《ToB，得大客户者得天下》。
•
管理客户流失率，这考验公司的经营战略和管理能力；因为公司这个funnel除了底部，其它各处都有可能出现客户流失的漏洞。
3. 系统化：实现增长的重要保障
对于增长的焦虑，很容易病急乱投医，每换一拨人就换个套路，很难形成自己强项的增长模式。如果加上错误的目标导向，比如：市场目标是正确地花钱、销售目标是更多提成、实施目标是配置系统、CSM目标是二次实施和催收续费… …，这样就与增长永远无缘了。
为了避免各种乱，在考虑怎样增长之前，需要有一个系统框架，以指导整个组织的协作增长。
ToB SaaS的增长系统框架如图所示：
使用增长系统框架，很容易把几个重要内容定义清楚：
•
线索到营收的业务过程，明确了3个对于增长最重要的目标：更多SQL、更多优质的合约和更多LTV持续收入。
•
对应的业务组织：市场/增长、销售、交付和客户成功。3个目标之间的连续性，对每个业务团队之间形成追溯和绩效制约。
•
通过5个紧密连接的典型业务，支持LTR的目标。
•
每个业务过程有IT工具的支持；使用工具的目的是：行为有效、业务加速和数据记录。
•
可视化的数据管理，实现增长的可预测、可度量、可复制和可分析。
让增长系统化的好处，是可以反复验证和持续改进，目标衔接和追溯，平衡投入各部分的增长资源，并能将成功经验在组织内部复制。
4. 增长的核心：增长杠杆
有了增长系统，为啥还需要增长杠杆呢？因为系统属于常规手段，只能解决有序经营问题，并不能解决你的增长问题，系统只是增长杠杆的基础。
事实上，业界现在最不缺的就是方法论和系统，而要想真正落地实现增长，必须依靠增长杠杆。也就是说，系统是通用的、而杠杆则是公司资产（媒体报道更多的是SaaS增长明星的高增速和估值，至于它们是如何做到的却很少提及）。
杠杆的概念已经在投资、金融和经营中广泛应用，凸显其“四两拨千斤”的威力和魔力。增长杠杆包含一系列动态的要素和指标。所谓要素是指：组织、流程、业务方法、工具和数据等所有可能影响增长的关键内容。动态是指不同条件下，通过不同的杠杆要素组合与优化配置，才能实现倍增的效果。
现在只要一提到增长，基本会被认为就是市场层面的事，好多市场群里都在讨论：病毒营销、流量、社交、推广、活动等“获客”行为。但是ToB的获客离着Revenue还非常远。将大笔的费用砸向市场，然后就静待增长发生；这种场景对于To C来说屡试不爽，对于To B来说作用有限。MQL和SQL作为增长之源固然重要，但如果不能转化为交易和服务收入，所有投入也就等于打了水漂。
所以，ToB的增长发生于整个客户生命周期，而不是在某一点上的灵机一动；而实现增长的业务闭环，离不开所有业务团队的增长协作。
最后需要说明的是，即使效果显著的增长杠杆，也不可能用一辈子，即增长杠杆是动态的。针对不同的业务、客户群体、不同阶段，增长杠杆都需要调整或重新配置。比如营收从0到500万和从500到5000万，几乎所有杠杆要素都需要调整和重新配置。
5. 打造你的增长杠杆
因为没有现成的增长杠杆可用，在借鉴的基础上，构建自己的增长杠杆，这是一件事半功倍的事。
直接复制国外高增长SaaS公司做法基本不可行。我的亲身经历，在Slack刚崭露头角时，我们就亦步亦趋地模仿：从产品功能到推送邮件风格，完全复制的做法收效甚微。因为我们并没有搞清楚它背后真正的增长策略逻辑，也就是它的增长杠杆是啥样。
正确选择和建立杠杆指标体系最重要。SaaS领域To B业务人员的缺乏，更多ToC人员转入To B领域。突出问题表现在杠杆指标的选取和设置上，比如：经常将登录率、访问率、日活、月活这些ToC指标，用于ToB的杠杆指标体系中，杠杆指标选错，数据说话就是瞎说。
对业务分类与对指标分级，以掌控最关键的指标，获取量化的经验。这在国外SaaS公司都有数据经验，比如：每月客户流失率>2%红线，就必须采取措施；又如：收入每增加200万美元，就需要招聘一名CSM。这些指标是否准确适用暂且不说，至少得有，国内多数情况下还是靠拍脑袋。
增长杠杆贯穿于整个业务流程与组织设计，而不是各自为政的两张皮；一个变了，另一个也必须跟着变。
让杠杆快速见效。业务方法与工具的使用，让杠杆的效率更高；一个杠杆最终会起作用，但是如果用时太久，也让人失去耐心而放弃。
抓住增长的转折点，实现业务增长规模化。增长有一个重要的里程碑和两个阶段：从0到1与从1到N。假如你的生意规模中等，收入从0-1000万是增长的第一个阶段（从0到1），这个阶段主要任务是找原型客户验证商业模式，增长杠杆只有少数几个指标。当进入1000-8000万收入区间的第二个增长阶段（从1到N），你会发现第一阶段的增长效果显现，原来的好多问题已经不再是问题了（比如大客户销售更容易了）。但也一定又会出现更复杂的增长问题待解决（比如说规模招聘），你必须升级增长杠杆，实现业务增长的规模化。
6. 利用支点撬动增长
作为一个杠杆，最重要的并不是要素和指标，而是杠杆的支点，只有选对支点，杠杆才有倍增效果。
什么才是ToB增长杠杆的支点呢？我觉得应该是利基市场（Niche Market），俗话称为细分垂直领域。因为对于ToB 初创公司来说，高速增长不可能靠向多个市场，出售多种产品和服务实现。
也许你认为做细分市场，会限制了你的能力和梦想，没有太大的增长，这其实是对利基市场的一个误解。利基代表着专注，即集中力量服务于一个特定的客户群体，也就是你最有可能赢的领域。尤其是ToB领域，利基的窄并不代表空间容量小，利基市场的ToB独角兽比比皆是。
利基市场的最大好处，可以针对专注领域设计深入和精准的增长杠杆，迅速攫取增量市场的收益。选择好一个支点，就有可能撬动一个大增长。
如果你已经是针对大众市场（Mass Market）进行了布局（比如说平台厂商），那也可以通过区隔服务于不同的客户群体，变成多个垂直服务领域，而实现并行增长。所不同的是多个支点就需要使用多个增长杠杆，但这需要更多领域的专业团队，运营也会更加复杂。
7. 后记
这篇作业写得很累，增长这件事本身就累，是个体力+脑力的重活。每个主题后面都有一些故事、客户、项目和伙伴；因头绪繁多，只能捡自己认为重要的问题分享，所以一定会有缺失，欢迎指正和补充。
因篇幅所限，一些有关增长的真实故事只能割爱了，只剩下主题可能理解起来有些抽象。
最后是我对ToB SaaS创业的理解：在选对支点的基础上，ToB成功是一个关于增长的努力过程。
免责声明：此文内容为第三方自媒体作者发布的观察或评论性文章，所有文字和图片版权归作者所有，且仅代表作者个人观点，与 无关。文章仅供读者参考，并请自行核实相关内容。投诉邮箱：editor@fromgeek.com。
免责声明：本网站内容主要来自原创、合作伙伴供稿和第三方自媒体作者投稿，凡在本网站出现的信息，均仅供参考。本网站将尽力确保所提供信息的准确性及可靠性，但不保证有关资料的准确性及可靠性，读者在使用前请进一步核实，并对任何自主决定的行为负责。本网站对有关资料所引致的错误、不确或遗漏，概不负任何法律责任。任何单位或个人认为本网站中的网页或链接内容可能涉嫌侵犯其知识产权或存在不实内容时，应及时向本网站提出书面权利通知或不实情况说明，并提供身份证明、权属证明及详细侵权或不实情况证明。本网站在收到上述法律文件后，将会依法尽快联系相关文章源头核实，沟通删除相关内容或断开相关链接。
