SaaS产品3招6式：解决个性化、加固标准化！(3)

上策：标准版解决了差异需求；

中策：在保证标准的同时，用其余方式解决用户的特异诉求； 下策：定制和标准二者保全一个。

1、直接拒绝 每一个不合理的需求本身都有可能导致底层架构的不兼容，引入诸多风险因素。 如果产品只是走马观花地应付眼前的需求，最终会让这个产品越走越艰难。 直接拒绝是一种“ 断舍离 ”的做法，可能会失去一两个客户。

但从好的方面看，也是过滤非价值用户，以及市场份额把握的手段。 2、为用户的个性需求定制开发 为客户的个性需求，另行提供产品或团队来解决，或者将该客户进行项目化独立开发。 比如在与一个大客户的合作过程中，由于其独特的业务模式和记账方式，导致无法与通 用版的相匹配。通用版的客户根本用不到他的功能。 最终的解决办法是就将该客户的产品转化为私有云部署，独立开发。 3、配置 配置说起来简单，但是也不是好办法。对大部分客户而言还是增加了操作复杂度，对开发更是增加了多倍工作量。 最理想的SaaS产品是开箱即用的，而不是增加前置的配置工作。 配置包括套餐配置、数据配置、功能配置等，将会在专门章节具体介绍。 4、灰度发布 在处理一个医药门店场景时遇到这样的案例： 正常的流程是顾客可以通过线上B2C下快递单，总部会从远处的仓库把货物邮寄到客户手里。 但是异常的场景式有客户希望邮寄到附近的门店中，而不是顾客家里。并提供了如下理由： （1）有些药品放在驿站，或者园区的快递专柜，担心温度等条件影响； （2）药店希望与客户有更多接触，以便增加线下的温度； （3）物流公司减少菜鸟驿站你的看管费用； （4）提出诉求的顾客可能更顺路、更顺手。 于是逻辑就变为： 顾客下单——>选择到店自提——>系统获取门店地址作为收货信息——>仓库接单发货——>邮寄到门店——>店员接收通知顾客到店自提。 这种功能具有小众化，并且暗含了一些风险，比如系统获取到的门店的收货信息中电话是店员维护的，万一他不在店怎么办，门店保存的时候没有专门的设备万一纰漏怎么办等。 这时候如果客户执意要做，从产品角度来讲，可以提供灰度的功能。若客户能将其形成一种模式，那么就可以扩大化，并且从功能上做到更多的适配和支持。 5、冷处理 如果你作为一个房屋设计师，智能居室的触控位点设计在那几个位置呢？ 如图所示。如果在交付之前就标准化一刀切设置，那么会发现这并不一定是用户习惯的？ 在工作一段时间之后才发现这种情况下让用户DIY更合适。或者干脆改用不局限位置的声控、红外感应等。 同样做产品也是这样，在没有足够样本的情况下，很难一步到位，只能委屈求全做一些临时过渡功能。 那么这就提示我们，某些需求可以冷处理一下，不要着急着做。即使要做也不要深做，做好统一重构的思想准备。 6、PaaS化 走到PaaS服务能力的公司毕竟是少数。这依赖于足够的技术能力和资源，以及对高价值、高频接口和应用的拿捏。 典型的例子是Saleforece，如图所示，是艾瑞咨询提供的资料，其按照“共性需求解耦化、通用能力平台化”的思路，将分通用的部分从主体产品中解耦下来，以aPaaS的形式将其积木化。 并将通用的API以iPaaS的方式提供给外部。整合产业链上下游厂商等不断丰富生态，显著提升客户粘性，不断抬高公司营收与估值天花板。 其好处如图所示，包括但不限于如下： （1）客户需求：定制需求被满足。 （2）边际效益：得到整体化的解决方案生态闭环,而非彼此独立的CRM、ERP、 OA孤岛。 （3）第三方共赢：ISV开发商被开放API吸引，合作共赢。 （4）服务商效益：增强其影响力与话语权,延长自身的服务链条。构建护城河！ 总结 以上，个性化和标准化需求是相对的，并贯穿于任何产品研发的始终。 通常情况下，服务商会先将明确的部分标准化，然后满足部分客户的个性化需求，再逐步将这部分个性化需求标准化……如此一个循环过程。 另一方面，笔者认为合理的个性化需求更符合企业发展的现状。 此外，只有重视客户的每一个诉求，才有机会掌握市场动向。 总之，标准化与个性化的博弈，考察的是产品经理或高层长处着眼，短处着手的能力。 在整个过程中应当掌握一定原则， 以价值为导向，不让产品锁死服务。 （完）