B端产品链路拆解法，专解复杂问题

从业务整体来看，C端产品可能会有相应的转化路径，那么B端产品的链路相较C端产品而言，有哪些不同？如果想要对B端产品的关键链路进行拆解，你又可以遵循什么样的方法？本篇文章里，作者结合实际案例总结了B端产品链路拆解策略，一起来看看。

———— / BEGIN / ————

关键链路介绍及C、B端区别

电商行业中，面对C端产品，会存在一个购物转化的经典黄金流程，如下图：

大家可以看到，从获取用户开始，到最后让用户买单贡献价值，其中要经过很多的环节。

这些环节，环环相扣，步步依赖，像一个链条一样。

而日常，业务端的一系列资源花销和努力的方向，都是将各个环节的转化率做到更高，最终实现获取更多的商业收益。

其实，除了电商购物等场景之外，其他各类C端产品，也都会有各种各样的转化路径。业务端整体去迭代产品或运营产品，也会按照路径的每个环节逐个聚焦。

那B端产品呢，相对C端产品有没有关键路径？它们的路径与C端产品又有何不同？

根据我自己的发现，B端产品链路性更强，但与C端会有区别。

我大概总结了以下3点的不同：

B端关键链路建设方法

1. 链路拆解构建模型

链路拆解，会用到一种产品需求分析的一种能力，即场景化还原能力。

场景化还原，就是需要按照时间线，100%还原现实中每一个环节，以及每个环节中的所有事件。

每个事件，包含用户**通过**做**这几个因子。

在拆解过程中，可以顺便记录下每个事件中，当前做的状态、用户遇到的痛点、预期希望实现的状态。

2. 正/反两向过程建设

把链路拆解成一个个环节之后，就要开始有针对性进行各个击破。

正向建设的思路，很好理解，就是我们为保证每个环节对应的事件，都能按要求实现保质保量按时交付结果，不出纰漏。

而反向建设呢，其实就是问题驱动，将日常过程中遇到的各类异常情况分类归因，并针对性地强化对应环节中的措施，确保同类问题不再发生或减少发生。

3. 指标监控与衡量

一般情况下，B端链路较长，后续累加逻辑会日益增多，再加上需多方协作，维护性差，出问题概率大。

如果出了问题，我们只是简单case by case，不落到环节/事件底层去彻底解决问题，那问题一定还会再出现。

所以，为了使得每条链路的建设变得更好，我们必须要考虑指标化，逐渐去经营它。

指标，除了设置整体链路结果的指标之外，也需要对关键环节设置指标监控。

如果产品结果是for效率的，那就是时间维度指标；如果是for稳定性的，可以是异常率指标。

以上，3个原则，就是B端关键路径的建设方法。

围绕方法论这块，我不打算花太多篇幅来介绍，下边我着重会用2个案例代入来讲解。

案例解析1. 微信打款异常专项

我们业务上有个回收场景，即个人用户卖手机给转转。用户下回收单，平台收到货之后，经过对用户手机的检测、报价/议价之后，如果用户同意价格则交易达成，转转平台就会把货款打给这个用户。

而本小节，我们讲的这个案例，就是发生在打款给用户的这个环节。

回顾上述这个流程，大家乍一看起来，是不是觉得比较简单？不就是触发一笔打款，把钱发给用户，不就好了么？

但事实上，并没有那么简单。

因为我们是回收场景，卖家是个人用户，他们一般使用微信、支付宝进行收款。再加上，转转有面交履约方式，如上门回收和门店回收，这些都是一手交钱一手交货。对打款及时性要求极高，如果钱款不能交割，会极大影响用户体验和线下工程师履约效率。

在过去历史上，我们出现打款异常（对用户没有收到钱款就算异常）的情况，发生了多次。出现问题的原因呢，也是各有不同。

读到这里，基本上这个案例的背景，我已经交代清楚了。

接下来，我们按照B端关联链路的建设方法，讲解下我是如何拆解这个问题的。

PS：声明一下，支付是一个相对比较专业的领域，想要解决这个问题，就需要对支付系统有较高的理解。本文重点讲解方法逻辑，大家不用特别在意专业知识本身。

我首先会按照第一步，场景化还原，将链路拆解为了多个关联的环节以及主要事件（实际情况中，核心关注关键事件即可，不容易发生问题的点可以暂不纳入模型中，后续可迭代）。

拆解过程中，我会分析各个环节的事件属性，构建正向建设的体系。

分析完之后，大概结果如下图：

我将打款这个链路，拆解为了9个关键环节。

并且针对不同环节，做了一些属性分类，有系统性的、技术性的、商户性的、运营性的、产品性的。

并且针对每个类型，提出了建设的方针，后续就转化为不同优先级的一些todo。

当然，过程中，也一定会有各类突发的问题，这时候就一定要归因问题，最终落到各个环节的建设中。

尤其是最频繁出问题的环节，就需要优先去解决，这就是反向问题驱动的要领。

这个链路，总体指标，是个典型的稳定性指标，我们使用异常率指标即可。简单来讲，就是中断发生的次数以及影响面。环节指标同理。

2. 业财一体化——管报

B端链路，可以是不同颗粒度的。

既可以是像上边那个打款一样偏局部功能的，当然也可以是一个更大的体系化工程。

下边讲一个最近比较有体感的案例，业财一体化之管报输出。

大家都知道，每个公司基本上都会由财务按照周期性对公司管理层输出管理报表。

管报讲究时效性和准确性，并且越早输出，对公司的管理决策就会越有利。

但可能鲜有人知道，一个管报的输出，背后到底要经过多少人的通力协作。

而这个协作，就像一个链路一样，环环相扣，哪个环节出问题，都会影响最终的结果。

那么我们如果要搞业财一体化系统建设，就必然需要拆解这个链路的实现，然后分而治之。

按照场景化还原，大概就能知道财务几个大的节点，以及每个环节中对应的事件和现况，如上图。

接下来，看指标。管报这个整体链路的指标有2个，一个是准确性（这个基本属于硬性指标），一个是及时性。

日常，我们更多是围绕及时性进行努力。

拆解完成之后，你会知道每个环节（T+a、T+b、T+c、T+d）的现有时效如何，有哪些事件是最耗时的，也就更能对症下药，有针对性去突破某些环节。

按照这个循环，持续精进，就能实现一个个更高的目标。

讲完以上2个案例，想必大家都能对本文中B端产品关键链路分析法有了较为深入的理解。

B端大部分的产品，尤其是越为复杂的产品，越适合用这样的拆解方法来做。

这个方法最大的好处，就是能够把功能视图转化为指标视图，然后能持续经营产品。

希望本文对大家有一定的帮助。

本文来自微信公众号：产品杂谈，作者：产品杂谈

想持续学产品，没方向？没人脉？没资源？点击加入“产品经理进化营”圈子，和1000+优秀产品人一起进化成长！