1. 交易纠纷处理系统是什么

电商场景下，由于商品品控和商家服务的层次不齐，纠纷投诉是一件不可避免的事情。纠纷处理系统（OP）是一个for平台集中处理投诉单的地方。

本文不讨论纠纷的全流程，仅讨论纠纷单在平台客服处理阶段的优化处理方式。

2. 为什么要做阶段划分

纠纷单流转到客服处理阶段，前置情况往往是双方未和解或是超时未处理的状态，这个时候，需要客服根据用户和商家提供的凭证，来判断这个case是谁的责任，以及需要谁做出补偿动作。

因为这一阶段涉及举证、判责、核实凭证等操作，流程较复杂，故对客服操作阶段做划分，旨在通过标准化的方式，保证纠纷单的处理效果，提高纠纷单的处理效率，提升用户&商家的纠纷体验。

2.1 降低客服的学习成本

电商场景下交易纠纷的细分场景纷繁复杂。即使不讨论case的多样性，仅仅在某一纠纷单的维度，客服操作流程也很长，需要客服理解和操作的部分很多，这花费了客服很多时间去熟悉流程。

如果客服需要处理其中的一环，那么准确性和效率都会提高很多。同时，随着处理次数的增加，客服对这一环节也会越来越熟悉，准确性和效率进一步得到提升。

学习曲线

2.2 降低客服的操作成本

由于客服对某一阶段很熟悉，随着纠纷单量的变大，带来的规模效益可以明显降低成本。

规模效应

2.3 降低客服的转换成本

由于客服处理阶段涉及多个环节，单一客服处理造成客服在不同部分之间操作和转化技能，造成不必要的转换成本浪费。

如果客服只处理某一阶段，那么就能省去大脑在不同阶段间切换的成本，从而提高效率与效率。

3. 怎么做阶段划分

讲了这么多铺垫，标准化的落地是这个part。

纠纷处理系统的标准化总共分为4个阶段，不同阶段的客服处理人员不同，每个客服专注做一个阶段。客服在这里的所有操作均为点击已配置好的标准化选项，无需主动编辑字段。

3.1 客服接手节点+隐藏状态

纠纷单客服接手操作节点的前置状态是待客服接入，后置状态为待客服处理，即进入纠纷操作的第一阶段，同时，客服接手的操作者与第一阶段的操作者为同一人。

之所以设置客服接手这个环节，是因为在纠纷处理系统的前期，还没有分流的策略，这一part将会在本文第4部分讲到。

关于隐藏状态，这个状态是for待用户/商家补充凭证等不需要客服操作的状态下，纠纷单不出现在纠纷处理系统，节省客服浏览时间。同时每一个阶段都是对上一阶段的QC（质量检查），具体这些状态将会在下文提到。

3.2 真·第一阶段：选择纠纷现状+首次判断是否需要补充凭证

• · 判断商品品类+纠纷现状，包括用户与商家是否和解/超时未处理，以及双方已提交的凭证描述。

• · 判断是否需要补充凭证，如需要，则向用户/商家/双方发起补充凭证；如不需要，则直接点击进入判责阶段。

3.3 真·第二阶段：判断是否需要二次补充凭证

第一阶段选择完纠纷现状+发起举证后，纠纷单进入第二阶段，即被第二个客服捞起（本阶段及下面的阶段无客服接手节点）。

由于这个环节存在循环举证的可能性，故整个纠纷处理的大多数人可能会集中在这个环节。

• · 判断是否需要二次补充凭证，如需要，则向用户/商家/双方发起补充凭证；如不需要，则直接点击进入判责阶段。

3.4 真·第三阶段：判责

来到这一阶段，纠纷单的来源可能是第一、第二阶段，客服在这里，依据前置客服推动带来的用户/商家凭证，进行判责。如无法判责，则返回第二阶段。

• · 客服根据前置阶段双方的凭证，选择判定商责、客责、双方有责、双方无责。

责任归属判定完成后，纠纷进入下一阶段：核实赔付。

3.5 真·第四阶段：核实赔付

面对来自第第三阶段的纠纷单，他们的责任可能是广义商责（包括商责、双方有责）和广义客责（客责、双方无责）。

• · 对于广义商责，需要商家退款或者用户退货后商家退款。这里的资金流可能是线上系统自动划扣（商家账上余额充足），亦可能为线下打款后上传凭证（商家账上余额不足）。不论是否通过上线还是线下退款，客服在这步都需要核实商家退款是否属实。

• · 对于广义客责，客服可判断是否需要使用客诉费进行平台赔付，用于安抚用户的情绪。

• · 在核实完退款凭证/客诉费赔付后，客服将纠纷单流转至隐藏状态，使得完结的纠纷单离开纠纷系统。

4. 未来优化方向

4.1 对于纠纷处理本身：优化纠纷整体流程

• · 分析纠纷单状态，优化操作框选项

这个系统是否work的一个重要因素为选项框内的业务选项是否适配纠纷场景。这里的选项设置，直接影响客服操作的效果和效率。大量case的积累有助于平台对选项内容做调整，兼容多场景纠纷。

• · 分析纠纷类目+客服操作，优化用户&商家侧纠纷流程

通过分析不同类目纠纷单的举证次数及举证内容，可以在用户&商家前端优化提示提交最能帮助处理case的材料，使得纠纷单无需进入第二阶段，甚至无需客服操作，直接和解。

• · 纠纷单自动分流，实现客服处理的千人千面

纠纷处理的千人千面，即根据同一客服在不同阶段、不同类目、不同纠纷发起场景下的用户满意度，对其有针对性地推送相关标签的case，让专业的人干专业的事。

4.2 对于平台治理业务：拉通邻近业务

• · 分析纠纷类型，支持商品品控建设

任何平台治理的业务，我相信其核心都是商品品控。纠纷的高效处理，能够倒逼商家提升自己的品控，从而提升整个平台的品控，使得平台层面的整体的纠纷原因从「商品质量问题」等对用户损伤较大的类型转移至「商家未履行赠品承诺」等损伤较小的类型。

• · 拉通平台治理措施，支持其他业务

大家都知道，纠纷是平台治理中一项极其基础的兜底业务，故所有业务的问题都有可能会流转到纠纷环节。基于此，纠纷更是能够看到其他业务在平台、用户、商家三方的表现，同时，纠纷结果也能为其他业务基础的数据支持。