经营分析
Ozon 多店铺怎么管?集中处理的三个要点
两三个店的时候手工切换还能应付。到七八个店,光是每天挨个登录后台看有没有新订单,就要花掉一小时——而这一小时里你什么都没产出,纯粹是在切换上下文。
更实际的风险是漏。各店的发货时效不同,分开看很难判断先处理哪个;某个店的 API Key 悄悄失效了,可能一周后才发现。店铺数量增长带来的不是线性的工作量增加,而是出错概率的上升。
这篇讲清多店集中管理必须处理好的三件事:订单怎么归集、库存为什么不能共享、以及数据口径为什么必须统一。
订单要按时效归集,不是按店铺分组
这是多店管理里最反直觉的一条。很多人的习惯是「先把 A 店的处理完,再处理 B 店」,因为这样切换成本低。但发货时效是按订单算的,不是按店铺算的。
正确做法是把所有店的订单放进同一个列表,按「须发货时间」排序处理。B 店的一个急单可能比 A 店所有单都紧急,按店分组就必然会漏。
面单可以跨店合并打印
批量打印时系统会自动按店铺正确归属,合并成一个 PDF。这样处理顺序按时效走,打印动作还是一次完成,不用来回切换。
库存是各店独立的
Ozon 每个店铺的库存独立存储,即使你在多个店卖同一款货,也要分别写。系统之间不会自动分配。
这带来一个实际问题:如果你的实物库存是共用的(仓库里就那么多货),而三个店各自显示有 10 件可售,理论上可能被卖掉 30 件。超卖之后要么赔付要么取消订单,两个都伤店铺指标。
- 按比例分配 —— 把实物库存按各店的出单速度分配,留一定安全余量。
- 集中在一个店 —— 主力店挂全部库存,其他店只挂少量。适合各店定位不同的情况。
- 动态调整 —— 每次补货后重新分配,而不是一次分完不管。
多店的 API Key 不能共用
每个 Ozon 店铺有自己的 Client-Id 和 API Key,这是身份凭证,技术上也无法混用。
更要注意的是:请求配额按账号算。同一个 Key 被多个工具使用时,配额会互相挤占,表现是所有 API 操作同时开始失败(报 429)。所以每个店的 Key 只给一处用,不要既配在我们这里、又配给别的系统。
怎么快速发现某个店出了问题
店多了之后,不能靠「感觉哪个店不对劲」。看几个可以横向对比的指标:
- 待发货积压数 —— 某个店突然堆积,通常是备货或人手问题。
- 超期风险单数 —— 临近截止还没处理的,这是最紧急的信号。
- 同步失败次数 —— 某个店持续失败,多半是 API Key 失效或权限变更。这类问题不看指标很难发现,可能坏了很久都没人知道。
同步长期失败是沉默的
同步失败不会弹窗提醒你,订单也不会消失,只是不再更新。表现是「这个店最近好像没什么单」——而实际是数据根本没同步进来。
用熊掌ERP 试试这个功能
一个工作台完成 Ozon 采集、采购、发货,支持最多 20 个店铺,提供 ¥0 免费体验版。
其他常见问题
正文没有覆盖到的零碎疑问,集中放在这里。
多店订单能一起处理吗?
可以集中到一个列表里按发货时效排序,跨店批量打印面单。关键是面单要按店铺正确归属,不能混——所以合并打印时要确认系统会自动分组。
多店的库存是共享的吗?
不是。每个 Ozon 店铺的库存是独立的,即使卖同一款货也要分别写。如果你的实物库存是共用的,要自己控制分配,避免超卖。
多店的 API Key 能共用吗?
不能,每个店铺有自己的 Client-Id 和 API Key。而且请求配额是按账号算的,同一个 Key 被多处使用会互相挤占,导致限流。
怎么快速看出哪个店有问题?
看几个关键指标的横向对比:待发货积压数、超期风险单数、同步失败次数。某个店突然异常,通常是 API Key 或库存出了问题。