URUB
URUB
相談
URUB / ARTICLE / ECの返品・交換フロー設計|受付・返送・検品・返金・在庫戻し
#返品対応#交換対応#受注処理#CS#在庫管理#返金

ECの返品・交換フロー設計|受付・返送・検品・返金・在庫戻しを止めない運用台帳と判断基準

2026-08-19
ON THIS PAGE
  1. 01まず規約を「現場が判定できる条件」に分解する
  2. 02返品・交換を8工程の状態に分ける
  3. 03交換品をいつ確保するかを先に決める
  4. 04検品・返金・在庫戻しを別々に閉じない
  5. 05返品・交換運用台帳の項目例
  6. 06例外処理は通常フローから分岐させる
  7. 07導入前後に実施するテストケース
  8. 08参考情報

返品・交換の運用は、返品ポリシーを公開し、カート上で返金できるようにしただけでは完結しません。受付後に承認が止まれば顧客への案内が遅れ、交換品を確保する時点が曖昧なら販売可能在庫と約束がずれます。返送品の検品結果が返金・在庫戻し・顧客履歴に連動していなければ、処理済みに見える注文にも未解決の作業が残ります。

重要なのは、返品・交換を「CSの問い合わせ」でも「物流の入荷」でもなく、複数部門が引き継ぐ状態遷移のある業務として設計することです。本記事では、Shopify、ecforce、makeshop、BASEなど、利用中のカートや外部サービスを問わず先に決めるべき運用要件を整理します。Shopify固有の仕様は、Shopifyヘルプセンターの記載に基づき、2026年8月18日確認時点の情報として扱います。

まず規約を「現場が判定できる条件」に分解する

通信販売では、返品特約を設ける場合、返品の可否、条件、送料負担などを明確に表示する必要があります。消費者庁は、不良品以外の返品を受け付けない場合も、その旨を表示する例を示しています。規約ページの文言と、CS・物流が実際に行う判断を一致させることが出発点です。

ただし、「商品到着後○日以内」「未使用に限る」と掲載するだけでは、担当者は次のような場面で止まります。

  • 到着日は配送完了日、顧客の受取日、問い合わせ受信日のどれで判定するか
  • タグを外した商品、試着した商品、セット商品の一部は未使用として扱うか
  • 色違いへの交換で差額が生じる場合、追加請求・返金・再注文のどれにするか
  • 誤出荷、破損、初期不良、顧客都合を誰が分類し、返送費を誰が負担するか
  • 返送期限を過ぎたもの、追跡番号がないもの、注文品以外が届いたものを誰が最終判断するか

そこで、ポリシーの各条件を次の4要素に翻訳します。

規約・方針の項目運用に落とす内容記録する項目
受付期限起算日、判定日、延長を認める担当・条件配送完了日、受付日、期限、延長理由
返品可否商品群、状態、付属品、除外品SKU、返品理由、申告状態、検品結果
送料負担返品理由ごとの負担者、案内する配送方法送料負担区分、送付ラベル有無
返金方法決済方法ごとの返金先、返金する範囲商品代、送料、手数料、返金額、実行日

規約を変更する前に、直近の返品・交換案件を数件抽出し、各案件をこの表だけで判定できるか試してください。判定不能な案件が出た箇所が、規約または社内判断表に追加すべき条件です。

法令上の表示要件と、個別案件への結論は別の論点です。特例を認める権限者、記録の残し方、顧客への説明文を決めずに「ケースバイケース」とするのは避けます。例外を許容する設計でも、承認者と理由を残せば、次回の規約見直し材料になります。

返品・交換を8工程の状態に分ける

「返品受付中」のような大きすぎる状態では、誰の作業待ちなのかが分かりません。以下の8工程に分け、各工程に担当・完了条件・次の担当を置きます。カートのステータス名と完全に一致させる必要はありません。運用台帳で補完してもよいので、少なくともこの粒度で追跡できるようにします。

  1. 受付:顧客の申請を受領し、注文・商品・理由・希望(返品または交換)を特定する。
  2. 承認判定:返品特約と社内判断表に照らし、可否、送料負担、返送期限、交換方法を決める。
  3. 返送案内:返送先、返送期限、同梱物、追跡番号の連絡方法、返金時点を案内する。
  4. 交換品の引当・出荷判断:在庫、出荷可能日、先出しか到着確認後かを確認し、必要な引当または出荷を行う。
  5. 返送到着確認・検品:到着日、SKU・数量・付属品・状態を確認し、受領した事実と検品結果を記録する。
  6. 返金実行:承認済みの返金対象・金額を確定し、決済またはカート側で返金を実行する。
  7. 在庫戻し:再販可、アウトレット等への振替、廃棄・保留など、検品結果に応じて在庫処理する。
  8. 完了連絡・履歴更新:顧客へ結果を伝え、注文・顧客・返品台帳の記録を完了させる。

ここで注意したいのは、返金と在庫戻しを同一の完了条件にしないことです。返金は決済・経理上の処理であり、在庫戻しは商品状態の判定を伴います。返品が届いたからといって再販可能とは限りません。一方、検品待ちの商品を販売可能在庫に戻さなければ、実在庫とシステム在庫の不一致につながります。

工程ごとの責任を「実行者」と「判断者」に分ける

小規模な組織では一人が兼務しても構いませんが、役割は分けて書きます。例えば、CSが受付と顧客連絡を担い、受注担当が承認、物流が検品、経理または権限保有者が返金を実行する構成です。

工程実行者の例判断者の例完了条件
受付CS注文・対象SKU・希望・理由が特定済み
承認判定CSまたは受注担当責任者、例外時は管理者可否・負担・期限・返金条件が確定
返送案内CS顧客に必要事項を送信済み
交換品対応受注・物流在庫責任者引当または出荷可否が確定
検品物流商品責任者(判定困難時)状態・数量・付属品が記録済み
返金経理または受注担当返金権限者金額・手段・実行日が記録済み
在庫戻し物流・在庫担当在庫責任者処分区分と反映日が記録済み
完了CS顧客連絡と台帳更新が完了

「返金を実行できる人」と「返金額を判断できる人」が違う場合は、承認記録なしに実行へ進めないルールを置きます。金額修正や例外対応での確認往復を減らせます。

交換品をいつ確保するかを先に決める

交換では、顧客に代替商品を渡す約束と、返送品の確認の順序が争点になります。代表的な設計は次の3つです。

方式流れ向く条件主なトレードオフ
到着・検品後に出荷返送品到着→検品→交換品出荷在庫が限られる、高額品、状態確認が必要顧客の交換完了まで時間がかかる
承認後に在庫確保、到着後に出荷承認→引当→返送品到着→出荷欠品を避けたいが、返送確認も必要引当中在庫を可視化する必要がある
承認後に先出し承認→出荷→返送品到着・検品誤出荷などで迅速な是正を優先する未返送・検品不可の回収管理が必要

どの方式にも正解はありません。商品単価、再販可能性、在庫余力、配送日数、返品特約に照らして商品群ごとに選びます。たとえば、サイズ交換と誤出荷を同じ方式に固定する必要はありません。

Shopifyでは、返品と交換を注文管理から扱えます。公式ヘルプでは、交換品の在庫は返品を処理するまで確保されないと案内されています(2026年8月18日確認)。したがって、承認時点で在庫を押さえる前提の運用を採る場合は、Shopify上の在庫挙動と実際の引当手順が一致するかをテストしてください。「台帳では確保済みだが、販売チャネルでは売れてしまった」という状態を防ぐためです。

また、交換に伴う差額の扱いも、受付前に決めます。差額が出る場合に、元注文の返金と新規注文を分けるのか、利用カートの交換機能で処理できる範囲に収めるのかは、決済、会計、在庫、顧客案内に影響します。利用中のカート・決済サービスで試験注文を作成し、注文履歴、在庫、返金明細にどう表示されるかまで確認します。

検品・返金・在庫戻しを別々に閉じない

返送品が届いた時点で必要なのは、「届いた」という記録だけではありません。少なくとも次の確認を検品票または運用台帳に残します。

  • 注文番号、返品受付番号、返送追跡番号
  • 到着日、検品者、対象SKU、数量
  • 商品状態、タグ・付属品・セット内容の有無
  • 返品申請内容との一致・不一致
  • 在庫処分区分(再販可、保留、再販不可など)
  • 返金可否、返金対象の内訳、承認者

検品の結果が申請と異なる場合、物流担当だけで返金額を変更しない設計が安全です。写真が必要な商品なら、撮影者・保存先・撮影日も台帳に残します。その後、CSまたは判断者が顧客への説明と返金額を確定します。

返品作業をカート内で処理する場合にも、処理順序の制約を確認してください。Shopify公式ヘルプでは、返金済みまたは在庫補充済みの返品アイテムは返品から削除できないと案内されています(2026年8月18日確認)。誤ったSKUや数量で返品を作成した場合に、どの段階まで修正できるかを、実運用前のテストケースに含めるべき理由です。

futureshopのオンラインマニュアルでも、キャンセル・返品に伴う在庫戻し、ポイント、クーポンなどの確認が必要であり、保留状態では在庫戻しなどが自動処理されない旨が案内されています。これはfutureshopの仕様ですが、他のカートでも「保留」「返品受付」「完了」など、ステータスに応じた自動処理の有無を確認する観点は共通します。機能名から推測せず、利用中のカート、連携アプリ、WMS、会計連携ごとに確認してください。

返品・交換運用台帳の項目例

カート機能だけで全工程を追えない場合、スプレッドシート、チケットシステム、受注管理システムなどで運用台帳を用意します。目的は二重入力を増やすことではなく、案件の現在地、次の担当、判断証跡を一つの画面で追えるようにすることです。

最低限の列は次のとおりです。

区分項目例
識別返品受付番号、注文番号、顧客ID、注文日、対象SKU・数量
受付受付日、受付経路、返品・交換区分、返品理由、顧客の希望
判定可否、適用ルール、承認者、承認日、例外理由、返送期限
配送送料負担区分、返送先、返送案内日、追跡番号、到着予定日
交換交換SKU・数量、引当日、出荷可否、出荷日、交換差額の扱い
検品・在庫到着日、検品者、検品結果、証跡保存先、在庫処分区分、在庫反映日
返金返金対象内訳、返金額、返金承認者、返金手段、返金実行日
完了顧客への完了連絡日、担当者、最終状態、次回受注時の確認事項

「次回受注時の確認事項」は、返品した事実そのものを一律に注意情報とする欄ではありません。配送先不備の確認、交換済み商品の重複出荷防止など、次回注文の処理に必要な内容だけを、根拠と更新日付きで残します。顧客対応履歴を保存・参照する範囲は、自社の個人情報取扱いの方針と権限設計にも合わせてください。

例外処理は通常フローから分岐させる

通常フローに例外を混ぜると、未返送、検品保留、返金保留が「対応中」の中に埋もれます。台帳の状態を分け、担当者が一覧で抽出できるようにします。

事前に決めるべき例外と判断者

例外最初に確認する事項判断者台帳に残す事項
返送期限超過案内日、期限、顧客連絡の有無承認者延長可否、理由、新期限
返送品不足・誤返送注文内容、同梱物、写真商品・CSの判断者不足内容、顧客連絡日、結論
検品不可・状態相違申請内容、商品状態、証跡商品責任者判定、返金への影響、説明内容
交換品欠品販売可能在庫、入荷予定、代替案在庫責任者提案内容、顧客選択、引当解除日
返金失敗・金額相違決済履歴、返金内訳、実行権限経理・受注責任者再処理日、訂正理由、完了確認

例外のSLA(いつまでに誰が確認するか)も置きます。ただし、すべてに一律の時間を設定するより、顧客へ次の連絡をする期限と、社内で判断を上げる期限を分ける方が実務に合います。確定できない案件でも、状況確認中であることと次回連絡予定を案内できるためです。

導入前後に実施するテストケース

返品アプリやセルフサービス返品を導入する場合も、先に運用をテストします。Shopifyでは、注文状況ページから顧客が返品リクエストを送るセルフサービス返品と、返品ルールによる対象商品・返品期間の管理が案内されています(2026年8月18日確認)。ただし、画面で受付できることと、自社の承認・検品・返金ルールが実装されていることは別です。

本番前に、テスト注文で少なくとも次を通します。

  1. 顧客都合の返品:期限内、未使用、返送費が顧客負担のケース
  2. 事業者側の誤出荷または不良の申告:返送費負担と代替品出荷のケース
  3. 在庫が1点しかない商品:交換受付後に別注文が入るケース
  4. セット商品の一部だけが返送されたケース
  5. 返送期限超過、または追跡番号が未共有のケース
  6. 検品後に再販不可と判定したケース
  7. 返金済み・在庫処理済み後にSKUまたは数量の誤りが判明したケース

テストごとに、顧客へ送る文面、カート上の注文・在庫表示、WMSや会計への連携結果、台帳の完了条件を確認します。特に「交換品の在庫」「返金額」「在庫戻し」の三つは、画面上の表示と実在庫・決済結果が一致しているかを別々に見ます。

運用開始後は、台帳の未完了案件を定期的に確認します。見るべきなのは返品率だけではありません。受付から承認、返送案内から到着、到着から検品、検品から返金まで、どの状態に何件が残っているかを確認すれば、担当分担、期限、連携設定のどこを見直すべきか判断しやすくなります。

参考情報

FREE CONSULT

この課題、もっと詳しく相談したい方へ

記事では答えきれない個別の状況にもお応えします。

無料で相談する →
CONSULT/ 無料相談

Stuck?
Let's talk.

この記事を読んでも詰まったら、相談してみてください

記事では答えきれない個別の状況にもお応えします。まずはお気軽にどうぞ。

HOW IT WORKS

  1. 01
    フォームで送信
    お名前とご状況を簡単にお知らせください。
  2. 02
    担当者がご連絡
    1営業日以内に株式会社かいなよりご連絡します。
  3. 03
    無料でご相談
    まずは状況をヒアリングし、最適な方向性をご提案します。