返品理由の分類辞書を先に作る

返品理由は、モールの管理画面や問い合わせメッセージに自由記述で残ることが多く、そのままでは集計に使えません。「イメージと違った」「サイズが合わない」「思っていたのと違う」といった表現は、書き手ごと・時期ごとに揺れます。この自由記述を毎月人力で読み直して分類していると、分類基準が担当者の忙しさで変わり、月をまたいだ比較ができなくなります。運用ループの起点は、自由記述を固定カテゴリへ正規化する「分類辞書」を先に作ることです。

固定カテゴリは10前後に収める

  • カテゴリが20を超えると、1カテゴリあたりの件数が少なくなりすぎ、どこから手をつけるべきかの優先順位が見えなくなります。
  • カテゴリが3〜4個では粗すぎて、「イメージ相違」という括りの中に採寸の問題と色味の問題が混在し、改善タスクに落とし込めません。
  • 実務上は10前後のカテゴリに収まると、件数の偏りが見えやすく、改善アクションと1対1で紐づけやすくなります。

辞書は実データから逆算して作る

分類辞書はゼロから頭で考えるのではなく、実データから逆算して作ります。

  • 直近3〜6か月分の返品理由テキストを、モールごとに集める。
  • 頻出する表現パターンをグルーピングし、10前後の候補カテゴリを仮置きする。
  • 各カテゴリに「判定基準の例文」を1〜2件添える(サイズ・数量誤認=「思ったより小さかった」「Mサイズなのに大きく感じた」など、実際に届いた文面を紐づける)。
  • 例文があることで、翌月以降に人が分類するときも、AIに分類させるときも、基準がブレなくなる。

この分類辞書は一度作って終わりではなく、新しいパターンの返品理由が出るたびに例文を追加していく「育てる辞書」として扱います。辞書が育つほど、後段の自動分類の精度も上がります。

カテゴリとページ要素のマッピング表を固定資産にする

分類ができても、「では商品ページのどこを直すか」が担当者の裁量に委ねられていると、改善のスピードも質も安定しません。カテゴリごとに直すべきページ要素をあらかじめ対応させたマッピング表を作り、分類が決まった瞬間に着手すべき作業が自動的に決まる状態にします。

  • サイズ・数量の誤認 → 採寸表の追加、着用モデルの身長・着用サイズの明記、完成サイズと梱包サイズの併記。
  • 色・質感のイメージ相違 → 複数光源での撮影画像の追加、色名表記の明確化(メーカー公式カラー名の併記)、実物との色差が生じ得る旨の注記。
  • 品質・機能の期待外れ → 「高耐久」「防水」などの抽象表現を、耐荷重・等級・厚みといった数値化された表現へ置き換える。
  • 付属品・セット内容の誤解 → 同梱物リストの明記、別売り品の強調表示、商品タイトルと説明文の同梱情報の整合確認。

マッピング表は作業台帳そのもの

このマッピング表は資料として一度作って終わりにするものではなく、商品ページ改善の作業台帳そのものとして運用します。返品理由が分類された時点で、担当者はマッピング表を参照し、該当するページ要素の欄にチェックを入れて改善タスクを起票する。分類からタスク化までの間に「どう直すか考える」工程が挟まらないため、対応スピードが安定します。想定外の誤認パターンが出るたびに行を追加し、これも育てていきます。

全部は直さない。月次の改善キューで上位3件に絞る

分類とマッピングが整っても、返品が出るたびに商品ページを直していては手が回りません。返品対応で失敗しやすいのは、全商品・全カテゴリを一度に直そうとして、結局どれも中途半端なまま止まるパターンです。運用ループとして回すには、月に1度、改善対象を機械的に絞り込むキュー化の工程が必要です。

優先度は「件数 × 1件あたりの損失額」で出す

優先度づけの考え方を、仮の数値で説明します。以下はすべて仮定の試算です。

  • 仮に、ある月の返品が全体で40件、うち「サイズ・数量の誤認」が16件(全体の40%)を占めていたとします。
  • 一方「付属品・セット内容の誤解」は6件と件数は少ないものの、対象商品の単価が高く、1件あたりの損失額がサイズ誤認の3倍相当だったとします。
  • 件数だけを見ればサイズ誤認が最優先に見えますが、件数×1件あたり損失額で並べ替えると、付属品誤解の優先度がサイズ誤認に迫る、あるいは逆転することがあります。
  • 件数ベースと金額ベースの両方で順位を出し、どちらの上位にも共通して現れるカテゴリ・商品から着手するのが実務的です。

キューの運用ルール

  • 月1回、前月分の返品理由データを分類・集計し、優先度順にリスト化する。
  • 上位3件(カテゴリまたは商品単位)だけを当月の改善対象として着手する。それ以上は翌月に持ち越す。
  • 着手した案件には「対応中」「対応済み・検証待ち」「効果確認済み」のステータスを付け、翌月の集計時に引き継ぐ。
  • 対応済みの案件は、効果検証が終わるまでキューから完全には外さない。効果が出ていなければ再着手の対象に戻す。

「気になったものから直す」のではなく「毎月機械的に上位3件だけ直す」というルールにすることで、改善作業が担当者の熱意に左右されず、淡々と回り続ける状態になります。

AIとGASの線引き:どこを自動化し、どこを人が持つか

この運用ループを複数商品・複数モールで回そうとすると、分類・集計・タスク化のすべてを手作業で行うのは現実的ではありません。一方で、すべてを自動化してよいわけでもありません。relmeaの現場では、工程ごとに役割を次のように分けています。

  • 自由記述の返品理由テキストの分類 → AI(表現の揺れを吸収し、分類辞書に沿ってカテゴリ判定させる)。
  • 分類結果の集計、件数×損失額での優先度算出、月次キューの生成 → GAS(スプレッドシート上の定型集計・並べ替え・リスト生成)。
  • 改善案のたたき台生成(文言の初稿、注記文の候補) → AI
  • ページ文言の最終確定、掲載可否の判断 →

最終確定を人が持つ3つの理由

分類や集計は定型作業のため自動化に適していますが、商品ページの文言確定は全自動にしません。理由は3つあります。誤分類が一定割合で混ざるため人の目でのスポットチェックが要ること。ブランドのトーンや表現を最終的に統一する判断が必要なこと。そして、景品表示法など表示に関する規制に抵触しない表現かどうかの確認は人が担う必要があることです。AIとGASは分類・集計・たたき台生成までを引き受け、「何を最終的にページに載せるか」の判断は人が持つ、という線引きにしています。

効果検証の落とし穴:数字が読めない状態を避ける

改善を実施した後、返品率の変化を確認する工程で、実務上つまずきやすい点がいくつかあります。

  • 母数が小さいとブレが大きい:月間販売数が数十件程度の商品では、返品が1〜2件増減するだけで返品率が数ポイント動きます。効果があったと判断するには、一定の販売数と観測期間が必要です。
  • 季節や商品構成の変化が混ざる:改善前後で季節や取り扱い商品の構成が変わっていると、返品率の変化が改善によるものか季節要因によるものかを切り分けられません。
  • 返品には計上ラグがある:返品は購入から一定期間を置いて発生するため、直近の集計ほど「まだ計上されていない返品」の分だけ実態より低く見えます。

落とし穴を避けるための運用ルール

比較は同一商品・同程度の販売数がある期間同士で行い、改善実施から最低でも1〜2か月の観測期間を置いてから判断することを基本にします。可能であれば前年同時期との比較も併用し、季節要因を分離します。返品の計上ラグを踏まえ、直近1か月の数字だけで「効果なし」と早期に判断しないことも重要です。なお、返品率の目安水準や許容ラインは商材・モールによって大きく異なるため、この記事では業界平均値を断定しません。返品・キャンセルのルールや出店者評価への反映有無は、各モールの公式ヘルプで必ず確認してください。

複数モールで返品理由の粒度が違う問題への現実解

複数モールで運営していると、返品理由データの取得可否・粒度がモールごとに異なるという壁に必ず当たります。

  • 返品理由が定型の選択肢として蓄積され、CSVなどでエクスポートしやすいモール。
  • 返品理由が購入者の自由記述でしか残らず、定型分類が用意されていないモール。
  • 返品自体は把握できても、理由データそのものを出店者側から十分に取得できないモール。

どのモールがどれに当たるかは仕様変更で変わるため、各モールの公式ヘルプ・出店者向けガイドラインで随時確認が必要です。

取れないモールは代替データで補い、物差しは統一する

理由データを十分に取得できないモールについては、返品には至らなかったものの不満が示された低評価レビューや、購入後の問い合わせ内容を代替データとして扱い、同じ分類辞書に当てはめます。重要なのは、モールごとに別々の分類基準を作らないことです。共通の10前後の固定カテゴリに全モールのデータを正規化すれば、「モールAでは付属品の誤解が多いが、モールBでは同じ商品でサイズ誤認が多い」といったモール間の傾向差も横断的に比較できます。取得できるデータの量や粒度が違うことは前提として受け入れつつ、分類の物差しだけは統一する。これが現実的な落とし所です。

分類辞書、ページ要素へのマッピング、月次のキュー化、AIとGASの役割分担、効果検証のルール、複数モールでの正規化。これらを一つずつ仕組みとして組んでおくことで、返品対応は「気づいたときにだけやる分析」から「毎月決まった手順で回り続ける運用」に変わります。最初に分類辞書とマッピング表を設計しておくことが、この運用ループ全体の土台になります。