Ulike 客服售后自动化拆解：RPA 实际在后台做了什么？
基于 Ulike 公开案例里的静默单推送、已发货仅退款、留言赠品发货信息三个场景，拆解客服售后 RPA 在订单、聊天、ERP、物流和消息后台里的真实执行过程。
很多人看到“客服售后自动化”，第一反应是 AI 自动聊天、自动理解用户诉求，甚至自动替客服做售后判断。
但 Ulike 这个公开案例更值得看的地方，其实不是“机器人有多聪明”，而是另外一件更现实的事：
RPA 代替客服和售后人员，在订单后台、客服后台、ERP、物流页面和群消息之间反复查询、复制、判断、留言、备注和回写。
公开案例明确提到了三个应用：静默单推送、已发货仅退款、留言赠品发货信息。本文不是 Ulike 官方逐点击脚本，而是基于公开描述和电商客服常见流程，对 RPA 实际执行动作做的流程还原。参考来源：影刀社区公开案例。
它不是一个聊天机器人，而是一张跨后台执行工作台
一条售后任务进来以后，RPA 做的事情很像一个人在电脑前操作：找到订单，补齐上下文，按规则判断，再去另一个后台执行动作。
静默单推送
找出未付款、未被跟进的订单，送到售前群。
已发货仅退款
跨 ERP 和物流查状态，再决定退款、等待或转人工。
赠品发货留言
把 ERP 中的赠品物流搬到买家留言。
这就是理解这三个案例最重要的入口：不要先想“AI 客服”，先想“一个任务如何在多个后台之间被处理完”。
一、静默单推送：像雷达一样，把值得跟进的订单筛出来
静默单不是所有未付款订单。
真正有价值的是那些“已经下单，但没有明显人工跟进”的订单。人工原来要不断刷新订单后台，再逐个去客服后台查聊天记录，最后把值得跟进的订单复制到群里。
RPA 把这件事变成了一套筛选雷达。
一笔未付款订单，必须穿过 4 道筛选
不是“看见未付款就发群”，而是不断排除已经处理过、不值得跟进或不应该重复提醒的订单。
- 金额
- ¥1,299
- 未付款
- 28 分钟
- 聊天
- 无人工跟进
先找到最近未付款订单
读取订单号、买家、商品、金额和下单时间。
检查是否已经提醒过
订单号命中历史记录就直接跳过，避免重复刷群。
扫描最近聊天和人工接待状态
无聊天、只有系统消息，或咨询优惠后未付款，才继续评估。
拼接订单信息并发送提醒
发送成功后回写时间和状态；失败则记录原因。
这里最关键的后台动作，不是“自动催付”，而是自动把订单送到正确的人面前。
请售前客服及时跟进。
人工原来反复做的是：刷新未付款订单、复制订单信息、切客服后台查聊天、判断有没有人跟进、发群、再记一遍已经推送。
RPA 的价值，就是把这串机械动作拿掉，让售前客服只看最终的待跟进队列。
二、已发货仅退款：真正复杂的是先查清“货现在在哪”
这是三个案例里最值得拆的流程。
商品已经发出，买家却申请“仅退款”。这时最危险的做法，就是只看平台售后单，然后直接点退款。
RPA 必须先跨系统回答一个问题：货到底在哪？
平台售后单只是入口，物流状态才决定下一步
RPA 先从售后单拿订单号，再去 ERP 找物流单号，最后用物流轨迹把订单分流到不同处理动作。
- 类型
- 已发货 · 仅退款
- 退款金额
- ¥1,299
- ERP 状态
- 已出库
- 物流单号
- SF********86
平台筛售后单
复制订单号查 ERP
读取快递和物流单号
查询最新物流轨迹
回平台执行动作并记录
先确认能否拦截
部分低风险场景可继续处理，但仍按店铺 SOP 执行。
不直接退款
货还在途中，回写备注或进入人工清单。
转人工核实
可能需要改走退货退款，不能自动同意仅退款。
等待回仓
保留跟进记录，货未回仓前不自动退款。
进入退款处理
回仓状态明确后，风险降低，可按规则提交处理。
停止自动动作
ERP 无订单、物流为空或平台与 ERP 状态冲突时，带原因转人工。
这个视觉路径比一张大流程图更接近 RPA 真正的执行过程：先收集上下文，再让物流状态决定动作。
RPA 在后台实际做了哪些动作
读取售后单号、订单号、金额、申请原因和当前状态。
输出：目标售后单读取发货状态、仓库、出库时间、快递公司和物流单号。
输出：物流字段把轨迹归类为未揽收、运输中、签收、拒收退回、回仓或异常。
输出：处理分支只有状态明确且符合 SOP 的订单才继续自动动作。
输出：平台结果页面提交失败、物流缺失或状态冲突，都要留下可追踪记录。
输出：可审计结果例如明确回仓，且符合店铺退款 SOP。
例如拒收退回中，需要等下一次物流更新。
例如已签收、金额异常、ERP 与平台状态冲突。
这类流程最适合 RPA 的地方，不是它能“自动退款”，而是它能先替售后人员完成最耗时的核实动作。
售后人员最终看到的应该不是一堆待处理单，而是：物流状态是什么、RPA 做了什么、为什么没有自动处理。
三、赠品发货留言：把 ERP 里的信息，沿着传送带送到买家面前
赠品流程比退款流程简单很多，但非常适合 RPA。
因为这里几乎没有复杂决策，核心就是一件事：ERP 已经有赠品物流，买家还不知道。
人工客服原来要查赠品单、复制赠品名称、复制快递和单号，再切到平台后台搜索原订单、打开留言窗口、粘贴话术、发送，最后标记已经通知。
RPA 可以把它做成一条很直观的信息传送带。
字段从 ERP 出发，经过校验，再进入买家留言
- 物流单号非空
- 赠品名称非空
- 还没有通知过
打开买家留言入口，填入模板，再判断是否出现发送成功提示。
物流单号为空、赠品名称为空、订单查不到、留言按钮不可用，都不强行继续，而是记录原因后转人工。
亲，您的赠品已为您发出，请注意查收～
- 赠品
- 活动礼包
- 快递
- 顺丰
- 单号
- SF********86
赠品与主商品可能分开发出，如您先收到主商品，请不用担心。
这个流程看起来最简单，却很能说明 RPA 的价值：系统里已经有答案，但需要有人把答案搬到另一个系统。
只要字段完整、目标订单明确、发送结果可验证，这种跨后台信息搬运就是非常典型的 RPA 场景。
四、三个案例放在一起，真正的共同点是什么？
表面上，它们一个在做催付前置，一个在处理退款风险，一个在发赠品物流。
底层却是同一套工作方式。
不是替人“思考所有问题”，而是把一个任务推进到明确结果
未付款订单、售后单、赠品发货单。
聊天记录、ERP 订单、物流轨迹、赠品字段。
是否静默、是否可退款、是否可以留言。
发群、备注、退款处理、买家留言。
已推送、已处理、已通知、失败原因。
这里有一个非常重要的边界：
RPA 不需要把所有异常都解决。它只需要把标准单处理完，把非标准单整理清楚。
真正好的客服售后自动化，不是“完全没人管”，而是让人工只处理那些确实需要判断的订单。
五、对我自己的启发：先找重复动作，不要先做“全自动客服”
这个案例最有价值的地方，是它选择的切入点很现实。
它没有一上来做一个庞大的智能客服系统，而是先从客服部门最重复、最明确、最容易验证的动作开始：
一个客服流程值不值得先做成 RPA，看这 6 个信号
订单、聊天、ERP、物流之间频繁切换。
强信号订单号、物流单号、商品信息和固定话术反复搬运。
强信号能明确区分继续、跳过、等待和转人工。
必要条件能确认消息是否发出、备注是否成功、状态是否回写。
必要条件群提醒、售后备注和买家留言可以稳定生成。
适合自动失败时能说明原因，而不是静默卡住或继续误操作。
关键边界RPA 最适合先吃掉那些重复、明确、可验证、可回退的后台动作
客服售后自动化不必从“替代客服”开始。先把人每天重复查、重复复制、重复提醒、重复记录的动作拿掉；标准单自动推进，风险单带着上下文和原因交给人工，这样才更容易稳定落地。