笔者复盘了做一个SaaS行业CRM系统的关键节点以及重要事项。

从项目启动到现在差不多大半年的时间，这半年中我经历了CRM系统从0-1的搭建过程。不过与以往接触的CRM系统不同，这次我主要负责的系统是面向SaaS行业。从产品形态上看，SaaS行业属于B2B行业大类，但也有着其独有的特征。

这篇文章我希望通过讲故事的方式分享我在V1.0版本时遇到的业务问题以及解决方案，大家如果有不一样的见解，也欢迎大家在评论区进行问题探讨。

一、产品V0.1版本的建立

在刚到公司之前，公司主要以某细分领域的定制化项目作为主要的盈利方式。在这之后公司希望结合自身领域上的优势将自己的产品SaaS化，这其中一方面是出于对产品通用性角度考虑：在这个细分领域中各企业的业务流程有着较多的相似之处，实现产品通用化是可行的；当然更重要的是从商业角度考虑，这样能够降低产品的开发与维护成本；同时通过按需订阅的方式能够争取更多中小“长尾组织”的有限预算。

我在来到公司负责的第一个项目就是将系统架构进行SaaS化改造：首先按照战略思路将产品功能划分为基础服务级、应用模块级，同时支持高可配置化的菜单及功能来满足多租户不同的业务需求，之后将系统权限改造为多租户权限模式，将应用模块与租户ID做灵活关联从而实现按需购买服务。

有关SaaS产品化改造的话题我先大概说到这，更具体的改造细节我会在后面的文章中为大家介绍。

而在改造的过程中，就逐渐有了CRM系统雏形：系统权限在划分为多租户后，需要企业后台系统需要有设置多租户入驻信息及租户开通功能，这也就完成了客户信息的采集与创建，因此我也称之为CRM产品的V0.1版本。

二、SaaS业务的快速扩张促进项目启动

由于是SaaS产品的初步尝试，公司在商业模式上并没有在初期就选择付费，而是希望通过免费的形式获得更高的市场占有率，树立品牌认同；同时持续打磨产品，而后再逐步将产品模块升级，并在原有的基础上做增值服务。

这一打法在市场上确实获得了预期成效：我们在短短一年多的时间内从40w用户量暴涨至240w，租户数也达到将近1w，用户量远远超过入驻即付费的其他平台。

却也随之带来更多业务问题：由于大部分客户是免费入驻与使用产品，产品的运营成本不降反升。因为一方面客户的免费入驻并不能为公司带来收入；与此同时，在售后服务上又需要投入更多的时间和人力成本来培训客户，并要及时解答客户提出的问题。

这时有的同学会问：为什么不通过植入广告的方式来缓解资金压力呢？

1. 我们的是to B的商业软件产品，主要以提升工作与管理效率为目的；
2. 我们所处的行业十分敏感，不宜通过商业广告的形式进行变现。

由于收益增长的压力与成本的提升，导致市场与客户运营部门没有足够的弹药扩充人手，总共不超过12个人的团队在产品上线初期，每天需要应对客户不断打来的电话，同时需要参与开拓市场与售前咨询任务，可谓是身兼多职。

后来，在线上产品慢慢打磨与过渡接近完整后，公司希望能够通过对部分应用采用增值服务的形式实现SaaS产品的业务增长。而争取的客户对象则主要是来自平台在搭建初期积累的这些线索客户，使之成为高意向潜在付费客户并完成付费转化。

这是面临的问题是：如何通过现有的团队来管理与维护如此大体量的客户？这需要引入客户管理系统来解决此问题。

三、项目启动前的研讨：自主研发还是外部采购？

关于系统是通过自研还是外采的问题，我们团队之间讨论过多次。相信很多公司也会有此困惑，如果选择外采，其优势是团队将节省大量的研发及时间成本，但是需要找到与产品业务契合的系统才能有效实施。

最终我们选择了自研系统，原因有以下几点：

1. 产品运营初期，产品战略及商业模式还有待市场考证，需要快速的响应市场快速迭代
2. 市面上的通用CRM系统不能满足当前的业务需求
3. 系统与自身产品的连接较为紧密，需要提供丰富的接口来支持，同时也要相应接口的不断变化

四、明确项目核心问题

在项目启动后，系统待解决的核心问题是：在销售人员较少的情况下，通过系统提升客户营销与管理效率，并最终并实现业务增长。

基于这个核心问题拆解成两个部分，如下图所示：

4.1 业务流程再造

由于是从0到1运营一条新的SaaS产品线，我们需要基于全新的产品形态设计与以往项目型销售不同的业务流程。为此我也做了很多产品调研，从商业模式上分析SaaS产品与原先销售模式的不同。

首先相比于项目型销售，SaaS产品的客单价较低，更多的收入将来自于客户的续费与增购。这就意味着以客户为中心的销售模式将确立主导地位。所谓“以客户为中心的销售模式”的核心就是要参与客户的全生命周期，了解客户在使用过程中产生的各种需求，并及时快速的响应需求。通过这样的销售模式才能真正服务好客户，只有通过这样的方式，才能获得更多的二次收益。

SaaS产品与项目型销售的第二点不同，是更为注重数据驱动而非营销驱动。用户在使用SaaS产品的替换成本会更低，即便客户在销售人员的说服下完成了首单消费，如果产品并不是他们真正需要的，也会直接流失掉。因此SaaS产品需要借助更多的数据挖掘潜在客户而非完全通过线下完成。

基于主流SaaS销售模式调研，并结合公司在组织人员架构与现有业务现状，我对业务流程进行了重新梳理，流程大致如下图所示：

在图中我列出了几个重要的流程节点：

4.1.1 线索获取

考虑前期有限的推广资源以及较低的投资回报率，公司并没有使用付费的市场推广形式。好在产品较好的口碑与高日活量使得在百度搜索的权重较高，加上产品是免费使用，每日的入驻用户仍保有稳定增长。

4.1.2 线索认证

对于线索认证这一阶段的考虑是通过系统目标账户营销（ABM）+人工的方式筛选合格线索（MQL）：

• 其中系统目标账户营销（ABM）是指通过系统获取用户在浏览付费增值应用时的浏览记录与习惯，通过系统规则标记为潜在客户；
• 合格线索（MQL）则是根据销售人员以往的经验，手动录入潜在客户信息。

两种潜在客户获取方式分别存成独立的数据表单放入数据库中。

这样做的好处是能够最大程度上起到辅助销售的作用，减少销售人员在客户跟踪与识别上的工作量；在此同时，通过数据还可以挖掘出销售人员在客户识别时的视线盲区，不放过任意一个线索机会。

4.1.3 商机客户转化

严格意义上，线索质量验证与培育应由市场部SDR来完成，而后将合格线索转到销售人员手中做商机客户的转化。但由于产品初期并未配备相关人员，这两个步骤都由同一个销售人员共同完成。

4.1.4 成交客户的续费与增购

前面说到，SaaS产品的大部分收入来自于此步骤，因此在客户完成首单交易后需要做更多的工作，以便实现客户留存并尽可能使之成为高净值推荐客户（NPS）。

在业务实施的开始阶段，我与客户运营部的负责共同制定了详细的相关工作内容及流程：包括客户的回访与跟进频次，产品bug与需求的反馈，客户培训与二次销售流程等等。结合用户需求及业务场景设计产品解决方案，具体解决方案我也会在后面的内容中提到。

4.2 组织架构的优化

在制定了新的业务流程之后，在组织架构层面也会随之调整。客户运营部门明确了岗位角色与分工，一部分人员被拆分到专门负责客户拓展与售前咨询的销售团队；另一部分进入负责售后咨询而增购的客户成功团队。

五、产品路线图规划

在明确了待解决的业务问题后，我们将产品明确定位在“以客户为中心”的核心思路。也就意味着产品功能会在紧张的开发排期中作出取舍。保留现阶段最需要解决的业务问题，同时砍掉与之无关的功能，将视角聚焦在“客户”上。如下图所示：

图中简要列出了一个产品结构示意图，从中可以大致了解产品的全貌。从整体架构上看，我将线索管理与客户成功管理拆分为两个模块，并按照各业务部门职能将权限按照整体模块分配给销售部与客户成功部。当客户处于未达成交易状态时，该条客户会存入线索管理中由销售部跟进，而当客户完成首单后，客户数据将流转至客户成功管理中挖掘二次销售商机。

此外，灰色部分代表暂时舍弃掉的功能，至于舍弃的原因在于客户营销与拓展部门的人数远没有达到通过系统管理的程度，因此暂时不需要开发相应功能。

5.1 线索管理与权限管理

线索管理是销售过程管理中最传统，同时也是最经典的部分；而权限管理是所有后台管理系统的必备工具，基于RBAC的权限设计方法也比较固定和基础，这两部分内容在很多CRM产品相关文章中都有涉及，我就在此不做过多描述。

5.2 客户成功管理

客户成功管理是SaaS领域最重要的部分，一个好的CSM业务体系需要介入客户的完整生命周期中，包括客户的初期促活、中期的客户意见反馈与使用指导。只有服务好客户的每一步，才能最终达成续费或增购的最终业务目的，实现企业收入增长。

在客户流转至客户成功模块后，平台会对客户的使用情况进行数据监控，让客户成功经理实时了解用户的使用情况；并通过系统规则提示哪些客户疑有流失征兆，并设置流失预警，提醒他们及时跟进。

此外，根据特定的业务场景我将商机管理模块放入客户成功模块，使得正式客户表与商机形成1对n的关系，并间接与订单关联；而处于未达成交易状态的潜在客户则直接与订单1对1关联，用户可直接由线上创建订单。这样做的考虑是既能够简化首单流程，又能在客户成功阶段增加对商机过程的管理。为项目后期的客户终身价值（CLV）建模提供较为准确的数据依据。

智能分析模块是CRM产品中非常重要的一部分，但由于初版上线时间紧任务重，以及数据的不完整，因此将放入二期需求；并在一期做好客户信息及销售过程数据的整合与沉淀，搭建数据仓库。

以上是我对V1.0版本CRM产品的设计过程介绍，由于篇幅原因就不再展开对每个功能细节的具体讨论。

六、总结与复盘

回顾整个项目，我认为收获到最多的是对产品全局把控的策略与思路。在产品规划初期，要对现在以及未来的业务发展趋势作出前瞻性预估，从而让系统架构更具扩展性；同时要学会平衡成本与产出，用最小的开发与人力成本完成当前最紧迫的业务问题，在不断地抉择与取舍中验证正确的方向前进。

本文由 @阿猫阿狗 原创发布于人人都是产品经理，未经许可，禁止转载

题图来自 Unsplash，基于 CC0 协议