返品対応の自動化受付・検品・返金判断を
分けるAI活用と
3依頼の管理表

返品依頼が来るたびに注文を探し、商品や到着日を聞き直し、倉庫へ状況を照会する。

メールには返答していても、返送と検品、返金のどこまで終わったかが分からないEC・小売の責任者向けの記事です。

返品対応の自動化は、受付と情報整理、注文との照合、返送・検品の追跡をつなぐ形から設計します。

返金や交換の判断は、人へ残します。

受付できたことを、返品が認められたことや返金完了と同じにしません。

架空の3依頼を、情報不足、規程の確認、担当者の判断が必要な状態へ分ける管理表を示します。

購入者向けの返品権利の解説ではなく、販売側が依頼を漏らさず扱う業務の設計例です。

実際の返金や連絡を行った報告ではありません。

この記事で分かること

• 受付したことを、返品可や返金完了と同じにしません
• 申告と検品結果を分け、注文の商品と数量へ結びます
• 返金や交換の判断は人が行い、操作後の結果も確かめます

返品依頼を受けた段階では、
返金を約束しない

購入者が申し出た内容を記録し、対象の注文と商品を特定します。

その後、適用する販売条件や規程、商品の状態、必要な確認を担当者が見て、対応を決める順です。

最初の1件で、分かる
ことと未確認を分ける

架空の依頼R01として「先週届いた収納ケースを返品したい」というメールが来たとします。

注文番号、対象商品、数量、返品理由、商品の状態は、この文だけでは特定できません。

AIに整理させたい内容は、次の見本です。

返品希望あり。注文・明細は未特定。

追加確認：注文を照合する情報、対象商品と数量、申告理由と状態。

注文を特定したことにはせず、確認する項目を残します。

「未使用なので受付可能」「全額返金」とは書けません。

足りない情報を質問する工程と、対応の可否を決める工程を分けます。

必要な情報がそろう前に返送先を案内すると、対象外の商品や確認できない荷物が倉庫へ届く可能性があります。

返品・交換・キャンセルは、
同じ処理ですか？

同じ処理として進めず、発送や受取の状態と、相手が望む対応を確かめます。

返送を伴う依頼、別の商品への交換希望、発送前に止めたい依頼では、確認先と作業が変わります。

Shopify公式の返品・交換の説明も、返品、返金、交換を分けています。

製品で処理できる操作と、個別の依頼で認める対応は別です。

この記事では、AIが可否や送料負担を決定する運用にはしません。

返品管理表で、
申告・
確認・判断・処理を分ける

受付IDを起点に、注文の明細と、返送された商品の記録を結びます。

情報を埋めただけで完了にせず、判断した人と、その後の処理結果を別に残してください。

購入者の申告は、
原文へ戻れるように残す

「届いた時から角が欠けていた」という申し出を、AIが「配送事故で破損」と要約すると、原因を決めたことになります。

申告は申告として保持し、出荷時の記録や検品で確かめる項目を別に取り出します。

急ぐ理由や希望する対応も落とさないようにします。

「交換してほしい」と「返金してほしい」を同じ返品希望へまとめると、担当者が違う手配を始める可能性があります。

写真と住所は、必要な範囲で扱う

状態確認に写真が必要なら、何を写してもらうかと保存先を決めます。

本人確認書類や、部屋全体、宛名の写った箱など、目的と関係のない情報まで一律に求めないでください。

注文の照合も、会社の確認手順で必要な項目へ絞ります。

顧客の住所や写真をAIへ渡す前に、サービスの契約、社内ルール、保存・処理条件と閲覧権限を確認します。

初回の検討は架空資料で進められます。

架空3依頼を、
情報不足・
規程確認・担当判断へ分ける

次の3件は説明用の受付例です。

日付や注文IDは架空で、返品できる期間や送料負担の標準を示す数値ではありません。

自社の実際の判断には、適用する条件の確認が必要です。

3件とも11月5日に受付した想定です。

R02の未開封、R03の欠けは顧客の申告で、担当者が現物を確認済みという意味ではありません。

注文に日付があることだけでも、申告内容の正しさや対応の可否は決まりません。

R01は、不足情報の
確認を先にする

注文を特定するために会社が認めた情報と、どの商品を何個、なぜ返品したいかを確認します。

照合できたら受付表へ注文と明細のIDを結び、次の工程へ進みます。

似た名前の商品や同じ時期の注文が複数あるなら、AIが1件へ決めてはいけません。

購入者が伝えた内容と社内の注文を並べ、担当者が照合できる状態にします。

対象不明のまま既存の注文状態を変更しないことが要点です。

R02は、受付可能と
交換手配済みを区別する

未開封という申告を確認し、今回の販売条件と規程へ照らすのは担当者です。

条件に当てはまると判断した後も、赤の商品が手配可能か、返送と交換品の手順はどうするかを確かめます。

在庫があるという表示だけで、購入者へ到着日を約束しません。

交換品の確保と発送、元商品の受取や検品にどの条件があるかを、現在の運用へ合わせて記録します。

R03は、3個全部を
返金対象へ広げない

依頼にあるのは3個中2個の申告です。

対象の2個と、残る1個の扱いを分けて担当者へ渡します。

原因、返送の要否、返金か交換か、送料や金額は、この文面だけで確定できません。

「欠けがある」という言葉を、不良判定済みや配送会社の責任確定へ読み替えないでください。

必要な状態確認と規程・販売条件の照合を経て、権限のある担当が判断します。

R03の誤った受付結果を、
対象2個へ戻す

「O-203の商品3個を全額返金、送料は販売側負担」と整理されたら、数量と対応を入力以上へ広げています。

原文にあるのは3個中2個に欠けがあるという申告と、返金したいという要望までです。

不適切な受付例：
R03／O-203 L02／3個すべて返品・全額返金、送料は販売側負担。

修正後の受付見本：
受付ID：R03
注文・明細：O-203 L02
注文数量：3個
申告の対象：2個
申告理由：欠けがあるとの申し出
要望：返金希望
状態確認：未実施
規程・条件の照合：未実施
次の担当：状態と対応範囲を確認する窓口
未確定：原因、返送要否、返金可否・対象金額・送料負担

修正見本なら、担当者は何を聞き、どの記録を照合するかを選べます。

残る1個についても、同じ状態と推測せず、依頼の対象へ含める意図があるか必要に応じて聞きます。

見本は架空の手作業で作り、実際の受付や判断とは区別します。

規程・例外・検品を、
担当者が判断できる形につなぐ

AIが規程を参照しても、適用する版や購入時の条件が違えば、答えが変わる場合があります。

該当する条件を示す補助と、個別の対応を確定する判断を分けます。

規程に合わなければ、
自動で断ってよい？

この例では自動で断らず、該当条件と不足情報を判断担当へ戻します。

申告理由や取引条件、適用する法令も含め、担当者が扱う必要があるためです。

AIが書いた条文や一般論だけで、購入者の権利を決める運用にはしません。

適用する条件が確認できる場合

注文時の販売条件と社内規程の該当箇所を示し、対象商品と日付、状態へ照合します。

条件へ当てはまるという候補が出ても、検品や追加確認が必要なら、その結果まで待つ状態です。

規程にない例外や食い違いがある場合

記載がないことを理由に、認める・認めないのどちらかへ補完しません。

購入時の案内と現在の規程が違う場合も、両方の記録を残して確認先へ渡します。

判断した内容と根拠を、次の担当が見られる場所へ記します。

現物や写真での状態確認が必要な場合

誰が何を見て結果を記すかを決めます。

R03なら商品、対象2個、欠けの箇所、同梱物など必要な範囲を指定し、受け取った資料と検品結果を結びます。

写真の受領を検品完了にしないようにしてください。

消費者庁の通信販売の説明には、返品特約など販売条件の表示に関する案内があります。

自社規程やEC製品の設定が、個別の法的判断を置き換えるものではありません。

不明な扱いは社内の確認先や必要な専門家へ戻します。

規程を改めた場合にも、過去の注文へ適用する条件を担当者が確かめ、受付記録へ根拠を残してください。

返送の手順は、
案内・発送・到着・検品を分ける

返送の案内を出したら、送信した対象と案内内容を記録します。

購入者から発送した連絡が来ても、倉庫へ届いたとは限りません。

追跡番号がある場合も、対象の受付IDと結んで扱います。

倉庫へ到着したら、荷物に含まれる商品と数量を照合します。

R03で1個だけ戻った場合、2個の検品完了にはしません。

受領1個・残り1個未受領として分け、次に誰が確認するかを残す必要があります。

同じ荷物に別注文の商品が入っていた場合も、元の注文IDへ無理にまとめません。

未特定の商品を保留にし、担当者へ照合を依頼します。

商品の原状や、再販売できるかの判断も、窓口へのメールだけでは決まりません。

返金や交換は、操作したことと
結果を確かめたことを分ける

対応が決まった後も、対象、数量、金額、交換品、在庫、通知の結果が残ります。

画面でボタンを押したという記録だけで、購入者への対応がすべて完了したとは判断しません。

R03の途中経過を、
処理ごとに残す

例えば担当者が、必要な確認を経て対象2個について返金対応を決めたとします。

金額と方法は別途確定済みという説明用の条件で、この記事では具体額を作りません。

この途中経過なら、返金成功と通知完了はまだ確認できていません。

「返金済み」と返信する前に、対象の処理結果を確かめます。

交換の場合も、交換品の確保、発送、購入者への案内を別に追います。

返金結果が不明なときに、
もう一度操作してよい？

同じ操作を再実行する前に、利用システムの履歴と現在の状態を確認します。

結果が分からないことと、処理されていないことは同じではありません。

二重返金や二重発送を避けるため、対象の受付/注文IDへ戻ります。

担当が変わっても同じ受付を続けられるよう、未完了の項目と次の確認先を一覧へ出します。

購入者へ何を伝えたかも残し、前の担当の約束を見ずに違う回答を送らないようにしてください。

注文・倉庫とつなぐ前に、
3依頼の受付と保留を試す

既存のECシステムに返品管理があるなら、まず現在の機能と設定を確認します。

独自の道具を増やすより、注文や返品の記録をつなげられる範囲から始められる場合があります。

既存機能のルールと、
自社の判断を照合する

Shopify公式の返品・キャンセルルールは、リクエストの条件やポリシーの設定を説明しています。

利用製品の操作を知る参考ですが、ほかのECへ同じ条件を適用したり、法的な返品可否へ一般化したりしません。

どの注文へ適用する設定か、判断担当がどこで確認するか、倉庫や決済への結果を見られるかを管理者と確かめます。

自動受付があることだけで、自動返金まで任せられるという意味ではありません。

受付情報を整理する指示文

初回はR01〜R03のような架空依頼と、許可した確認項目だけで試します。

出力を読み比べ、不足がある行で止まれることを確かめてください。

返品・交換の申し出を受付表へ整理してください。
列：受付ID、注文/明細ID、対象商品と数量、購入/受取日、申告理由、要望、未確認、次の確認担当。
入力にない注文、日付、数量、商品の状態を補いません。
顧客の申告と、社内記録・検品で確認済みの結果を分けます。
対象が特定できない場合は情報不足、条件未照合は規程確認待ちとします。
返品可否、交換可否、原因、送料負担、返金額や期限を確定しません。
返送案内、連絡送信、返金、在庫更新などの操作はしません。
対象数と注文全体の数量を区別し、不明は判断担当へ戻します。

R01が情報不足、R02が規程確認待ち、R03が対象2個の申告と担当判断待ちになるかを見ます。

R03を全3個の返金確定へ変えたら不合格です。

ここに示した結果は期待する見本で、特定AIを実行した報告ではありません。

試行には、同じ依頼を再受信した場合と、注文番号が別のものに変わった場合も含めます。

前者が同じ受付へ戻り、後者が対象不一致で止まるかを担当者が見てください。

確認待ちを自動承認へ変えないことと、操作権限を持たない整理だけの試行を先に行うことが判断材料になります。

連携の相談へ、
例外と確認担当を添える

機密を含まない依頼3件、対象注文の見本、規程の該当部分を用意します。

倉庫と決済の道具、返送/検品の担当、結果不明のときの窓口も整理します。

まだ決まらない条件は未定のまま相談できます。

返信の書き方は、クレームの受付記録と返信案で扱っています。

メールの下書きと送信前確認は、メール返信のAI活用へ進めます。

本稿では、まず注文と商品を特定し、受付から処理結果まで別の欄で追うことを始めてください。

まるっとAIの問い合わせ対応の支援へは、受付、注文照合、担当者への引き継ぎ、結果の記録をつなぐ相談ができます。

対応する道具と範囲は個別に確認し、返金判断や送信を自動で確定する約束にはしません。