生鲜配送小程序案例：次日达履约与缺货替补怎么落地｜互联商通

一、客户背景与痛点

这家社区仓配团队有 1 个前置仓、约 800 个常售 SKU，下单集中在 19:00–21:30 的晚高峰。公众号只用来发到货提醒，交易搬到小程序，但履约仍靠人工。

四个最疼的问题：

• 缺货靠群里吼：拣货才发现没货，补不补、换什么全凭客服口头。
• 替补无标准：客户下单后才被告知「没货」，信任感一路走低。
• 截单后改单乱：司机已排线还有人改地址，成本吃掉毛利。
• 月底对不齐账：缺货、退款、替补散在群里，客服和仓各执一词。

二、方案总览：次日达与缺货替补先做死规则

首版克制，只做履约闭环，把「下单后才说没货」变成「下单前就有替补候选」。

1. 分类菜谱与规格上架：菜品按分类与规格结构化入库，下单前就看清有什么、什么时候送。
2. 时段配送 + 截单规则：按次日达窗口设置截单时间，截单后仅支持联系客服评估改单。
3. 缺货自动替补候选：拣货发现缺货时给出替补候选，按既定规则换货，不再凭口头承诺。
4. 订单状态推送：拣货、配送、送达状态用订阅消息推给客户，客服少接「到哪了」电话。

完整能力清单见 生鲜配送方案；同类场景可参考 社区团购分销案例。

三、核心功能清单

• 分类菜谱与规格：约 800 个 SKU 结构化管理，规格不再靠备注。
• 时段配送与截单：次日达窗口 + 截单时间写进规则页，用户下单前可见。
• 缺货替补候选：系统给候选、按规则换货，缺货不再靠群里吼。
• 订单状态推送：履约进度订阅消息触达，减少重复进线。
• 简易售后：冷链破损等售后入口固定在订单详情，可带图取证。

四、落地实施过程

总览里的四步讲的是方案逻辑，这一节讲它怎么落到仓里：两周内完成灰度上线，拆成下面五个动作，前一步跑顺再进下一步。

1. 进场前准备：主数据与规则页先定稿。开工第一周集中录入菜品、价格、营业时间，并和仓负责人逐条确认截单时间、替补规则、改单权限，写进用户须知页。商家看到的是一页页对完的主数据和几条可勾选的验收项；客户此时看不到变化，但下单那一刻规则已经是清晰的。
2. 系统对接：库存与订单单一写入方。上线前明确库存字段只由一方写入，避免两套系统互相覆盖；订单状态与订阅消息模板逐个申请、逐个联调。客服感知是「不用再在群里问有没有货」，仓库感知是拣货单和系统对得上。
3. 员工培训：客服话术与替补口径统一。客服只教两条主线——截单后改单怎么答、缺货替补怎么换，都按系统里写死的规则说，不临场发挥；仓管学会后台维护售罄与替补候选。商家感知是接电话变少、口径不再打架。
4. 灰度试点：部分楼栋先跑，收敛再全量。先拿部分订单试跑两周，盯三件事：缺货替补换得顺不顺、截单规则有没有被绕开、订阅消息触达率高不高。试出来的问题当场改——替补候选补全、模板文案重写；试点期不做数字考核，只看客诉清单收不收敛。
5. 值班与应急：首周高峰驻场加兜底。上线首周晚高峰驻场，值班覆盖支付、通知、售后三类突发；冷链异常按售后页示例图取证处理，改址请求统一走客服评估通道。试点暴露的问题全部进了第七节的复盘清单。

五、明确没做的事（对比与取舍）

首版不上多仓智能路由、不做社区团长分销、不做复杂积分商城。这些会拉长联调周期，现有客服编制也扛不住；先把「货按时到门口」闭环可验，再谈增长玩法。

六、上线后效果（试点口径）

两周灰度后：

• 缺货相关客诉从日均 18 单降到 7 单左右（试点口径）。
• 截单后仍可改址的比例压到 5% 以下。
• 店长的原话感受是「少接电话」比「多卖一件」更有体感。

所有数字为项目试点口径，复制前请重估仓配半径、品类结构与客服配置；数据对比写清统计周期与排除项。

七、坑与复盘

1. 库存字段被两个系统同时写：先定唯一写入方再联调，否则售罄状态随时打架。
2. 替补商品图未过审：替补候选的商品图也要过平台审核，不能只上主商品。
3. 订阅消息模板标题太营销：模板按履约通知类目申请，写太营销会被拒，见 订阅消息说明。

复盘沉淀为方法论：把「截单后谁有权改单、替补是否需用户确认、冷链异常怎么赔」写成一页职责与规则表，开工当天交给仓负责人，避免口头承诺漂移。

八、常见问题 FAQ