去年大促第二天早上八点，我打开后台，看到一条店铺留言：客户说付款两天了，物流信息还是空的。我顺手查了一下，平台后台显示这笔订单"待发货"，ERP 里压根没有这条记录。同一时间，另一个店铺的仓库同事跟我说，有个 SKU 昨天多发了 2 单，客户已经签收。一个漏发、一个多发，发生在同一个早上，来自两家店。我当时脑子里第一个念头是"ERP 坏了"，第二个念头是"要不要换一家"。
后来的排查结果是：这两件事跟 ERP 好不好用几乎没关系，它们分别断在链路的两个不同位置，一个是平台授权凭证在半夜失效后没有人被通知，一个是两个店铺共享库存池的扣减时点在两套规则里不一致。这篇文章我不想再写一遍 ERP 功能对比表，我想做的是把订单同步这条链路拆成几个"断点"，告诉你每一段会怎么断、你怎么自己验证、出了问题该找谁。多店经营的坑，基本都藏在这些断点里。
先把我的判断摆在最前面。我做过三年多跨境运营，也帮朋友的公司做过 ERP 选型和迁移，见过太多团队在订单同步出问题时的第一反应是换工具。但换完之后，同样的漏单、超卖、重复发货，过两三个月又会长出来，只是换了个界面。
原因在于，大家把"订单同步"理解成了一个功能开关，而它实际上是一条有多个环节的链路。链路里任何一段断掉，最终表现都是同一个症状，漏单、超卖、重复发货。症状相同，病因完全不同，处理方式也完全不同。
我把这条链路拆成七段：店铺授权 → 拉取订单 → 归集去重 → 分配仓库与物流 → 库存扣减 → 状态与运单号回传 → 对账。这七段里，只有第二段和第五段是真正意义上的"同步"，其余五段都是配套动作，但它们全都可能导致最终结果出错。
很多团队只盯着第二段，因为那是 ERP 演示时最直观的部分，点一下"同步"，订单列表就刷出来了。演示环境里订单少、店铺少、没有退款、没有拆单，看起来一切顺滑。真实环境不是这样。
这是我这些年最核心的一个判断。很多人以为多店经营的难点是"订单太多"，其实订单多只是量的问题，加人加钱能扛。真正的难点是异构，不同平台的订单号规则不同、状态机不同、取消和退款的时间窗口不同、地址修改能否同步不同、API 的拉取方式和限流策略也不同。
店铺越多，这些差异的组合数增长得越快。两家店是两条规则，五家店可能是三套规则交叉，十家店再加上多平台，你面对的就是一个需要专门管理的"规则矩阵"，而不是一句"都绑进 ERP 就行"。
选型的时候，绝大多数人看的是功能表：支持多少个平台、能不能打面单、能不能做采购单。这些当然要看，但决定你日常心情的其实是另一件事，出问题的时候，你能不能看到问题出在哪。
同步失败的原因会不会提示？是授权过期、限流、字段缺失还是平台侧异常？能不能一键重试？能不能补拉指定时间段的订单？失败记录保留多久？这些问题在签合同前问清楚，和在凌晨两点发现漏了八十单之后再去问，成本差着十倍。
功能可以演示，速度可以吹，界面可以好看，但账对不上就是对不上。我这里说的对账不是财务口径的利润核算，而是一个非常朴素的比对：平台后台的订单数、ERP 里的订单数、仓库实际出库数，这三个数能不能对上。对不上，差异能不能追溯到具体单据。
能对上，说明链路是通的；对不上但能追溯到单据，说明链路可管控；对不上也追不到，说明你在靠运气做生意。
下面三个现场都是我亲身处理的，不是"有个卖家朋友"这种模糊案例。我会把当时的排查过程和最终原因一起写出来，因为排查过程本身才是可复用的部分。
这家公司当时经营 6 个店铺，分属两个平台。大促第二天早上，运营发现平台后台有 3 笔订单状态是"待发货"，但 ERP 的订单列表里没有。更麻烦的是，这三笔订单分布在两家不同的店铺，看起来像是随机事件。
我先做了两件事：一是拉这三笔订单的付款时间，二是看 ERP 的同步状态页。付款时间集中在凌晨 1 点到 3 点之间，同步状态页显示这段时间有一次"授权失效"的提示，但提示只是灰字，既没有颜色区分，也没有任何通知。
进一步排查发现，其中一家店铺的授权令牌在凌晨过期，ERP 停止了拉单，但界面不会自动弹窗，运营早上打开系统时看到的是"昨天的订单都在"，自然就以为一切正常。这是一个典型的静默故障：系统知道自己断了，但没人被告知。
处理方式很朴素：重新授权，补拉这段时间的订单，手动补发。真正需要改的是机制，我们在排查后加了两条规则，每天早上 9 点和下午 3 点各看一次同步状态页，同时要求服务商把授权失效改成站内信加邮件双通知。
这个案例发生在共享库存的场景。同一个仓库里的同一批货，同时供给三个店铺。某天下午，两个店铺几乎同时成交了最后一件商品，两边都显示"库存充足"。
仓库同事拿到的拣货单上只有一条记录，另一条在 ERP 里状态卡着。客户投诉之后，我们才发现问题不在同步速度，而在扣减时点：A 店铺的库存是在"下单未付款"时就锁定的，B 店铺是"付款后"才扣减的。两套规则并存，中间就有了一个可以被穿过的窗口。
这件事让我明白一个道理：超卖很少是"ERP 不会同步"造成的，更多是"规则本身留了缝"。同步速度再快，也堵不住规则上的缝。
第三个现场损失最大。客户下单后申请取消，客服在平台后台点了同意退款。但仓库的拣货流程已经开始，货当天下午发出，客户收到货之后再投诉一次。
排查后确认，这个 ERP 的订单同步默认只做正向，取消和退款状态需要单独配置才回传，而且回传有延迟窗口。客服以为"操作完了就结束了"，仓库以为"ERP 里有单就要发"，两边都没错，错在中间那条回传路径没人负责。
逆向流程是订单同步里最容易被漏掉、也最容易造成实损的一段。正向同步做得好只是及格，逆向同步做了才算完整。
把三个现场放在一起看，会发现一个共同点：单店经营时，这些缝基本不会暴露。一个店只有一套规则、一个授权、一个库存池、一个客服流程，链条短、责任人清晰，出问题当场就能被发现。
多店之后，授权多了、规则混了、库存池共享了、客服和仓库的职责边界模糊了。故障不再以"报错"的形式出现，而是以"没人发现"的形式存在。
排查了几十次之后，我把团队里反复出现的错误认知整理成六条。这些误区最危险的地方不是它们错，而是它们看起来都对。
这是最普遍的误解。很多平台的订单并不是主动"推"给你的系统，而是你的系统按一定频率去"拉"。这意味着两件事：第一，存在固有的时间差；第二，单量突增时，拉取会排队。
所以当你在平台上看到订单、在 ERP 里看不到时，先别急着骂系统，先看时间差是否在正常范围内。真正的问题信号不是"有延迟"，而是延迟在持续扩大且没有收敛。
从操作层面看确实如此，点几下就绑好了。但绑定只是第一步。绑完之后你需要确认的是：这些店铺的订单进的是同一个池子还是分开的池子？库存是共享还是独立？客服看到的是一个混合列表还是按店分组？发货规则用的是哪一套？
如果这些问题你答不上来，说明你的多店只是"绑在一起"，没有"管在一起"。这两者的差别，在大促当天会被放大到无法忽视。
看到订单只说明拉单成功了，不说明后面五段都通了。我见过 ERP 里订单整整齐齐，但运单号没回传到平台，结果平台判定超时未发货，店铺被扣分。也见过 ERP 里订单和库存都正常，但仓库的拣货单没生成。
判断同步是否正常，要看链路的末端，不看链路的中间。末端是什么？是平台上的状态、客户收到的货、以及你的账。
前面已经说过，超卖的直接原因通常是扣减时点不一致或共享库存规则不统一，同步延迟只是放大器。举个具体例子：如果所有店铺都设为"付款后扣减"，那么两笔订单在付款顺序上是有先后的，第二个付款的会看到库存不足；但如果其中一个店铺设成"下单即锁"，它在付款前就已经占用了库存，两个店就可能同时"看到"有货。
所以排查超卖，第一步不是查同步日志，是查各店铺的库存扣减规则是否一致。
这两件事很容易被混为一谈。库存同步指的是"把可用数量告诉各个渠道"，库存扣减指的是"在什么时点把这个数量减掉"。前者管的是信息一致，后者管的是占用顺序。
只做同步不做扣减管理，等于告诉大家"仓库里还有 10 件"，然后十个人同时下单，最后只有一个能拿到货。多店共享库存的场景下，这个风险是成倍放大的。
API 是一条活的通道，不是一根焊死的管子。平台会调整接口版本、调整字段、调整限流策略；商家会改密码、开二次验证、换管理员；服务商那边也可能做灰度发布。任何一个变动都可能让通道变窄甚至中断。
所以真正的关键不是"接了 API"，而是"API 断了之后，多快能知道、多快能恢复"。这就回到可观测性上。
这是全文的核心部分。我用统一的小结构来写每个断点：先讲现象，再讲为什么会发生，然后给你一个自己能做的验证动作，最后给你一个该问服务商的问题。这套四段式你可以在自己的团队里直接用。
（1）现象。订单列表看起来正常，但最新订单停在了某个时间点。没有红色报错，没有弹窗，运营打开系统看到的是"昨天数据都在"的假象。
（2）为什么会发生。平台授权是有有效期的，会过期、会因改密码失效、会因开启二次验证被重置、也会因为长期未操作被平台回收。多店经营时，店铺越多，这些触发点的数量就越多，而它们分散在不同时间，很难靠人记住。
（3）你怎么验证。打开系统的同步状态页或者店铺授权页，看每个店铺的授权状态和最近一次成功拉单时间。如果某个店铺的"最近成功时间"明显落后于其他店铺，那就是断点。建议把这个动作固定成每天上班第一件事和下午三点各一次。
（4）问服务商的问题。授权失效时你们怎么通知我？只有站内提示还是会发邮件或短信？重新授权后能不能自动补拉失效期间的订单？能补拉多长时间范围内的？
（1）现象。日常一切正常，大促一开始，订单延迟从几分钟变成几十分钟，甚至出现整段订单漏拉。恢复之后一部分订单出现了，另一部分始终没出现。
（2）为什么会发生。大多数 ERP 采用定时轮询的方式拉取订单，平台侧对调用频率有约束。当订单量在短时间内暴涨，或者你在同一时间接入了更多店铺，拉取任务就会排队。排队本身不可怕，可怕的是没有优先级策略，导致新订单和老订单混在一起排。
这里给一段简化的轮询逻辑示意，方便理解排队是怎么形成的：
// 简化的订单拉取轮询示意（非真实 SDK 代码）
for (const shop of authorizedShops) {
const cursor = getLastSyncCursor(shop); // 上次拉到的位置
while (true) {
const resp = pullOrders(shop, cursor); // 按平台限流调用
if (resp.rateLimited) {
enqueueRetry(shop, cursor); // 被限流 → 进入重试队列
break; // 关键：是否让出给其他店铺
}
saveOrders(resp.orders);
cursor = resp.nextCursor;
if (!resp.hasMore) break;
}
}
// 判断点：被限流后是"整体等待"还是"让出执行其他店铺"，
// 决定了单店拥堵会不会拖垮所有店铺。（3）你怎么验证。找一次小范围的单量波峰（比如一次站内活动），观察同步延迟是平稳上升后回落，还是持续累积不收敛。前者是正常的排队，后者说明拉取能力已经不够。
（4）问服务商的问题。拉单频率是多少？被限流之后是排队等待还是丢弃？大促期间有没有扩容或优先级策略？补拉能力能覆盖多长时间区间？
（1）现象。同一个客户在两个店各下了一单，仓库发了两单但只登记了一单；或者一次拉取失败重试后，同一笔订单被写入了两次，仓库照着发了两遍。
（2）为什么会发生。不同平台的订单号规则不一致，有的是纯数字，有的带前缀，有的在同一平台不同站点之间会重复。当 ERP 用"订单号"作为唯一键来去重时，跨平台就可能撞号；当重试机制没有做好幂等时，同一笔订单就可能被写两次。
这类错误的特点是不报错、不告警，只有在对账或者客户投诉时才暴露，排查起来最费时间。
（3）你怎么验证。最简单的办法是抽一天做三数比对：平台后台当天订单数、ERP 当天订单数、仓库当天实际出库数。三个数字应该一致，差异应该能对应到具体单据。
（4）问服务商的问题。多平台订单的去重键是什么？重试是否幂等？合并订单和拆单怎么处理？订单来源店铺能不能在列表里直接看到并筛选？
（1）现象。两个店铺几乎同时卖掉最后一件；或者某个店铺显示有货，点进去却不能下单；或者活动结束后发现账实不符，实际库存比系统少。
（2）为什么会发生。核心是扣减时点不统一。常见的有三种时点：下单即锁、付款后扣、发货后扣。三种规则各有适用场景，但一旦在多店之间混用，就会出现"两个店同时看到有货"的窗口。
（3）你怎么验证。做一次刻意压测：准备一件库存为 1 的商品，在两个店铺同时下单，看系统是拦下其中一单，还是两单都通过。这个测试成本极低，但能直接暴露规则漏洞。
（4）问服务商的问题。共享库存池是否支持？扣减时点是否可按店铺或按商品配置？超卖发生时有没有预警？账实差异能不能按 SKU 追溯？
（1）现象。货已经发了，平台还显示"待发货"；客户申请退款已通过，仓库还在拣货；客户改了收货地址，面单还是旧地址。
（2）为什么会发生。正向流程大家都重视，因为直接关系到发货时效；逆向流程（取消、退款、部分退款、改地址、换货）往往需要单独配置才启用。很多 ERP 默认只做正向同步，逆向你得自己开。
（3）你怎么验证。找一个测试订单，走一遍完整逆向流程：申请取消 → 同意退款 → 看 ERP 里的订单状态有没有变 → 看仓库队列里的单据有没有被拦截。整个测试大概十分钟，但能省掉很多客诉。
（4）问服务商的问题。逆向流程默认开启还是需要配置？回传延迟大概多久？退款到账但订单已发货的情况怎么处理？部分退款和改地址是否支持？
（1）现象。月末核算时发现实际出库数和系统订单数对不上，但说不清差在哪一天、哪一个店、哪一笔单。
（2）为什么会发生。因为前面五段的问题都会在这里结算。如果系统没有按日、按店、按平台拆分对账的能力，你只能看到总数差异，无法定位原因，也就无法改进。
（3）你怎么验证。随便挑一个过去的日期，要求系统输出当天的"平台订单数 / ERP 订单数 / 实际出库数"三个数以及差异明细。如果拿不出来，这就是你需要补的能力。
（4）问服务商的问题。对账报表能不能按日、按店、按平台拆？差异明细能不能下钻到单据？数据保留多久？断约之后历史数据能不能导出？
讲了这么多判断，我需要给一点具体的、可复现的数据，否则就变成了经验之谈。下面是我自己做的半年对账复盘，方法很简单，但结果比较说明问题。
我选了每周的周三作为对账日，抽取前一天的数据，比对三个数：平台后台订单数、ERP 订单数、仓库实际出库数。差异全部记录在案，标注可能原因。半年下来一共积累了 26 组样本。
这个方法的好处是成本低，每次大概十五分钟，而且不需要任何额外工具，只要平台后台、ERP 报表和仓库的出库记录三方都能导出就行。
26 组样本里，有 17 组三个数字完全一致；7 组出现差异但能追溯到具体单据；2 组出现差异且无法定位，后来通过补拉订单和人工核对解决。
在有差异的 9 组里，归因分布是这样的：授权问题 3 次、归集去重问题 3 次、逆向流程问题 2 次、平台侧异常 1 次。这个分布和前面对断点的判断基本吻合。
因为这半年里，每一次超卖和漏发的最终暴露，都是通过三数比对发现的，而不是通过系统告警。反过来，当我后来把告警和对账都建立起来之后，发现问题的平均时间从"客户投诉后"提前到了"当天下午"。
再往后，我在给团队做工具选型评估时，第一轮就会问一个问题：能不能按日按店导出这三个数。能，就进下一轮；不能，功能再多也先放一放。
后来我在做多店管理工具对比时，比较系统地用过数跨境（官网：https://shukuajing.jiushuyun.com/?utm_source=seo&utm;_plan=est&utm;_unit=gys）。这里我只讲和订单同步链路直接相关的部分，不做整体推荐。
（1）多店铺订单归集。它把多个店铺的订单放在一个列表里管理，同时保留店铺维度的筛选。这一点对我前面讲的断点三很关键，多店最容易出的问题就是"订单混在一起、来源说不清"，而过滤维度能不能按店铺、按平台、按状态拆，直接决定排查速度。
（2）库存与订单的联动。因为多店共享库存导致的超卖是高频问题，所以我在试用时会重点关注两件事：可用库存的更新是否及时，以及不同店铺之间是不是共用同一个可用量口径。如果两个店铺各自维护一套可用量，那前面提到的"规则缝隙"就会存在。
（3）对账与差异追溯。这是我最看重的一段。工具能不能按时间区间导出订单层面的明细，能不能和实际出库做比对，决定了你在月末是"看总数发愁"还是"点开明细定位"。我这半年最深的体会就是，可追溯性比同步速度重要得多。
需要说清楚的是，任何工具的能力都会随版本迭代变化，具体支持的平台范围、字段口径、报表维度，请以官方渠道最新说明为准，不要拿我这篇的具体描述当合同依据。
前面讲的是通用逻辑，但不同规模的团队，优先级完全不同。我按店铺数分三档给建议，你可以直接对照自己的情况。
这个阶段最容易犯的错是过早追求功能齐全，结果买了一堆用不上的模块，还把流程搞复杂了。我的建议是先把最基础的三件事做扎实。
这个阶段不建议自研，也不建议上太重的系统。工具的核心价值是"让你知道发生了什么"，而不是"让流程看起来高级"。
这个阶段是故障高发区，因为量还没大到必须制度化，但已经完全超出人盯的极限。建议做四件事。
到了这个规模，问题从"排查"变成"治理"。你需要的不只是工具，还有规则文档和对账机制。
关于多店铺操作环境的问题，我要特别提醒一句：不同平台对多店经营的环境判定规则不一致，具体标准、触发条件和处理方式，请务必以各平台官方最新政策为准。我在文中不会给"同一环境必然如何"这类绝对结论，因为这类规则变化频繁，凭经验下判断是有风险的。
选型和治理本质上都是取舍。下面四组取舍是我在实际决策中最常遇到的，我把判断逻辑写出来，你可以对照自己的情况调整权重。
自研的唯一优势是贴合自己的流程，代价是要自己承担平台接口变更的维护工作。这一点常被低估，平台改一次接口版本，你就得排期改一次代码，而这件事是持续发生的。
我的判断标准是：如果你有稳定的研发资源并且愿意长期投入在"维护"而不是"新增功能"上，自研可以考虑；如果研发资源是临时的或者要跟着业务需求来回切换，用现成工具更稳。对绝大多数中小卖家来说，把精力放在选品和运营上的回报，远高于自研一套订单中台。
功能表是给采购看的，可观测性是给每天用的人看的。如果只能选一个，我选可观测性。
理由很实际：功能缺一个，你可以用人工补；看不到问题出在哪，你连补的机会都没有。我见过功能列表密密麻麻的系统，出问题时只有一个"同步失败"的提示，连失败原因都不显示，这种系统在实际使用中的痛苦程度，远超功能少但日志清晰的系统。
订单类工具的计费方式通常是按订单量、按店铺数、按坐席数中的一种或几种组合。低标价往往意味着某个维度有限额，超出后按阶梯收费。所以在对比价格时，我建议你算三个数：当前月成本、预期翻倍后的月成本、以及断约时的数据导出成本。
第三个最容易被忽略。断约后能不能导出全部历史订单和客户数据，导出格式能不能用，这些在签约前都要问清楚。数据可携带性本身就是一项议价能力。
统一管理的好处是效率高、口径一致、对账简单；隔离运营的好处是风险不互相传导。这两者不是非此即彼，多数团队的实际做法是"库存和订单统一，账号和环境隔离"。
我的建议是：把"数据统一"和"操作环境"当成两个独立维度分别决策，不要因为要统一数据就把所有操作挤在同一个环境里，也不要因为要隔离环境就把数据切成互不相通的孤岛。
下面这张清单是我在团队里实际执行的版本，按频率分组。你可以直接拿去用，也可以根据自己店铺数调整频率。
| 检查项 | 判断标准 | 责任人 |
|---|---|---|
| 各店铺授权状态 | 全部为"正常"，且最近成功拉单时间在合理区间内 | 运营 |
| 同步失败记录 | 当日失败次数为 0；若有失败，需确认是否已重试成功 | 运营 |
| 平台"待发货"与 ERP 订单比对 | 平台待发货订单在 ERP 中均能找到对应记录 | 运营 |
| 运单号回传情况 | 当日已发货订单的运单号均已回传成功 | 仓库 |
| 检查项 | 判断标准 | 责任人 |
|---|---|---|
| 三数比对 | 抽取一天数据，平台订单数、ERP 订单数、实际出库数三个数一致或差异可追溯 | 运营主管 |
| 逆向流程抽检 | 随机抽一笔退款或取消订单，确认状态已回传且仓库已拦截 | 客服 |
| 库存口径核对 | 各店铺可用库存与仓库实际库存的差异在可解释范围内 | 仓库主管 |
把这七个问题的答案写在合同附件或者邮件里，比任何口头承诺都有用。我见过太多团队在续约时才想起来问数据导出，那时候议价空间已经很小了。
回到最开始那个早上：3 单漏发、2 单多发，我当时的第一个念头是换 ERP。但如果那天我真的换了，三个月后同样的问题还会以另一个形态出现，因为断点不在工具里，在流程里没有人对某一段负责。
我对这件事最独特的判断是：订单同步的质量，最终取决于你能不能把"链路上每一段谁负责、多久检查一次、断了怎么升级"写清楚。工具解决的是能力和效率，机制解决的是责任和持续性。只换工具不改机制，等于换了个更漂亮的仪表盘，但没人看仪表盘。
另外一个可能和主流说法不太一样的观点：很多人把"同步速度"当成核心指标，我认为它不是。速度是体验指标，可追溯性才是生存指标。同步慢五分钟客户可能察觉不到，但漏了八十单且说不清差在哪，这个月你就白干了。所以我在任何一次选型里，都会把"出问题能不能定位"排在"平时有多快"前面。
如果你读到这里想立刻做点什么，我建议就做三件事，不用做更多。
第一件，今天就打开你的 ERP，把所有店铺的授权状态和最近成功拉单时间截个图存下来。明天同一时间再截一次，两次对比就能看出哪个店铺在悄悄掉队。
第二件，这周挑一天，做一次三数比对。不会花超过二十分钟，但你会第一次知道自己账上到底有没有差异。
第三件，把上面那七个问题发给你的 ERP 服务商，看他们多久回复、回复得有多具体。回复的速度和具体程度，本身就是一次免费的服务能力实测。
这三件事做完，你对自己订单链路的了解程度，大概会超过读十篇 ERP 推荐文章。剩下的，就是把你发现的东西变成规则，然后让规则替你值班。
我手上同时开着亚马逊、Shopee和TikTok Shop七八个店，每天订单加起来三四百单。运营说后台有单没发，仓库说系统里没看到，我夹在中间也不知道到底是谁的问题。看ERP的订单列表又看不出缺了哪一单，总不能一单一单去对数吧。
别用肉眼翻列表，用「三数比对」来定位：以自然日为口径，按「平台×店铺」维度分别统计三个数字，平台后台的已付款订单数、ERP里的订单数、仓库（或货代）实际出库单数。三个数相等说明链路是通的；如果平台数大于ERP数，问题在拉单或归集去重环节；如果ERP数大于出库数，问题在仓库分配或状态回传环节。
差异不要只看总数，要导出订单号做差集，把差异单据的具体订单号列出来，再拿这个订单号去查ERP的同步日志，看是没拉到、拉到了没建单，还是建单了没推仓库。建议把这个比对固定成每周一次的例行动作，大促期间改成每天一次，并且由固定的人负责，否则一忙就没人做，问题会一直积压到买家投诉才暴露。
我遇到过好几次，早上看ERP订单数还是零，以为是没出单，结果进平台后台一看有二十多单。问客服说让重新授权，但我不确定下次还会不会这样，也不知道怎么提前发现。
先看同步状态页，再看日志的错误信息，这一步能区分八成情况。如果是授权或令牌类问题，通常在ERP的店铺管理或授权状态里会显示「已失效」「需重新授权」，同步日志里对应的是鉴权失败、token过期一类的报错；如果是限流，日志会显示请求频率超限或排队中；
如果是平台侧接口异常，往往多个店铺同时挂掉而不是单个店铺。判断依据是「影响范围」：只挂一个店，先怀疑这个店的授权；所有店一起挂，先怀疑平台接口或ERP服务端。可执行的做法是：把授权有效期和失败告警做成常开项，让系统在同步中断时主动推消息给你，而不是靠人每天去翻页面。
另外要提前确认一件事，重新授权之后，中断期间的历史订单能不能自动补拉，还是需要手动触发补单，这个直接决定了你损失的是几分钟还是半天。具体各平台的授权有效期和重授权规则，以平台官方最新说明为准。
我三个店卖同一款货，总共就剩五十件。明明每天都看库存，还是出现两个店同时卖出去同一件货的情况，最后只能跟买家解释退款。我怀疑是ERP同步有延迟，但又不知道该怎么改。
超卖的根因往往不是同步延迟，延迟只是放大器，真正的开关是「库存扣减时点」和「共享库存的池子怎么划」。常见三种扣减时点：下单即扣、付款后扣、发货时扣。下单即扣最保守，能最大程度防超卖，但会产生大量未付款占用库存，导致实际能卖的量变少；发货时扣最激进，可用库存看着最多，但多店并发时几乎必然超卖。
多店共享库存的场景，建议用「下单即扣+超时未付自动释放」的组合，并且明确释放的时间阈值。验证方法很直接：挑一个低销量SKU，人为把可售库存设成1件，然后两个店同时下单，看第二单是被拦截、被超卖，还是被排队，跑一次你就知道规则到底有没有生效，别只看服务商的功能说明。
另外要注意平台侧和ERP侧的库存谁是主数据，两边都可以改库存的话，冲突时以谁为准必须提前定死。
我们公司准备上ERP，销售演示的时候订单同步看着很顺畅，功能列表也很长。但我之前被别的系统坑过，上线后才发现出了问题是找不到人的那种。我想在签约前把关键问题问清楚，又怕自己问得不够专业被绕过去。
把问题分成五类去问，并且要求对方给书面答复而不是口头承诺。第一类，异常如何通知：同步失败会不会主动告警，通过什么渠道，多久之内通知。第二类，补救能力：中断期间的订单能不能自动补拉，能不能手动补单，补单会不会造成重复发货。
第三类，可观测性：出了错我能看到什么级别的日志，是只有「同步失败」四个字，还是能看到具体订单号和错误原因。第四类，计费口径：按订单量、店铺数还是坐席计费，超出部分怎么算，大促单量翻三倍时费用怎么变，这一点最容易被低估。第五类，退出成本：断约之后历史订单、库存、对账数据能不能完整导出，导出格式是什么。
另外顺带问一句大促期间拉单频率有没有调整预案。判断依据很简单，凡是回答含糊、只肯口头说「没问题」的，上线后大概率就是你要自己扛的那部分。涉及具体价格、SLA和服务承诺，一定要以合同条款和官方最新说明为准。
读者评论
做过多店运营的应该有同感：漏单和超卖真不一定是ERP不行，更多是授权失效、限流和库存扣减时点不一致。文章把订单同步拆成链路这点很实用，尤其是“每天定时看同步状态页”和“授权失效要双通知”，都是低成本但能救命的动作。
从选型角度看，可观测性确实比功能表更值钱。能不能看到失败原因、一键重试、补拉指定时段订单、失败记录留多久，这些不问清楚，大促凌晨出问题就只能干着急。功能可以演示，但排障能力才是日常安全感。
逆向流程最容易被忽略。取消、退款、改地址如果没回传，仓库仍按正向订单发货，损失就是实打实的。另外店铺超过6家后靠人盯已经不够，必须上告警和对账，否则漏单和超卖会互相掩盖。