一、项目背景

这是一家区域鲜花连锁，线上小程序商城加二十多家线下门店。它最头疼的是节日——情人节、母亲节一爆单就超卖，顾客下单了仓里没花，只能临时调货或退款，口碑塌方。平时的问题更隐蔽：线上线下库存两套账，门店养护状态（比如这批玫瑰还能放几天）完全不透明，售后换花全靠顾客发图、客服肉眼判断，扯皮多。我们进场时老板一句话：能不能让"下单就有花、送过去还新鲜、坏了能说清"。

二、落地场景

我们在 XpShop 商城基础上做了同城库存实时同步：每个 SKU 在总仓和门店的可用量实时汇聚，顾客在小程序看到的就是可发量。节日做"预售+产能对齐"——爆款花束按产能上限开放预售，售罄即止，不透支库存。配送侧接即时配送，订单按"养护时效窗"排程，临近凋谢批次优先发、优先提示。门店养护状态做成结构化字段（到货日期、品种、预计可售天数），顾客下单前能看到"新鲜度"提示。售后换花走标准化流程：顾客上传照片，系统按规则初判，门店确认后走换花工单，全程留痕。

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

核心挑战是库存实时同步与预售超卖防护。鲜花是非标品，同一品种不同批次新鲜度不同，不能简单合并库存。我们用"批次+门店"为最小库存单元，下单即按批次预扣，预售按产能上限设硬阈值，超阈值直接售罄，从机制上杜绝超卖。预扣带时效，未支付自动释放。

第二个挑战是节日爆单的产能与履约调度。我们没有硬扛峰值，而是把预售产能拆到分钟级窗口，配合"就近门店履约"，让距离顾客最近的门店发货，既压配送时效又均衡各店负载。

第三个挑战是养护状态可视与售后。我们把养护建模成带衰减的字段，到货即录入，系统按品种衰减曲线推算可售天数并提示。售后换花用"规则初判+门店确认"两段式，减少客服主观误判，也方便后期复盘哪些批次问题多。

四、效果数据

上线两个节日周期的脱敏示意值：节日订单超卖事故从上一年的约 11 起降到 0；因配送超时/损耗导致的换花客诉率从约 5.8% 降到约 2.1%；门店库存可视率从约 0（靠问）提升到约 96%；旺季就近门店履约使平均配送时长从约 95 分钟降到约 52 分钟。最关键是顾客下单前能看到新鲜度提示后，"收到不新鲜"的差评下降约 44%。

五、可复用经验总结

鲜花这类易损品，履约的第一性原理是"控损耗"，时效是第二位的。第一，库存必须以批次为最小单元实时同步，预售产能设硬阈值，超卖在机制上就不该发生。第二，节日爆单别靠堆人，把产能拆到时间窗 + 就近履约，负载和体验都更好。第三，养护状态一定要结构化、可衰减推算，别让门店用脑子记"这束还能放几天"。第四，售后换花标准化留痕，既降扯皮也沉淀出"问题批次"数据，反哺采购。我们把批次库存与衰减模型抽成组件，后续做生鲜也打算复用。

结语

鲜花这类易损品，我们进场前老板最怕两件事：节日超卖和送过去不新鲜。上线后这两件都用机制兜住了——库存以批次为最小单元实时同步，预售产能设硬上限，达上限即售罄，超卖在架构上就不该发生；养护状态结构化、可衰减推算，顾客下单前能看到新鲜度提示，收到不新鲜的落差被提前抹平。

节日爆单我们没靠堆人，而是把预售产能拆到时间窗、配合就近门店履约。距离顾客最近的门店发货，既压配送时效又均衡各店负载，旺季不再出现某店爆仓、某店闲置。这个思路后来被证明比单纯加临时工有效得多，成本也更低。

售后换花标准化留痕，是我们一开始低估价值、后来越用越香的一块。顾客上传照片、系统按规则初判、门店确认走工单，全程留痕。它不只降扯皮，更沉淀出"问题批次"数据——哪批花损耗高、哪批养护短，反过来指导采购，形成正向循环。

我们把批次库存和衰减模型抽成了通用组件，后续做生鲜、做短保食品都打算复用。易损品履约的第一性原理其实都一样：先控损耗，再谈时效；把"新鲜度"这种模糊感知变成可计算、可展示的字段，体验和信任就立住了。

复盘下来，鲜花履约最容易被忽视的是"新鲜度"这件事的数字化。过去它停留在店长经验里，顾客更是一无所知。当我们把养护状态变成可计算、可展示的字段，体验的确定性就来了——顾客知道这束花还能放几天，门店知道哪批该先发，采购知道哪批损耗高。易损品生意，确定性就是复购，技术只是把确定性显性化而已。

案例片段（已脱敏）： ```

鲜花批次预扣与时效窗（伪代码节选）

batch = pick_batch(sku, store,    rule='freshness_desc')   # 优先发新鲜度高的批次 if batch.available < qty:    return SOLD_OUT prehold(batch, qty, ttl=900) # 15 分钟未支付自动释放 schedule_delivery(order,    window=batch.freshness_window)  # 临近凋谢批次优先发 ``` 预售产能在商品上设硬上限，达上限即售罄，从根上防超卖。