漏发赠品补寄重复拦截：别再重复补发

这个案例来自电商场景。

电商售后里有一种很典型、也很少第一时间被看见的损失：
同一单赠品漏发后，团队为了把事情处理好，结果在不同入口上补了两次。

最常见的现场通常是这样的：

顾客先找客服说赠品没收到
客服登记了一次补寄
顾客又去评论区、私信或平台工单再反馈一次
运营或售后担心差评，额外又补了一次
仓库最后按两个来源各发一票

每个人当时都觉得自己是在积极解决问题。
真正的损失，是重复补寄往往不是个别，而是高峰期会成批发生。

这个问题为什么在活动期特别容易爆

这家企业主营美妆个护和小家居，大促和直播专场赠品规则多。
漏发赠品的场景并不少见：

主商品正常发了，赠品遗漏
套装里赠品缺件
直播专场的限定小样漏带
满额送在不同仓拆单后掉了一票

一旦顾客来反馈，处理入口往往不止一个：

客服聊天
平台售后工单
评论区回评
店铺运营人工安抚

如果这些入口之间没有共享“这件事已经补到哪一步”，重复补寄几乎是迟早的事。

旧流程里最危险的不是漏寄本身，而是补寄动作太分散

1. 同一事项在多个入口重复创建

前台不同角色看到的都是“顾客这事还没解决”，
但没有人能一眼确认是不是已经有人在处理。

2. 赠品补寄和优惠补偿常常混在一起

有的顾客收到的是补寄赠品；
有的顾客同时又拿到了一张补偿券；
如果没有清楚区分，就更容易出现：

赠品补过了又发券
发券了又补寄
部分补齐却被当成完全未处理

3. 仓库只看到发货指令，看不到事项是否重复

仓库的目标是尽快执行，不是判断这条申请和上一条是不是同一件事。
如果前端没把重复问题拦住，仓库很难在最后一环补救。

改造前的旧流程

flowchart TB
    A[顾客反馈赠品漏发] --> B[客服登记补寄]
    B --> C[顾客又在其他入口继续反馈]
    C --> D[运营或售后再次登记处理]
    D --> E[仓库收到多条补寄指令]
    E --> F[同一事项被重复补寄或重复补偿]

派宝怎么把“想做好事”变成“别给重了”

派宝在这里不负责替团队决定要不要补寄，而是先把这次请求和历史处理记录对上，判断是不是同一事项的重复处理。

1. 先识别当前顾客反馈对应的是哪一件事

系统会把：

订单号
商品和赠品清单
顾客反馈内容
历史补寄记录
历史补偿记录

一起拉齐，避免前线只凭一句“没收到赠品”就新开一条链。

2. 用重复享受校验判断是否已经给过

派宝会判断：

这次是否和之前同一订单、同一赠品有关
之前是否已发起补寄
已给的是全部补齐还是部分补齐
当前是需要补差额，还是明确重复

结果会给出：

可继续补寄
只补剩余部分
疑似重复，需人工确认
明确重复，应直接拦截

3. 对复杂情况再走配套和留痕

如果赠品是成套发放，系统还会判断：

漏的是哪一件
已补的是哪一件
当前是否仍有配套缺口

这样不会因为“补过了”就把另一个真实缺件也一起拦掉。

4. 把结论同步给客服和仓库

真正有价值的地方，是前台和执行端看到的是同一结论：

客服知道该怎么解释
运营知道是否还需要额外安抚
仓库只执行真正该发的补寄单

改造后的流程图

flowchart TB
    A[订单信息 赠品清单 会话记录和历史处理记录进入系统] --> B[重复享受校验<br/>判断是否已补寄 已补偿或仅部分补齐]
    B --> C[对象配套校验<br/>识别具体缺失的是哪一件赠品]
    C --> D[工单分派<br/>仅把有效补寄单交给执行团队]
    D --> E[操作留痕追踪<br/>记录谁补过 什么时间补过]
    E --> F[客服获得统一口径]
    F --> G[减少重复补寄和重复补偿]

上线后的变化

这个项目上线后，团队最明显的变化不是赠品再也不漏了，而是“漏了以后到底处理到哪一步”终于比较看得清。

几个变化特别明显：

客服不再轻易因为顾客二次追问就再次新开补寄
运营能更快判断某条差评回复后还需不需要额外动作
仓库收到的重复补寄单显著变少
同一事项“赠品补了又发券”的情况明显收敛

项目复盘结果

以 8 周内 3217 条赠品漏发处理请求为样本，复盘结果如下：

对比项	改造前	改造后
同一订单因多入口反馈产生的重复补寄比例	较高	下降约 61%
仓库执行后才发现是重复补寄的情况	偶发但反复	明显下降
客服判断是否已处理过的耗时	偏长	缩短约 47%
部分补齐被误当成全部补齐的情况	较多	明显减少
赠品补寄与补偿券重复叠加的损失	持续存在	明显下降

为什么这个案例值得写

因为赠品漏发补寄不是一个简单的发货问题，而是一个很典型的“同一事项在多入口上被重复处理”的问题。
这类问题如果不在执行前拦住，事后几乎只能认损。