返品対応がばらつくのは、ポリシーが文章だから｜条件表に直す

同じ申請なのに、担当者によって答えが違う

「開封したが使用はしていない」商品の返品申請。Aさんは受け付け、Bさんは断る。数日後、顧客から「前回は返せたのに」と連絡が入り、対応した本人ではない誰かが謝ることになる——EC・小売のカスタマーサポートでよく起きる状況です。

こうしたばらつきは、担当者の理解不足が原因ではありません。返品・交換ポリシーが文章で書かれていることが原因です。「未使用に限る」「商品到着後7日以内」「お客様都合の場合は送料をご負担いただきます」——それぞれは明確でも、実際の申請は条件の組み合わせで届きます。開封済み・8日目・初期不良の疑いあり。この組み合わせに対する答えは、たいていどこにも書かれていません。

書かれていない部分は、その場の解釈で埋められます。ベテランは過去の経験から判断できますが、その判断基準は本人の中にしかなく、新しい担当者には渡りません。結果として、顧客から見ると「人によって言うことが違う会社」になります。

ばらつきが起きるたびに「ポリシーをよく読むように」と伝えても、状況は変わりません。読む側の問題ではなく、書かれ方の問題だからです。

裏を返せば、条件の組み合わせと答えを表の形に直せば、誰が見ても同じ結論にたどり着けます。AIに判定を任せられるようになるのも、この形にしてからです。

自分でやるなら：判断を条件表に移す3ステップ

ステップ1：過去の申請20件から、実際に使っている条件を洗い出す

出発点は、ポリシー文書ではありません。実際の対応履歴です。文書に書かれていない運用ルールが、現場には必ずあります。

直近の返品・交換の申請を20件ほど集め、それぞれについて「どんな申請だったか」「どう判断したか」「その判断の決め手は何だったか」を並べます。ここで、判定に使われている条件が見えてきます。購入からの経過日数、開封の有無、商品カテゴリ、返品理由（初期不良かお客様都合か）、送料の負担先——多くの会社では、この5つ前後に収まります。

同時に、同じような申請で違う答えを出している事例も見つかります。それが、いま顧客に見えているばらつきです。

並べた履歴は、ChatGPTやClaudeに読み込ませて整理させます。貼り付ける前に、お客様の氏名・住所・電話番号・注文番号は外しておきます。

コピペで使えるプロンプト例（対応履歴からの条件抽出）：

以下は、当社の返品・交換申請とその対応履歴です。

次の観点で整理してください。
・判断の決め手になっている条件を、項目として洗い出す
・条件の組み合わせごとに、実際にどう判断されたかを一覧にする
・似た申請で判断が分かれているものがあれば、指摘する
・文書化されていないが、慣習として使われていそうな基準を挙げる

［対応履歴をここに貼り付け］

ステップ2：条件の組み合わせと答えを、1枚の表にする

洗い出した条件を、行と列の表に組み直します。行が条件の組み合わせ、列が「可否」「送料の負担」「案内文の型」です。

作るときのポイントは、グレーを残さないことです。「ケースバイケース」と書きたくなる組み合わせが必ず出ますが、そこを空白にすると、結局その場の解釈に戻ります。判断が難しい組み合わせには「保留：責任者に回す」と書きます。誰に回すかまで決まっていれば、それも立派な答えです。

表ができたら、直近の申請20件を当てはめて検算します。表どおりに判断すると過去の対応と違う結果になるものが出てきたら、そこが議論すべき論点です。過去の判断が間違っていたのか、表に条件が足りないのか、どちらかがわかります。

ステップ3：AIに判定と案内文の下書きをさせ、人が承認する

条件表ができて初めて、AIに任せられる形になります。表そのものをプロンプトに貼り付け、届いた申請内容と突き合わせて判定させます。

コピペで使えるプロンプト例（申請内容の判定と案内文の下書き）：

以下は、当社の返品・交換の判定表と、お客様から届いた申請内容です。

判定表に照らして、次を出してください。
・可否の判定と、根拠になった条件（表のどの行に当たるか）
・送料の負担先
・お客様への案内文の下書き（丁寧だが、事務的になりすぎない文面で）
・判定表のどの行にも当てはまらない場合は、その旨と、不足している情報

［判定表］
［申請内容］

ここで外せないのが、送信前に人が承認する工程です。AIの判定をそのまま自動送信にすると、表に当てはまらない事例や、文面の温度が合わない事例がそのまま顧客に届きます。判定と下書きまでをAIに任せ、最後の確認は人が持つ。この形なら、対応時間は短くなりながら、品質のばらつきは抑えられます。

判定と案内の履歴を残す場所も決めておきます。問い合わせ管理ツールを使うなら、Zendeskの場合はSupport Teamプランが1エージェントあたり月19ドル、Suite Teamプランが55ドルです（いずれも年払いの場合のドル建て価格。2026年9月時点、公式サイトより）。国産のRe:lationには登録ユーザー1名までのフリープランがあり、有料プランの月額は利用ユーザー数とストレージによって変わるため、公式サイトでの確認が必要です（2026年9月時点）。まずはスプレッドシートに判定の記録を残す運用から始めても構いません。

つまずきやすいポイントと回避策

条件表を作って終わり、更新されない → 表に当てはまらない事例が出たときに追記する担当と、見直す頻度（月1回など）を決めます。例外は必ず出ます。出ること自体は問題ではなく、表に戻ってこないことが問題です。

表に載らない事例を、無理に当てはめてしまう → 「どの行にも当てはまらない」と判断できることが、表の価値です。当てはまらない申請は保留に回し、判断した内容を次の行として追加します。

AIが書いた案内文を、そのまま送ってしまう → 返品の連絡は、顧客が不満を持っている場面です。事実として正しくても、温度が合わないと二次クレームになります。定型化していい部分と、状況に応じて足す一文を分けておくと、承認の工程が速くなります。

お客様の個人情報を、そのままAIに貼り付けてしまう → 判定に必要なのは「いつ買ったか・開封したか・理由は何か」で、誰の申請かは要りません。氏名・住所・電話番号・注文番号は外してから貼ります。何を入れてよくて何を入れないかの線引きは、AIの誤情報・情報漏れ対策は「禁止」より「仕分け」で扱っています。

（各ツールの機能・料金は変更になる場合があります。最新情報は各社の公式サイトでご確認ください）

自走では越えにくい境界線

上記の方法で、「同じ条件なら同じ答えが出て、対応時間も短くなる状態」までは自社で作れます。一方、次の領域は専門的な設計が必要になります。

返品ポリシーそのものの設計

返品条件をどこまで認めるかは、顧客満足とコストの両面に関わる経営判断です。あわせて、通信販売では特定商取引法に基づく返品特約の表示など、法令上の要件があります。ポリシーの内容を変更する場合は、専門家の確認を挟む領域になります。

基幹システム・在庫との連携

返品を受け付けた商品の在庫の戻し、返金処理、会計側の記録までを自動でつなぐには、システム間の連携設計が必要です。

複数チャネル・複数店舗でのポリシー統一

自社EC・モール・実店舗で条件が違う場合、どこまで揃え、どこを分けるかの整理は、運用と契約条件の両面を見る設計になります。

今週からできる、最初の一歩

今日試せることが1つあります。

直近の返品・交換の申請を10件だけ並べて、「同じ条件の申請に、同じ答えを返せているか」を確認してみてください。対応した担当者の名前も横に置きます。

違う答えが出ている組み合わせが1つでも見つかれば、それが条件表の最初の1行になります。全部を整理しようとせず、いちばん頻度の高い組み合わせから書き始めるのが現実的です。

本記事で紹介したツールの機能・料金は2026年9月時点のものです。各社の仕様変更により変わる場合があります。導入前に各社の公式サイトで最新情報をご確認ください。