32,000 件のプレセール注文。OMS のダッシュボードは緑一色「在庫あり」。そしてロングビーチ港の沖合に、誰もモデル化していなかった 4 日遅れの入荷コンテナが停泊していた。2021 年のブラックフライデーの 3 日前、私が関わった美容ツールブランドが直面していたのはそういう状況だった。事態が収まってみると、2,800 件の注文が出荷できなかった。返金、再発送、マーケットプレイスのペナルティで $60,000 を超える損失——ブラックフライデーの利益はまるごと、1 週間で消えた。
その電話で私は 1 つ質問した。「貴社の販売可能数量には、入荷予定在庫も含まれていますか？」3 秒の沈黙。そして「たぶん入っていると思います」。それが問題のすべてだった。
販売可能数量と手元在庫は別物だ。プレセールのラッシュ時、その差は生死を分けるラインになる。
5 つのバケツ、1 つの計算式
OMS の画面の多くは「在庫」という 1 つの数字だけを表示する。私はそういう画面を何度も開いてきたので知っているが、その数字はたいてい手元在庫＋入荷予定−引当のごちゃ混ぜだ。この計算は閑散期なら無害だ。入荷予定が予測でき、数日のずれが問題にならないからだ。プレセールは違う。入荷が予定通り来るという賀けの上に、明日の在庫を今日売っているのだから。
2021 年当時、ロングビーチの混雑でコンテナ 1 週間遅れは日常茶飯事だった。入荷予定を販売可能として数えることは、港が詰まらないという賀けだった。
私の OMS には最低 5 つのバケツがある。
手元在庫：入庫済み、棚入れ済み、ピック可能。入荷予定：出荷済み、未入庫——お金は払ったが、まだ手元にないもの。引当：注文に紐づき済み、未ピック。凍結：在庫を意図的にロックしたもの——プレセール専用、品質保留、顧客指定ロット。安全在庫：下限。絶対に触れない。
正しい計算式は 1 つだけだ：販売可能数量＝手元在庫−引当−凍結−安全在庫。入荷予定はこの式に入らない。
手元 5,000、入荷予定 8,000、引当 1,200、凍結 2,000、安全在庫 500 の SKU を考えよう。販売可能数量＝5,000−1,200−2,000−500＝1,300。画面が 13,000（手元＋入荷予定−引当）を表示しているなら、今日の注文に対して 11,700 個の未来の在庫を売っていることになる。コンテナが 1 本遅れれば、売り越しが爆発する。
では入荷予定は何に使うのか。独立したプレセールプールだ。プレセールの商品ページはこのプールからのみ引き当て、スポットの販売可能数量には絶対に手を付けない。プールの水準＝確定済み入荷予定×信頼度係数。係数はサプライヤーの実績で決める。納期遵守率 95% 以上のサプライヤーは 0.9、慢性的に 3〜5 日遅れる組は 0.6、新規サプライヤーはゼロ——実績を示すまでプレセールの権利なし。プレセールが売るのは「確実性」だ。係数はあなたの正直さのスコアである。
プレセールが在庫を食う順番
プレセールとは、未来の手元在庫を前倒しで売ることだ。だからプレセールとスポットの在庫は 2 つのプールに住み、物理的に分離し、絶対に混ぜない。
順番はこうだ。プレセール注文はまずプレセールプールから引き当てる。入荷予定が到着して手元在庫に変わったら、プレセールプールを補充する。スポット注文はスポットの販売可能数量からのみ引き当て、プレセールプールには絶対に触れない。そしてプレセール注文がスポット在庫を直接食うこともない。
なぜここまで厳格に？2022 年のプライムデー、私のアウトドア用品のクライアントはプレセールとスポットを 1 つのプールで回していた。プレセールがプールを食い尽くし、スポット注文が来たときにはピックできるものが何もなく、カスタマーサービスが 1 週間総攻撃を受けた。2 つのプールに分ければ、プレセールが売り切れてもスポットの本業には触れない——最悪でもプレセールの掲載を閉じれば中核は動き続ける。
凍結のタイミングも重要だ。プレセールの開始前に、対応する在庫を凍結する。凍結量＝計画プレセール数量＋クッション。クッションは計画数量の 10–15% を目安にし、キャンセルと破損をカバーする。そして凍結は必ずシステム上の記録にする——誰が、いくらを、いつ解除するのか。「口頭の凍結」が殺し文句だ。チャットグループで誰かが「このロットは触るな」と言い、誰もシステムに入力せず、スポット注文がそれを食ってしまう。
キャンセルにも明確な解除ルートが必要だ。キャンセルされたプレセール注文はまずプレセールプールに戻し、プレセールプールが満杯のときだけスポットに溢れ出す。直接スポットに送ると、これから来る注文のためにプレセールプールが干上がる。
数字の入ったキルスイッチ
どんな計算式もときどき間違える。だから最後の防衛線はサーキットブレーカーだ。SKU の販売可能数量がしきい値を下回ったら、システムが自動的に制限または掲載停止し、人のレビューだけが復旧できる。
しきい値はどう決めるか。私は 2 段階を使う。プレセール SKU は計画プレセール数量の 5% でトリップ——20,000 個の計画なら、販売可能 1,000 個で自動停止。スポット SKU は平均日販の 2〜3 日分でトリップ。ゼロに設定してはいけない。ゼロはブレーカーなしと同じだ。システムは正から負へまっすぐ飛び、反応する時間がない。
もう 1 つの落とし穴。ブレーカーはストアフロントの注文は止めるが、カスタマーサービスの手動注文は止めない。KPI を守るために担当者が売り越し中の SKU の注文を手入力し、売り越しがそのまま起きたのを私は見てきた。ブレーカーは手動の受注もカバーしなければならない——最低でも強い確認を出すこと。
トリップ後の復旧手順は文書化しておく。誰が掲載を復旧できるのか、まずどの数字を突き合わせるのか、影響を受けた顧客に連絡するのか。最悪のパターンは、数字がまだ間違っているのに担当者が気軽に「販売再開」をクリックすることだ——1 時間に 3 回トリップしたら、顧客は二度と戻ってこない。
痛いのはここからだ。売り越しのコストは返金より高い。マーケットプレイスのペナルティ、墜落したセラー評価、燃えた広告費——合わせればたいてい商品価値の何倍にもなる。その $60,000 のうち、返金は半分にも満たなかった。残りは補償と失ったリピートビジネスだった。1 件の売り越しが、その顧客の 3 年分のリピート購入を奪いかねない。
では、あなたのチームへの問いかけけだ。もし明日からベストセラー SKU の入荷が 1 週間遅れたら、誰かが気づく前に何件売り越すだろうか。10 秒で答えられないなら、計算式の見直しが必要だ。
英語版からの翻訳。内容に相違がある場合は英語版を優先します。
