一、项目背景

某服饰品牌在我们 XpShop 底座上同时运营正价门店和奥莱折扣渠道，早期两套库存各管各的。正价店卖不动的同款，想调去奥莱清货，但系统里是两盘账，调拨靠微信群喊，经常出现一款在正价端显示有货、奥莱端也显示有货，实际就一件，谁先卖谁算，超卖和滞销一起发生。更糟的是，有次为了共享库存图省事，把奥莱的折扣价透传到了正价端的小程序，渠道商看到自己拿的价比奥莱还高，追着品牌方要说法，关系差点崩。那次事故之后我们明白，一盘货不是把数字放一起那么简单，价格和库存这两件事混着管，迟早出乱子，而且一出就是渠道信任的硬伤。

二、落地场景

这个项目里我们做了全渠道一盘货：所有渠道共享同一个物理库存源，但每个渠道有独立的价格视图和可用量规则。正价端和奥莱端看到的是同一批货，但价格严格隔离，奥莱的折扣价只在奥莱视图生效。系统根据各渠道销售速度和库存水位，给调拨建议，运营确认后生成调拨单，库存从一端划到另一端，两端库存实时更新。超卖防控放在库存中心统一做，任何渠道下单都先过原子扣减。我们还给运营做了盘货看板，能按款看"正价剩多少、奥莱剩多少、在途多少"，哪里积压一眼清，调拨决策不再靠拍脑袋。

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

第一道关是价格隔离。我们早期吃过透价的大亏，后来把价格从库存数据里彻底拆出来，库存只管有没有货，价格由渠道价格引擎按渠道身份算，两个视图互不串，连内部接口都不允许把奥莱价回传给正价端。第二道关是调拨的库存状态机，货在调拨途中的状态是在途不可用，不能两端同时卖，我们用状态字段加行锁保证调拨中库存只减不加，签收后才在目标端加回。第三道关是智能调拨建议，不能拍脑袋，我们按近 30 天各渠道动销和季节因子算调出优先级，建议给运营看，人确认才执行，避免系统瞎调把正价款也甩去奥莱，伤了正价渠道的利润。

案例片段（已脱敏）： 渠道价格隔离配置片段： 请求头带 X-Channel: outlet，价格引擎返回奥莱价 199；同 SKU 带 X-Channel: retail 返回正价 599，两视图同源库存 stock=120，互不透传。 调拨状态机片段（脱敏）：SKU coat-winter-07 从 retail 调出 40 件，状态置 IN_TRANSIT，retail 可用量减 40、outlet 未增；签收后状态转 AVAILABLE，outlet 可用量加 40。调拨途中两端合计可用恒等于 120。

四、效果数据

一盘货上线后，同款超卖客诉从每月 20 多单降到 1 到 2 单，群里那种"我拍下说没货"的抱怨基本听不到了。库存周转率提升约 18%，主要是滞销款能及时调去奥莱清掉，不用等到季末硬打折。调拨建议采纳后，人工调拨决策时间从平均 1 天缩到 2 小时内，运营终于从微信群里解脱出来。价格透传事故自隔离改造后没再发生，渠道商投诉归零。文中数据为项目复盘口径，已做脱敏。

这套一盘货跑稳之后，品牌方把更多渠道也接了进来，奥莱、正价、电商、直播共用一个库存源，价格各自隔离。我们后来在调拨建议里加了利润因子，不再只看出动销，还会提示哪款调去奥莱清最划算、哪款留在正价端更值，运营决策从清库存升级成算利润。渠道商那边也稳了，因为价格隔离后他们再没看到自己的进价被透出去，信任关系慢慢修复。库存周转率上来之后，品牌方一个季度少压的货值相当可观，这比单纯少几单客诉更有说服力。调拨从微信群喊话变成系统建议加人确认，仓库和渠道终于不在月底对账时互相甩锅了。

价格隔离做扎实之后，我们顺手把促销也纳进了渠道规则，正价端的满减和奥莱的折扣各自独立计算，不会再出现正价款被奥莱优惠券误伤的情况。我们还给运营做了价格穿透检查，调价前系统会模拟一遍：这个价在哪些渠道可见、会不会低于最低管控线，提前拦住违规。之前那种靠人肉审价的日子结束了，一次误调价可能引发的渠道投诉，被挡在了发布之前。库存和价格两套规则解耦之后，不管是加渠道还是改促销，都不用再动底层库存逻辑，扩展成本低了很多，品牌方加新渠道时不再担心把老价格搅乱。

五、可复用经验总结

一盘货的核心不是把数放一起，是先把库存和价格两个概念拆干净，库存讲物理事实，价格讲渠道规则，混在一起迟早出事，我们那次透价把渠道关系差点搞崩就是教训。调拨中的库存必须计状态，别让在途货被两端重复卖，否则超卖和账不平一起找上门。调拨建议交给人确认比系统全自动稳，毕竟清货策略涉及渠道关系，机器还不懂人情，哪些款能清、清到哪个奥莱，人比规则更清楚边界。这套机制跑下来，品牌方最满意的是终于敢共享库存了，不用再靠微信群救火，仓库和渠道也都能睡安稳觉。