在五个平台刊登时怎样避免超卖

超卖是指一双你只有一件的鞋，在两个平台上都接了订单。这不是一个小的管理失误。它会迫使你取消订单，而取消会受到严厉惩罚：卖家评分受损、产生费用或罚款，在部分平台上还会暂时冻结结算。发生几次之后，你在所依赖平台上的账户信誉就会下降。

超卖会随着成功而增加。刊登越广、库存流转越快，两个买家在几分钟内抢同一件货的情况就越频繁。对手动卖家来说，问题在于结构，而不是速度。

本能的解决办法是更快：不停刷新标签页，一卖出就删掉其他刊登。这在两笔销售同一分钟到来、你睡着了，或者一次发售让你同时确认二十个订单之前都还行。

以秒计算的赛跑，盯着标签页是赢不了的。关联库存和受支持的自动清理可以降低风险。平台的时间差仍然需要对账。

防止超卖，要从怎样建模库存开始。RestocksAIO 把大多数电子表格混在一起的两件事分开：

• 库存：你拥有的每件实物一行，包含成本、尺码、成色、包装和 SKU。这是唯一可信来源。
• 商品刊登：每个平台上的每条在售刊登一行。多条刊登关联回同一件库存。

每条刊登都绑定到一件具体的自有库存。因此系统始终知道 StockX 刊登、WeTheNew 刊登和 Alias 刊登是同一双鞋，而不是三双。

自动删除之所以可行，是因为这些刊登知道自己属于同一双鞋。这个关联保存在 Controller 中。Bricker 把定价和生命周期组织成两个单位。一个 Task 为一件商品自动化一个平台。一个 Controller 把同一 SKU 和尺码的 Task 归为一组。Controller 表示“这五条刊登是同一件货”，正因如此，检测到成交后才能请求下架另外四条。

它还能防止不同类别互相冲突。Resale、Direct（StockX Buyer-Direct）和 Consign / Flex 对同一双鞋作为独立的 Controller 运行，各有自己的定价和生命周期。所以确认一笔 Resale 销售时，不会误下架你的 Consign 刊登。在这个模型下，避免超卖不再那么依赖你赢得一场赛跑。系统维护一件自有库存、一个 Controller，以及多个一起上调、下调和消失的关联 Task。关联库存让受支持的清理成为可能，但当更新延迟时，你仍需要检查销售和刊登状态。

越忙的时候，这个模型越有用。发售期间你可能几分钟内要确认二十个订单。当正在运行的自动化检测到符合条件的销售时，在受支持的关联路线上，每笔检测到的销售之后都可以发出清理请求。手动销售跟不上这个节奏。按 Controller 执行的结构不受同时到来多少笔销售的影响。

它也能处理不是通过工具完成的销售。如果一双鞋在 RestocksAIO 没有触发的地方卖出，Sync Data 会显示那条已经消失的刊登。你通过行复选框把它标记为已售，这会让 Controller 重新对齐，并阻止过时的关联刊登再接第二单。即使实际情况跑在工具前面，一次对账操作也能让这件库存回到一致状态。

所以，应对超卖的答案在于数据怎样组织，而不在于做得更快。你组织好数据，让关联刊登在成交后可以对账。

当销售处理自动化检测到一笔销售时，它可以在受支持的平台上请求下架关联的其他刊登。任务必须正在运行，刊登必须正确关联，每个已连接的账户都必须允许该操作。平台响应和销售检测延迟可能留下再接一单的空档，所以自动化能降低重复售出的风险，而不是保证零超卖。

在繁忙的发售或手动修改之后，请检查销售和关联刊登的状态。定期运行 Sync Data，需要时按住 Shift 点击执行完整刷新，并把消失的刊登对账为已售或已删除。球鞋多平台刊登流程介绍了受支持的渠道和账户限制。

超卖还有一个相关问题：本该成交的订单没有成交，因为确认太慢，买家走了。尤其在 Alias 上，买家在你确认前都可以取消，所以订单在未确认期间随时可能消失。被取消的销售还会让你手里留着已经算作卖出的库存，记录又会脱节。

Confirm Sales 同时解决这两个问题。Load Unconfirmed 把所有已连接平台的待处理订单拉到一个视图里，你不用来回切换后台。Auto-Confirm 会在你启用的网站上每五分钟自动接受一次订单。快速确认能保住这笔销售。它也让自动删除更早触发，从而更早请求清理受支持的关联刊登。

受支持的自动清理能降低实时销售中的风险。避免超卖的另一半，是让库存和商品刊登长期保持对应。当某条刊登在 RestocksAIO 没有触发的平台上卖出，或者某次手动修改被漏掉时，两者就会脱节。

两个习惯可以弥补这个空档。第一，定期运行 Sync Data。增量同步会拉取新增和消失的刊登，按住 Shift 点击则会从头完整刷新。第二，当某条刊登消失时，用行复选框把它标记为已售或已删除，让库存和商品刊登视图保持一致。如果某个 SKU 本来就在一个渠道净到手最高，用 Price Comparator 把它只分配到一个平台，就能完全避开重复售出的风险。

eBay 和你自己的 Shopify 店铺按数量销售，而不是每双鞋一条刊登。在 RestocksAIO 中，这个数量等于你关联到该商品的 Inventory 库存件数。当一件关联库存在 StockX 或 Alias 上卖出时，应用会降低 eBay 和 Shopify 上的数量。数量为 0 时，刊登会被结束或撤下。

有两个限制。应用必须处于打开状态。而且 Shopify 或 eBay 上的销售只有在下一次读取时才会被发现：Shopify 约每 10 分钟一次，eBay 约每 15 分钟一次。在这段时间内，两个买家可能都会付款。第二笔销售会进入 Review 收件箱等你决定。Marketplace tab 页面介绍了关联的工作方式。

店铺销售也会清理转售平台一侧。eBay 或 Shopify 订单成交后，这双鞋的每个 Bricker Mode 任务都会删除它在 StockX、Alias 和其他转售平台上的刊登。没有 Bricker 任务的刊登会保持在售并显示在 Review 中，除非你开启 Also delete listings without a Bricker task。寄售和 Flex 刊登永远不会被删除。当有多条刊登与售出的鞋匹配、但都没有关联到它时，应用不会删除任何刊登，并在 Review 中询问你。

能看到保护机制在运作，你才会更信任它。按事件触发的 Discord webhook 会在销售到来、关联刊登被删除的那一刻发送通知，让你实时看到机制在运作。如果某次删除失败（网络波动、平台故障），它会作为一个事件显示出来。你不会等到第二个订单到来才发现。

双向 Telegram 机器人把同样的事件发到你的手机，并让你直接处理。即使在繁忙的发售期间，你也能看到什么在卖，并在任何地方介入。系统负责请求清理，通知会告诉你发生了什么。你不再需要盯着标签页去抓重复售出。关联刊登被下架时会通知你，下架失败时也会通知你。

把每条平台刊登关联到它所代表的实物库存。在受支持的地方保持销售处理任务运行，检查清理结果，并运行 Sync Data 对账外部或延迟的变更。这能降低重复售出的风险，但无法让多个平台同时下单变得不可能。

在增加新渠道之前，请通过球鞋库存管理流程了解库存关联、从手机到桌面的入库和对账。