5つのマーケットプレイスに出品するセラーの大半は、在庫切れで死ぬのではない。5つのプラットフォームが同じ在庫を同時に売ってしまうことで死ぬ。
去年の11月にその現場を見た。知り合いのセラーは、人気の車載充電器をAmazon、Walmart、eBay、自社のShopifyストア、TikTok Shopに出品していた。インフルエンサーの動画が一晩でバズり、3,000件超の注文が押し寄せた。朝には、全プラットフォームが在庫数いっぱいに売り続けていた——もちろん、その数字はフィクションだった。返金、悪いレビュー、アカウントヘルスへのダメージ。フルコンボだ。
まさにこの状況のために、私がクライアントに渡すプレイブックがこれだ。在庫をどう分けるか、そして需要が急増したときにどう出血を止めるか。この2つの半分からなる。
プールを切る：5チャネル、5つの台帳
ルールはシンプルだ。保管はまとめて、帳簿は分けてつける。
やり方は2つある。物理的な分離は、チャネルごとに保管ロケーションを専有すること。月数万件を扱う大口セラーには有効だが、スペースを浪費し、移動が面倒になる。論理的な割り当ては、物理的には在庫を混ぜて、WMS上で仮想プールを切り分けること。安くて柔軟で、月1万件程度までのセラーにはこちらを勧める。過剰に作り込まないこと。
配分は勘ではなく、実際の売上ウェイトで決める。直近30日のチャネル別売上を取り、在庫総数をそれに応じて分ける。Amazonが売上の60％を稼いでいたら、販売可能在庫の60％をAmazonに。次に、誰のものでもない5～10％のフレックスプールを確保する。あるチャネルが急増したら、フレックスプールから振り替える。週次で見直し、勢いのある方へプールを寄せていく。
ここで皆が間違えるポイントが2つ。1つ目、AmazonのFBA倉庫に入っている在庫は、もう自分の管理下にはない。自社発送プールと混ぜず、別の台帳で管理する。2つ目、輸送中の在庫は販売可能な在庫ではない。海上の輸送中の貨物や、工場が今出荷したばかりのカートンは、表の別の行に書く。プールに入るのは、受入と格納が終わってからだ。輸送中在庫を販売可能として数えることは、私が見てきた過剰販売の原因の第2位だ。
以上はすべて、売上履歴がある前提だ。新商品は別のゲームだ。ローンチSKUは売上日数がゼロなので、30日ルールは何も生まない。私のやり方はこうだ。同じカテゴリーで最も近い既存商品のチャネルミックスを借りる。古いモバイルバッテリーが売上の70％をAmazonで稼いでいたなら、新しい充電器の最初の5,000台も同じ配分にする。ただし誤差の余裕として、フレックスプールを2倍の15％程度にする。月末ではなく、2週間の実データが出たら配分を切り直す。在庫処分は3つ目のケースだ。5つのプラットフォームに広げるな。最も早く動く1～2チャネルに集中させ、他は売り切れ表示にする。動きの遅い在庫は、薄く広げると死ぬ。集中砲火こそ、最も早く現金に変える。
サーキットブレーカー：3段階、順番に
プールだけでは救われない。ブレーキが必要で、順番に作動しなければならない。
第1段階は、プラットフォームごとの販売可能数上限だ。WMSが各マーケットプレイスに更新後の販売可能数を15～30分ごとに送信する：割り当て数から販売済み未発送を差し引き、リザーブを引いたものだ。その同期頻度をSOPに書き込む。マーケットプレイスのフィードには遅延がある。遅延は正常と捉えて計画を立て、連携を組む前に各プラットフォームの在庫フィード制限を確認しておく。
第2段階は、フレックスプールアラームだ。フレックスプールが枯渇したとき、あるいはチャネルの販売可能数が安全ラインを下回ったとき、すべてが引き締まる。全プラットフォームの販売可能数を自動で切り下げるか、運用責任者がそれ以上の解放を手動で承認する。このステップが、2023年のブラックフライデーにクライアントを救った。TikTokが一晩で8,000台を動かしたとき、第2段階がAmazonとDTCストアの販売可能数をロックし、全体が過剰販売になるのを防いだ。
第3段階は、完全停止だ。本当に売るものがなくなったら、迷わず出品を停止するか、約束の出荷日を延ばし、カスタマーサービスの台本を用意しておく。1件の過剰販売の返金＋悪いレビューのコストは、逃した数件の販売の利益よりはるかに大きい。この計算を1回やれば、第3段階を飛ばすことは二度となくなる。
もう1つ：どのブレーキを誰が引くかを書き出しておく。第1段階は自動。第2段階は運用責任者の判断。第3段階はオーナー直轄だ。委員会の決定にするな。過剰販売が起きているとき、会議をしている時間はない。
第2段階には、設計で回避すべき副作用がある。誤作動だ。プロモの急増は正常だ。フラッシュセールは10分で数百台を焼き尽くし、1回の同期サイクルで販売可能数を安全ラインの下に引きずり下ろすことがある。そのタイミングでブレーカーを落とせば、健全な在庫を出品停止にして自分のトラフィックを殺してしまう。だから2次確認を加える。作動条件が発火したら、販売可能数を削らずに15分間フリーズし、システムに実際の残在庫を再計算させる。在庫数から販売済み未発送を引き、未決済のカート分のおおまかな引当を差し引いたものだ。まだ余裕があれば解放して、運用責任者には警告だけ送る。本当に枯渇していたら、3段階を走らせる。2次確認は誰かの勘ではなく数字で動く。だから、本物の過剰販売はブロックし、自社プロモへの誤射は防げる。
倉庫との握手：数字が合わなければ、他は何も機能しない
これらすべては、1つの前提の上に成り立つ。WMSの数字が正しい、ということだ。だから倉庫との関係こそが本当の土台だ。
週次で照合する。WMSの在庫数は、全プラットフォームの販売可能数＋販売済み未発送＋輸送中＋フレックスプールに等しくなければならない。合わなければ、どこかで漏れている。最も多い漏れは返品だ。返品された商品が倉庫に戻ってきたのに、誰の販売可能プールにも戻されず、棚に置かれたまま出品はゼロ表示になる。
5列の固定シートを勧める：SKU、在庫数、全プラットフォームの販売可能合計、販売済み未発送、輸送中＋フレックスプール。毎週月曜の朝にグループチャットに投稿する。合わない行は赤くフラグを立て、誰かがその日のうちに説明する。
もう1つの落とし穴。3PLのリザーブ在庫だ。一部の倉庫は、WMSの中で大口クライアント向けに在庫をこっそり確保している。その確保ロジックが自分に透明でなければ、販売可能数はフィクションだ。契約時に確認して、書面に残す。
数字が合わないとき、私は3つのチェックポイントを歩く。1つ目、プールに戻っていない返品。返品エリアの在庫数を販売可能プールと突き合わせ、ギャップを見つける。受入とシステム上の格納が同日に行われたか確認する。一晩のずれこそ、在庫が消える場所だ。2つ目、早すぎる輸送中計上。販売可能数が在庫数を上回っているSKUを探す。ほぼ間違いなく、誰かが海上の貨物を数えている。3つ目、不透明な3PLリザーブ。倉庫にリザーブ明細をエクスポートさせ、契約上のリザーブ量とSKUごとに突き合わせ、ラインを超えたものは説明させる。3つを全部歩けば、10回中9回は根本原因が見つかる。
今夜、1つだけやろう。トップSKUを取り、在庫数、プラットフォーム別販売可能数、輸送中の3つの数字を表に入れる。明日の朝、倉庫に電話して1行ずつ突き合わせる。合えば、マルチチャネルの在庫は健全だ。合わなければ、1週間は成長のことを忘れて、まず帳簿を直そう。
英語版からの翻訳。内容に相違がある場合は英語版を優先します。
