跨境电商售后处理工单流转效率提升交付 3 周
售后 · 工单自动归类与流转系统
工单进来先自动判定类型，人工只处理需要判断的那部分
示例数据：本页数值为演示用示例，真实口径与数值待补充。
自动归类
91%
结案时长
-62%
返工率
4%
背景与痛点
原来卡在哪
- 服务对象
- 某跨境电商卖家
- 行业
- 跨境电商
- 规模
- 多店铺售后团队
- 上线时间
- 2026-07
工单靠人工逐条看、手工分派
分类不一致，同一个问题分给不同人
紧急工单混在普通工单里
该先处理的没有先处理
超时没人提醒
等客户投诉才发现已经压了很久
解决方案
怎么做的
把「读取 → 归类 → 分派 → 超时升级 → 结案留痕」做成一棵树，工单进来就自动走对应分支。
- 归类依据显式化，任何人都能看出这条工单为什么分到这一类
- 超时阈值与升级路径配置化，不同店铺可以不同
- 所有流转动作留痕，方便复盘与优化规则
数据流
工单接入→类型识别→紧急度判定→自动分派→超时升级与结案
技术栈
Python规则引擎接口对接定时调度消息通知
设计思路
为什么这么设计，而不是那么设计
设计目标让工单进来自动找到该去的地方
为什么要做
- 分派靠人看逐条人工判断，慢且标准不一致
- 紧急度分不清重要工单淹没在普通工单里
- 超时无提醒等投诉才知道压了很久
关键取舍
- 识别不确定就转人工宁可多转一条，也不能分错让客户等
- 规则显式化分类结果要能解释，不能是黑盒
- 优先保证紧急件分级处理的收益大于绝对平均
技术决策
- 先标准化字段多平台字段不统一，先归一才能做后续判断
- 超时阈值可配置不同店铺标准不同，不能写死
- 兜底样本回流转人工的工单是优化规则的最好材料
风险与兜底
- 误判导致客户流失敏感类型强制转人工，不自动结案
- 规则僵化业务变化后规则需定期复核
- 自动回复得罪客户涉及赔付的答复必须人工确认
识别不确定时转人工，而不是猜
归类错的成本，比多转一条人工的成本高得多——客户在等的是正确处理，不是快速处理。
系统架构
这套系统是怎么搭起来的
重点是「归类判断」这一层——它决定后面所有环节走哪条路。
L1接入层把各渠道的工单收成一条流
L2判定层决定这条工单该怎么办
L3执行层按判定结果实际做动作
L4复盘层让规则越用越准
点任意一个模块
会说明这个模块负责什么，以及为什么这么设计。
功能画廊
点开截图上的点，看每个功能在做什么
每一张都是系统真实界面结构。琥珀色的点是功能热区，点它说明这个位置的功能是什么、替你省了什么。
01工单看板：待受理、处理中、待补件、已完结
这张图在证明整体积压情况一眼可见
选择一个功能热区
截图上的琥珀色圆点可以点击，查看该位置的功能说明。
改造前后
拖动分割线，看人工流程和 Agent 的差别
左：人工分派下的工单明细。右：自动归类后的看板流转。
拖动下面的滑块可以左右对比。键盘用户可以用方向键调节。
功能清单
这个 Agent 具体能干哪些活
工单拉取
定期从各平台拉取新工单
失败自动重试
类型识别
识别工单类型与业务归属
不确定则转人工
紧急度判定
按金额、时效、客户等级分级
阈值可配置
自动分派
按规则分派给对应处理人
考虑负载与专长
超时升级
临近超时自动升级提醒
各店铺阈值独立
流转留痕
全部动作留档可追溯
可导出复盘
价值量化
上线前和上线后，差在哪
每一项都标注了统计口径。没有把握的数据我们留空标注「待补充」，不填 0 充数。
节省人力
1人/天
统计周期：日均
获客效果
待补充
成本变化
待补充
回本周期
待补充
待补充
你的场景也能这么跑
先做一次免费诊断：我们看你的流程，告诉你哪些环节能自动化、能省多少人。