笔者在工作过程中，几乎每天都被个性化需求所“折磨”，偶然有感，故简单做个小结，希望对你有启发~
SaaS的本质是标准化
SaaS产品的本质是续费率和服务，也是标准化和规模化。因为只有标准化才能规模化，只有规模化才能覆盖前期投入的巨大研发成本。
比如有赞创始人白鸦说他们共有7个系统，20000多个功能，如果按25人日/功能，3000元/人日，那过去11年他们对系统研发的投入将超过30亿。
每年平均需要2亿的研发成本，那至少需要年营收10亿才能盈利。如果按客单价1万计算，那就需要至少10万家商家客户。
所以只有标准化、规模化，才具备盈利可能性。
客户需求 = 标准化需求+个性化需求
如果从SaaS服务提供者（即企业）视角切换到SaaS服务采购者（即B端客户）视角，可能就会发生一个视角差。
即每个商家对SaaS产品的需求，是标准化需求与个性化需求之和，只是这二者的占比有差异。同时，它们二者的比例会随着时间的推移、市场的变化，配比也会发生变化，这就会影响续费的意愿度。
比如A客户采购某SaaS产品时，标准化需求与个性化需求比是9:1，1年后其业务发生重大变化，导致新需求出现，导致二者配比变成8:2（甚至7:3）。
作为SaaS产品提供者如果不能及时满足其需求，那A客户的续费成功率将会降低不少。
如何解决标准化与个性化需求之间的矛盾？
方法论：从系统角度解决问题，而不是从问题的症状或人
回到SaaS服务系统，则可考虑从两个视角去解决：商业模式、产品设计。
从商业模式视角
商业模式是经营活动集合以及相关利益者的交易结构。
交易结构则包括五大部分：交易要素、交易主体、交易方式、交易收支、交易风险管理。
具体到SaaS商业模式，我们可以着手优化的方向是：交易要素与交易方式。
SaaS交易结构示意图
第一，从交易要素看，可将软件系统与服务的售卖颗粒度细分，让客户实现积木式按需购买，解决大颗粒度的个性需求。
- 从模块上，可以将一个完整系统拆分成多个模块进行售卖。比如HR SaaS系统可拆分为：组织人事、考勤管理、薪酬税务、绩效考核、招聘管理、培训管理等；
- 从服务上，可将服务拆分为对接服务、接口服务、实施服务、定制化升级服务、插件化升级服务等。
第二，从交易方式看，保持订阅制模式，但改变渠道商与SaaS企业的关系（甚至是第三方开发者），来满足客户定制化、插件化个性需求服务的问题。
- 原有模式：渠道商核心负责销售、营销产品，以及成交后的实施与培训服务，产品的研发与升级，统一均有SaaS企业负责，导致个性化需求无法有效得到响应。
- 新模式：渠道商保留现有职能外，还可负责升级系统，解决其客户的个性需求。同时可将其解决方案进行插件化，最终售卖给其他有类似需求的客户。
-
同理，第三方开发者，如果对应有兴趣，则也可进行插件化开发，最终放到对应插件市场进行售卖。比如Salesforce的AppExchange、钉钉的钉钉搭等，都类似这种模式。
AppExchange
钉钉搭
从SaaS产品设计角度
第一，可配置化产品设计。通过预制能力的产品设计方式，提供尽可能多的能力供用户进行配置化使用。
可配置化产品设计分层
1、权限层配置化。一般包含菜单权限和数据权限配置，可采用角色、角色组赋能用户，实现不同客户对权限、数据的个性化控制需求。
比如钉钉管理员的权限设计，可定义管理范围以及应用权限范围。
钉钉子管理设置
菜单/管理权限配置
2、页面层配置化。一般包含页面列表、详情、视图、字段等的配置，客户可按需进行页面的配置，实现个性化的页面需求。
比如北森的配置化平台，可以实现每个模块、每个页面的按需配置。同一个页面也实现不同客户的显示列表、字段、按钮、视图等有差异。
页面详情配置
页面视图配置
特殊说明：这种模式本质上来说，已属于Paas平台的范畴，如果是轻量级的SaaS配置化，则可采取更简化的方式。
3、功能层配置化。一般包含页面功能、要素、逻辑、规则的组合，满足不同客户的个性化需求。
比如飞书考勤管理端的【假期规则】，则可逐层、逐级进行按需配置。
第一层：默认假期类型与自定义假期类型。允许用户在系统预置假期类型的基础上，自定义企业自身的假期类型。比如献血假、慈善假、福利年假、妇女节、父亲节等。同时，通过内置的模板，供客户快捷设置。
假期模板设置
第二层：自定义假期规则。允许用户根据实际诉求，自定义员工请假规则、发放规则、使用规则等。
1、请假规则
2、发放规则
3、使用规则
特殊说明：产品规则/逻辑的抽象程度与颗粒度，决定了扩展性，扩展性最终将影响个性需求的满足程度。
举个例子。
上述年假发放规则中，如果抽象为【年假周期】（如年/半年/季度/月）与【发放频率】（如按天发/一次性发）两个要素进行组合，则可扩展出8种组合。
反之，如果不抽象，默认【年假周期】就是【年】，【发放频率】就是【一次性发】（但可限制请假时【按天折算请】），则后续的扩展性就将大大被影响。
第三层：假期余额显示与调整。允许用户对于假期余额在员工端的显示与否进行设置，也允许用户对假期余额的额度、有效期等进行调整，满足过程中不同客户有可能出现的个性需求。
假期余额明细
修改假期余额
4、字段层配置化。一般包含系统预置字段、自定义字段，允许用户可使用自带字段，也可自定义符合自身计算规则的字段，实现不同客户对不同计算逻辑有差异的需求。
比如飞书的报表相关字段，可分两层进行个性化设置。
第一层：自定义报表以及相关字段顺序等。用户可按需设置每个报表的字段以及顺序。比如每日情况表，只要打卡时间与时长、每日应时长、每日实际出勤、每日加班时长等。
自定义报表字段
第二层：自定义字段的规则。用户可按需定义字段的规则。比如30分钟以上迟到计为【严重迟到】；或【实际出勤时长】需刨除【外出时长】等。
自定义字段
第二，开放Api接口设计。通过开放对应的Api接口与数据，让具备研发能力的客户（或第三方），可二次研发解决部分个性化需求。
比如某HR SaaS产品可开放对应的排班、打卡、假期、外勤类、日报等数据，对应客户则可采用自研或第三方对接的方式，实现取两者最佳功能的效果。
比如某客户是餐饮行业，对于排班有自己的规则与诉求，所以自研了一套智能排班系统，可实现根据历史营业额、天气情况、岗位、人数等情况，自动完成排班。
同时，采购SaaS产品，主要是用于算薪扣税等，但其排班能力相对比较标准，无法有效支撑所有需求。此时就可借用对应SaaS企业的OpenApi能力，把原系统的排班等信息同步过去，保证出勤结果的正常计算，最终可实现算薪与扣税等。
自研排班系统
或者某客户的人力是通过第三方外包过来，每日的出勤结果需要双方及时确认，否则影响最终的薪资结算。
但标准化SaaS产品不太会支持此功能，此时，如果SaaS系统可以把每日出勤结果（即日报）通过OpenApi的形式对外开放，则其就可自行研发，实现双方的每日出勤结果确认。
总结
1、SaaS本质是续费和服务，也是标准化和规模化，而客户一定有个性化需求，“阻碍”规模化，所以如何解决这二者的矛盾，成为SaaS企业的一大痛点；
2、遵循“系统角度解决问题，而不是从问题的症状或人”的方法论，从商业模式与产品设计两个角度切入解决个性化需求问题；
3、从商业模式角度，则主要有两种可行解决方案：
- 第一种是改变交易要素。将软件系统与服务的售卖颗粒度拆分，让客户像购买积木式一样按需购买，解决大颗粒度的个性需求；
- 第二种是改变交易方式，保持订阅制模式的同时，改变渠道商与SaaS企业的关系（甚至是第三方开发者），实现插件化研发，且提供插件交易市场。
4、从产品设计角度，则主要也有种可行解决方案：
- 第一种是可配置化产品设计。可细分为四个方向：权限配置化、页面配置化、功能配置化、字段配置化。
- 第二种是开放Api的方式。
5、解决方案虽好，按需使用就好。任何一种解决方案都是需求、成本、商业价值综合权衡后结果，并不存在一蹴而就，也不一定全部解决方案均采用。
