很多时候，我们可以从一些需求中深挖出不一样的东西。这篇文章里，作者讲述了自己在CRM领域中遇到的一个优化需求，一起来看看本文所延伸的系统功能思考。

前段时间CRM关于客户申领遇到了一个优化需求。希望申请后审核通过的可以直接变成保护状态（在待营销中的客户）。

前情概述：

如正常的CRM系统规则，客户在一定时间内没有进展是会掉入公海的。

在新制度出来前是没有客户等级这个概念，于是营销可以任意申领客户。

新制度出来后，公司根据类型和规模划分了等级，针对已经保护中的客户是不受新制度约束，如果掉入公海或者新建一个新的客户是要受新制度的约束。

如果营销没权限去保护就要走申领这一步操作，需要相关管理人员进行审核，通过后才能保护继而营销。

之前因为制度相关的功能都在另一套管理系统，而客户相关的在CRM系统，分属不同的产品管理。因此在最终方案上有瑕疵，各做各的，只是最后把数据同步了。

那么就出现了一个问题，营销从公海中想要申领这个客户，但是呢提示没有权限，需要去管理系统中申请客户资源，等营销去管理系统申请客户资源之后，由相关人员进行审核，通过后，营销需要再次去公海进行申领。因此全部流程只是做了资格权限的申请而已，不是客户的直接申领。显然这中间就多余了操作步骤。

现在系统归到了一位产品手中，为了解决上述问题，我们展开了讨论，如何去解决这个问题。

从上述描述来看我们可以看到营销在CRM中申请客户，但是只是告知了没有权限，之后再无下文，这是断档1。

营销去管理系统申请并审核通过后，也只是获取了资格，没有形成有效的保护，这是断档2。

这中间其实还引申了另一个问题，我们申请的这个客户之后是这个客户的全部条线产品还是单一条线产品还是单个产品，这个我们放后面说。

既然现在是一个产品来负责了，那么我们可以将系统归集起来，因此这里又引申出两个问题。

1. 营销申请是在哪申请（CRM还是管理系统）？
2. 审核是在哪里审核（CRM还是管理系统）？这里还有一个小问题，审核的人和层级是否可变，是否需作配置？

带着这些问题，我们按照优先级来规划下项目的迭代版本。

因为整体的功能已经有了，只是如何把这些功能串起来，不做的话，人工操作会多一些，而人会有遗忘，操作越多，涉及系统越多会出现变数。

因此最优先解决的是断档2中的问题，因为营销去公海申请客户，发现没权限，知道要去哪里申请了，就去了，但是申请通过之后，可能没来得及再次领出来，就被被人领走了，这就比较麻烦了。

因此我们的步骤1是审核通过后自动将公海中的客户转为营销保护。那么这个客户有多产品线多产品呢，是否全部保护？这个我们后面来讲。

紧接着我们再来处理断档1的问题，于是就有了步骤2。步骤2要做的是当营销去公海申请客户的时候，提示没有权限，顺便询问是否申请，如果营销选择申请的话，自动在管理系统生成一天客户申请的记录，等待审核即可。

好，到了这里我们营销跨系统去申领客户的动作都给解决了，那么我们就要来解决审核到底在那个系统进行。因为步骤2中已经解决了申请在在CRM自动创建申请记录。

这个我们就要看审核人是谁，他们经常使用什么系统进行操作，于是又牵扯到了配置问题。

那么步骤3就是我们的审核配置，因为客户会跨条线，而每条条线的负责人是不一样的，除非是由公司的统一部门来审核，比如说董事长之类的，一般会下放到各条线负责人，毕竟他们懂自己条线的业务及知道目前处于什么情况是否可以由该营销人员进行营销。

这里面就涉及到了我们申请客户保护的范围是什么？是全部（只要申请一次这个客户，所有条线产品都可以申领）？是条线（通过后营销只能申领这条线下的产品）？还是产品（每次申领都是要申请审核的）？

那么这个问题还是回归到业务问题，只是我们不能只听他们的，我们需要告知每种形式的优势和弊端。

第一种，全部的。那么这里面的优势显然是一次操作众生收益，不需要频繁操作了；弊端也显而易见，有些不该营销人员营销的就不好控制，以及如果是全部的话，那么由各业务线负责人审核这件事显然也不合适，会起冲突。

第二种，条线范围内，这个是比较折中的，条线本不多，而且各自负责人都有，且对营销比较了解。弊端则是如果产品多，好的条线的营销都想去，也会出现大包大揽的现象，这样就造成资源的浪费了。

第三种，产品级，这是比较严谨的，你要销售什么产品就申请什么产品，好管控，缺点在于每个产品都申请可能比较频繁。

那么就要分析当前营销的产品及每个客户会用到的产品数量多寡来决定采用哪种方案。从当前情况来看的话，采用第三种比较合适，首先每个客户购买的产品不多且固定，其次在申请的时候可以批量申请，不是一个个申请。这样就能达到当前阶段最优效果了。

当然也有人说，那么我以后变了呢？

如果变化不是很频繁，几年变一次的，直接硬编码。如果想要做得更灵活多变的，那么做个配置，申领后是控制全部还是条线还是产品，这样只需要把配置切换下即可，顺便更改下审核人员，因为从产品或条线切换到全部的时候，如果审核人员没切换回来那么就需要默认一个审核人或者只要申请的相关条线的负责人任意一个审核都行，这些都基于业务，我们提供参考建议。

最后一步就要确定操作放在哪个系统。那么这个其实是需要看操作人的，他们习惯在哪个系统中，不是说这个功能是CRM相关的，就一定放在CRM中，如果审核人之前不需要使用CRM系统，那么势必还会要给他配置权限以及审核人员出现系统来回切换的问题。

当我们分析到这里的时候，我们其实把版本迭代的顺序都理顺了，那么接下来我们如何做，就看业务方的建议是否全套做还是按部就班以及看研发时间，来决定最终使用哪种方案来完成这部分的优化功能。

在分析一个功能的时候，需要把这个功能的范围放大了看，放在整个流程链路中去看他处于什么位置，会对这条链路有什么影响，还可以再放宽到整个系统中去看，这个对整个系统的影响，在不断放大的过程中，我们会发现不一样的问题，这也是我们经常做完了这个需求发现其他地方出问题了。因为我们只看到了这块内容，没有放大去思考。

就像历史事件，我们在看的时候，只知道这个时候发生了什么，没有去看为什么偏偏在这个时候发生了。或者只是在这个时候爆发了开来而不是开始。比如打车、外卖等行业的崛起，其实是在移动互联网兴起的时候起来的，那么移动互联网又是在智能机普及的时候兴起的，再加上3G的推广，才会有这些行业的兴起。

不存在没来由的需求，放大了看会发现不一样的东西，有助于我们去挖掘需求，做好产品。

不正之处，请不吝指教！