一、项目背景

我们服务的这家临期食品折扣连锁，门店分布在社区周边，SKU 上千，保质期从几天到一年多不等，每天都有一批商品悄悄跨过临期阈值。项目接手前，店员每天对着 Excel 手动改价，漏改是常态，等到顾客拿起一看价签和收银对不上，投诉就来了。总部其实想要统一控价，但管不到门店那一堆手写价签，月底盘点总有一批临期品没处理掉直接报损，损耗率一度压不下来。更麻烦的是临期品的处理节奏完全靠人记，哪些该打折、哪些该下架全凭店长经验，新人一上手就乱。我们盘点过一家样板店，光效期管理这项，店长每周要花将近一天在表格和价签之间来回倒腾，还经常出错。有次督导巡店，发现同一款临期饼干三家店三个价，最便宜的比最贵的低了将近两成，顾客当场拍了照发群里，总部脸面挂不住。

我们当时判断，核心矛盾不是"要不要打折"，而是效期数据没有变成主数据。价格跟着效期走，效期跟不上，定价就是瞎蒙。

二、落地场景

我们把它拆成几条线。一是效期主数据贯通：供应商到货时把生产日期、保质期录进系统，按批号管理，门店库存和中央仓库存都挂在同一个效期时间轴上。二是临期分级自动折扣：系统按剩余保质期占保质期比例自动套档，比如剩余三分之一进入八五折，剩余五分之一进入七折，不需要人去想。三是价签联动：电子价签和线上小程序价格同步刷新，顾客在手机上看到的价，到店扫码也是这个价。四是临期品分销：临期较重的批次自动推到特卖渠道和社群，提前清掉。五是报损预警：效期进入不可售区间前，系统提前给门店和总部发预警，避免临期品默默烂在货架上。

三、关键技术挑战与解决思路

最磨人的是效期主数据的实时同步。临期商品调拨频繁，仓到店、店到店都在动，效期状态必须跟着实物走。我们用了批号维度的库存流水，每次出入库都带效期标签，定时任务每十分钟重算一次临期档位。这个十分钟不是拍的，早期设成一小时，大促时一批临期品已经超期才被扫到，后来压到十分钟，鲜食类我们甚至改成五分钟一次，算力和准确性之间找平衡。

折扣策略也不能一刀切。不同品类损耗弹性不一样，饼干临期两周还能卖，鲜奶临期两天就得狠打折。我们把折扣档位做成可配置的品类矩阵，运营在后台拖一下就能调，不用改代码，鲜食档位更紧、干货更松，巧克力这类保质期长的甚至可以放宽到五成以下才打折。

还有价签联动的一致性。早期我们让门店自己改价，结果同一款商品三家店三个价，被投诉价格欺诈。后来改成价签由系统统一下发，门店只有确认上架的权限，改价动作收归总部策略引擎，店长从定价者变成确认者，这一改把价格投诉直接归零。

案例片段（已脱敏）： 折扣档位配置（yaml 节选）：rules:  - category: bakery    tiers:      - remain_ratio: 0.33        discount: 0.85      - remain_ratio: 0.20        discount: 0.70  - category: dairy    tiers:      - remain_ratio: 0.15        discount: 0.60上线后某门店 dairy 类一批临期两天商品，系统自动落到 0.6 档，当天售罄，而此前同批靠人工忘记改价，整批报损约四百元。另一家店 bakery 临期三天的面包，系统按 0.85 档出清，比店长习惯的统一定价多卖了两成。

案例片段（已脱敏）： 某社区店春节前盘点，临期干货区积压约六百袋坚果，按旧流程要等店长周末来调价，往往拖到过期。接入自动折扣后，系统在剩余保质期到三成时直接挂七折并推到社群，三天清空，较去年同期同批临期品报损减少约三千元，店长省下两天盘货时间，把精力挪去盯鲜食周转。

四、效果数据

跑满三个月，报损率从之前的约 4.2% 降到 1.8% 左右，临期品平均周转天数从 9 天压到 5 天。毛利反而升了约 3 个点，原因是以前临期品大多直接报损零收入，现在能卖出七折八五折。店员人工调价工时每周从约 6 小时降到不足 1 小时，店长终于不用在表格里耗着。最明显的信号是价格投诉归零，之前每月稳定有两三起。文中数据为项目复盘口径，已做脱敏。

五、可复用经验总结

临期商品的定价本质是效期驱动，把它当主数据而不是运营拍脑袋，后面一切都顺。折扣档位一定要按品类分矩阵，别用一套比例打天下，鲜食和干货的损耗弹性差太远，巧克力这类长保甚至有自己的一套。价签联动这件事，权限要收口，门店只确认不定价，否则三店三价迟早出事。现在回头看，折扣引擎的可配置化是这一步最值钱的设计，运营改策略不再等发版，这点比多打几个折扣点更实在。报损预警上线后，总部这下能提前三天看到哪些店要出问题，管理动作前移了，督导不再靠巡店撞见。