Saas如何解决好标准产品与个性化需求之间的平衡?-技术圈

我们知道，做Saas产品和做定制化项目之间最大不同是：

做定制化项目，可以根据客户的需求，考虑其业务的特征，最大化的满足客户个性化需求；

做Saas产品时，就要考虑其通用性，如何把产品做的通用，满足更多客户的需求。

但同时，当Saas产品服务的客户越来越多，还是会出现不同的客户有着一些不同的个性化需求。

这时，这个问题该如何解决？

我们可以通过配置化的手段来解决。

当个性化需求的业务流程与现有产品业务流程差别较小，可以从功能层面进行配置来解决个性化需求问题。

当个性化需求的业务流程与现有产品业务流程差别较大，可以从系统层面进行配置来解决个性化需求问题。

通过以上2种可配置方法基本上解决了大多数遇到个性化需求应该怎么办的问题。

不过，

做个提醒，我们做可灵活配置的目的，是为了解决顾客问题，我们有必要把配置做的非常灵活吗？还是要根据实际情况把握好灵活的度？（这个问题我文章后面会回答）

因此，

为了解决如何通过可配置方法，高效的满足顾客个性化需求。

本篇文章，我将从以下3个方面来讲解：

1.功能层面的可配置

2.系统层面的可配置

3.如何把握好可配置的灵活度？

接下来，我将一个一个展开来讲。

功能层面的可配置

当个性化需求的业务流程与现有产品业务流程差别较小，可以从功能层面进行配置来解决个性化需求问题。

具体怎么用？

拿到需求，首先分析需求与现有产品业务流程的差别是否较大。

若差别较小，则先站在整个产品架构的层面来看个性化需求，把需求归类到属于它的模块，在对应的模块里进行可配置操作。

案例1:

这里我还是以上一篇文章聊到的景区智慧营销Saas系统为例，讲一讲面对一个个性化需求时该如何思考并落地。

首先，先介绍一下智慧景区Saas系统目前的现状，目前模块现状是：一级模块“商品管理”里包含了“门票（此时的门票是指付费门票）、特产”两个二级模块。

还有其它如，订单管理、店铺管理、数据管理等一级模块。

大概的架构如下面这样：

然后现在遇到了以下2个最终确定有价值的需求：

1.有的景区想提供给游客免费门票，但需游客提前预约，而有的不需要；

2.有的景区入园时需要出示身份证，而有的景区则不需要；

这时面对不同的景区，都有不同的个性化需求，该如何落地产品设计？

思考过程如下：

1.有的景区想提供给游客免费门票，但需游客提前预约，而有的景区不需要；

那么，这业务需求肯定要归类到商品管理里面的门票管理模块里面去，通过梳理发现，免费门票和付费门票的业务逻辑，在整个后台景区工作人员的工作流里，基本上是一致的，不同点就是有的景区门票收费，有的免费。

这时只需要在门票管理模块里配置一个是否要收费的功能，就能把这这个问题解决了。

如果不需要收费的门票，工作人员选择了不需要按钮，图片中的市场价和销售价框就会被置灰，不能操作。

2.有的景区入园时需要出示身份证，而有的景区则不需要；

这时也简单，在门票管理模块里配置一个“景区可选择取票时是否需要出示身份证按钮可供选择”就能解决问题了。

案例2:

还是以上面的景区Saas为例，每个景区都需要有一个店铺（或者说，叫做商城系统）来面对C端游客，供游客查看、下单各种商品。

这个时候，行业内的不同景区都希望自己家的店铺和别家的不一样，想要自己个性化的店铺，面对这样个性化的需求如何解决？

方法1，

可以开发出很多套来供景区选择，这样做不好的地方是，开发的越多，投入的产研成本越大，甚至开发出来的店铺模版，景区不一定满意。

方法2，开发出来的每一套店铺模版，店铺模板中的功能组件（景区可以自由增加、删除、修改），最终搭配出一个自己比较想要的个性化店铺模版。

案例3:

有一款产品叫“微伴助手”，是企业微信里，做私域流量运营的一个工具。

在帮助服务的商家解决客户转化问题时，其中有一个解决方案是，围绕用户的全生命周期做精细化运营管理的方案。

可在微伴助手服务的所有商家里，大家的生意业务逻辑不一样，对客户的全生命周期管理也不一样，也就是“围绕用户全生命周期做精细化运营管理”有了不同的个性化需求。

这时，微伴助手给出的解决方案是：

给出了一套可配置的“全生命周期管理方案”。

从图中我们可以看到微伴助手软件首先给出了一个默认配置好的用户全生命周期解决方案。

分为，

新客户——初步沟通——意向客户——商家——无意向客户这5个阶段。

这个生命周期的划分只是初步划分，商家可以根据自己业务的个性化需求，对这个划分进行编辑、增加、删除。

删除是指，这5个阶段，可以删除掉1个、2个等等，根据你的业务需要，进行调整。

增加是指，除了这5个阶段，你还想增加更多的阶段，根据你的业务需要，进行调整。

编辑是指，你可以对客户阶段名称、阶段提醒规则的重新调整。

我举的这几个案例，我们可以看到一个现象，就是默认项的设置，比如门票是否收费，默认的配置是需要收费（这是因为，收费门票的场景会更常用）。

我们在做功能配置项时，也要做好默认项设置工作，看什么的设置需求更高频，把它变为默认设置项。

以上，

就是面对个性化需求时，当个性化需求的业务流程与现有产品业务流程差别较小，从功能层面进行配置来解决个性化需求问题的一个整体讲解。

系统层面的可配置

当个性化需求的业务流程与现有产品业务流程差别较大，可以从系统层面进行配置来解决个性化需求问题。

为什么需要从系统层面来进行配置？

因为，功能来源于需求，需求受流程的影响，当用户个性化的需求与现有产品架构流程差别较大时，只能从系统层面来配置。

从系统层面来配置时，有三种解法：

第一种是，配置的权限在Saas产品服务商手里，Saas服务商根据顾客的需求，进行后台配置；

第二种是，配置的权限在顾客手里，顾客根据自己的业务需求来进行权限配置；

第三种是，系统自动配置。

具体什么意思呢？

我们下面用一个案例来讲讲。

这个案例，还是用文章中，我们提到的景区Saas产品案例来讲解。

景区Saas产品中，目前有的业务系统就是票务系统；但是根据Saas软件服务的景区中，有的景区还有酒店管理系统需求，而有的没有，这个时候应该怎么办？

首先我们经过初步分析，发现酒店管理系统和现在产品架构的业务流程差别还是比较大的。

只能在商品模块里面在添加一个房型管理（之前的商品模块里有一个门票管理），然后因住宿而增加的订单、数据需求加到之前的订单、数据模块，新增加的这些功能合在一起形成一个完整的住宿管理系统。

这个住宿管理系统可通过以下几种方法在系统层面进行配置，最终满足景区的个性化需求。

1.默认景区都有住宿系统需求，景区注册Saas软件后，若景区不需要住宿、或者是门票系统，联系Saas服务商，服务商手动给景区配置，把不需要的系统去掉，给景区留下需要可简洁操作的功能；

2.给景区默认的是一套没有住宿系统的版本，当景区有需求时，Saas服务商再通过后台给配置；

3.景区注册系统时，提示景区是否有哪些系统需求，景区选择完后，根据景区的需求，自动配置出景区需要的系统。

最终选哪种？这没有标准答案，根据产品经理综合评估以后来选择（包括产品收费方式、发展阶段，技术实现难度等等因素）。

如何把握好可配置的灵活度？

当然，可配置不是万能的解药，我们不能认为，既然有那么多个性化的需求，我们把各个功能都做成可配置就可以了。

要记得我们的一个终极目标，我们开发的Saas产品是为了帮助客户解决问题的，希望客户能持续用起来，以后还继续付费。

如果灵活配置度过高，配置项多，就会带来页面的不简洁，看起来、且操作起来就会麻烦，增加顾客工作量，且还会大大的增加开发成本和开发周期。

因此我们需要综合评估以后（包括对客户的理解，收入方式，客户服务投入度等），把握好灵活度。

比如，

就像我在文章中提到的：

景区对店铺有个性化需求，因此开发出来的每一套店铺模版，店铺模板中的功能组件，景区可以自由增加、删除、修改，最终搭配出一个自己比较想要的个性化店铺模版。

假设是给中小商家用，

你说，如果你问顾客，他有店铺个性化需求吗？

回答是肯定的。

但是开发出来以后，我们会发现，小商家根本就用不了，不会用，你需要的是给他一套固定好的模版就行。

同时，就算会用，由于小商家对产品的购买付费金额会比较低，而在店铺模版环节做那么多的个性化需求，投入的产研周期是比较长，且成本比较高，会大大的增加产品的盈利难度。

综合评估完，只需要有一两套简单固定的店铺模版就好。

最后，

关于Saas产品如何解决标准产品和个性化需求之间的平衡就讲到这里了。