退换货分流：规则表与人工介入点

退换货分流，指的是按订单状态、商品类别与客户诉求，把售后请求分派到自动处理、人工处理，或需要线下核实这三条路径上。它的目标不是把人工减到零，而是让简单请求更快、复杂请求更早交到对的人手上。很多项目一开始就冲着全自动去，结果在少数复杂场景上反复翻车，最后连简单场景的优势也一并失去了

分流的三类判据

• 订单状态：是否已发货、是否已签收、是否已开票，决定了可用的处理方式。
• 商品类别：是否属于特殊品类（定制品、贴身用品、生鲜等），这类通常有额外限制。
• 客户诉求：是咨询规则、申请操作，还是对结果不满 —— 前两类适合自动处理，第三类更适合人工。

判据要尽量取自系统里已有的字段，而不是让客户先解释一遍。让客户自己选分类看似省事，实际会把判断成本转给最不熟悉规则的一方，分类自然不准。

规则表怎么落地

规则表的作用是让每一个请求都能被解释清楚：为什么走这条路，而不是另一条。写成一张可以被非技术同事读懂的对照表，比写成代码里的条件分支更容易维护。

• 一条规则只处理一种情形：多个条件混在一条里，出现例外时没人敢改。
• 每条规则写清依据：引用的是平台规则、商家承诺还是行业惯例。
• 优先顺序明确：规则之间存在重叠时，先判断哪一条，要写在表上。
• 预留人工改判：任何一条规则都应当允许人工改判，并记录改判原因。
• 定期复审：平台规则变化时，规则表需要有人负责同步更新。

哪些请求必须转人工

• 情绪激烈或已经投诉：此时客户需要的是被认真对待，而不是更快的话术。
• 涉及金额争议：减免、赔付、补偿这类决定不应由自动流程给出结论。
• 责任难以判断：收到商品与描述不符这类情况，需要核实后才能定责。
• 超出规则范围的例外请求：规则表没覆盖的情形，应升级而不是让系统猜。
• 反复申请或历史异常：同一请求多次提交，往往意味着前面的处理没有解决问题。

自动化能覆盖到哪一步

把自动化定位在「把事情推进到需要人做决定的那一步之前」，通常最安全也最有效。

• 可以自动做：告知规则、核对条件、收集必要信息、生成待处理的申请。
• 不建议自动做：给出赔付金额、判定责任归属、承诺具体处理结果。
• 边界要写在明处：客服与客户都能看到哪些环节是系统判定、哪些是人判定的。

与订单系统、客服知识的关系

分流依赖订单状态，因此订单数据必须以业务系统为准，不做二次存储。分流的判据与话术又必须与客服知识库同源，否则会出现「系统判可以退，客服说不能退」这类自相矛盾。这两条关系不打通，分流做得越自动，矛盾暴露得越快。

分流的判断顺序

先判订单状态，再判商品类别，最后看客户诉求。这个顺序不能颠倒：跳过订单状态直接判类别，会出现「该商品可以退，但这一单已经超期」这类自相矛盾的结论；先看情绪再判规则，则会把所有表达不满的客户都推向人工，自动化等于没有生效。

验收口径

• 每一个请求都能说明它为什么走了这条路。
• 规则表能被非技术同事读懂，并有人负责更新。
• 人工改判有记录，且改判集中的位置能被指出。
• 订单状态与业务系统一致，不存在两套口径。