SaaS 平台客户管理模块的核心业务目标有两个：一是建立客户档案，可结合企业现有 CRM 简化，确保能与 CRM 客户对应即可，二是以客户为主体提供产品及服务，涵盖客户的订阅、增值服务采购、工单提交、使用跟踪等所有业务连接，这也是核心目标

01 前言

对于SaaS平台来说，客户管理模块的主要业务目标有两个，一是建立客户档案，方便维护客户关系；二是以客户为主体，为客户提供SaaS的产品及服务。对于第一个业务目标，有点和CRM系统类似，通常会需要有客户的基本资料以及业务对接人信息。当然，如果SaaS企业内有有采用其他的CRM系统，那么客户档案可以简化，只要能够和CRM系统的客户对应起来即可。而第二个目标，则是SaaS平台客户管理的主要目标，包括了客户与平台发生的所有连接，例如订阅、采购增值服务、提交服务工单、使用情况跟踪等等。

02 客户来源

不同的SaaS平台的客户信息来源不同，比如有些SaaS平台支持个人用户注册免费试用；有的则需要先提交资料，再由平台确认后才开通账号。对于支持直接注册使用的，通常会以团队作为一个客户，甚至支持一个人创建多个团队。例如墨刀、语雀、Teambition等等。这种来源的客户对资料真实性要求不高，通常适合那种无需培训实施，偏向依赖口碑传播的PLG类型的产品。

对于第二种，大多数是因为产品本身功能比较复杂或者深入某一块垂直业务，用户自主注册试用不仅无法实现产品口碑传播，反而可能因为过于复杂而劝退用户。这类产品更好的方式是通过渠道收集意向客户，再通过市场销售跟进，演示产品功能特性，促使客户产生购买意向。最后，签订合同后再开通客户账号。当然，也有先开通试用账号，后面再签合同的，这种一般是客户业务负责人要求先试用，评估产品是否符合公司业务需求。

从SaaS平台的业务上来说，实际上用户自主注册只是一个特殊的新增客户的渠道，这种方式可能也会需要在SaaS平台的后台给客户开通账号（例如大客户）。因此，对于SaaS平台，实际上在客户管理这块没有太大区别。

03 业务对象关系梳理

SaaS产品，客户是业务的中心，可以说大部分的业务对象都会和客户有关联，下面这张图给出了客户关联的主要业务对象。

对于一个产品的核心业务对象，建议是在产品设计前期就把该业务对象与其他主要业务对象的关系梳理出来。完成业务对象关系梳理后，整个产品的数据层基本上就能定下来了。当然，具体的一些约束条件如果能够想到，那么也可以列出来，例如客户与销售版本，应该是有一个时间约束的，即同一时间点客户与销售版本是一一对应关系，也就是一个客户同时只会有一个销售版本。但是，如果是看时间段，那么客户可能一开始订阅的是基础版本，后面又升级到了更高级的版本。这种历史记录，我们可以通过订单反映出来，也可以单独设计一个客户订阅版本变更记录来管理。

04 客户属性

实际上，客户管理如果要做复杂，就变成了一个传统的CRM系统，个人其实不建议前期就做这么复杂。对于SaaS产品从0-1阶段，满足最基础的业务需要即可。就算业务发展到了一定阶段，也可以使用市面上比较好的CRM工具来做客户拓展。到了后期，如果确实要拉通SaaS平台与客户管理，实现“端到端”管理 ，那么可以考虑在平台侧搭建CRM系统。因此，对于前期，我们的客户属性可以简化到只有下面这些属性：

• 客户名称：对于后台开通的客户账号，通常会使用客户企业名称作为客户名称，对于自主注册的客户，建议默认为注册用户名称，后续如果该用户添加了团队或者进行了企业认证，再更新为团队名称或企业名称。
• 所在地区：通常会精确到城市级别，如湖南省长沙市。这个属性一方面可以帮助我们统计客户的地域分布，另一方面也可以用于客户代码的生成。此外，若客户数量比较多的时候，市场销售团队通常会划分地理区域进行管理，也会用到这一属性。
• 客户代码：这个客户代码要求是唯一的，用于区分不同客户。比如，我们在账号体系中提到的企业代码其实就是客户代码。这个代码建议由程序自动生成，以确保唯一，且具备一定的规律。我们曾经的方案是“4位城市代码+2到3位序号”作为客户代码，例如北京的城市代码是1100，那么第一个客户的代码就是110001。
• 证件号码：如果是企业客户，那么可以使用18位统一社会信用代码，这样能够保证不同平台的统一性；如果还有个人用户，那么可以使用18位二代身份证号码——前提是有实名认证环节。当然，对于PLG类型的SaaS产品，做实名认证实际上拉长了转化链路，这种情况下作为预留的字段即可。后期，如果有必要实名认证，再进行认证也可以。
• 联系人：这个联系人建议是留客户主管理员的信息，包括姓名和手机号信息。后期如果主管理员变更其实没必要同步更新，由市场销售团队维护联系人信息即可。而且这里只保留一个联系人即可，因为在CRM系统中会管理客户的多个联系人信息。
• 密码：如果是后台创建的账号，有两种方式，一是有程序创建随机密码，并通过短信发送到主管理员手机号；另一种是不创建密码，由主管理员通过验证码登录，首次登录要求设置密码。
• 地址：地址可以设置为非必填，主要是初创型SaaS企业可能也没有购买CRM系统，那么地址信息会是一个有助于客户跟进的关键信息。
• 备注：客户的一些特殊说明，如意向、电话咨询时反馈的需求信息等。备注可以设置为非必填，根据实际情况填写即可。这里顺带提一下关于某个业务对象属性扩展的问题。有些产品经理会想一开始尽量将业务对象的属性设计得足够全，这样可以一次性地收集到足够的信息。这样的缺点是表单填写比较繁琐，而且非必填的属性往往都不会填。从技术上来说，扩展字段并不麻烦，因此，我个人的建议是在MVP阶段，尽量只保留必要的业务对象属性，简化表单。

05 原型设计

客户管理本身的功能设计其实就是添加客户、编辑客户信息、查看客户详情、开通账号、冻结账号等操作。大部分原型和其他模块没有太大区别，这里就不一一列出原型了。

重点说两个功能点，一个是前面提到的如果密码是后台创建的，并且通过短信发送给客户的，那么就应该有一个重发密码的功能。这是因为短信会有一定的失败率，如果失败了会给客户造成不好的体验，因此需要支持重发密码。重发密码从安全角度考虑，应该需要重新生成一个新的密码。

第二个功能点是客户详情，客户详情不能只是简单地列出我们上面说的客户属性，而是把与客户关联的主要业务对象信息也列出来，例如订阅的销售版本、订单记录、合同、发票等。这样可以帮助我们更全面地了解某个客户与平台发生的业务往来，从而提供更个性化的客户服务。下面是客户详情的原型截图。

06 总结

SaaS平台侧的客户管理其实比较简单，如果有兴趣全面了解客户管理，建议可以去看看CRM SaaS产品，比如公众号介绍的纷享销客和HubSpot。