

首页  思维导图  详情



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产品是为了帮助客户解决问题的，希望客户能持续用起来，以后还继续付费。 如果灵活配置度过高、配置项多，就会带来页面的不简洁，看起来、且操作起来就会麻烦，增加顾客工作量，且还会大大的增加开发成本和开发周期。 因此我们需要综合评估以后（包括对客户的理解、收入方式、客户服务投入度等），把握好灵活度。 比如，就像我在文章中提到的：景区对店铺有个性化需求，因此开发出来的每一套店铺模版，店铺模板中的功能组件，景区可以自由增加、删除、修改，最终搭配出一个自己比较想要的个性化店铺模版。

假设是给中小商家用，你说，如果你问顾客，他有店铺个性化需求吗？ 回答是肯定的。 但是开发出来以后，我们会发现，小商家根本就用不了、不会用，你需要的是给他一套固定好的模版就行。 同时，就算会用，由于小商家对产品的购买付费金额会比较低，而在店铺模版环节做那么多的个性化需求，投入的产研周期是比较长，且成本比较高，会大大的增加产品的盈利难度。 综合评估完，只需要有一两套简单固定的店铺模版就好。