把「订单→仓配→售后」串起来：n8n一条工作流搞定
连锁门店最烦的不是单量大，是系统多：收银/外卖平台出单、WMS拣货、快递/同城配送、CRM做售后。用n8n的思路很简单：所有变化都变成Webhook事件，进来后做节点编排，把数据推到各系统，再把状态回写。比如一个门店日均200单、10家店就是2000单，只要把触发、重试、告警做好，就能稳定跑。
Webhook触发：让订单变成“可追踪的事件”
在n8n新建工作流，用Webhook节点做入口。平台能推就推；不能推就用定时拉取（Cron + HTTP Request）模拟事件。
- 路径建议：/hooks/order-created、/hooks/order-cancel、/hooks/after-sale
- 鉴权：Header里带token，n8n里用IF校验，不对就直接返回401
- 幂等：用订单号+事件类型做唯一键，写进数据库（Postgres/Redis均可），重复就丢弃，避免“重复出库”
案例：门店POS推来一笔订单，Webhook拿到后立刻返回200，别在入口做重活，先接住再处理，不然平台重推会把你打爆。
节点编排：订单分流到仓配，再回写状态
常见编排是：Webhook → 数据清洗(Set/Function) → 门店路由(Switch) → WMS创建出库 → 选择配送 → 回写订单状态。
- 门店路由：按store_id分到不同仓库/承运商规则，比如A区走同城，B区走快递
- 库存校验：HTTP Request查WMS库存，不足就走“缺货分支”，自动发短信/企业微信给店长
- 售后闭环：CRM创建工单（退货/换货），同时通知WMS生成退货入库单，并在订单系统打标“售后中”
建议加一个统一字段映射节点，把各系统字段对齐：sku_id、qty、receiver、address、order_amount。后面每接一个系统，只改这一处。
失败重试与日志告警：让工作流“能扛事”
跨系统必然会失败：接口超时、WMS维护、配送平台限流。n8n里把稳定性做好，才敢放量跑。
- 重试：关键HTTP节点开启重试或用自定义循环，间隔5秒/30秒/120秒递增，最多重试6次
- 错误分支：节点失败走Error Trigger/失败分支，把请求体、响应码、门店、订单号写入日志表
- 告警：当同一门店在10分钟内失败≥5次，自动发消息到运维群，并附上n8n执行链接
- 追踪ID：每次执行生成trace_id，贯穿WMS/配送/CRM，排查问题能一键串起来
可执行建议：今晚就挑1家门店、1条链路做试点（下单→WMS出库→回写状态），把幂等、重试、日志表先落地；明天把配送和售后两个分支接上；一周内再复制到其余门店，用同一套字段映射和告警规则，扩店不会越扩越乱。
