一个 SKU 五个名字：OMS 渠道商品映射的实战做法

周一早上八点，咖啡还没泡好，手机先响了。客户在群里甩了一张截图：OMS 异常订单队列里躺着 47 个单子，状态清一色"商品未匹配"。黑五刚过去三周，退货季正忙，这 47 单要是卡着发不出去，客服电话能被打爆。

我远程登进去一看，乐了——不是系统坏了，是他们上周在 TikTok Shop 新开了一家店，运营把二十多个爆款直接铺了上去，SKU 命名沿用了 TikTok 那边的习惯，跟 OMS 里建好的商品一个都对不上。订单倒是源源不断拉进来，可 OMS 不认识这些 SKU，只能一单一单扔进异常队列等人来认。

这就是多渠道生意里最常见、也最容易被低估的一件事：渠道商品映射。同一个商品，在 Amazon 上叫 AMZ-BLK-HOODIE-L，在 Walmart 上叫 WM_98213，在 Shopify 自家站上叫 HOODIE-BLK-L-2024，到了 TikTok Shop 又变成 TTS@hoodie-black-l。名字有五个，货只有一个。订单从各个渠道拉进 OMS 的那一刻，系统必须知道"这五个名字说的都是同一件东西"，不然轻则异常单堆积，重则发错货、扣错库存。

二十年干下来，我可以很肯定地说：映射表不是一张 Excel，它是整个 OMS 订单链路的地基。地基歪了，后面 WMS 发货、财务对账全跟着歪。

映射表长什么样

先说结论：映射的最小粒度不是"渠道"，是"渠道 × 店铺"。

很多公司第一版映射表只做到渠道维度——Amazon 的 SKU 对 OMS 商品，Walmart 的 SKU 对 OMS 商品。等到在 Amazon 上开了第二家店（比如主品牌店加清仓店），两个店卖同一个商品却用了不同的渠道 SKU，表就乱了。所以从第一天起，映射键就应该是三段式：渠道加店铺加渠道侧 SKU。

一张能用的映射表，核心就这几列：渠道代码、店铺编号、渠道侧 SKU 原值、渠道侧标题快照、对应的 OMS 商品编号、状态、生效时间。标题快照很多人嫌多余，我坚持要留：人工核对异常单的时候，看一眼标题就知道这单大概是什么货，比对着一串 SKU 猜快十倍。状态列也别省，渠道下架的商品把映射标成停用而不是删除——删了，历史订单就查不到当初是怎么翻译的，对账会哭。

还有三个实战里踩出来的细节。

第一，永远以渠道侧 SKU 为准，不要拿标题做匹配。标题是运营天天改的东西，今天加个"Hot Sale"，明天换个关键词，拿标题匹配等于天天重建映射。SKU 相对稳定，是渠道订单里最靠谱的锚。

第二，大小写和空格先洗一遍再比对。Shopify 传过来的 SKU 尾巴带个空格，Amazon 那边又是全大写，OMS 里建的是小写——人眼看是同一个，系统看是三个。拉单翻译之前统一转小写、去首尾空格，这行代码能消灭约三成的"假异常"。

第三，给 UPC 留一个二级匹配键。SKU 是各渠道自己起的名字，UPC 是商品的"身份证号"，跨渠道通用。新品上架时把 UPC 也录进商品主数据，遇到 SKU 对不上的，先拿 UPC 兜一圈，能救回来不少。

没对上号的订单去哪了

翻译失败的订单，正确归宿是异常队列。不是直接丢弃，更不是硬着头皮建单。

异常队列要解决三个问题：别让异常单堵住正常订单、让人能快速处理、处理完能自动归位。我的做法是：拉单程序遇到无映射的 SKU，不建 OMS 订单，只生成一条异常记录，记下渠道、店铺、渠道 SKU、标题、数量、下单时间，状态标"待认领"。正常订单一秒都不耽误，继续往下走。

人工处理每天固定两次——上午十点一次，下午四点一次，大促期间加到四次。处理就三种动作：第一种，认领，确认这个渠道 SKU 对应哪个 OMS 商品，补一条映射，这单自动重新翻译入库；第二种，合单，同一个买家在多个渠道下了单，按公司规则决定合不合并包裹；第三种，作废，测试单、恶意下单直接关掉。

这里有个血泪教训。2023 年感恩节，一家在加州 Ontario 的 3PL 客户，运营为了赶黑五提前铺货，两百多个新 SKU 没建映射就上了架。拉单程序把异常单全扔进了队列，但没人去看——大家都以为"系统会自动处理"。结果三天后队列里积了九百多单，客服已经先被买家问候了三轮。从那以后我给所有客户定的规矩是：异常队列必须有主人，大促期间每天至少看四次，队列深度超过 50 单自动发短信报警。没人看的队列，等于没有队列。

另外，组合装是个特殊情况，要单独说。一个渠道 SKU 对应 OMS 里两个商品（比如"买卫衣送袜子"的打包 SKU），映射关系是 1 比 N。拉单翻译时要拆成两行订单行，一行卫衣一行袜子，各自扣各自的库存。很多 OMS 的映射表只支持 1 比 1，选型的时候就要问清楚支不支持 1 比 N，不支持的趁早换方案，别等上线了再打补丁。

新开一个渠道，三步接进来

每开一个新渠道，映射都是从零开始。我的标准动作就三步，屡试不爽。

第一步，导全量 SKU，上架前先对表。渠道店铺建好、商品铺上去之后，第一件事不是开卖，是从渠道后台把在售 SKU 清单导出来，跟 OMS 商品主数据逐条对，生成首版映射表。对不上的，当场决定：是 OMS 里缺这个商品（新建），还是渠道 SKU 起错了（让运营改）。顺序一定是"先有映射，再开卖"，反过来就是开篇那 47 个异常单的下场。

第二步，接拉单，翻译和异常开关一起上。API 对接做完，先别全量跑，用近七天的历史订单做一次回放测试：拿真实订单走一遍翻译流程，看映射覆盖率。我的及格线是 98%——低于这个数，说明首版映射表漏了东西，回去补。回放通过了再切正式拉单，同时异常队列的报警规则配好，别等真出事了才想起来。

第三步，跑一周对账，覆盖率达标才算接完。每天核对三个数：渠道侧订单数、OMS 成功建单数、异常队列新增数，三者要对得上。第一周每天看，第二周隔天看，第三周没问题了再交给日常巡检。新渠道前两周的映射表几乎每天都要加几条，这是正常的——长尾 SKU 总有漏网的，流程跑顺了，加一条映射就是两分钟的事。

电商运营人员在仓库办公室处理多渠道订单