关于SaaS业务增长的思考【下】

在我们拥有了一个故事以后，我们就需要进入到第二个关键环节：让更多的人听到这个故事，

这个环节有三个步骤：媒体-内容-节奏

过去我们常说，应该基于内容去选择媒体，应该打造以内容为主的传播通路，但是在今天，我认为这个观点有待商榷。今天的媒体形式，已经明确的形成了信息茧房的状态，搜索引擎、官媒、微博、抖音、小红书、信息聚合软件、公众号等等，不同的媒体形态形成了各自的用户群体，以及适应该用户群体的信息内容，所以，适应这样的变化，我们首先要确认的就是媒体形式。

从用户的覆盖和流量来看，现在最重要的三个媒体形式，就是以私域传播和覆盖为主的公众号、以信息透传和广域检索的短视频、以针对性和特定需求的搜索引擎。针对这三个核心的传播形态，我们需要基于各自不同的媒体特性设计内容。

在媒体和内容确认后，我们需要考虑节奏的问题。就如同发动一场攻坚战，各种物资到位以后，节奏很重要，火力覆盖一定要在我方队伍还没冲上去之前，步坦协同一定要在火力覆盖之后。

大的节奏把握，一般情况下是官网+SEO/SEM＞短视频＞活动事件营销＞自媒体公众号矩阵。

通过让大家听到故事而降低陌生感之后，我们就要进入第三个关键环节：创造“遇见”的机会。

闻名不如见面，我们听得再多，也不如能够遇见真人来的更为妥帖，所以，创造“遇见”的机会就显得格外重要，一般情况下，创造遇见的机会有两种方式：

1、通过足够多的销售人员去主动触达客户

关于这个方式，不用赘述，已经有很多人给出了满分解答。

马克·罗贝齐将他的SaaS业务定义为“每次都找拥有相似成功特质的销售人员”、“以相同的方式培养每个销售人员”、“让销售人员对相同的销售流程负责”、“每月为销售人员提供相同质量和数量的销售线索”，他认为通过这四个要素，可以达成“可衡量、可预测的收入增长”。

硅谷蓝图中，对于SaaS增长的解读是：建立一个能够平衡技巧、流程和工具之间关系的，并经过精心设计的、以客户为中心的销售组织。它需要借助流程来实现规模化扩张，而不是依靠个人，他还要能与网络融合，让销售组织人员能够使用最新网络和增效工具来达成销售目标。

2、通过关键合作伙伴和资源网络被动触达客户

关于这个方式，是我认为现阶段被忽略或者说因为疫情导致的“中断的3年”所带来的缺失。

我们需要再能够聚合更多潜在客户的场合下，与客户进行沟通和交流，包括但不限于行业协会、展会、论坛、行业沙龙、自媒体矩阵等等，这是非常重要的，因为组织市场的客户心智，并不如同消费者心智一样，可以通过以1、2个简单因素直接撬动，他们需要更多的信息，更多的接触以及信任。

当我们通过营销方式和渠道方式的结合，终于创造了这个“遇见”的机会时，我们需要进入第四个关键环节：最短时间描述最完整故事

完整的故事是最重要的，因为我们无法确保我们的核心价值点恰恰就是客户这个时间点最关注的痛点，所以在“遇见”的时候，尽可能的呈现完整性就变的很重要了。

这里面有很多的细节，我们不在此赘述，不过有一个公式可以先抽象一下：

一个公众号+一个视频号+一份PDF可下载文档+一个企业微信

第五个关键环节：创造“付款买单”的场景

我们在前面四个环节做的所有努力，都是为了“付款买单”这个场景的发生，但是付款买单这个场景包括了很多的细节，而不仅仅是我们在超市买东西最后结账的简单动作：

• 销售链路：从第一次遇见客户开始的全销售链路，一般包括了L2C的完整链路，在销售链路中经常使用的工具主要是销售漏斗管理，以及与之配套的一系列软件工具；
• 签约场景：签约是需要管理整个签约场景的，包括是否是有制式合同，或者需要有签约仪式，或者需要往复盖章，还是直接客户在线付款电子合同，这些签约场景必须匹配目标客户的操作习惯；
• 议价场景：议价的前提是定价，基于商业化定价我们可以针对不同的用户群体给予不同的议价权限，包括总采购金额、分批付款的批次、流水抽成的方式等等；
• 促销场景：促销场景的前提是在不破坏定价模型的基础上，给予少量的优惠用于促进或提升客户在当期的付款意愿；
• 付款场景：付款场景包括了付款的方式，公对公转账、私对公转账、线上付款等等，付款场景需要基于客户的实际作业场景进行设计，以客户付款动作最少最便利为核心目标；
• 交付场景：交付场景包括了事前承诺、交付物和事后体感三部分，特别是在SaaS软件的交付上，由于仅涉及权限开通的动作，客户在付款前和付款后并没有明确的体感，所以在开通当时或者开通后，是需要一个现场回访的动作来提升交付的质感；

2、来自于行业化适配后，带来的行业市占率、品牌声誉、知识沉淀形成的市场拓客效率上增长

与组织市场的合作，核心是建立以价值增值为目的的合作关系，这才是保障合作方能够长久合作的基本盘，在我们完成上一个阶段的工作后，基本上我们具有了一定的客户基数，有了相对完成和成熟的运营体系，从市场到成交的链路也相对完整，就必须开始完成行业化适配的课题了。

行业化适配，意味着我们能够在标准的软件上，基于某个特定行业或者领域的需求，针对性的提供与之匹配和对应的能力及服务，以帮助和支持合作伙伴实现价值增值。

通用性的行业化适配有三种做法：

1. 研发单独的行业化产品；
2. 利用已有能力包装行业化产品；
3. 在产品不变的前提下，推出行业化的服务产品；

行业化适配的目标是不断提升在某个特定行业或领域的市占率，以此建立护城河与品牌声誉，并且通过一个行业领域的知识沉淀形成跨领域的洞察，为我们进行市场拓客奠定更稳健的“系统性”基础。

3、来自于交付及服务带来的留存率、客户裂变产生的增长

这也是SaaS业务与传统软件业务相比一个非常重要的差异性，SaaS业务取得新客户的比率只要超过客户流失率，业务规模就会持续扩大，因此长期保持客户留存就可以获得稳定的增长基础。而保持客户留存是一个长期的时间轴，这个时间轴的起点，是交付环节，这个时间轴的长度维持，靠服务。

但是当下的实际情况是受到定价、支付意愿和软件便捷性的影响，交付的环节越来越简单，付款开通账号，交付环节即宣告结束，这在2C的场景中是没问题的，但是2B的场景中却总是因为事前承诺或跨部门协同而产生冲突和误解。

服务最大的价值是解决合作期间可能出现的所有问题，并让整个时间轴的周期可以尽可能的长一些。这里有两个问题使我们需要回答的：

1. 我们能不能够帮助每一个客户成功？【不能】
2. 我们能不能让每一个客户感觉在使用过程中的舒适？【能】

通过交付和服务，我们确保了客户在使用的过程中所具有的舒适度，并且尽可能的让那些成功的客户与我们建立了更密切的合作关系，这就会带来SaaS业务的客户增长引擎中有一个简明的规则：新顾客是由以往顾客的行动带来的。

4、基于构建生态体系后形成的不可替代性带来的增长；

SaaS业务的终极目标就是构建一套生态体系，通过商业化管理理念、标准化作业流程、软硬件开放接口的共同努力，形成围绕组织市场客户的生态体系，这个体系内，每一个组织市场客户在不同的阶段和不同的场景中，都可以基于生态环境的不同选择不同的软件组合，来解决当下需要解决的问题。而开放性的接口和数据底层，则可以形成不同时间周期的沉淀，这些沉淀最终会变为数据资产和经验知识，为企业未来的发展奠定基础。

备注：增长背后的组织能力支撑

SaaS业务的底层模型包括是两个场景的组合：软件及解决方案+B2B，因此，从组织模型的设计上他需要符合软件及解决方案公司“强产品、重研发”的设定，也需要符合B2B模式下的增长逻辑，既“任何单点改善带来的增长都会被系统性的不匹配所抵消，但系统性改善能够带来1+1大于2的最终结果”。

SaaS新客增长受到“产品*市场*销售”三个系统的效率影响，而每个系统内部又存在自己的闭环逻辑，这三个系统的运营效率相乘，是整个业务增长的效率，而每个系统内部的效率相乘，则是系统自身的运营效率。

• 产品：需求洞察—创意产生—产品原型—技术实现—市场验证—迭代优化
• 市场：品牌塑造—品牌透传—细分营销—认知建立—线索获取
• 销售：潜客触达—意向转化—订单签约—实施交付—口碑传播—潜客触达

正因为如此，任何一个点转突破都无法形成有销售竞争力，所以在整体的增长拉动上，需要有一个角色承担，对这个角色的职能、定义可能各有不同，但是他们的核心目标是明确的：提效与增长。

提效是在资源有限的情况下，受制于B2B业务较长的内部价值链以及相对缓慢的市场传导速度，公司需要以“端到端”流程为目标，持续的优化和提升整个系统中各个环节的效率，市场分析及调研的效率、产品客户洞察的效率、产品PRD的生产效率、技术的研发效率、市场的营销效率、销售的获客及转化效率等等，而效率之间的关联性和传导，让我们需要有一个的运营及组织机制，保证内部“端到端”效率的持续优化。

这里经常碰到的组织问题是任务不清、目标不明，容易陷入“纯数据岗”或“纯管理岗”，经常出现“站着说话不腰疼”的现象，只发现数据上的异常，不解决实际业务中的问题，那一堆数据让各个业务部门认领回家，过两个月一看，还是老样子。

这里可以尝试的解决方案有两个：

1、对于中小体量的公司，从人员成本的角度考虑，“发现问题”的责任是核心管理团队，比如CEO或者COO，而解决问题则是将于问题相关节点上下游关联的部门TL抽调组成虚拟项目组，在规定时间内提交解决方案，这一方面可以增强执行的效果，另一方面可以锻炼团队的融合；

2、对于中等及规模以上体量的公司，可以成立运营中台，通过任务清单的管理方式，逐项逐级对问题卡点进行清理，注意，这里是清理，不是解决。清理的核心是找到卡点，明确是组织链路问题，还是人员能力问题，并不解决。如果非常清晰的，可以通过引入外部第三方软件或管理工具解决的，就即刻解决。这个好处是我们可以将大量的问题抽象化，并寻找问题背后的相关性，并在明确解决方案后，调动资源一次性推动解决问题。

增长是因为软件产品、技术革新、产品商业化以及组织市场需求之间有较长的时滞性，而时滞性带来了更多的不确定性，虽然B2B的竞争相对缓慢以及温和，不至于想2C一样“刀光剑影”、“血雨腥风”，但是一旦决策失误，可能很长时间内都会让公司发展陷入困境或停滞。所以，B2B公司需要有一个团队，对增长进行探索、规划、设计以及实施。

对于资源相对充裕的大公司而言，正如我们上面提到的，增长受到组织市场的管理者和组织市场的消费者，以及技术变革、交通和通信技术发展、管理理论革新的影响，与聚焦于企业内部运转的提效不同，增长的核心是聚焦于外部变化和周期把握，并将洞察与内部的提效相融合，形成完整的闭环。

因此，增长到底是CEO负责，还是COO负责亦或者是一个团队负责呢？

有以下三个实施建议可供参考：

1. 增长核心是CEO/COO负责，但是他需要一个小的助理团队，主要负责信息获取、信息筛查、业务匹配度判断、产品PMF验证、客户端调研体验等工作，这个团队对CEO/COO汇报，只负责信息的获取，不承担决策内容的输出；
2. 增长核心由专人负责，该角色需要有极强的市场洞察力和丰富的内部管理经验，他可以在与核心管理团队进行对话的基础上，将市场的前瞻性变化与产品和组织能力的匹配度上的差异转变为我们的业务策略，并通过组织培训、文化宣导、资源分配等方式，调整内部团队的行动轨迹；
3. 大中型公司，需要建立中台负责，形成类似于参谋部的机制，对管理层汇报。之所以这样设计是因为从组织管理上来说，大中型公司由于复杂的组织场景和管理分支，让他们通过小团队解决增长问题的可能性极低，因此，需要设定中台结构承担问题发现、数据分析、相似性问题解决的职能。在这里，中台本身就是一个巨大的资源协同器和信息分流器，各个业务模块的数据都汇总至中台，由中台进行拆解分析形成比照后，做出对事实现状的评判结论，如果B业务单元遇到的问题在A业务单元有了解决方案，则可以立刻执行减少时滞，如果没有他们必须有明确的汇报机制向上传递；

版权声明

本文来自互联网用户投稿，文章观点仅代表作者本人，不代表本站立场。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如若转载，请注明出处。如若内容有涉嫌抄袭侵权/违法违规/事实不符，请点击 举报 进行投诉反馈！