↗付きの用語リンクは、別タブで説明を開きます。
予約販売は販売開始日を設定するだけでは完了しません。モールでは予約と表示されても、在庫管理システムが通常注文として処理したり、SKUが一致せず在庫を引き当てられなかったりすることがあります。
結論：表示、注文、在庫、出荷、切替を一つの流れで設計する
対象商品とチャネルを限定し、予約用SKU、納期、受注データ、在庫マスター、CSV項目、出荷可能日、通常販売への戻し方を事前に決めます。
対象商品とモール差を整理する
販売期間、予約上限、発売日、キャンセル条件、納期表示を一覧にします。各モールと自社ECの最新仕様を確認し、同じ文言をそのまま流用しません。
SKUと在庫マスター
通常商品と予約商品をどう識別するかを決め、商品コード、選択肢、倉庫、引当ルールを照合します。予約用SKUを新設する場合は、通常販売へ切り替えた後の統合・廃止方法も記録します。
CSV・API連携の確認
必須列、文字コード、日付形式、空欄、上限、エラー時の再処理を確認します。実データの一括投入前に、テスト用の少数データで取込結果を読み戻します。
テスト受注
- 予約表示と注文完了
- 受注管理への取込
- 在庫引当と上限
- 顧客向けメールの納期
- 出荷保留と解除
- キャンセル時の在庫戻し
管理画面の成功表示だけでなく、受注・在庫・通知をそれぞれ確認します。
通常販売への切替
発売日前後の担当、時刻、在庫数、表示変更、予約注文の扱いを手順化します。複数チャネルを同時に変更せず、確認できる順序を決めます。
例外注文への対応は複数チャネル受注の例外処理、SKU選択は選択肢の多い商品のカート改善も確認してください。
まとめ
予約販売連携は、SKU、納期、受注、在庫、データ形式、切替を先に設計し、少数のテスト注文で読み戻します。まず対象商品一つで全工程を通してください。
