在SaaS系统商业化的过程中，企业客户的需求多样化和市场竞争的激烈性给产品经理带来了诸多挑战。本文深入探讨了如何通过标准化和灵活配置来解决这些挑战，满足不同客户的需求。
1、客户声音的真实反馈
-“我们只有3个员工需要登录，为什么必须为50个员工账号付费呀？”
-“旺季时我们需要临时扩容到200个账号，能否只付3个月费用？”
2、竞争态势的倒逼
-X竞品上月推出了“基础功能免费+增值模块按需订阅”模式，当月转化率提升40%
-Y竞品的账号体系支持与钉钉/飞书组织架构自动同步，实施周期从2周缩短到2天
3、客户组织复杂度演变：从“单一团队”到“生态协同”
-集团型客户：需要母公司统一采购，子公司独立使用并成本分摊
-项目制客户：A项目团队需要高级分析功能（愿意付费），B项目团队只需基础功能（希望免费）
本文主要讲述saas系统商业化的需求背景、需求分析以及一些必须要解决的问题梳理思路。
前几年，小编接手一个Saas系统商业变现的需求——企业租车的客户，希望付费用车的同时，可以使用我们公司的车辆管理平台的系统帮助企业内管好车、用好车以及能提供一些增值的个性服务。我分析来看，企业用户的出发点，是希望在用车的同时有个配套的服务，相比于企业专人转岗管理这些用车（第一他们不一定专业、垂直，第二专门招聘这样的岗位也需要花费一定的人力成本，招进来组织架构也不好放），系统能为他们提供高效的管理、抓手，肯定是性价比比较高的，当然，性价比过低的时候用户也不会买单的。
用户一般都是组织庞大、人数众多的大型企业，只有大型企业才需要这样的服务，要是就一两个人的小公司，也不至于上系统去调度车、安排司机之类的。
这种用户，一般分两种：一种是自己独立运营的企业，他们的数据自己看就可以；
一种是有集团和分子公司的上下层级的企业，这种可能集团还得看下级单位的数据；
所以第二种还涉及企业间的数据权限向上开放的处理。
每个客户有自己的“企业文化”，企业老板的心态肯定是希望一次买单，后续自己管理这个系统就好，当然后续如果需要再使用高阶功能，员工呼声强烈的话，老板也会再次淌血买单的。
企业用户的付费一般都伴随着签署合同、内部审批、对公打款、开发票，所以这份业务流转也需要考虑企业客户的法务合规、合同签署、线下付款、发票开具的流程等。
我们公司老板的预期有以下几个方面：
1、这个Saas要满足商业化变现的价值——简单说——能卖钱、卖很多钱！
2、这个业务流程要有销售激励，因此需要有业务合同、负责销售、绩效奖励的机制。因此销售业绩的基础数据要从你们这个业务线提供，简单说——有人愿意 并且能帮老板卖出去！
老板和客户的需求其实都挺抽象的，啥都需要自己去梳理、细化框架。如果B端企业用户要只有一类就好处理，但是一般情况，“现实都是很骨感的”，B端客户是有很多类型——单一组织架构、多级组织架构，通讯行业、建筑工程、银行金融等行业，抽离出来他们的共性做到基础业务中去，个性化、定制化的需求抽离出来做配置，这样就简单了。
为了我们自己公司效率能够高效、协同、快速响应，所以我这里必须要解决一个重大难题：如何让定制化的付费产品不那么定制化、而是尽可能的标准化呢？
接到一个需求，分析结束后，第一步要做的是——画个圈——PM要决定自己设计的方案要包含哪些内容，自己的需求边界在哪里、自己需要做那些事、分几个阶段做、每个阶段的交付达到什么效果、如何找其他部门配合你的工作。
本次需求范围，我列出了如下四个大方面
为了保障销售业绩数据可查、可提供，因此我们需要对合同、客户进行基础的管理，这里必须记录xx合同是xx销售业务员在什么时间和xx客户签署的、记录下合同的生效周期、合同金额、购买的业务等等。
这些数据是用来计算销售业务员的绩效计算公式的，例如支持按照签单日期统计销售额，支持按照合同到期前一个月提醒销售联系客户续签……总之是用来支持公司内部的业务流转的。
产品标准化的方案，我的设计思路是将Saas系统内的功能权限单独拆分成小的业务单元，把最小的业务单元支持灵活组装，按需组合打包成一个可定义价格的产品包，企业客户根据业务单元的范围进行按需付费。
例如人员组织管理中的 员工账号、角色列表、菜单权限这部分封装成一个小的业务单元——权限管理模块，然后基于业务组合的关键业务模块，可以满足用户的业务流程需求，可能包括核心的几个业务功能；这样通过多选 业务单元的方式配置成一个产品包。产品包的概念是 功能全权限和一些业务配置的集合。业务配置可以包括 这个企业最多的用户数、这个企业最多可管理的车队规模、这个企业的数据保存的时间年限、这个企业最大的数据存储空间（图片、视频、轨迹等数据的存储在哪里存储都是有成本的）……，具体的业务配置有哪些 可以根据企业的业务发展从而抽离出来进行配置。
按需付费其实是比较标准化的，但是我们的业务又不标准，比如大客户M觉得应该包括ABC三个业务模块，但是大客户N觉得应该有AB两个业务模块，所以这样就造成产品的的定价可能千差万别，这样对于大公司内部来讲就得一事一议，所以可能会造成领导审批起来就很累。所以我考虑的是将基本的功能组合成标准的基础业务模块（比如基础配置、权限管理这类的），使用这个业务就是每个月单价0元，然后核心业务A模块里有三个业务定价是每个月10元（这里是举例子）；假设xx企业客户购买了A模块和基础业务模块的组合，则这个产品包的推荐定价为每个月10元，如果B核心业务模块定价是5元，某个客户买了基础业务模块∪核心业务A模块∪核心业务B模块，则可以直接计算这个产品包的价格为每个月15元，所以只要把基本单价做好，其实销售人员/业务管理人员爱怎么组装，怎么组装，领导只需要审批产品包的定价就行了。
当然了，如果某个企业大客户要来讨价还价 ，系统也是需要支持的，这里我的做法是在推荐定价之外加了一个字段——产品包的实际销售价格。
企业账号体系主要是企业账号内的数据权限的继承、以及集团企业间的数据权限不外泄的问题解决。
1、企业账号内部的数据权限
以上两点，在RBAC的数据权限下很好解决，这里我重点强调下xx人员离职的数据权限移交的特殊处理。因为不可避免人员流动，所以这里可以考虑向上转移，就是在人员信息删除/离职操作的时候，一并将数据做转移（数据较多可以异步处理），这里做的是数据权限的转移，而不是业务数据的修改，要不然审计不太合规哦。
2、企业之间的数据权限开放和外泄
1、企业间的数据权限如何开放？
这里可以有好几种方式：
3、按需购买升级产品包后，权限如何自动到账？
这个问题就是普通会员升级到大会员后，产品包内的功能权限由谁来分配呢？可以系统来分配，这个权限直接分配给管理员角色，管理员可以再手动将新买来的功能权限分配给企业内的同事。这样就减轻了Saas平台公司的维护工作量了。
这不仅仅是技术项目，这也是个商业化落地的项目。所以有很多问题是陆续出现的，办法还是比困难多的。注意这里关键因素是快速，快速迭代试错才能足够响应市场和客户。
本文由 @爱喝奶茶的小树丫 原创发布于人人都是产品经理。未经作者许可，禁止转载
题图来自Unsplash，基于CC0协议
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。