编辑导读：电商购物中，经常会有对商品不满意的情况，这种交易纠纷无法避免。这时候就需要建立交易纠纷系统，纠纷处理系统（OP）是一个for平台集中处理投诉单的地方，本文作者对纠纷单在平台客服处理阶段的优化处理方式展开分析，希望对你有帮助。
一、交易纠纷处理系统是什么
电商场景下，由于商品品控和商家服务的层次不齐，纠纷投诉是一件不可避免的事情。纠纷处理系统（OP）是一个for平台集中处理投诉单的地方。
本文不讨论纠纷的全流程，仅讨论纠纷单在平台客服处理阶段的优化处理方式。
二、为什么要做阶段划分
纠纷单流转到客服处理阶段，前置情况往往是双方未和解或是超时未处理的状态，这个时候，需要客服根据用户和商家提供的凭证，来判断这个case是谁的责任，以及需要谁做出补偿动作。
因为这一阶段涉及举证、判责、核实凭证等操作，流程较复杂，故对客服操作阶段做划分，旨在通过标准化的方式，保证纠纷单的处理效果，提高纠纷单的处理效率，提升用户&商家的纠纷体验。
2.1 降低客服的学习成本
电商场景下交易纠纷的细分场景纷繁复杂。即使不讨论case的多样性，仅仅在某一纠纷单的维度，客服操作流程也很长，需要客服理解和操作的部分很多，这花费了客服很多时间去熟悉流程。
如果客服需要处理其中的一环，那么准确性和效率都会提高很多。同时，随着处理次数的增加，客服对这一环节也会越来越熟悉，准确性和效率进一步得到提升。
学习曲线
2.2 降低客服的操作成本
由于客服对某一阶段很熟悉，随着纠纷单量的变大，带来的规模效益可以明显降低成本。
规模效应
2.3 降低客服的转换成本
由于客服处理阶段涉及多个环节，单一客服处理造成客服在不同部分之间操作和转化技能，造成不必要的转换成本浪费。
如果客服只处理某一阶段，那么就能省去大脑在不同阶段间切换的成本，从而提高效率与效率。
三、怎么做阶段划分
讲了这么多铺垫，标准化的落地是这个part。
纠纷处理系统的标准化总共分为4个阶段，不同阶段的客服处理人员不同，每个客服专注做一个阶段。客服在这里的所有操作均为点击已配置好的标准化选项，无需主动编辑字段。
3.1 客服接手节点+隐藏状态
纠纷单客服接手操作节点的前置状态是待客服接入，后置状态为待客服处理，即进入纠纷操作的第一阶段，同时，客服接手的操作者与第一阶段的操作者为同一人。
之所以设置客服接手这个环节，是因为在纠纷处理系统的前期，还没有分流的策略，这一part将会在本文第4部分讲到。
关于隐藏状态，这个状态是for待用户/商家补充凭证等不需要客服操作的状态下，纠纷单不出现在纠纷处理系统，节省客服浏览时间。同时每一个阶段都是对上一阶段的QC（质量检查），具体这些状态将会在下文提到。
3.2 真·第一阶段：选择纠纷现状+首次判断是否需要补充凭证
- 判断商品品类+纠纷现状，包括用户与商家是否和解/超时未处理，以及双方已提交的凭证描述。
- 判断是否需要补充凭证，如需要，则向用户/商家/双方发起补充凭证；如不需要，则直接点击进入判责阶段。
3.3 真·第二阶段：判断是否需要二次补充凭证
第一阶段选择完纠纷现状+发起举证后，纠纷单进入第二阶段，即被第二个客服捞起（本阶段及下面的阶段无客服接手节点）。
由于这个环节存在循环举证的可能性，故整个纠纷处理的大多数人可能会集中在这个环节。
判断是否需要二次补充凭证，如需要，则向用户/商家/双方发起补充凭证；如不需要，则直接点击进入判责阶段。
3.4 真·第三阶段：判责
来到这一阶段，纠纷单的来源可能是第一、第二阶段，客服在这里，依据前置客服推动带来的用户/商家凭证，进行判责。如无法判责，则返回第二阶段。
客服根据前置阶段双方的凭证，选择判定商责、客责、双方有责、双方无责。
责任归属判定完成后，纠纷进入下一阶段：核实赔付。
3.5 真·第四阶段：核实赔付
面对来自第第三阶段的纠纷单，他们的责任可能是广义商责（包括商责、双方有责）和广义客责（客责、双方无责）。
- 对于广义商责，需要商家退款或者用户退货后商家退款。这里的资金流可能是线上系统自动划扣（商家账上余额充足），亦可能为线下打款后上传凭证（商家账上余额不足）。不论是否通过上线还是线下退款，客服在这步都需要核实商家退款是否属实。
- 对于广义客责，客服可判断是否需要使用客诉费进行平台赔付，用于安抚用户的情绪。
- 在核实完退款凭证/客诉费赔付后，客服将纠纷单流转至隐藏状态，使得完结的纠纷单离开纠纷系统。
四、未来优化方向
4.1 对于纠纷处理本身：优化纠纷整体流程
分析纠纷单状态，优化操作框选项。
这个系统是否work的一个重要因素为选项框内的业务选项是否适配纠纷场景。这里的选项设置，直接影响客服操作的效果和效率。大量case的积累有助于平台对选项内容做调整，兼容多场景纠纷。
分析纠纷类目+客服操作，优化用户&商家侧纠纷流程。
通过分析不同类目纠纷单的举证次数及举证内容，可以在用户&商家前端优化提示提交最能帮助处理case的材料，使得纠纷单无需进入第二阶段，甚至无需客服操作，直接和解。
纠纷单自动分流，实现客服处理的千人千面。
纠纷处理的千人千面，即根据同一客服在不同阶段、不同类目、不同纠纷发起场景下的用户满意度，对其有针对性地推送相关标签的case，让专业的人干专业的事。
4.2 对于平台治理业务：拉通邻近业务
分析纠纷类型，支持商品品控建设。
任何平台治理的业务，我相信其核心都是商品品控。纠纷的高效处理，能够倒逼商家提升自己的品控，从而提升整个平台的品控，使得平台层面的整体的纠纷原因从「商品质量问题」等对用户损伤较大的类型转移至「商家未履行赠品承诺」等损伤较小的类型。
拉通平台治理措施，支持其他业务。
大家都知道，纠纷是平台治理中一项极其基础的兜底业务，故所有业务的问题都有可能会流转到纠纷环节。基于此，纠纷更是能够看到其他业务在平台、用户、商家三方的表现，同时，纠纷结果也能为其他业务基础的数据支持。
以上，产品新人的简单思考，不当之处，还望各位大佬指正。
本文由 @咔喔Archer 原创发布于人人都是产品经理，未经许可，禁止转载。
题图来自 Unsplash，基于CC0协议
