ECサイトの問い合わせ対応を自動化する方法｜業務分類と有人切替

ECサイトの問い合わせは、購入前の商品選びから注文後の配送、返品・交換まで、異なる判断を含みます。AIを設置するだけで全てを自動化できるわけではありません。先に「根拠を示して案内できる質問」と「注文情報や担当者の判断が必要な質問」を分けることが重要です。

少人数で運営する店舗では、正本が明確で、回答条件を更新できる定型案内から小さく始めるのが基本です。AIには同じ説明を繰り返す役割を持たせ、返金の確定、例外の承認、配送事故への対応などは人へ渡します。この記事では、業務分類、正本の整備、公開前テスト、有人切替、公開後30日の見直しを一続きの運用として整理します。

ECの問い合わせを四つに分類する

最初に、過去の問い合わせを商品、注文、配送、返品・交換の四つに分けます。決済、会員、店舗受け取り、定期購入などが多い店舗は、その分類も追加します。件数を数えるだけでなく、「何を見れば答えられるか」「誰の判断が必要か」「間違えた場合の影響は何か」を各分類に付けると、自動化の順番が見えます。

商品に関する質問

素材、寸法、使用方法、付属品、サイズ表の見方などです。商品ページや仕様書が正しく、更新担当者が決まっていれば一次案内に向きます。一方、「自分の体型に必ず合うか」「特定の症状があっても使えるか」のように個人差や安全性を含む質問は断定せず、注意事項や相談窓口を示します。

注文に関する質問

注文方法、支払方法、変更やキャンセルの手順には共通案内があります。ただし、「自分の注文を変更してほしい」「キャンセルが完了したか確認したい」という依頼は、本人確認、注文情報へのアクセス、操作権限が必要です。利用環境で連携と権限を確認できない場合は、AIが完了を装わず注文窓口へ渡します。

配送に関する質問

発送条件、対象地域、通常の配送日数、追跡方法は一般案内にできます。「発送まで何日か」と「私の荷物が今どこにあるか」は別の質問です。後者は個別の配送情報を確認する必要があり、遅延、紛失、破損を伴う場合は担当者の対応が必要になります。

返品・交換・返金に関する質問

返品期限、対象条件、申請方法など、規約に書かれた一般条件は説明できます。しかし、商品の状態を判定する、対象外の商品に例外を認める、返金を確定するといった行為は規約の説明とは異なります。AIが受付に必要な情報を整理し、結論を出す権限を持つ担当者へつなぎます。

正本とAIの回答範囲を対にして決める

正本とは、回答の根拠として採用する情報源です。商品仕様なら承認済みの商品情報、送料や発送条件なら配送案内、返品なら最新の返品規約というように、一つの論点に対する基準を決めます。同じ条件を商品ページ、社内メモ、古いPDFに重ねて持つと、更新後も以前の内容が残り、回答が揺れます。

正本には、内容だけでなく所有者、更新者、承認者、確認日を付けます。商品や規約が変わったら、旧情報の参照を止め、新情報を照合し、関係する質問を再テストしてから運用へ戻します。毎週確認する情報と、規約変更時だけ確認する情報を分ければ、全資料を毎回読み直さずに済みます。

FAQには、結論だけでなく適用条件と次の行動を書きます。「返品できます」ではなく、対象期間、商品の状態、対象外、申請方法、判断が必要な場合の窓口を分けます。数字、曜日、金額、商品名、型番は登録後に原本と照合します。画像やPDFを参照情報にする場合も、読み取り結果に欠落や表のずれがないか確認が必要です。

正本は回答内容を決める資料、運用ルールは回答を止めて人へ渡す条件を決める資料です。両者を混ぜて同じ説明を何度も書くのではなく、「何を根拠に答えるか」と「どこから人が判断するか」を対応させます。この対応表が、公開前テストと公開後レビューの共通基準になります。

一つの問い合わせを回答から記録まで通して設計する

自動化の境界は、抽象的な規則だけでは判断しにくいため、実際の問い合わせを最初から最後まで追って確認します。ここでは「昨日届いた靴を室内で試着しました。タグを外した後にサイズが合わないと分かりましたが、返品できますか」という質問を例にします。

1. 質問を分類する。中心は返品ですが、商品状態、到着日、購入経路、注文の特定も関係します。「返品」という単語だけで定型回答を返さず、一般条件の案内と個別判断を分けます。
2. 参照情報を決める。最新版の返品規約、対象商品の返品対象外条件、返品申請の手順、有人窓口を参照します。担当者が注文を確認する段階では注文情報も必要ですが、AIがその情報を直接参照できるかは利用環境と権限を確認します。
3. AIが答える範囲を限定する。規約に書かれた期限、未使用・試着・タグなどの一般条件と申請手順は、そのまま案内できます。受付に必要であれば、注文番号、購入経路、到着日、試着場所、商品の状態を必要最小限で確認します。確認できない注文状況や返品の承認結果は答えません。
4. 要確認となる理由を説明する。タグを外したことや試着後の状態が規約上どの条件に当たるかは、文章だけでは確定できない場合があります。AIは単に「分かりません」と返すのではなく、「商品の状態確認が必要なため、この場では返品可否を確定できない」と理由を示します。
5. 有人対応へ引き継ぐ。担当者には、質問の要約、確認済みの項目、参照した規約、未確認の項目、顧客が希望する対応を渡します。顧客には、窓口と次の手順を案内します。返信時期を保証できない場合は、確実に守れる表現にとどめます。
6. 結果を記録する。問い合わせ分類、参照した正本の版、AIが案内した内容、切替理由、担当者の最終判断、追加で確認した項目を残します。次回も同じ追加質問が必要ならAIの確認項目を見直し、例外判断だったなら自動回答の範囲は広げません。

このケースの引継ぎ票

担当者に会話全文だけを渡すと、結論に必要な情報を探し直すことになります。引継ぎ票は、AIが確認した事実と、まだ確認できていない判断を分けて書きます。このケースなら、次のように一画面で把握できる形にします。

担当者が追加で商品の写真や購入時の条件を確認したなら、その事実も残します。ただし、一度の例外承認を新しい一般ルールとして扱ってはいけません。正本を変更する場合は規約の所有者が承認し、該当する代表質問と境界質問を再テストします。こうして個別対応の記録を運用改善へ戻すことで、AIが次回確認すべき情報と、今後も人が判断すべき領域を混同せずに済みます。

一つの窓口で公開前テストを行う

最初から全商品、全ページ、全時間帯へ広げず、問い合わせが多く、正本が整っている商品群やページを選びます。対象ページ、対象商品、回答する分類、回答しない範囲、有人窓口を明記します。利用できるWeb埋め込み、公開設定、チャネル連携、注文情報の参照範囲は、Socratesの最新仕様と契約内容で確認してください。

公開前テストでは、正しい答えが返るかだけでなく、情報が足りないときに確認質問をするか、判断が必要なときに回答を止めるかを見ます。商品ページごとの情報と全店共通の規約を混同していないか、回答の冒頭に結論と次の行動があるかも確認します。

誤りを見つけたら、原因を正本、質問の解釈、回答境界、有人窓口のどこにあるか切り分けます。送料が古いなら正本と参照停止を直し、商品を取り違えるなら商品固有情報の分け方を直します。例外返品を承認してしまうなら、言い回しだけでなく切替条件を直します。一度に複数箇所を変えず、同じ質問群で再テストすると、修正が有効だったか判断できます。

公開できる状態とは、全質問に答えられる状態ではありません。重要な定型案内が正しく、答えられない質問が明確な理由とともに人へ渡り、担当者が引継ぎ情報を使って対応を始められる状態です。公開前に、停止を判断する責任者と、問題発生時に対象範囲を縮小する手順も決めます。

公開後30日は記録と再テストを一つの運用にする

公開後のレビューは、会話数や自動化率だけを見る作業ではありません。正答、情報不足、未解決、有人切替を分類し、切替後に担当者が何を追加で聞いたかまで確認します。AIの案内時点を受付、担当者が判断や処理を終えた時点を解決として分けると、無理な自己解決を成果として数えずに済みます。

運用表には、質問分類、参照した正本、正誤、未解決理由、切替理由、追加確認、最終結果、修正内容、再テスト日を残します。同じ質問の再発が正本の不足によるものなら情報を更新し、質問の曖昧さによるものなら確認質問を直します。人の裁量が必要だったケースは、回答例を増やして自動完了に寄せず、切替条件の妥当性を確認します。

毎週は未解決と切替理由を確認し、商品や規約の変更時は通常の周期を待たず、関係する質問を再テストします。大型連休、キャンペーン開始・終了、送料改定の前後も同様です。月末には、自動化対象を広げる、維持する、縮小するの三択で判断し、理由と次回確認日を残します。

対象を広げられるのは、定型案内が安定し、正本の更新担当者が明確で、有人切替後の再質問が減り、変更後の再テストを継続できる場合です。たとえば商品仕様の案内が安定した後に配送の一般条件を加えても、配送事故や個別追跡は人へ残せます。注文操作や自動返金は、利用できる連携と権限を確認できない限り前提にしません。

問い合わせ件数、購入率、売上の変化は参考になりますが、AIだけの効果とは断定できません。広告、価格、在庫、季節、キャンペーン、配送遅延など、同時期の要因を記録してください。まず見るべきなのは、重要回答が正しいか、利用者が次の行動を理解できたか、例外が適切な担当者へ渡ったかです。詳しい運用整理はチャットボットの運用ルールの作り方も参考になります。

よくある質問

関連ガイド

• 問い合わせの優先順位を決める方法
• FAQチャットボットの導入チェックリスト
• AIから有人対応へつなぐ設計
• WebとLINEの問い合わせ導線