热搜: 中文分类目录

编辑导读:电商购物中,经常会有对商品不满意的情况,这种交易纠纷无法避免。这时候就需要建立交易纠纷系统,纠纷处理系统(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 对于平台治理业务:拉通邻近业务

分析纠纷类型,支持商品品控建设。

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

拉通平台治理措施,支持其他业务。

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

以上,产品新人的简单思考,不当之处,还望各位大佬指正。