编辑导语：什么是异常流程？它会导致哪些后果？产生的原因是什么？作为产品经理，我们该如何处理异常流程呢？本文将围绕这些问题展开，从异常流程发生以及解决方式进行分析，希望对你有所帮助。

对产品经理来说，正常流程，我们大家都很熟悉，就是我们产品设计的所有策略、流程、页面、文案的元素组合体。

但是说到异常流程，我想可能很多人了解程度就可能没有那么高了。

今天，我们就围绕互联网产品设计中的异常流程，展开聊聊。

一、什么是异常流程

先声明下我对异常的定义：

异常就是用户在使用产品的过程中，遇到阻断流程、选择障碍、目标不明确、操作麻烦等所有不符合用户预期的情况。

接下里我用一些工作中发生的真实case，来带大家感受下什么是异常。

案例1（信息流）：“11.11购买券活动用户的差评”

在前段时间公司举行的11.11活动中，业务上有一个购买券的活动，让用户可以以支付较少的金额购得一张面额较大的优惠券。

但是，在活动开始没多久，就发生了一件不那么美好的事情。购买券的用户闹着要退款，而平台的政策说明是不支持退款的，于是用户在评论里面就炸锅了。

紧接着，平台第一时间修改政策，同意对购买券但未使用的用户进行退款，用户的愤怒才得以平复。

然后呢，在活动结束后的24小时，平台针对对应的用户进行批量退款，但是中途由于操作失误，其中一小部分用户直到之后的第三天才收到了退款。

事情的经过大概就是这样的。是不是感觉不复杂，并且好像整体上也没有啥太大的“问题”。

接下来，我以用户的视角和产品逻辑（含内部人工操作），按照时间线梳理了全程，让大家再感受下异常：

经过这个事情，我们跟业务复盘的结果，后续需要对“购买券”当做一个整体的产品，在用户感知层面多打磨，一些重要的规则需要更加强调。在后端，把支持退款作为一个开关，满足业务需求，当退款时能无成本操作，并且也避免人为原因出现错误。

案例2（资金流）：“用户微信问题导致收不到钱”

公司做C2C业务起家，是典型的担保交易形态。那么对卖家一方，就会涉及到结算打款问题。

而平台最早时候，依托于微信登陆体系使用的是打款到卖家微信零钱的方式，卖家相对一般电商商户的入驻，会简单很多。

但微信支付（支付宝也存在）有个问题，就是可能会根据用户的情况（例如账号异常、风控、限额等）拦截掉打款。而无语的是，这个拦截的原因，有非常多，我们在接口层面并不能提前知道所有的状态码值（第三方的接口还动不动就更新）。

所以，我们只能定向解析出我们已知的拦截原因，停止重试打款，转到用户自助流程，引导用户更换打款方式/账号来提现。

但是，对我们无法理解的新的状态码值，固定逻辑是会继续重试的。而这时候，用户感知就会有个时间差，就是钱款还在处理中。只有我们定向将新的状态码值加到白名单才会停止重试再转由用户自助取回。

针对以上的规则逻辑。如果是在线的C2C还好，对于打款不及时的感知会被交易线上的引导文案所缓冲，感受并不会有那么强烈。

但是，我们有一个业务是上门C2B回收，这个场景下跟线上不一样，在线下，几乎就是一手交钱一手交货。

如果打款遇到微信拦截问题，并且刚好还是我们没有识别过的拦截码值，那用户就会很崩溃，觉得我们是骗子，很可能会终止线下的回收交易。

而现场回收的工作人员也会很焦急，觉得我们产研一个简单的打款问题都搞不定，不仅丢单还丢人。这时候，就会打电话给业务运营人员或是产研，到最后其实就只能研发排查具体情况然后停止重试才能转自助取回。

可能有人会问，为啥不对重试无法成功的直接都转用户自助取回，其实这是一个取舍的问题，因为失败重试的情况发生的概率更大，影响面也更大，如果都擅自转用户取回，那整体这些用户操作取回的总成本也会更高。

目前这类case，已经时间的累积，已经解决了绝大部分，但是仍然会有零星的情况会发生。

后续，我们能做的，就是考虑能否将解决这些零星问题的过程工具化，并且培训给一线人员可以更加及时的解决用户问题。

案例3（实物流）：“用户拒签导致售后慢”

再说一个售后的案例。

电商流程中一般都有售后，支持退换修的服务。那么，如果用户遇到售后，就会存在一个逆向物流的环节，即用户需要把货物返回商家售后站点，然后商家进行判责然后给用户进行售后服务履约。

正常情况下，没什么问题，但是如果是用户选择拒签退货时，就会有个“异常”的发生。

背后发生这个“异常”的原因是：物流拒签会原路打回发货地，而发货地和售后站点如果分属于2个物理站点和2个团队，那就会多很多中间的转移环节。

具体我们看下图：

大家可以看到，“拒签到货”会到发货仓，而“正常售后到货”会到售后站点。所以，拒签到货进入发货仓时候，质检环节无法识别为自己需要作业的件儿，会当做异常进行处理。

后续，只能等周期性的售后部门前来寻找异常件，那么这中间就会存在信息时间差，以及物理位置转移的时间差。

所以，给购买用户的感受，就会觉得他的售后处理起来特别慢，觉得平台是不是没有人在处理他的售后，对平台失去信任，也可能会发展为舆情投诉。

以上这种拒签的问题无法避免，那么我们能做些什么呢？我们需要针对异常件进行定向设计，包括产品层面和线下团队进行流程重塑，确定执行规范和时效标准。

二、异常流程有哪些后果

以上3个案例讲完了，按照同理心，我尝试推演了下用户侧和我们内部工作人员的一些感受。

显而易见，异常流程会发生“溢出”效应，并对所有受影响的用户，造成心理上、精力上的影响和损耗。

以下，我们按照溢出的类型，把对象分成2类：外部终端用户（C/B用户）、内部系统用户（客服、售后、运营、线下作业人员等），来分别看下影响链。

先总结下：

拿上面案例1（11.11购买券活动）为说，我们是可以看到外部终端用户一步步的心理变化。

而实际上，真正评论、投诉的人占比肯定还是少的，背后那些没有发声的用户，其实内心活动应该也是如上图差不多。根据最终退款的人数，可能好几千的用户数，他们每一个都是有自己主见的个体，也都有信任体系和自己的口碑传播通道。

再来说说，对内部系统用户的影响吧。

首先，明面上，业务童鞋和客服童鞋投入到这个事情中处理的时间和精力是最长线的，整体时间有至少一周左右。

其次，处理一些看不到的东西，其实花的成本一点也不低，只是更多时候大家看不到而已。

我们事后统计了一下，只是产研在这个事情中投入的精力至少有40个工时以上。

另外，这个过程也间接产生出了一个事故，造成了数万经济损失，对参与童鞋的情绪影响也是很负面的。

总之，异常产生的后果，虽然更多时候，不可直接量化，不容易被看得到，但是产生的影响确是不小的。

三、异常流程产生的原因

异常发生的背景多有以下特点：多角色共同协作、流程长、逻辑复杂。例如，上边举的3个案例，其实分别就是电商系统的信息流异常、资金流异常、实物流异常，这3个流向都符合以上3个特点。

异常产生的原因，从表面上来看，是系统的逻辑分支多与流程设计覆盖度不全之间的矛盾。

但从根本上来看，我认为主要集中在以下几个原因：

• 没有以用户视角来设计产品；
• 没有基于全局视角做设计；
• 唯一责任人制缺失；

其中，1和2看起来是产品设计的问题，但是真正细究起来，发现第3点更加重要，即唯一责任人制。

因为，每个人在日常工作中都会有自己“重要”的事情，这个可能跟公司的kpi/okr有关，也就是绩效导向。而这些所谓的“异常”，平时可能并不会像业务目标一样被更多人关注到，自然也不会有人对这个角度提出更高的要求。

四、怎么处理异常流程

1. 产品设计层面

正向的逻辑，一般是被大家熟知的，也是最容易被设计的；而看不见的逻辑，也更应该被设计。

接下来，分别从事前、事后、还有重构这3个方面聊下异常如何被设计。

（1）事前预防：降低异常出现概率

① 策略完整性：产品设计对流程尽可能穷举；

这个其实没有更好的办法，跟产品经理的功力有关系，经验丰富优秀的产品一定会比其他人做得更完善。

在关键产品上，公司的项目流程尽可能在需求评审环节多进行一些check和打磨，降低后续出现异常的概率。

② 降低影响面：小流量测试；

灰度小流量测试，就不说了，其实就是提前暴露风险的一种手段，既保证了影响面较小，又能在生产环境下复现异常，然后打补丁。

③ 降低影响时间：建立监控预警，提前发现风险；

产品上线后，必要的监控预警机制不能少，有时候你不能盯到所有环节的情况，但是一些关键环节和结果数据，是可以帮你发现一些异常的。这样，问题就能第一时间被暴露出来，产研提前应对，降低线上异常对用户的影响时长。

（2）事后补漏：快速解决异常并定向设计

相比事前预防，其实我更建议产品做的是事后补漏。

为什么？因为事前预防说起来容易，其实做以上3个事情，都是需要花费额外的成本的，很多时候，大家不愿意去做，或做得不那么到位。

但事后不一样，异常出现了，问题直接就被摆在明面上了，这时候你就会有非常明确的“需求”去解决，以及有“动力（压力）”去解决。

补漏的过程，其实就是你积累经验的过程，这次的疏忽，会变为下次你的事前预防产品设计。

说到这里，我提一个现象，那就是很多产品，在对待用户反馈问题时，总是觉得是打断，是负担，是用户太笨，从而产生抵触情绪。

但我说一个我自己的观点：“补漏是一个很好提升产品设计能力的方法，你应该主动去挖掘一些要补漏的信息通道，然后把补漏当做你成长最好的食粮”。

用户online反馈、客服进线咨询问题、售后遇到的用户问题，都是产品很好的食粮，有时候你越是关注末端的部门，那你就距离用户越近。

在过去的一段时间内，我自己负责的业务中，也做了很多自主排查/解决问题的工具，还有一些像异常件、打款异常等项目也被列为了我们的重点项目去推动。

（3）做重构：敢于做破而再立的决策

有些系统设计由于历史架构的原因，再加上逐步的打补丁，已经到了积重难返的地步。那如果此刻在老的基础上迭代，用户体验和实现成本都已经非常糟糕，那么就很有必要搞一次大的重构。

长痛不如短痛，破而再立才能为用户负责。

2. 协作机制/责任人机制保障落地

异常更多时候是由用户遇到并提交客服部门的，或者内部系统异常是由一线作业人员最先发现的。

但异常却是由很多环节共同造就的，那这时候用户是崩溃愤怒的，客服或一线也是焦急且无助的，那如何把用户和客服/一线的声音传达到需要整改的人呢？

这时候，就一定需要机制的保障。这里说2个机制，搭配起来用应该会很有效。

（1）信息传输机制：按灯机制

按灯机制，应用比较出名的应该是亚马逊。所谓按灯，就是指一线员工在发现一个异常出现多次的时候，有权利停掉业务运营（如商品下架、商家处理等），进而倒推相关方第一时间尽快解决问题。

这个按灯机制，非常巧妙了改变了一线员工在遇到用户问题焦急但无奈的现况，让异常信息可以第一时间被相关方所感知到去解决，毕竟停掉业务运营上游业务kpi都会受到影响的。

遇到异常—>用户声音—>一线员工信息传输—>上游解决异常，整个过程非常高效，不仅当前用户异常问题得到解决，并且一劳永逸解决了类型问题，防止损害到更多用户的利益。

（2）责任人机制：确定主责任人并跟绩效挂钩

有时候，异常解决所需要协作的角色非常多，之间相互依赖，可能最后，有些问题就会因为各种“不可抗拒”的原因给拖延了。

追求责任的时候，就会变为了法不责众，相互责任边界也扯不清楚。

所以，确定主责任人或唯一责任人，就会变得很有必要。给予权责，并跟绩效挂钩，那么这个责任人就会有“动力”持续牵引这个事情的解决。

以上内容，就是我对“异常”这个事情的观点。

大家都能发现，“异常”相对“正常”大概率都是不好解决的，有时候甚至会伴随着非系统化流程、三方非强约束合作这些风险因素存在，异常根本上无法杜绝。

但是，面向用户，我们没有任何借口，唯有从用户出发，做事情对用户多一些同理心。只有这样，我们的产品能力才会提升、用户体验才会提升、企业口碑才会提升。