去年旺季，一个做东南亚市场的卖家把后台截图发给我：同一个 SKU 在 Shopee、Lazada、TikTok Shop 三个店铺同时开卖，实际可售库存只有 20 件。大促开场 11 分钟，三个店铺累计成交 37 单。ERP 没有报错，仓库里没有货，客服那边已经炸了。
他的第一反应是"这套 ERP 不行，要换"。但排查完发现，问题不在 ERP 有没有库存模块，而在于三个店铺被配成了同一个共享可售池、平台侧锁单机制没有真正生效、退款回补库存在队列里排了 6 分钟。换任何一套系统，只要配置方式不变，同样会超卖。
这正是《erp跨境电商选择标准：库存管理维度如何评估店群管理》这个题目里最容易被写偏的地方。大多数选型文章在比"对接了多少平台""有没有库存模块""是不是免费"，而店群卖家真正需要的，是一套能判断"这套系统能不能管住我这盘库存关系"的评估框架。功能清单会告诉你它能做什么，库存关系治理能力才决定它在你的业务结构里会不会出事。
我过去几年陪跑过十几家从 3 个店铺做到 50 个店铺的跨境团队做选型，也在大促夜里被叫起来处理过负库存。这篇文章不写推荐榜单，只写我在真实场景里验证过的东西：评估维度、测试方法、判断阈值，以及每种选择背后的代价。
我见过太多选型会议卡在一个问题上："你们家有没有库存管理？"这个问题几乎一定会得到"有"的答案，因为库存模块是跨境电商 ERP 的标配，没有的早就被淘汰了。但"有"和"能管住"之间，隔着一整条链路。
打个比方：库存模块相当于给你一把锁，库存关系治理相当于问你，这把锁要装在几道门上，谁能拿到钥匙，钥匙丢了怎么补，门被撬了有没有记录。店群卖家的麻烦从来不在"有没有锁"，而在"门太多、钥匙太杂、出事找不到人"。
所以我在任何一次选型沟通里，都会把问题换一种问法：这套系统能不能同时支持我的店铺 A 和店铺 B 共享库存、店铺 C 独立库存、店铺 D 只做合并看数不参与分配，并且让每一次库存变更都能追到人？能把这句话回答清楚的系统，才值得进入 POC。
在打开任何 ERP 官网之前，我建议先把下面三个问题写在纸上。回答不出来，说明你的业务结构还没梳理清楚，这时候看任何系统都会觉得"都差不多"。
店群 ERP 的库存管理评估，必须从"功能有没有"转向"关系管不管得住"，评估方式必须从"看介绍"转向"做压测"。凡是不能做 POC、不允许你用自己真实 SKU 跑一轮大促场景的候选系统，无论宣传多好，都建议直接放到备选池底部。
很多文章把"店群"简单等同于"多开店铺"，这是最省事也最误导的定义。实际业务里，店群是四个维度的同时放大，任何一个维度增加，库存的计算复杂度都不是线性增长，而是乘法级增长。
这是我认为整套评估框架里最关键的一块拼图。很多卖家在选型时只问"能不能多店铺共享库存"，但真正需要区分的是四种完全不同的关系，它们对应不同的风险和收益。
| 库存关系 | 典型配置 | 主要收益 | 主要风险 |
|---|---|---|---|
| 共享库存池 | 同仓同主体的 3-10 个店铺共用一个可售数 | 周转最快，不容易出现"这家断货那家压货" | 任一路径延迟会同时放大到全部店铺，超卖波及面最大 |
| 独立库存 | 每个店铺单独持有分配额度 | 事故被限制在单店，责任清晰 | 容易出现结构性缺货与结构性压货，整体周转率下降 |
| 合并视图 | 物理库存隔离，报表层做总量合并 | 老板能看到全局库存水位，便于补货决策 | 人工按合并数下调分配时容易高估可售量 |
| 跨仓调拨 | 调拨单在途库存参与可售判断 | 缩短缺货窗口，提升在途资金效率 | 在途未收货就被卖出，是最常见的超卖来源 |
我的一般建议是：同主体、同仓库、同物流时效的店铺可以共享；跨主体、跨仓库、跨物流时效的店铺必须隔离。但这不是一刀切，而是一个需要在系统里可配置、可分组、可随时调整的能力。如果一个系统只支持"全部共享"或"全部独立"两种极端，它就不适合真正意义上的店群。
库存关系配置错了，最终会以三种方式爆出来，而它们对生意的伤害路径完全不同。
超卖伤害的是平台侧信誉。轻则订单取消、绩效扣分，重则限制活动报名。它的特点是爆发快、修复慢，一个晚上的差评可能需要三个月的新品评价去覆盖。
负库存伤害的是履约链条。系统显示 -8 件，仓库没货，采购来不及，最后演变成延迟发货。它的特点是隐蔽，往往在生成波次单或打印面单时才被发现。
对账差异伤害的是决策质量。ERP 说这个月这盘货赚了 12 万，财务算出来是 7 万，差距来自仓储费没摊、退货没回补、调拨在途没计成本。它的特点是不致命但持续，长期会让你对整盘生意失去判断力。
我把这次事故的完整链路拆成了六段。你会发现，超卖从来不是单点故障，而是一连串"刚好"叠加的结果，这也是为什么不能只靠"换一个 ERP"来解决。
"免费"是极强的决策钩子，我自己早期也踩过这个坑。当年选了一套免费 ERP，用了半年后发现：免费版限制店铺数到 5 个，第 6 个店铺要付费；批量操作有次数限制；API 调用额度在旺季第一天就用光了；工单响应是 48 小时起步。
免费不等于总成本低，它只是把成本从"订阅费"挪到了"人工费"和"机会损失"。真正的算法是：总成本 = 订阅费 + 实施与培训 + API 与插件 + 超额店铺/订单量 + 人工补位工时 + 事故损失 + 迁移成本。免费只影响第一项，后面六项一项没少，甚至因为自动化程度低而更高。
对接平台数量是最好看、也最没信息量的指标。真正决定成败的是对接深度：这个对接是否覆盖库存同步，同步是推送还是拉取，频率是多少，失败是否自动重试，重试是否幂等，限流时如何降级。
我见过同一个平台，两套 ERP 的对接效果天差地别：一套是分钟级推送 + 失败重试 + 限流排队；另一套是 15 分钟拉取一次且失败静默。后者在大促期间基本等于没有库存同步。
库存模块的功能列表通常长这样：入库、出库、调拨、盘点、库存预警。这些功能十年前就有，不是差异点。差异点在列表之外：能不能分组配置库存关系、能不能追溯每一次变更、能不能在不允许负库存时硬性拦截、能不能处理组合品和赠品的扣减逻辑。
我的判断标准很简单：把系统里所有跟库存相关的配置项截图给我看。配置项少于 15 个，基本可以判断它只适合单店铺或轻店群；配置项超过 40 个但文档混乱，说明它灵活但实施成本高，需要评估自己团队能不能吃下来。
店群最容易出的问题，其实是内部人祸。运营为了冲业绩把安全库存调低、仓管为了省事手动改库存、客服为了安抚买家承诺有货。没有权限分级和操作日志，这些动作出事之后根本追不到人。
退出成本同样被严重低估。库存数据、历史出入库流水、批次成本记录，能不能完整导出？导出格式是不是通用的？如果你的库存历史只能留在系统里，那你在商务谈判中几乎没有任何议价能力。
准确性不是"系统算得准不准"，而是"系统的口径和你的业务口径是否一致"。要核对的具体项包括：同一 SKU 在不同平台是否映射到同一个内部编码；组合品销售时子件是否按正确的倍数扣减；赠品是否占用可售库存；批次或效期商品是否按先进先出扣减；仓库之间的库存单位是否统一（件 / 箱 / 托盘）。
我建议在 POC 阶段专门做一轮"口径核验"：挑 10 个结构最复杂的 SKU（组合品、赠品、多批次、多仓），在 ERP 和平台后台各跑一遍出库，看两边扣减数量是否完全一致。差异率超过 1% 就应该视为口径未对齐。
这是我最看重、也是厂商最容易含糊其辞的一项。要问的问题应该具体到可以被验证：库存变更后多久推送到平台？推送失败后多久重试，重试几次？平台限流时是排队、降级还是直接丢弃？是否支持幂等键防止重复扣减？是否支持库存预留和锁单？
我会在 POC 里做一次小型压测：用脚本模拟 300 个并发下单请求打到同一个 SKU，观察 ERP 侧可售数变化、平台侧可售数变化、最终成交订单数三者是否一致。允许的偏差是零超卖，允许的延迟是业务可承受窗口（通常 30 秒以内）。
店群的权限设计要比单店铺复杂一个量级。至少要能区分：谁能调整可售库存、谁能跨店铺调拨、谁能看到成本价、谁能修改安全库存阈值。此外，店铺组和仓库组的配置粒度决定了你能不能实现"部分共享、部分隔离"的中间态。
操作日志必须可查询、可导出，并且记录字段要包含操作人、时间、变更前值、变更后值、变更来源（手工 / API / 系统自动）。如果日志只能看最近 7 天，那它在处理月度对账问题时的价值几乎为零。
防超卖的关键机制有三个：安全库存缓冲、库存预留、锁单。安全库存缓冲是给每个销售渠道留出一定比例的冗余；库存预留是在订单生成到支付完成之间锁住数量；锁单是支付完成后正式扣减。
三者需要组合使用。只做预留不做缓冲，会在支付失败率高的平台频繁出现"锁了又放"的抖动；只做缓冲不做预留，在并发场景下依然会超卖。判断系统是否合格的方法很简单：问它这三种机制分别在哪一层实现，是否可配置比例和超时时间。
库存的真实分布是：仓内可售 + 采购在途 + 头程在途 + 海外仓在途 + 退货在途。店群卖家最容易忽略的是后三项。采购在途能否参与可售计算，取决于供应商交期的稳定性；头程在途参与计算则风险很高，因为清关时间不可控。
我的建议是：采购在途可以有条件参与（前提是交期历史波动小于 3 天），头程在途一律不参与可售计算，只做补货提醒。退货在途要看平台政策，如果退货必须重新质检才能上架，那它就不应该算作可售。
"是否允许负库存"这个问题看起来很小，实际上决定了整套系统的风险偏好。允许负库存，业务灵活但事故隐蔽；禁止负库存，操作会被卡住但能强制暴露问题。
我通常建议：面向消费者的可售库存禁止为负；内部台账允许出现临时负数但必须触发告警。同时对以下场景要求明确的回补规则：订单取消后多久回补、退款成功后多久回补、超时未支付释放后多久回补、盘点差异确认后如何调整。
如果一套 ERP 只能告诉你"还有多少件"，不能告诉你"这批货压了多少资金、周转了多少天、每个店铺分摊了多少仓储费"，那它只是一个库存记录工具，不是管理工具。
要评估的指标包括：按店铺 / 仓库 / 主体维度核算库存成本；批次成本或移动加权平均；库存周转天数；滞销库存占比；资金占用金额。这些指标能不能出，决定了你后期能不能做精细化运营。
店群卖家通常不会只用一套系统。ERP 之外还有物流系统、财务软件、数据分析工具、BI 报表。开放 API 的完整度决定了你能把库存数据接到哪里去。
评估要点：API 是否覆盖库存读写、订单、调拨、盘点；是否有沙箱环境；调用额度是多少；超额如何计费；限流策略是什么。这些都应该在签约前问清楚，而不是上线后才发现额度不够。
我把 POC 设计成一个可以直接照做的清单。每个场景都要给出动作和验收标准，用真实或高度仿真的数据跑，不要接受厂商演示环境里的"演示账号"。
权重不是固定的。刚起步的店群，时效和成本权重更高；到了 20 个店铺以上的多主体阶段，权限、异常和成本核算的权重会快速上升。下面这组权重是我在陪跑中常用的起步基准，可以根据自己的业务结构微调。
很多人会问："晚几分钟同步能有多大事？"我把这个问题做成了一个可观察的关系：随着同步延迟变长，超卖订单率和人工核库耗时都会上升，而且不是线性上升，而是在某个点之后急剧恶化。
在选型阶段和上线之后，我遇到的最大痛点是同一个：ERP 的库存数据、平台后台的可售数据、海外仓的库存报表，三者永远对不上，而且对不上之后很难归因。在 ERP 里翻日志的效率极低，通常要拉三张表手工比对，一次排查两三个小时。
后来我把这件事拆出来，单独用一层数据分析工具来解决。以数跨境（官网：https://shukuajing.jiushuyun.com/?utm_source=seo&utm;_plan=est&utm;_unit=gys）为例，它在我这套流程里承担的不是"库存执行"的角色，而是库存数据的校验层和观察层，把 ERP 的库存快照、平台后台的可售数量、仓库的实物报表拉到同一张数据表里，按 SKU + 仓库 + 日期做差异比对，把"哪一端的数据跑偏了"直接暴露出来。
我特别想把它的定位说清楚，避免误会：这类工具不能替你在平台侧锁单，不能替你回补退款库存，也不能充当 ERP 的库存执行引擎。它的价值在于让差异可见、可归因、可追踪。这是两件不同的事，很多人混为一谈，结果既没选对 ERP，也没用好数据工具。
选型阶段，我把这层底板当成 POC 的裁判。做法是：把候选 ERP 的库存快照每天导出一次，和平台后台数据、仓库报表一起进同一个数据集，跑一个月的差异统计。谁能把差异率压到 1% 以内，谁就在数据准确性这一项拿高分。
上线之后，它变成周度巡检工具。我通常设置三个固定看板：平台可售与 ERP 可售的实时差异率、退款回补的时效分布、负库存事件的时长统计。这三张表基本能覆盖 80% 的库存异常。
还有一点实际收益：当差异出现时，我可以直接下钻到具体 SKU 和时间点，把"是平台扣减延迟"还是"ERP 重试漏扣"还是"仓库实际未入库"区分开，再去找对应的人或系统。这个归因过程从原来的一次两三个小时缩短到了二十分钟左右。
下面这段是我在做三端对账时常用的校验逻辑示意。核心思路是：以 SKU + 仓库 + 日期为唯一键，把三个来源的数据拼在一起，先算差异，再按差异方向做归因标记。用任何数据分析工具都可以实现，关键不在于工具，而在于把口径固定下来。
— 三端库存对账：ERP 快照 vs 平台可售 vs 仓库实物
— 唯一键：sku_code + warehouse_id + stat_date
SELECT
e.sku_code,
e.warehouse_id,
e.stat_date,
e.erp_available,
p.platform_available,
w.warehouse_on_hand,
(p.platform_available – e.erp_available) AS diff_platform_vs_erp,
(w.warehouse_on_hand – e.erp_available) AS diff_warehouse_vs_erp,
CASE
WHEN p.platform_available e.erp_available THEN 'ERP 扣减过度或重试漏放'
WHEN w.warehouse_on_hand 0
OR ABS(w.warehouse_on_hand – e.erp_available) > 0
ORDER BY ABS(p.platform_available – e.erp_available) DESC;
这段逻辑看着简单，但它解决了一个很实际的问题：把"库存对不上"这个模糊描述，变成了"差异在哪一端、差多少、最可能的原因是什么"这三条可执行信息。我把这段跑了半年之后，团队里负责库存的同事从"每天到处救火"变成了"每天看一次表、处理三条异常"。
下面这组数据来自我陪跑的一个从 8 个店铺扩到 22 个店铺的团队，时间跨度 5 个月，属于样本推演而非行业统计，但趋势方向在多个团队里是一致的：先说结论，对账底板的收益不是"库存变多了"，而是"差异变小了、归因变快了"。
这个阶段大部分免费或低价 ERP 其实够用，问题通常出在配置方式上。我建议按顺序做三件事：把不需要共享的店铺拆开、给每个销售渠道设安全库存缓冲、把退款回补的超时规则确认清楚。
这个阶段不需要上对账底板，用一张手工维护的日库存表就能应付。真正需要投入的是把库存关系图画出来，贴在工作群里，让运营和仓管都清楚哪个店铺和哪个店铺是共享的。我见过太多事故是因为运营根本不知道自己和隔壁店铺共用一个池子。
这个阶段是问题集中爆发的区间。跨仓调拨、多平台口径、退款回补时效、权限分级，四个问题会在同一个季度里同时找上门。我的建议是两条线并行：
这个阶段最常见的错误是"先换系统，再看效果"。没有对账底板，你无法判断换完之后是变好了还是只是问题换了个形式。
到这个规模，系统切换的代价已经很高，选型要考虑的是三到五年的适配性。评估重点应该从"功能"转向"治理"：能不能按主体隔离库存、能不能按主体核算成本、能不能支持店铺组的动态调整、数据导出是否完整。
这个阶段我建议在合同里明确写入：POC 验收标准、服务 SLA（尤其是大促期间的响应时长）、数据导出格式与频率、退出时的数据交付义务。没有退出条款的系统，本质上是在用你的数据锁定你。
我在选型沟通里从不推荐"最优解"，只讲取舍。因为库存管理这件事没有普适最优，只有和你当前阶段匹配的权衡。下面这组数字是示意基准，用来展示取舍的结构，不是市场报价。
| 方案 | 一次性投入 | 月均成本 | 能力覆盖 | 适合阶段 |
|---|---|---|---|---|
| 免费型 SaaS ERP + 人工补位 | 约 1.5 万元（培训与流程梳理） | 约 0.3 万元（人力补位为主） | 55 分（示意） | 3-5 店铺、单主体、单仓 |
| 付费型专业 ERP | 约 8 万元（实施 + 接口 + 培训） | 约 2.2 万元（订阅 + API + 服务） | 86 分（示意） | 6-50 店铺、多仓、单或多主体 |
| 付费 ERP + 数据校验层组合 | 约 11 万元（含数据层搭建） | 约 3.0 万元 | 94 分（示意） | 20 店铺以上、多主体、多国 |
共享库存池周转最快，但事故概率最高；独立库存最安全，但整体周转率会下降。我的建议是不要全局二选一，而是按渠道分层：出单稳定、退货率低的主力渠道共享；新品测试渠道、高退货率渠道独立。
配置项越多的系统，能力上限越高，但实施难度也越大。我见过一个团队买了配置能力很强的系统，结果因为没人能配明白，最后只用了最基础的功能，等于花了钱买了不用。判断标准是：你团队里有没有一个人能完整读懂它的配置文档并独立完成店铺组设计。没有的话，宁可选择配置简单但覆盖你核心场景的系统。
20 个店铺以上的团队经常会考虑自建库存中台。我的判断是：如果你的核心业务逻辑在库存分配上（例如寄售、代发、预售组合），自建确实有优势；但如果只是标准的多店铺多仓管理，自建的隐性成本（人力、迭代、离职风险）通常高于采购。而且自建系统最容易缺的恰恰是异常处理和对账这两块，它们不产生收入，但决定系统能不能长期用。
这个取舍最容易被忽略。签约时省下的钱，可能在退出时变成数据迁移的代价。我的建议是在任何合同里都争取一条：全量库存流水、出入库记录、批次成本数据，可按约定的通用格式导出，导出频率不低于每月一次。这条谈不下来，说明你对数据的控制权很有限。
下面这十二个问题可以直接拿去问任何一家候选厂商，重点不是要一个"是"，而是要一个可以被验证的具体回答。
我通常用一张打分表做横向对比，八个维度各占 1-5 分，再乘以第四节里的权重，得出加权总分。分数不是给老板看的漂亮数字，而是逼着自己在每个维度上写下具体证据。
打分的规则有三条：没有实测证据的项不能给 5 分；任何一项低于 2 分都应该触发深度追问；总分相同的情况下，优先选择同步时效和权限两项得分更高的系统。这两项后期最难点补齐，而报表类的差距通常可以通过外挂工具弥补。
系统上线不等于问题解决。我建议前三个月每周固定看四个指标：库存差异率、负库存事件数、退款回补平均时长、人工库存核对工时。这四个数字只要连续三周下降，说明配置和流程走对了；如果某个数字不降反升，通常意味着某条库存关系的配置需要重新调整。
三个月之后，把巡检频率从每周降到每两周，把精力转到补货预测和滞销清理上。库存管理的终点不是"账实相符"，而是用准确的库存数据支撑更少的资金占用和更高的周转效率。前者是手段，后者才是目的。
回到开头那个卖家。他最后没有换 ERP，而是做了三件事：把三个店铺的共享关系改成两个共享、一个隔离；给所有渠道加上 8% 的安全库存缓冲；退款回补的队列从 6 分钟压到 40 秒。第二个月大促，同样的订单量，零超卖。他后来跟我说的一句话我一直记着："原来我一直以为我要买一个更好的系统，其实我要的是一套想清楚的规则。"
我以前管十几个店铺的时候，大促当天两个平台同时出单，结果一个SKU卖超了30多件，赔了运费还被平台扣分。从那以后我选ERP就不敢只看功能列表了，但真到测试环节又不知道该怎么设计场景、看哪些指标。
别只让销售演示，自己设计三类压测动作。第一类是同SKU并发出单：把同一个SKU挂到两个以上店铺，把可售库存改为3件，用两个账号在同一分钟各下单2件，看ERP是否只放行3件、第4件是否被拦截或进入待确认。
第二类是回传延迟：直接在平台后台把某SKU库存改成0或改成50，掐表记录ERP多久更新，再反向从ERP改库存，看平台多久生效，中间隔了多少秒。第三类是异常链路：下单后立刻取消、退款、部分退款，观察库存回补的时间点和数量是否对得上。
判断口径建议这样定，日常同步延迟控制在1分钟内，大促峰值不超过5分钟；失败必须有自动重试且能查到重试记录；负库存默认应该是禁止的，要允许也只能对指定店铺组开口子；取消订单的回补时间要能问出明确秒数或分钟数。
验证周期别只测一天，连续跑7天，每天早晚各抽20个SKU，把平台后台、ERP、仓库实际库存三端对一遍，差异率超过0.5%就要求对方出书面原因和改进方案，否则不要签。
我手上有二十多个店铺、三个经营主体，还用了国内仓和海外仓各一个。之前把所有店铺的库存合成一个池子，结果财务月底对账完全分不清哪个主体占了多少货；后来全改成隔离，又出现A店压货、B店断货的情况，真是两头都难受。
不要二选一，按主体、仓库、平台规则三个维度做矩阵再定策略。主体维度：同一营业执照下的店铺可以共享库存池，不同主体必须隔离，否则成本、利润和税务口径分不开。仓库维度：同一物理仓内的货可以共享，跨仓（比如国内仓和海外仓）只能做可视化和调拨，不能直接当同一个池子扣减。
平台维度：有些平台要求店铺库存独立申报，这种店铺即使同主体也要单独设池。落地时用分层安全库存：共享池整体预留总库存的10%到15%作为缓冲，销量排名前20%的SKU单独设更高的安全库存阈值，避免一个爆款把整个池子吃空。
同时把补货触发点写清楚，比如共享池可用量低于安全库存时自动生成采购建议，而不是等运营发现断货再手工补。测的时候拿一个共享组和一个隔离组各跑两周，对比超卖次数、断货次数和资金占用，用数据决定哪类店铺进共享池。
我们团队有运营、客服、仓管、财务四拨人，之前一次盘点差异查了三天，最后发现是客服为了给客户补发手工改了库存，但系统里根本看不到是谁改的、改前是多少。现在选ERP，权限这块我特别在意，但不知道具体该问哪些点。
抓三件事：权限颗粒度、日志完整度、审计可用性。权限颗粒度要求能按角色加范围两层控制，也就是既区分运营、客服、仓管、财务，又能限定某人只能操作指定店铺组或指定仓库。至少要能把改库存、看成本价、跨店调拨、导出数据这四个动作拆开授权，客服默认不应该有成本查看权和跨店调拨权。
日志完整度看每条库存变动是否记录操作人、操作时间、变更前后数值、变更来源（手工还是API推送）、关联单号，并且普通管理员不能删除。审计可用性看能不能按SKU、按店铺、按人、按时间段导出明细，能不能和平台后台的操作记录对上。
测试方法很直接：用一个客服账号登录，尝试改库存、导出成本表、跨店调拨，看系统是否拦住；再让管理员尝试删一条历史日志，如果删得掉，这项直接判不合格。合同里把日志保留期写清楚，建议不少于12个月，跨主体经营的至少要覆盖一个完整财年，否则出问题只能吃哑巴亏。
我最开始就是被免费两个字吸引的，先用了一个免费ERP，店铺一多就发现订单量超了要付费、API调用次数也限得厉害，大促期间客服排队等半天。后来换系统又花了一笔迁移成本。现在我再看到免费，第一反应是这钱到底省在哪、后面会不会补回来。
把成本拆成六块来算，而不是只看订阅价。第一块是订阅或月费，第二块是店铺数、订单量、SKU数超出后的阶梯单价，第三块是API调用频率或调用量的限制与加价，第四块是插件和增值模块（比如海外仓对接、财务对账、BI报表），第五块是实施、培训和流程改造的人力投入，第六块是将来想换系统时的数据导出和迁移成本。
免费版本通常在这几个地方设限：可绑定店铺数量、月订单上限、API调用次数、客服响应优先级、历史数据查询范围。选型时必须问清楚超出后的具体单价和计费口径，比如订单量是按创建时间还是按发货时间统计、API是按次还是按流量计费。
还要确认三件事：数据能不能随时全量导出成通用格式、导出是否收费、停用后数据保留多久。建议按三年总成本做对比，把大促期间的响应时效单独写进服务条款，比如客服首次响应不超过多少分钟、故障恢复不超过多少小时，因为对店群来说，大促当天没人应答造成的损失，往往比一年订阅费还高。
读者评论
文章把库存问题从功能清单拉到关系治理，这点很戳人。我们五个店铺共用一个可售池，去年大促就因为平台回调延迟超卖过，后来改成同仓共享、跨仓隔离才稳住。选型时确实该先想清楚自己的库存关系，而不是先看对接了多少平台。
POC压测那段最实用。很多系统演示时数据漂亮，一上真实并发和限流就露馅，尤其是重试幂等和退款回补队列这两块，不实测根本发现不了。建议补充一下压测的具体验收阈值。
权限和退出成本被低估这点同意。我们之前换系统，历史出入库流水导不出来，对账对了一个月，商务上也很被动。库存配置项数量那个判断方法虽然粗糙，但作为初筛挺有效。