连锁零售订单中台
统一官网、小程序与门店 POS 的订单与库存，把门店履约从“人对账”变成“系统可追踪”。
背景
客户同时运营官网商城、微信小程序与门店 POS，三套订单各自独立，客服每天用表格对账。
库存以门店手工盘点为主，线上超卖与门店拒单频发，旺季客诉明显上升。
业务方希望先解决“看得见、调得动”，再谈会员与营销中台，预算与工期都有硬上限。
约束
- POS 厂商只提供有限 webhook / 导出接口，不能改 POS 内核
- 首期必须在大促前 3 周上线主链路，不允许停业切换
- 门店店员操作习惯弱，后台交互必须比现有表格更短路径
真正的难点
真正难点不是“再做一个订单系统”，而是在接口不完整、门店习惯难改、上线窗口极短的前提下，先统一订单事实源，又不能一次重写全部渠道。
关键取舍
先建订单事实源，不先做全渠道营销
砍掉一期优惠券中心与复杂分销。先保证下单、支付、锁库、门店接单、异常改址五条主路径可观测，避免范围膨胀拖垮大促窗口。
库存采用“可售库存 + 门店预留”双账本
线上可售与门店实物不完全等同。可售库存由中台汇总；门店预留库存按规则冻结。对账差异进异常队列，而不是假装实时绝对一致。
灰度按城市切流，不做大爆炸切换
先 2 城试点，再扩到全网。POS 侧保留降级：中台不可用时门店仍可本地开单，事后补偿同步，保证营业连续性。
怎么做的
搭建订单中台与库存服务：统一订单状态机，定义渠道侧适配层；官网/小程序经 API 直连，POS 经适配器拉取与回写。
管理后台覆盖异常单、缺货、改址、退款协同；日报按门店/渠道输出履约与拒单原因。
一期上线订单统一与锁库；二期补履约路由优化、对账报表与新渠道接入模板。
可核对的结果
人工对账工时约 ↓60%客服从日均 3–4 小时表格对账降到异常单处理
缺货误单显著下降可售库存与门店预留分离后，超卖类客诉明显减少
新渠道接入从周级 → 天级二期沉淀适配模板后，活动页渠道可按配置接入
大促窗口如期切流试点城市提前 10 天稳定，全网在大促前完成扩面
复盘
- 接口不全时，先定义“可接受的不一致”和补偿机制，比追求完美实时同步更现实。
- 对店员侧，少一个菜单比多一个功能更重要；验收标准要写成操作步骤，而不是接口清单。
- 合同里写清灰度范围与回滚条件，比口头承诺“保证不影响营业”更有用。
技术栈
Next.jsNode.jsPostgreSQLRedis消息队列