去年双十一前一周，一个做家居品类的卖家朋友半夜给我打电话，说他们在 Amazon、Shopee、TikTok Shop 三个平台同时推同一款收纳盒，结果一个晚上超卖了 400 多单。问题是：三个平台的后台库存显示都还有货，但仓库实际可用库存早就被其中一个平台的订单吃光了。他们用的 ERP 每天同步一次库存，而 TikTok Shop 的爆单速度是每小时几百单。这不是 ERP 不好用，而是他们的协同逻辑从设计上就是错的，把"刊登"当成了前端动作，把"库存"当成了后端数据，中间没有任何规则层。
这篇文章不打算再讲一遍 ERP 有哪些功能模块，那类内容已经太多了。我想讲的是：当你从单平台扩到多平台刊登之后，供应链协同到底发生了什么变化，哪些环节会先崩，方案设计的顺序应该是什么，以及在什么阶段该自己搭、什么阶段该上工具。文中会以"数跨境"（官网 https://shukuajing.jiushuyun.com/?utm_source=seo&utm;_plan=est&utm;
_unit=gys）作为一个可参照的样本，说明一套面向多平台刊登场景的协同系统应该长什么样，但主角仍然是你的业务流程，不是任何一款软件。
我把过去几年接触过的、超过 30 个多平台卖家的协同故障案例做了归类，发现不管表面现象是超卖、错发、断货还是库存积压，根因最后都收敛到两个问题上：时序问题和归属问题。理解了这两个词，方案设计就有了主轴，剩下的都是实现细节。
单平台时，库存扣减只有一个来源，逻辑是线性的：订单进来 → 扣库存 → 仓库发货 → 库存更新。这个链条短到几乎不会出错。
多平台之后，同一个 SKU 的库存被拆成了"平台可见库存"和"仓库实际库存"两层，中间还夹着在途、锁定、预占、退货待检等状态。你在 Amazon 后台看到的可售数量，和在仓库里能真正拣出来的数量，可能相差 30% 以上，这个差距就是时序造成的。
典型场景是这样的：Shopee 上的订单在中午 12 点进来，平台的库存扣减是准实时的；但你的 ERP 可能是每 15 分钟拉一次多平台订单，再统一回写库存。这 15 分钟里，Amazon 上同一个 SKU 仍然显示有货，买家可以继续下单。如果这个 SKU 是小爆款，15 分钟足够超卖。
更麻烦的是退货回补。有的平台退货入库后立刻回补可售库存，有的要等质检通过，有的要等 48 小时。如果 ERP 用了统一规则去处理，就会出现"A 平台能卖但系统显示没货"或者"B 平台明明没货系统却显示了"。
时序解决的是"什么时候"，归属解决的是"算谁的"。这是多平台刊登里被严重低估的一块。
假设你有 1000 件某 SKU，同时在 4 个平台刊登。这时候你必须回答一个问题：这 1000 件是共享池，还是被切成了 4 份？
共享池模式的好处是库存利用率高，坏处是任何一个平台爆单都会抽干全局库存，其他平台瞬间断货；分区模式的好处是各平台稳定，坏处是总有一部分库存在慢平台上被"浪费"掉。
我见过一家做宠物用品的卖家，用的是完全分区：Amazon 600 件、Shopee 200 件、TikTok 100 件、独立站 100 件。结果 TikTok 爆了，当天卖空，而 Amazon 那边 600 件里只动了 80 件，整体周转被拖慢。这就是归属没设计好的代价。
真正合理的做法是动态归属：用共享池保证总体效率，同时给每个平台设一个"下限预留"和"上限封顶"，通过规则层动态调整。这就引出下一节的架构问题。
很多团队在做协同方案时，是从 ERP 的功能列表倒推流程的，这是本末倒置。正确的顺序是：先把刊登动作触发的下游环节列清楚，再决定哪些交给系统、哪些留给人工。下面用一个具体的刊登场景走一遍。
假设你决定在 4 个平台同时上架一款新的硅胶厨具，刊登动作看起来只是"填标题、传图、设价、提交"。但往后追，它至少触发了这些环节：
这 7 个环节里，只有第 1 和第 6 是"刊登时"就要确定的，其余都是刊登之后持续运行的规则。很多团队的失败在于把这 7 个环节都交给了 ERP 的默认配置，而没有针对自己的业务做设计。
不同平台的库存回传机制差别很大，这一点在方案设计时必须有明确的基准表，否则你连"实时"这个词都没法定义。根据公开的平台开发者文档和我实际接入的经验，差异大致是这样的（具体政策以各平台最新开发者文档为准，这里只做量级参考）：
| 平台 | 订单拉取方式 | 库存回写方式 | 典型延迟量级 | 风险点 |
|---|---|---|---|---|
| Amazon | API 轮询/MWS 推送 | Feed 批处理 | 分钟级到十几分钟 | Feed 失败会静默丢单 |
| Shopee | Webhook/轮询 | API 实时更新 | 秒级到分钟级 | 促销期限流严重 |
| TikTok Shop | Webhook 为主 | API 实时更新 | 秒级 | 爆单瞬时并发压力大 |
| 独立站 | 自建，完全可控 | 自建 | 取决于架构 | 容易与平台侧脱节 |
这张表的意义在于：你不能用一个统一的同步频率去覆盖所有平台。如果按 Amazon 的批处理节奏设计，TikTok 那边早就爆了；如果按 TikTok 的秒级设计，Amazon 侧的 API 调用次数会超标并且频繁报错。
回到开头那位朋友。事后我们一起复盘，问题链条是这样的：
最终超卖 400+ 单，客服成本、平台罚分、退款损失加起来超过了那次活动的全部毛利。这不是系统故障，是协同设计缺陷。
如果当时采用的是"平台侧预留 + 异步核减"的设计，也就是在 TikTok 爆单期间，先把 Amazon 和 Shopee 的库存临时压缩到一个低位保护区间，等 ERP 完成回写再恢复，超卖量可以控制在几十单以内。这个思路在下面第三节的架构里会详细展开。
这是最大的认知陷阱。市面上绝大多数 ERP 都宣称支持 20+ 平台，但"支持"通常只意味着能对接 API、能拉订单、能回写库存，这是连接层能力，不是协同层能力。
协同层要解决的是：库存怎么分、规则怎么优先、异常怎么兜底、多仓怎么路由。这些不是"支持多平台"就能自动拥有的，需要你自己定义规则，系统负责执行。我见过太多团队买完 ERP 才发现，所有规则都要自己配，而供应商只提供一个默认模板。
很多采购决策会问"你们库存同步是实时的吗"，但"实时"这里是个营销词，而不是技术指标。真正该问的是：在平台限流、API 报错、订单突增这三种异常情况下，系统的降级策略是什么？
这才是协同质量的关键。一个每 5 分钟同步一次但有完整降级策略的系统，比一个"声称实时"但一遇限流就静默失败的系统可靠得多。
这是经典争论："先梳理流程再选 ERP"还是"先用 ERP 再优化流程"。我的判断是：核心流程必须先想清楚，边缘流程可以边用边优化。
什么是核心流程？库存分配规则、订单路由规则、采购触发规则，这三条必须在选型之前就想清楚，因为它们决定了你必须要求系统具备哪些能力。什么是边缘流程？报表格式、导出字段、通知方式，这些完全可以上线后再调。
把核心流程交给系统默认配置，等于把公司的库存安全外包给了一个不了解你业务的模板。
统一规则看起来管理成本低，实际上会在两个地方付出代价：一是爆单平台的保护不足，二是慢平台的库存被无谓占用。
正确的做法是分层规则：全局基线规则 + 平台差异化覆盖规则。全局层定义安全库存的默认比例、超卖的兜底动作；平台层针对 TikTok 这种高爆发平台加更厚的缓冲，针对独立站这种可预测平台用更薄的缓冲。
大部分团队把注意力放在"上架"和"库存"上，却忽略了下架。实际上，一个平台因违规或断货下架，如果不同步到其他平台，会造成严重的库存预期错位。
举例：Amazon 因品类审核问题临时下架了某 SKU，团队还没来得及在 Shopee 和 TikTok 下架，结果这两个平台的流量全部导向了这款已停售的产品，卖出后无法发货，产生大量取消订单，直接拉低店铺评分。
讲完问题，进入方案设计。我推荐的分层结构是三层 + 两条规则线：数据层、规则层、执行层，加上库存规则线和订单规则线。这个框架的好处是把"数据"和"规则"分开了，很多团队的问题就是把两者混在一起，导致改一处规则要动一堆数据。
数据层要解决的核心问题只有一个：同一个实物，在不同平台、不同仓库、不同系统里，如何被识别为同一个东西。
做法是建立三层映射：
这一步看起来枯燥，但它决定了后面所有规则的可行性。我在项目里见过最惨的案例是一个卖家有 3 个仓库、5 个平台，SKU 映射表靠 Excel 维护，一次运营改了个平台 SKU 名字没同步，导致 200 多单发错货。映射表必须是系统里的强约束，不能是文档里的约定。
库存规则线要定义四件事：分配方式、安全阈值、回补逻辑、异常降级。
| 规则项 | 要定义什么 | 常见错误 |
|---|---|---|
| 分配方式 | 共享池/分区/动态归属，各平台预留上下限 | 全平台一刀切共享 |
| 安全阈值 | 各平台下架触发线、低库存预警线 | 所有平台用同一百分比 |
| 回补逻辑 | 退货、取消、调拨回补的时效与条件 | 取消订单也立刻回补 |
| 异常降级 | API 失败、限流、爆单时的保护动作 | 没有降级，静默失败 |
订单规则线要定义：订单进哪个仓、优先哪个物流、面单用哪个渠道、异常订单怎么隔离。
多仓卖家的典型问题是"哪个仓近发哪个仓"，但实际业务里还要考虑：某仓库正在盘点、某物流渠道当天截单、某平台要求特定承运商。所以订单路由规则应该是多条件优先级队列，而不是简单的就近原则。
执行层是大多数人理解的"ERP 本身"，也就是对接平台 API、WMS、物流商，完成实际的读写。
但执行层最容易被忽略的是监控与兜底。我给团队的建议是：执行层必须有三个监控看板，同步延迟看板、失败重试看板、异常订单看板。前两个是系统健康，第三个是业务健康。
没有这三个看板，你会陷入"出事了才知道"的被动状态。有了它们，你可以在超卖发生之前就发现"某个平台的库存回写开始积压了"。
前面讲的是框架，这里落到一个可参照的样本上。之所以选"数跨境"（https://shukuajing.jiushuyun.com/?utm_source=seo&utm;_plan=est&utm;_unit=gys）来举例，是因为它面向的场景和多平台刊登的协同需求比较贴合，可以用来对照前面讲的三层架构，而不是因为它一定适合所有人。
多平台协同的第一道门槛是商品主数据统一。数跨境这类系统的做法是建立一个内部商品中心，平台侧的 Listing 通过映射关系挂到内部 SKU 上。
这个设计的价值在于：当你在 4 个平台刊登时，你维护的是 1 份商品主数据，而不是 4 份。价格、库存、状态的变化都作用在主数据上，再按规则分发到各平台。这与我在第四节强调的"数据层是地基"是一致的。
对照检查点：如果你的系统需要你在每个平台分别维护库存，说明它只有连接层，没有数据层。
规则层的核心是能否配置差异化的库存策略。以多平台刊登场景为例，需要能配置：
这里面最关键的判断标准是"降级动作"是否可配置。如果系统在 API 失败时只会重试，没有保护性动作，那么在多平台爆单场景下它是不可靠的。
执行层的能力体现在两件事上：一是能否把一次编辑分发到多个平台（刊登效率），二是能否把多个平台的订单收敛到一个处理队列（订单效率）。
这两件事在多平台卖家那里是刚需。我见过一个团队 5 个人管 6 个平台的刊登，每周花在重复上架和改价上的时间超过 20 小时。上系统之后这部分时间压缩到 5 小时以内。但要注意，刊登效率的提升不代表协同质量提升，这只是执行层的收益。
| 能力层 | 典型功能 | 对应解决什么问题 | 判断标准 |
|---|---|---|---|
| 数据层 | 商品中心、SKU 映射、库存主数据 | 同一实物多平台识别 | 是否需要逐平台维护库存 |
| 规则层 | 库存分配、安全阈值、降级策略 | 时序与归属问题 | 降级动作是否可配置 |
| 执行层 | 多平台刊登、订单归集、API 对接 | 操作效率问题 | 异常是否有监控看板 |
我跟踪过一家做户外用品的卖家，SKU 约 800 个，运营 Amazon、Shopee、TikTok Shop 和独立站四个渠道，年 GMV 在 3000 万左右。他们的改善路径分了三步：
第一步，先把 SKU 映射表系统化。原来用 Excel 维护，改成系统强制映射后，订单错发率从每月约 15 单降到 2 单以内。这一步耗时约 3 周，成本主要是人力。
第二步，把库存从"全共享"改成"动态归属"。给 TikTok 设 15% 预留，给独立站设 5%，其余共享。改完之后大促期超卖从每场几十单降到个位数。这一步耗时约 2 周。
第三步，补上监控看板和降级策略。这一步最容易被跳过，但效果最直接：他们发现某个平台的库存回写每天凌晨会积压 30 分钟，之前一直不知道。补上降级动作后，凌晨时段的超卖风险基本消除。
如果你现在正准备从单平台扩到多平台，或者多平台已经跑起来但协同很乱，下面这 5 个动作可以直接照着做。顺序不要调整，因为后一步依赖前一步的输出。
输出物是一张表：每个平台的订单拉取方式、库存回写方式、退货回补时效、限流规则。
这张表的用途是确定你的同步基准。不要凭感觉写"实时"，要去查平台开发者文档，或者直接问对方的技术支持。这张表做完，你会对"为什么不能用一个频率同步所有平台"有具象认知。
编码规则要满足三条：唯一、可扩展、不含业务含义（不要在编码里塞平台名或年份，因为业务会变）。
映射机制的关键是强制约束：任何平台 SKU 如果没有映射到 Master SKU，系统应该拒绝入库或标记异常，而不是放过。
示例：Master SKU 命名规则
格式：品类代码(3) – 材质代码(2) – 序号(5) – 变体码(2)
示例：HOM-SI-00123-RD
说明：
品类代码 HOM = 家居
材质代码 SI = 硅胶
序号 00123 = 该类目下第 123 个产品
变体码 RD = 红色
禁止：在编码中包含 AMZ/SHP/TTK 等平台标识
这一步要产出的是库存规则表。建议按下面的结构来定义，先做全局，再做平台覆盖。
这套数字不是标准答案，是起点。上线后必须根据实际超卖和断货数据迭代，前两个月建议每两周复盘一次。
订单路由建议按优先级队列设计，而不是简单的就近发货：
采购触发则要解决"用哪个口径算销量"的问题。多平台之后，建议用近 7 天加权销量（权重向近 3 天倾斜）+ 在途 + 安全库存来算补货点，而不是简单用总销量除天数。
不要一次性把所有 SKU 切到新规则。选 20-30 个 SKU 做灰度，覆盖不同的销量层级和平台组合，跑满 2 个完整补货周期再全量。
灰度期间重点看三个数：超卖次数、库存回写延迟、订单路由人工干预率。如果人工干预率超过 15%，说明规则还不够细，不要急着全量。
方案设计最忌讳的是照搬别人的架构。下面按三个阶段给出差异化的建议，核心判断依据是 SKU 数、平台数和团队规模。
这个阶段我的建议是不要上复杂 ERP，先用轻量工具 + 严格的人工规则。
理由是：这个体量下，协同复杂度还没到必须系统化的程度，上一套重系统反而会增加配置和维护负担。核心动作是两件：把 SKU 映射表做规范，把库存共享规则定清楚（建议这个阶段就用共享池 + 高比例预留，简单可靠）。
什么时候该升级？当你每月因为库存问题产生的损失超过 5000 元，或者人工处理多平台订单的时间超过每周 10 小时，就该考虑系统化了。
这是最需要系统化协同的阶段，也是数跨境这类系统的主战场。核心需求从"能对接"变成"能配规则"。
这个阶段的重点动作是：建立商品主数据、配置平台差异化库存策略、上线监控看板。团队里最好有一个明确的"协同负责人"，负责规则维护和异常处理，而不是分散给几个运营各自管。
选型时的关键问题是：这套系统能不能承载我的规则复杂度？而不是它支持多少个平台。测试方法是拿你最复杂的一个场景（比如"TikTok 爆单期间 Amazon 库存保护"）去问供应商能不能配，配置过程有多复杂。
这个阶段往往需要 ERP + WMS + 自建规则引擎的组合，因为标准 ERP 的规则层难以承载高度个性化的路由和分配逻辑。
此时的重点从"配置规则"转向"规则的可解释与可追溯"。你需要能回答：为什么这一单走到了这个仓？为什么这个平台的可售被压到了这个数？可追溯性在这个阶段比性能更重要。
这是最根本的取舍。共享池利用率高但断货风险大，分区稳定但库存浪费。我的建议是按品类价值分层决策：
提高同步频率能降低超卖风险，但会增加 API 调用，可能触发平台限流。取舍策略是分平台差异化 + 分时段动态调整：
平时用较低频率（如 10-15 分钟）省配额，大促期对高爆发平台单独提高到 1-2 分钟，同时把其他平台的频率降下来。这个动作需要系统支持按平台、按时段配置，是选型时要确认的能力。
规则越复杂，协同越精准，但维护成本越高。我见过一些团队把规则做到十几层，结果只有写规则的那个人能看懂，一旦他离职，整个协同就失效了。
我的建议是规则层不超过三层优先级，且每个规则必须有文档说明和负责人。如果一条规则你自己都解释不清楚为什么要这么设，那它大概率是多余的。
标准 ERP 上线快、成本低，但遇到个性化路由逻辑时会受限；定制开发灵活，但维护和升级成本高，且一旦平台 API 变化，需要自己跟进。
判断标准很简单：如果你有超过 30% 的订单需要走非标准逻辑，就该考虑定制或混合方案；如果低于 10%，用标准产品加人工兜底更划算。
把前面所有内容压缩成一份可以直接对照的清单。这份清单我在项目里用过多次，能过滤掉大部分常见问题。
这 8 个问题如果有一半答不上来，先别急着选型，先把答案补上。选型是在答案清晰之后才有的动作，而不是用来找答案的。
| 监控项 | 健康值参考 | 异常时的动作 |
|---|---|---|
| 库存回写延迟 | 峰值不超过 5 分钟 | 排查 API 配额和限流，考虑分时段策略 |
| 超卖订单数 | 每周不超过 2 单 | 提高对应平台预留比例 |
| 订单路由人工干预率 | 低于 10% | 补充路由规则，检查多仓库存分布 |
| SKU 映射异常数 | 每日为 0 | 检查新品上架流程，是否绕过了映射 |
| 平台同步失败率 | 低于 1% | 检查 API 凭证和平台侧权限变更 |
做了这么多年，我对多平台刊登场景下的供应链协同只有一个核心判断：协同不是买来的，是设计出来的。ERP 是执行工具，规则是设计产物，而规则只能来自你对自身业务的理解。
数跨境这类系统的价值在于，它把数据层和规则层的能力产品化了，让你不用从零开发，但它替代不了"想清楚"这一步。我见过买了很好的系统但协同依然一塌糊涂的团队，也见过用轻量工具但规则设计得非常清晰的团队，后者往往活得更好。
另一个我越来越确信的判断是：多平台协同的问题，80% 会在你上线新平台的前三个月暴露。所以最好的时机不是等出问题再解决，而是在决定上第二个平台之前，就把库存归属、同步策略、降级动作这三件事定下来。这三件事定好了，后面上的平台越多，边际成本越低；定不好，每多一个平台，风险就翻一倍。
如果你现在正准备扩平台或正在被协同问题困扰，我建议按这个顺序动手：
这套动作不需要额外的预算，需要的只是把"协同"当成一个需要设计的东西，而不是一个买了就有的功能。如果你在这几件事上有不同的实践经验，或者遇到过更刁钻的协同场景，欢迎一起讨论，这块的公开经验确实太少，多交流对彼此都有价值。
我做亚马逊、Shopee、TikTok Shop三个平台卖同一批货，每个平台的库存扣减速度都不一样，有次TikTok半夜爆单，早上起来发现亚马逊那边已经超卖了十几单。所以一直在纠结同步频率到底设多少，安全库存又要留多少才既不压货又不超卖。
先做分层，不要所有SKU都开实时同步。按动销和超卖损失分层：A类（日销大于20单、断货会掉排名的）用5到15分钟的近实时同步，B类用15到30分钟定时，C类长尾用1小时或手动触发。缓冲逻辑有两种主流做法。
一种是百分比法，把平台可售库存设成可用库存乘缓冲系数再减安全库存，回传延迟高、退货率高的平台留5%到10%，回传快的留2%到3%。
另一种是配额法，给每个平台分配固定库存池，比如总库存1000件，亚马逊400、Shopee350、TikTok250，平台之间不互相借货，好处是绝对不会跨平台超卖，代价是可能出现A平台断货而B平台有货，需要每周按销量占比重新调整配额。
判断依据很简单，拉过去30天的超卖订单数除以总订单数，能压到0.3%以下说明策略没问题，超过1%就必须回头改同步频率或缓冲值。注意各平台的库存回传机制和API限流政策会变，具体参数以你实际接入时平台的最新规则为准。这套参数不可能一次设对，先用20到50个SKU跑两周再放大。
我们最开始是每个平台各建一套SKU，运营在平台后台自己起名，结果同一个产品在三个平台有三个编码，采购看不懂、仓库发错货。后来想统一，又发现组合装、变体这些情况很难套进一套编码里，一直没想清楚该怎么设计。
用主SKU加平台SKU映射表的两层结构。主SKU是你自己定义、唯一的内部编码，建议包含品类加关键规格，比如ABC-TS-RED-M，编码里不要带平台和店铺信息。平台SKU作为子级挂在主SKU下面，靠一张映射表维护平台加店铺加平台SKU指向主SKU的关系，这张表是全公司库存和订单的唯一对照源。
组合装不要新建独立主SKU，用虚拟组合SKU指向组件主SKU，扣减时按BOM拆到组件；赠品同理，单独设成0成本或独立成本项，否则毛利算不准。变体要注意，刊登时是父子关系，但在库存层只有一个可售SKU，不要把每个变体当独立SKU管库存，否则同一批货会被重复计数。
落地动作是先导出所有平台在售Listing清单做一次人工映射清洗，500到2000个SKU一般2到3天能理完，之后新增SKU必须走映射表登记，禁止运营直接在平台后台上新，这条纪律比工具本身更重要。
我们在国内有一个中心仓，海外有FBA和第三方海外仓，同一批货分散在几个地方。经常出现买家明明离海外仓近，订单却从国内发，时效拖到十几天，或者某个仓积压另一个仓缺货。想知道订单路由到底该按什么规则来配，ERP里怎么落地。
按三层排序配：库存位置优先，其次是时效承诺，最后才是成本。第一层，优先选距离买家最近且该SKU有可用库存的仓；第二层，看平台的时效要求，比如某些平台要求48小时发货或Prime标识，满足不了就换仓或换渠道；第三层，在都满足前两条时比尾程成本。
ERP里一般配成规则引擎，条件字段包括买家国家或邮编、平台、各仓可用库存、SKU优先级、物流渠道。实操有几个要点：每个仓设可分配比例，避免所有订单挤向一个仓；设拆单阈值，分仓发货通常意味着物流成本翻倍，除非单笔金额超过某个值（比如50美元）或客户加急，否则宁可等齐一起发；
FBA类订单由平台自己配送，ERP只做库存回传，不要重复路由否则会扣两次库存。判断依据是订单履约时效中位数和单均物流成本两项，建议每季度复盘一次规则，尤其是旺季前后，因为海外仓的仓位和时效会变。
我们团队现在三个平台两个仓，全靠Excel加微信群在跑，库存靠人工每天对一次。想上ERP，但听说有同行切换的时候乱了半个月，订单积压、库存对不上。所以想知道到底该先梳理流程还是先买系统，切换有没有稳妥的节奏。
结论是先梳理流程再选系统，但不要等流程完美才动手。做法上用两周画一张现状流程图，只标四个节点：库存数据从哪来、订单在哪落、采购由谁触发、物流面单在哪打，同时标注每个节点现在是人做还是系统做。选ERP时拿这张图去对照，能覆盖现状80%的就可以，剩下20%改流程而不是改系统，否则你会被系统牵着走。
切换要分批，按仓库、平台、SKU三个维度拆，典型节奏是先切一个平台的A类SKU，跑通两周，确认超卖率低于0.5%、订单处理时效没有下降，再扩到同平台全部SKU，然后是一个仓，然后是全平台。
期间允许新旧并行，但库存只能有一个真相源，也就是ERP，必须收掉运营在平台后台直接改库存的权限，这条不执行就永远对不上。参考时间：单平台单仓的小卖家2到3周能跑通，三平台两仓的团队预留6到8周比较稳，旺季前两个月不要做切换。总的原则是协同不是买来的，是先把规则想清楚，再让系统去执行。
读者评论
时序和归属这两个词抓得很准，我们做多平台时超卖根因确实都在这里，文章把问题说透了。
动态归属那组周转率和断货率的对比很直观，完全分区虽然安全但库存利用率掉太多，值得重新算账。
平台回传时序差异那张表很实用，之前用统一同步频率吃过亏，按平台分别设计降级策略确实是关键。
误区三和误区四说得对，核心流程没梳理清楚就上系统，后面返工成本比软件费用高多了。
下架传导这点之前没重视过，一个平台停售没同步导致其他平台继续出单，评分掉得很难受。