

Vol.13 SaaS平台销售版本管理

产品海豚湾

2025-09-21

导读：管理好SaaS的销售版本，能够更好地支持市场和销售的业务开展。

前言

在公众号上曾经简要地介绍过SaaS产品的销售版本如何管理，有兴趣的可以先看一下这篇文章《SaaS 的多版本销售该如何设计》。SaaS产品分版本销售的目的是对客户进行分层，使得客户可以根据自己的业务需要选择相应的版本。大多数SaaS的销售版本会控制在3个，例如基础版、企业版和旗舰版。通常来说，不同版本的功能不同，功能越多价格越高。本篇以CRM为例来介绍如何设计CRM SaaS的销售版本。

图片来自Teambition官网

怎么定销售版本

怎么定销售版本实际上市场策略决定的，从产品层面来说则是要确定产品的关键资源，这里的“关键”是针对客户而言的，也就是客户能够感知到的最关键的价值点。例如，如果是根据功能划分版本，那么不同版本的功能差异要对客户业务有明显的影响。例如电商SaaS，可能基础版本只有商品管理、订单管理这些基础模块，更高级的版本可能会有会员系统、营销模块，因为这些模块对电商业务的助推作用很明显。同样的，项目协作工具按账号收费，是因为参与项目的人员越多，意味着项目越大，项目价值越高。

本篇我们介绍的是按功能差异定版本的产品设计，如果是其他类型的收费，确定好要收费的“关键”计量资源即可。也可以是组合收费的方式，比如按“功能差异+账号数量”进行收费。

业务对象管理梳理

按功能差异定销售版本，实际上就是通过销售版本控制客户能够使用的菜单（包括按钮）。对应的业务对象关系如下图所示。这种业务对象关系很像我们的RBAC权限管理，销售版本就类似于角色，我们通过赋予客户某个销售版本来完成客户可使用的功能授权。

算上页面的操作按钮的话，菜单有可能会有很多项，这个时候，如果直接将菜单配置到销售版本里，当菜单发生变更的时候操作会很繁琐，容易导致遗漏。因此，如果说我们的SaaS产品的功能很多，比较复杂，那么可以在菜单和销售版本中增加一个业务模块。当然，如果你的产品本身比较简单，那么没必要增加业务模块，那样反而会使产品变得复杂。

比如商品列表、添加商品、导出商品、导入商品、商品详情等等都是具体的菜单，我们可以将这些菜单归集到商品管理模块，然后销售版本设置包含哪些业务模块。通过这种方式，当菜单发生变更时，我们不需要去修改销售版本绑定的菜单，而只需要修改业务模块绑定的菜单就能够更新全部相关的销售版本。这种思路其实和RBAC权限管理的基础上增加用户组是一致的，通过引入中间业务对象可以简化授权管理操作。为了避免业务模块间的菜单重复，导致销售版本功能不清晰，我们可以限制一个菜单只能属于一个业务模块。

业务对象属性

关于菜单管理，我们在前一篇已经介绍过了，客户管理我们会在之后的客户管理模块中讲解。因此，本篇新增的业务对象其实就是业务模块和销售版本。我们先看销售版本有哪些字段属性：

销售版本名称：根据我们自己产品的需要对版本命名，如上面提到的基础版、企业版和旗舰版。版本名称不宜过长，建议是不超过6个字（如果有英文字符可以适当调整得更长一点）。
销售版本一句话介绍：一句话介绍该销售版本的卖点，这个字数也不宜过多，建议不超过20个字。
最大账号数量限制：这个根据自己产品的需要设计，如果是提供免费版本的话，通常对免费版本会有最大账号数量限制，以让客户团队增加的时候转为付费客户。协作类的SaaS该数值至少要大于1，具体数值由市场销售部门确定。为了避免出现误操作，建议设置一个上限值，比如10。由于我们介绍的是CRM，且假定基础版不免费，因此不设置最大账号数量限制。
功能特性：这个功能特性是介绍性的文字，主要是面向客户的，通常是一个功能模块一条描述。由于条数会比较多，交互上可以设置为换行即为新的一条功能描述，这样录入的效率更高。
关联业务模块：销售版本中包含了哪些业务模块。
销售版本说明：销售版本的简要说明，方便内部市场销售，运营人员查看。
是否推荐：通常只会有一个销售版本作为推荐版本，设置为推荐的销售版本可以在官网、版本升级对比中展示。
版本定价：定价通常会带单位，比如按账号收费就是单位就是每个账号，也有不带单位的，比如电商SaaS一般都是按功能模块收费（这类SaaS同时还收取交易手续费）。还有一类SaaS产品版本定价是打包的，包括授权的资源数量，比如企业版最大就是1000个账号，超过1000个账号只能升级更高级的集团版。

接下来是业务模块，业务模块会比销售版本更简单一点，具体的字段属性如下：

模块名称：根据我们的产品功能模块进行命名，通常字数也不宜过多，建议不超过10个字。
模块说明：业务模块功能说明，主要是方便内部的市场销售和运营人员了解业务模块特性，不对外展示。
关联菜单：该模块关联了哪些菜单。
状态：状态用于标记当前业务模块的可用状态，如开发中、内测中、可销售，主要让配置销售版本的人员知道当前业务模块是否可以配置到销售版本。
是否必备：也就是该业务模块为租户侧系统必需的模块，缺少这些模块租户侧系统无法正常使用，例如账号管理、权限管理等基础模块。必备模块需要自动加入到所有销售版本中，并且不可以取消关联。

理清楚业务对象关系和字段属性后，实际上到了原型设计就非常清晰了，我们列举涉及到的功能，然后画原型就行。所以，产品设计前期的需求分析、业务梳理工作非常重要。前期这些工作做到位了，到后续的画原型、写需求文档是水到渠成的事情。

产品原型

原型中，我们将租户菜单管理、业务模块管理和销售版本管理放在同一个菜单下面，将相关的功能聚合，可以避免操作时在不同的菜单间来回跳转。这里没有绘制租户菜单管理的原型，因为和前一篇的菜单管理是一致的，因此没必要重复画原型。租户菜单管理删除时需要有限制，也就是当菜单被授权给某个客户（客户订阅某个销售版本，实际上是把销售版本中的菜单授权给对应的客户）的时候不允许删除，避免误删除影响客户的业务。

业务模块列表

查看业务模块关联菜单

在业务模块列表中我们列出来了业务模块关联的菜单数量，点击对应的数量可以查看具体的菜单，以便了解当前业务模块具备的功能。由于业务模块不会太多，因此业务模块列表不使用分页浏览。

添加业务模块

添加业务模块分为两个步骤，第一个步骤是填写基本信息，第二个步骤是设置业务模块关联的菜单。为避免菜单被多个业务模块重复关联，已经被其他业务模块关联的菜单不允许再被当前业务模块关联。交互上，被其他业务模块选择的菜单置灰，禁止选择（但有下级菜单的，如果下级菜单有未勾选的，允许选择）。编辑业务模块的原型和添加类似，不再赘述。

删除业务模块需要进行二次确认，同时如果业务模块被销售版本关联，则不允许删除该业务模块。