SAAS化产品定制化需求
2023-04-14 14:13:35 1 举报AI智能生成
了解SAAS产品，对于客户定制化需求的处理提供了一些建议
作者其他创作
大纲/内容
SAAS产品过程中，用户需求中的定制化部分难免会与其自身的产品化产生矛盾冲突。当遇到这种情况时，如何进行平衡处理，是一个合格的产品经理必须掌握的技能之一
先明确SAAS产品特点及框架
SaaS(software as a Service)
案例：随着公司有了一套完整的后台系统，老板希望拓展新的盈利方向，将已有的后台系统作为标准产品面向外部客户销售，即SaaS化服务
SaaS产品具备以下基本特点
1、托管在远程服务器上
2、可通过互联网访问（通常是浏览器或移动端）
3、用户不负责硬件或软件更新（统一维护）
4、提供统一的服务和收费
5、在商业意义上，SaaS是一种收入模式
客户通过互联网进行软件访问，并通常会按每月/年订阅形式支付费用
注意：SaaS是针对B端企业客户
SaaS产品的框架
一个SaaS产品通常由管理平台、租户实例、用户界面三个部分构成
分别对应SaaS产品的平台端、租户端、用户端三大功能模块
以飞书为案例
飞书的管理平台是谁？
飞书公司
飞书的租户实例是谁？
它的合作客户
每个合作的客户根据自己的情况定制了不同的功能，用的过程中就产生了数据留存。功能加上数据就形成了一个实例
飞书的用户界面
我们具体的员工在使用过程中，打开了飞书，见到的就是用户界面
SaaS租户和实例
SaaS是基于一套标准软件系统，为多个不同客户提供服务
SaaS的客户也叫做“租户”（多租户系统）
租户下的应用使用者即“用户”，租户给用户鉴权后用户才能使用
一般来说，不同租户之间的数据是相互隔离的，保证安全的同时也能适应差异化需求
软件系统加上这些相互隔离的数据，构成了租户的“实例”
SaaS平台通常按实例的使用时长向租户收取费用，形成“租约”（订阅），租约通常由租户、租用内容、有效期等信息构成
SAAS产品与定制化项目之间最大的不同是
定制化项目，可以根据客户的需求，考虑其业务的特征，最大程度满足客户个性化需求
SAAS产品，要充分考虑的是通用性，如何把产品做得通用，满足更多客户的需求
解决建议
通过配置化的手段来解决
当个性化需求的业务流程与现有产品业务流程差别较小，可以从功能层面进行配置来解决个性化需求问题
当个性化需求的业务流程与现有产品业务流程差别较大，可以从系统层面进行配置来解决个性化需求问题
具体说明
一、功能层面的可配置
拿到需求，首先分析需求与现有产品业务流程的差别是否较大
若差别较小，则先站在整个产品架构的层面来看个性化需求，把需求归类到属于它的模块，在对应的模块里进行可配置操作
案例解析：以景区智慧营销Saas系统为例，每个景区都需要有一个店铺（或者说，叫做商城系统）来面对C端游客，供游客查看、下单各种商品。
这个时候，行业内的不同景区都希望自己家的店铺和别家的不一样，想要自己个性化的店铺，面对这样个性化的需求如何解决？
这个时候，行业内的不同景区都希望自己家的店铺和别家的不一样，想要自己个性化的店铺，面对这样个性化的需求如何解决？
方法一：可以开发出很多套来供景区选择，这样做不好的地方是，开发的越多，投入的产研成本越大，甚至开发出来的店铺模版，景区不一定满意。
方法二：开发出来的每一套店铺模版，店铺模板中的功能组件（景区可以自由增加、删除、修改），最终搭配出一个自己比较想要的个性化店铺模版。
二、系统层面的可配置
当个性化需求的业务流程与现有产品业务流程差别较大，可以从系统层面进行配置来解决个性化需求问题。
为什么需要从系统层面来进行配置？
因为，功能来源于需求，需求受流程的影响，当用户个性化的需求与现有产品架构流程差别较大时，只能从系统层面来配置。
如何做
配置的权限在Saas产品服务商手里，Saas服务商根据顾客的需求，进行后台配置
配置的权限在顾客手里，顾客根据自己的业务需求来进行权限配置
系统自动配置
案例说明
景区Saas产品中，目前有的业务系统就是票务系统；但是根据Saas软件服务的景区中，有的景区还有酒店管理系统需求，而有的没有，这个时候应该怎么办？
首先我们经过初步分析，发现酒店管理系统和现在产品架构的业务流程差别还是比较大的。
只能在商品模块里面在添加一个房型管理（之前的商品模块里有一个门票管理），然后因住宿而增加的订单、数据需求加到之前的订单、数据模块，新增加的这些功能合在一起形成一个完整的住宿管理系统。
这个住宿管理系统可通过以下几种方法在系统层面进行配置，最终满足景区的个性化需求。
首先我们经过初步分析，发现酒店管理系统和现在产品架构的业务流程差别还是比较大的。
只能在商品模块里面在添加一个房型管理（之前的商品模块里有一个门票管理），然后因住宿而增加的订单、数据需求加到之前的订单、数据模块，新增加的这些功能合在一起形成一个完整的住宿管理系统。
这个住宿管理系统可通过以下几种方法在系统层面进行配置，最终满足景区的个性化需求。
默认景区都有住宿系统需求，景区注册Saas软件后，若景区不需要住宿、或者是门票系统，联系Saas服务商，服务商手动给景区配置，把不需要的系统去掉，给景区留下需要可简洁操作的功能；
给景区默认的是一套没有住宿系统的版本，当景区有需求时，Saas服务商再通过后台给配置；
景区注册系统时，提示景区是否有哪些系统需求，景区选择完后，根据景区的需求，自动配置出景区需要的系统。
最终选哪种？这没有标准答案，根据产品经理综合评估以后来选择（包括产品收费方式、发展阶段，技术实现难度等等因素）。
给景区默认的是一套没有住宿系统的版本，当景区有需求时，Saas服务商再通过后台给配置；
景区注册系统时，提示景区是否有哪些系统需求，景区选择完后，根据景区的需求，自动配置出景区需要的系统。
最终选哪种？这没有标准答案，根据产品经理综合评估以后来选择（包括产品收费方式、发展阶段，技术实现难度等等因素）。
三、如何把握好可配置的灵活度
当然，可配置不是万能的解药，我们不能认为，既然有那么多个性化的需求，我们把各个功能都做成可配置就可以了。
要记得我们的一个终极目标，我们开发的Saas产品是为了帮助客户解决问题的，希望客户能持续用起来，以后还继续付费。
如果灵活配置度过高、配置项多，就会带来页面的不简洁，看起来、且操作起来就会麻烦，增加顾客工作量，且还会大大的增加开发成本和开发周期。
因此我们需要综合评估以后（包括对客户的理解、收入方式、客户服务投入度等），把握好灵活度。
比如，就像我在文章中提到的：景区对店铺有个性化需求，因此开发出来的每一套店铺模版，店铺模板中的功能组件，景区可以自由增加、删除、修改，最终搭配出一个自己比较想要的个性化店铺模版。
要记得我们的一个终极目标，我们开发的Saas产品是为了帮助客户解决问题的，希望客户能持续用起来，以后还继续付费。
如果灵活配置度过高、配置项多，就会带来页面的不简洁，看起来、且操作起来就会麻烦，增加顾客工作量，且还会大大的增加开发成本和开发周期。
因此我们需要综合评估以后（包括对客户的理解、收入方式、客户服务投入度等），把握好灵活度。
比如，就像我在文章中提到的：景区对店铺有个性化需求，因此开发出来的每一套店铺模版，店铺模板中的功能组件，景区可以自由增加、删除、修改，最终搭配出一个自己比较想要的个性化店铺模版。
假设是给中小商家用，你说，如果你问顾客，他有店铺个性化需求吗？
回答是肯定的。
但是开发出来以后，我们会发现，小商家根本就用不了、不会用，你需要的是给他一套固定好的模版就行。
同时，就算会用，由于小商家对产品的购买付费金额会比较低，而在店铺模版环节做那么多的个性化需求，投入的产研周期是比较长，且成本比较高，会大大的增加产品的盈利难度。
综合评估完，只需要有一两套简单固定的店铺模版就好。
回答是肯定的。
但是开发出来以后，我们会发现，小商家根本就用不了、不会用，你需要的是给他一套固定好的模版就行。
同时，就算会用，由于小商家对产品的购买付费金额会比较低，而在店铺模版环节做那么多的个性化需求，投入的产研周期是比较长，且成本比较高，会大大的增加产品的盈利难度。
综合评估完，只需要有一两套简单固定的店铺模版就好。
0 条评论
下一页
