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

系统层面的可配置

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

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

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

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

1. 配置的权限在Saas产品服务商手里，Saas服务商根据顾客的需求，进行后台配置；
2. 配置的权限在顾客手里，顾客根据自己的业务需求来进行权限配置；
3. 系统自动配置。

具体什么意思呢？我们下面用一个案例来讲讲。

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

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

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

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

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

• 默认景区都有住宿系统需求，景区注册Saas软件后，若景区不需要住宿、或者是门票系统，联系Saas服务商，服务商手动给景区配置，把不需要的系统去掉，给景区留下需要可简洁操作的功能；
• 给景区默认的是一套没有住宿系统的版本，当景区有需求时，Saas服务商再通过后台给配置；
• 景区注册系统时，提示景区是否有哪些系统需求，景区选择完后，根据景区的需求，自动配置出景区需要的系统。

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

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

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

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

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

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

假设是给中小商家用，你说，如果你问顾客，他有店铺个性化需求吗？