新旧套餐映射售后接续：衔接别断线

这个案例来自电商场景。

很多电商商品不是单件长期不变，而是套餐会不断升级、改版、换组合。
真正最容易出问题的时候，不是新套餐上线那一天，而是旧套餐已经下线后，顾客拿着旧订单回来问售后的时候。

最常见的现场通常是：

旧套餐 A 已经下架
新套餐 B 已经替上来
顾客的旧订单却还在售后期
顾客来问补件、替换件或兼容关系

如果团队没有把新旧套餐的映射关系挂清楚，就很容易出现：

客服说现在对应这个新套餐
仓库说旧套餐里的某个配件已经没编号了
售后说责任还是按旧套餐算
顾客完全听不懂为什么同一件事前后台说法不一样

这个问题为什么在套餐型商品里更常见

这家企业主营小家电和家庭清洁工具，套餐迭代快。
一组旧套餐下线后，通常会有几种变化：

配件数量调整
赠品更换
型号升级
主件不变但辅件结构变了

这些变化对销售是正常升级，对售后却意味着：

旧订单责任还在
新套餐资源已经接管
顾客问题却仍围绕旧套餐展开

如果没有持续映射，售后就会在“已经没有这个套餐了”和“可它确实卖过”之间摇摆。

旧流程为什么总要靠资深同事翻老资料

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[减少旧单售后断链]

上线后的变化

项目上线后，团队最明显的变化不是套餐升级变少了，而是旧套餐下线以后，顾客旧单第一次不再像系统里的“失联历史”。

几个变化特别明显：

客服能更快找到旧套餐现在对应的处理对象
仓库补件时更少因编号换代而反复确认
售后解释“为什么现在给的是这个替代件”更稳定
复杂拆分或合并关系更早被标灰，不会硬套成简单升级

项目复盘结果

以 4 个季度内 93 组套餐升级关系、1842 笔相关售后为样本，项目复盘结果如下：

对比项	改造前	改造后
旧套餐售后因找不到当前对应对象而转单的比例	较高	下降约 51%
客服定位新旧套餐关系的平均耗时	很长	缩短约 55%
仓库因编号迭代导致的补件混乱	偶发但反复	明显下降
售后解释新旧差异不一致的情况	较多	明显减少
复杂升级关系在前期被识别出来的比例	低	明显提升

为什么这个案例值得写

因为新旧套餐售后接续不是一个简单“旧的换新的”问题，而是一个“对象前后关系、差异说明和责任承接”一起参与的场景。
这类问题如果不做稳，套餐一升级，售后就会立即变乱。