:::info 我们经常会看到 SaaS 产品会按版本销售,比如个人版、专业版和旗舰版,不同版本的功能不同,价格也不同。那么不同的销售版本该如何设计? :::

前言

在回答如何设计不同的销售版本前,我们首先来看一下一般的 SaaS 系统的结构。通常一个 SaaS 系统会由运营端、客户 PC 端和客户移动端组成。

  • 运营端:提供给 SaaS 产品研发公司的业务人员使用,包括市场人员、技术人员、实施人员、客服人员等等;
  • 客户 PC 端:通常也是我们对外销售的产品名称,比如 xx CRM 系统,给客户使用,通常客户的管理人员、行政办公人员、相关业务部门会使用这套系统。
  • 客户移动端:和 PC 端配套的,形式上可能会有 App、小程序、钉钉应用或企业微信应用。主要是满足客户管理层或员工的移动办公、处理日常业务需求。

image.png
由于客户存在多个应用,就意味着不同的销售版本需要考虑不同端的功能也不同,这个怎么实现?很显然,要通过权限配置实现,要做权限配置,首先需要对客户应用的功能进行管理,这就需要运营端有对应的功能。

菜单管理

菜单管理属于功能授权的一个维度,通常也是最小的颗粒度。通常菜单是和前端的路由关联起来的。路由有点偏技术了,什么是路由? :::info 路由其实就是前端某个功能的访问路径,当点击某个菜单或按钮进行跳转时,实际上就是路由地址发生了改变。通常我们会看到的路由路径是/account/profile 这种形式。 ::: 因此,设计菜单管理的时候,通常会涉及下面这些信息:

  • 菜单名称:对应移动端可能是某个按钮的名称或是某个功能的名称
  • 上级菜单:这个在 PC 端更常见,一般会分一级、二级甚至三级菜单,对于二级、三级菜单就会有上级菜单。通常菜单设计上会支持无限层级的树状结构。
  • 路由地址:即前端功能对应的路由地址。
  • 路由标识:这个在有些场合会用,因为前端有些功能存在一个页面对应多个 tab 页,每个 tab 页共用路由地址,但可以通过标识区分。
  • 图标:配置图标的好处是可以根据需要直接调整,而不是固定在前端页面里(换图标的需求还是经常有的,典型的例子是到了节假日很多 App 的一整套图标都换了)。

接下来一个问题就是移动端的菜单和 PC 端的菜单要不要统一管理,个人的建议是看二者的属性结构差异大不大,如果不大可以放一起,在菜单里加一个应用类型区分就可以了。如果差异很大,那么还是分开。

授权方式

有了菜单后,我们就要考虑给客户的授权方式了。最简单的方法是直接给客户分配菜单权限。这种设计自然是有弊端的,比如说,每个客户都需要分配一次菜单,碰到菜单变更了要挨个客户授权,实际上很难维护。所以,这种模式适合前期的 MVP 阶段,客户不多,为了快速服务客户,可以人工替代开发来做。
第二种方式是将相同模块的菜单组合成一个业务单元,按业务单元给客户授权。这里的聚合层级多了一级,菜单变更只需要维护对应的业务单元即可。当然,这种模式也是有缺陷的,最大的缺陷是不好定价,因为按业务单元组合起来的价格非常多,这样市场容易搞乱。当然,好处也是有的,那就是可以根据客户的需求组合不同的销售方案,满足不同客户的需要。
最后一种方式就是我们的销售版本了,下图是某产品的一个示例。
image.png
建议是有多个业务单元组合成一个销售版本,这样的好处是我们可以通过维护业务单元来维护客户的权限,减少运营人员的工作量;同时,我们也能够对客户进行分层,针对不同版本匹配不同的服务;此外,价格上也能够做到统一,基于版本来制定价格策略会简单很多,客户也可以直接通过对比就知道价格和功能上的差别。这种方式其实是更合理的一种方式,整个的业务实体关系如下图所示:
image.png

资源约束

除了版本功能不同之外,很多 SaaS 平台还会按资源来收费,比如上面的例子,企业版是399/人/年,旗舰版是699/人/年,意味着还需要按使用人数计费。使用人数就是一张资源,更准确的说是按账号收费。一般这种的话我们需要定义产生付费的主要资源,比如账号数、存储空间、楼盘数等等,这些资源通常和客户的业务规模挂钩,客户业务规模越大收费越高。这个时候,客户授权上还需要增加资源的授权管理,相对来说是比较简单的,后台业务限制客户能够使用的资源就可以了,当然,建议是在客户资源不足时给出升级指引,这样可以提高转化率,增加收入。
敬请关注公众号:产品海豚湾