中台产品驱动业务功能优化案例

今天以一个实际案例来讲讲，我们在处理一个需求时，该如何考虑需求的规划，业务的闭环，以及后续的跟进。

这个功能是关于导购与客户关系链的自动解绑，需求的原始诉求是希望通过给导购已经绑定的客户关系链制定各种约束条件或者叫做考核机制，如果这个导购没有达到，那么就要把导购和客户的关系解绑掉，从而给导购压力，起到让导购积极沟通并跟进客户的作用。

通过这里面的描述我们必须马上发现，其实解绑关系链只是激励导购积极沟通客户的一种解决方案。常规情况下我们会提出，如果想要达到激励导购的效果，不仅仅是关系链解绑规则这一个解决方案，我们可以扩散思维考虑很多个解决方案，然后再考虑，哪个解决方案的优先级最高。

当然了，这个产品同学她就负责关系链，所以她一定会在关系链这个事情上想办法，而其他的基本功能也都满足了，现在也是创新尝试阶段，所以我们就先默认为这个关系链解绑规则的需求，是一个可以优先尝试的解决方案。

那么，应对这个需求，这位产品提出的解决方案，大致上就是这样的：

1.约束了是否解绑的开关设置。

2.配置了几个简单的规则条件，用于执行关系链是否解绑。

3.提供了关系链绑定和解绑记录给商户（所有解绑和未被解绑的放到一起了），商户自己随意愿去捞人看要不要把人重新手动绑定。

看到这个需求，我提出了几个问题。

1.未来关系链这里针对于导购的激励和引发，有什么作用，是如何规划的？

2.关系链解绑了，被解绑后的用户就没有上级，属于完全无人触达和维护的状态，业务如何闭环？

3.这个需求上线后，我通过什么方法判断我这个需求到底有没有达到效果？

4.这个设置界面，这样的交互，商户能否理解，如果遇到不懂运营方法论的商户，如何引导，往大了说，是否真的做到了“赋能”？

下面我们一个一个来拆解下我这些问题的目的，以及如何解决。

1.未来关系链这里针对于导购的激励和引发，有什么作用，是如何规划的？

这里主要是在问，目前我们看到的这个功能只是第一阶段的一个小的迭代计划，长远了看，这个功能的产品策略是什么，现在通过这样的一个功能结构和信息排布，我们是完全抓不到重点的，不知道未来是什么，甚至有点看不懂应该如何配置。

经过多次沟通和讨论，我发现这位产品是有想法的，后续关系链作为线索，会有线索分配机制，从线索分配，线索回收整体规划，但是为什么呈现的需求比较难懂呢？一方面是和页面的布局和信息结构有很大的关系，另一方面“关系链线索解绑和分配机制”也是站在功能角度，并不是站在业务角度。

后来，我引导这位产品往“关系链分层运营”去思考，参考RFM模型和用户分层方法，把关系链的绑定时间作为一个纬度将关系链分层。具体这个结论怎么来的，大家将在后面第 4 点看到。

这样我们就能够看到，这个功能的未来，是一个以关系链为基础的，可以根据关系链的绑定时间和其他纬度进行关系链的分层，再对不同分层的关系链进行不能纬度的指标关联，进而引导导购形成“绑定周期不同的关系链，需要用不同的目标和方法”的心理意识，她只需要听话照做就可以得到阶段性的成绩。

这时候作为中台，我也能够比较清楚的看到，我需要提供线索（关系链）聚类能力，线索（关系链）与指标关联能力，线索（关系链）回收规则模板。

2.关系链解绑了，被解绑后的用户就没有上级，属于完全无人触达和维护的状态，如何闭环？

这个问题是大部分产品经理最容易犯的错误，实际上，这个产品经理是有这方面的规划的，她知道应该在解绑了关系链之后，把被解绑的无上级的客户都放回“公海”，然后再通过后续的分配规则，促进公海里的客户被导购重新绑定，进而形成新的触达。然而，很多人的阶段性拆解就如同这位产品一样，先做一个解绑功能吧，下一个版本再做分配。

这个问题十分恐怖。

那些被解绑的客户，如何才能被重新捡起？其他导购如何知道去哪儿可以捡起这些被放回归公海的客户？商户手动操作吗？是否有引导路径，否则一旦出现一大批被解绑的，商户每天花多少时间重新分配？你业务会说，不会有那么多的被解绑的，但是，对产品结果的敬畏心是产品经理的重要同理心，小批量也是损害。在没有公海池子和分配机制的情况下，是否允许原来的导购通过什么方法重新找到原来的客户（因为可能存在误伤）。

是不是发现，哪怕功能规划不清晰，产品策略不完整，都可能不会在当时当下造成大问题，这种无法让业务闭环的需求，会有短时间爆发大量问题的效果。

也许你会说，我本来想了自动分配啊，可是这样这个功能就很庞大了，这一次只是一个小版本迭代。

是的没错，是小版本迭代，所以我们只要最小化闭环就可以了，关系链解绑规则做最简单实用的（按跟进次数），重新绑定按最简单的商户手动分配，但是需要做好商户重新分配的路径和机制就可以了（后面我们会发现，商户路径也不畅通）。

这样才是，从一个滑板车到小汽车的过程，而不是从一个轮子到一辆小汽车的过程，对吗？

3.这个需求上线后，我通过什么方法判断我这个需求到底有没有达到效果？

你猜到了，是的没错，这个问题是在问，你有没有什么数据需求？

其实作为一个中台产品，业务做的好不好，效果如何，前期我能给的功能支持并不多，但是我并不希望一个功能做了之后，没有任何的效果，甚至都不知道后面怎么优化。另外也经常出现，做功能的时候不考虑数据，等到要统计数据的时候才发现原来的功能要改一下或者要加个字段，或者要加个接口才能统计到某个数据。

而且，团队逐渐大了，分工又细又不明确的情况下，数据需求谁来做，谁来提供明细，谁来做聚合，能否实时等等，都是需要跨团队多方讨论的，非常耗费时间，需求弄好一次解决是最方便的。

我更希望这个功能是既有意义又完整的。所以我让这个产品经理，把数据需求也整理好了再来勾兑一遍。

4.这个设置界面，这样的交互，商户能否理解，如果遇到不懂运营方法论的商户，如何引导，往大了说，是否真的做到了“赋能”？

进入这个页面，我们第一眼看到的是跟进次数，然后看到了其他考核因素比如消费金额和消费次数，然后同时要进行关系链时长限制。我们不免提出疑问，这是在干啥？仔细回想，是在进行关系链解绑规则配置。这种配置只能定义xx天以上的关系链在xx天内跟进次数xx后是否解绑，而xx以上的关系链和xx天内的行为，其实是重复的。

一方面理解有难度，一方面xx天以上的关系链约束意义不突出。相反，从销售节点来看，xx小时内的关系链更应该被尽快跟进，更应该值得考核，但是当前需求却无法满足。进而我们想到了关系链分层策略，引导商家将关系链按照绑定天数进行分层，每个分层内都可以约束不同的任务。同时也支持商家想省事儿，不分层。

这样，我们就把分层运营的理念结合进这个产品设计中了，当前是按关系链绑定时间，以后可以尝试用各种纬度进行分层。

这时候，也许商家不会运营，看到分层就顺手做了，慢慢导购接到任务也可以逐渐养成不同顾客不同频次跟进的习惯。如果商家会运营，看到这个会觉得很好用，提出更多建议，产品功能会更强大。

这样，就是从产品功能上为商家业务赋能。

总结

中台产品能驱动业务优化，仅仅因为你的角色是中台，一定程度上也是业务的后台，对方要接入，就不得不受你约束，就像运营要找你提需求，你会问他要需求价值一样。

作为中台产品，最大的忌讳就是，永远只思考通用化的解决方案，解决方案通用化只是中台产品能力之一，扎实的产品基本功和方法论，知道未来如何做业务，产品方向是什么，才是中台产品的必杀技。