OMS返品フローの設計、RMA、返金タイミング、再入庫ロジックを一気に押さえる

返金が実行されたのは火曜日でした。箱は戻ってきませんでした。

今年3月、カリフォルニア州オンタリオのホームグッズ倉庫のシステムを点検していたとき、財務とカスタマーサービスが$120をめぐって言い争う場面を見ました。顧客が返品を申請し、配送業者のスキャンには「引き取り済み」と表示されていたため、CSは社内方針に従って返金を実行しました。ところが3日後、その荷物は輸送中に消えてしまいました。お金は消え、在庫も消え、2つの部署は誰の責任かを巡って午後を潰しました。

根本原因はCSでも財務でもありません。答えるべき3つの基本的な問いに答えていなかった、OMSの返品モジュールでした。いつ返金するのか、何を誰が承認するのか、箱が戻ってきたら誰がオーナーなのか。この3つが固まるまで、返品フローは開いた傷口のままです。

結論を先に言います。返品設計の80%はお金が動く前に決まります。残りの20%は箱が戻ってきてからです。順番を間違えないでください。

すべての返品に「使えるID」を付ける

すべての返品にはRMA　返品商品承認番号　が必要です。返品の身分証明書のようなものです。私の推奨は、プレフィックス＋日付＋連番、たとえばRMA-20260314-00427です。UUID風の文字列は避けましょう。倉庫スタッフは32文字の16進コードをラベルから読み取れませんし、ラベルミスの箱は思っているより頻繁に起きます。

番号付けルールが決まったら、合わせて3つのことを決めます。

1注文に何件のRMAか。顧客が3点を買い、2点を別々の荷物で返送してくる。いま決めましょう。私は1荷物につき1RMAを推奨します。追跡番号と物理的な箱が対応し、CSが実際にものを探せるようになります。

セルフサービスの返品ポータルを作る。顧客が返品理由を選び、写真をアップし、ラベルを印刷するまでを1つのフローにします。重要な細部があります。理由はドロップダウンで、自由記述欄は絶対に使わない。自由記述の理由は集計できませんし、CSが1件ずつ手作業で読み替える羽目になります。ゴミが入ればゴミが出ます。

すべてのRMAに有効期限を付ける。返送まで7日が妥当な出発点です　サンプルです。カテゴリと平均注文単価に合わせて調整してください　。ポータルにはっきり表示します。有効期限のないRMAは孤児レコードになります。2024年、アパレル倉庫で返品率18%、半年以上放置された未処理のRMAが2,000件超という現場を見ました。どの箱がまだ「輸送中」なのか、誰にも言えなかったのです。

返金はいつ出す？ 3つのタイミング、3つのリスクプロファイル

返金のトリガーはチームが争うポイントです。なぜなら現金リスクと顧客体験の直接的なトレードオフだからです。3つのモデルがあります。

引き取りスキャンで返金。配送業者が「引き取り済み」を示したら返金します。体験は最高、リスクも最高。荷物の紛失、空箱、すり替えはすべて自社の負担です。

倉庫受領で返金。お金が動く前に箱を受け取って登録します。リスクはコントロール可能。顧客は通常3–5日余計に待ちます。

検品後に返金。箱を開け、商品をグレード判定して、初めて返金します。最も安全ですが、サイクルは7–10日に延び、顧客は嫌います。

私の判断はこうです。全商品に1つのルールを当てはまない。低単価の商品　たとえば$30未満—サンプルの閾値です　なら、たまの紛失箱のコストはCSとのやり取りのコストより小さいので、引き取り時返金は合理的な賭けです。スニーカー、化粧品、電子アクセサリーといった高単価で、すり替えやすいカテゴリは、検品後返金にしましょう。トリガーはサイト全体ではなく、OMSでカテゴリごとに設定します。

承認ルールも同じく段階制にします。バンドの例、$75未満は自動承認　サンプルです。自社の平均注文単価に合わせて調整してください　、$75–$300はCSスーパーバイザー承認、$300超は財務承認。次に、手動レビューを強制するレッドラインをOMSのルールエンジンにハードコードします。壁のポスターに書くのではありません。たとえば、同じアカウントが30日間で3回以上返品　サンプル　。「不良品」が繰り返し選ばれるのに品質クレームの記録がない。交換申請が処理途中で返金に切り替わる。

箱が戻ってきた。次は？

返品された箱の行き先はちょうど3つです。いま決めて、OMS↔WMSのステータスマッピングを一度だけ作ります。

再販可能。包装無事、タグ付き→通常のスロットに戻す。OMSステータスは「resellable」、WMSは標準のputawayを実行。

修理・リファービッシュ。OMSは「repair」、WMSは修理ゾーンへ。修理が終わったらステータスを販売可能に戻す。そしてその切り替えはOMSに書き戻さなければなりません。

廃棄。OMSは「scrap」、WMSは廃棄エリアへ移動し、財務が償却します。「pending」のまま3か月システムに置きっぱなしにしないでください。

返品受付ステーションで返品を処理する倉庫スタッフ

典型的な失敗は、2つのシステムが別々の帳簿を付けることです。OMSは「refunded」と言っているのに、箱はWMSの検品キューに未処理のまま置かれている。あるいは逆に、WMSは既に再入庫しているのに、OMSでは返金がまだ「pending inspection」で止まっている。ロサンゼルスのある3PLでは、2つのシステムが一度も照合されず、すべて手作業のスプレッドシートで回していたせいで、検品エリアに400+件の返品が山積みになっているのを見たことがあります。

解決策は特別なものではありません。OMSが返品を「received」とマークしたら、WMSが受領タスクを自動生成する。WMSが「sellable」と判定したら、OMSが返金を解放する　検品後返金モデルの場合　。ステータス変更はAPIでリアルタイムに送り、2つのシステムが食い違っている注文をすべて拾う夜間照合ジョブを足します。APIは落ちます。照合ジョブがセーフティネットです。両方必要です。