なぜテンプレートを作っても「使われない」のか

多くのEC担当者は、一度は問い合わせテンプレートを作った経験があると思います。しかし実際の現場では、テンプレートを用意しても使われず、結局ゼロから返信を書いてしまうケースが目立ちます。原因の多くは、分類が細かすぎることです。

型を10種類、20種類と増やすほど、「今回はどのテンプレートを使えばいいか」を判断するコストが上がります。探す時間が、一から書く時間とほとんど変わらなくなった時点で、担当者はテンプレートを開かなくなります。効率化のための仕組みが、逆に一手間を増やしてしまう典型的な失敗です。

  • 分類名が細かすぎて、どれに当てはまるか判断に迷う
  • テンプレートの保管場所が分散していて、探すのに時間がかかる
  • 微妙に状況が違うたびに新しい型を追加し、際限なく増えていく

型が増えすぎたら、使われていない型を消す

運用を続けると、当初は使われていた型でも、商品ラインナップの変更やページ改善によって問い合わせ自体が来なくなることがあります。件数がほぼゼロになった型は、残しておいても検索の手間を増やすだけです。月次の集計で件数がゼロに近い型を見つけたら、削除するか、他の型に統合します。型の総数を増やす判断だけでなく、減らす判断も同じ頻度で行うことで、テンプレート一覧が使いやすい状態を保てます。

分類は作り込まず、実際に来た問い合わせを数える

テンプレートを機能させる出発点は、分類をきれいに設計することではなく、実際に届いた問い合わせを一定期間集計することです。過去1〜3ヶ月分の問い合わせを、配送状況・在庫確認・仕様質問・返品交換・使い方相談といった項目でざっくり数え、件数の多い順に並べます。

この集計結果のうち、上位3〜5型だけをテンプレート化の対象にします。件数が少ない型まで無理に型にする必要はありません。個別対応のまま残しておいたほうが、テンプレートの総数を絞れて運用しやすくなります。まず数える、次に上位だけ型にするという順序が、実際に使われるテンプレートを作る近道です。

  • 1〜3ヶ月分の問い合わせ件数を項目別に集計する
  • 件数の多い順に並べ、上位3〜5型に絞る
  • 残りは個別対応のままにし、型を増やしすぎない

テンプレートの中身をどう作るかも、実際に使われるかどうかを左右します。そのまま送れる完成文にすると、状況に少しでもズレがあった場合に使えず、結局担当者が書き直すことになります。逆に空欄だらけの穴埋め式にすると、埋める部分を考える負担が残り、テンプレートを作った意味が薄れます。実務では、挨拶・状況説明・締めの文言は完成文で固定し、注文番号・商品名・日付・金額など個別情報が入る箇所だけを穴埋めにする、という中間の形にすると使われやすくなります。穴埋め箇所は3〜4か所までに絞り、それ以上増えるようなら、そもそもその型を細分化しすぎている可能性があります。

AIに任せる部分と人が判断する部分の線引き

上位の型が固まったら、返信文の下書きをAIに作らせる工程を組み込みます。ただし「AIに全部任せる」のではなく、どこまでを任せ、どこから先を人が確認するかの線引きが、運用の質を決める最も重要な部分です。

線引きの基準は、「事実の照会か、文面の組み立てか」で分けることです。在庫の有無・納期・仕様・価格といった事実は、必ず人が受注管理システムや在庫データを見て確認してから返信に反映します。AIに在庫状況や納期を推測させて書かせると、実際の状況と異なる案内をしてしまうリスクがあります。

一方で、確認済みの事実を丁寧な文章に組み立てる作業、敬語の調整、状況に応じた言い回しの選定は、AIの下書きに任せて問題ありません。人は「事実が正しいか」「トーンが型から外れていないか」を最終確認する役割に専念します。この分担にすることで、事実確認の精度と返信作成の速度を両方確保できます。

  • AIに任せる範囲: 確認済みの事実を文章に組み立てる、言い回しやトーンの調整、定型の挨拶・締めの文言
  • 人が担う範囲: 在庫・納期・仕様・価格などの事実確認、送信前の最終チェック、型から外れる個別事情の判断

AIに下書きを作らせる時に渡す材料

AIに下書きを作らせる際は、注文情報（注文日・商品名・数量）、商品仕様（サイズ・素材・使用方法など公開情報）、過去の類似対応で使った文面の3点を渡します。渡す情報は事実として確定しているものだけに絞ります。

逆に、在庫の残数や配送予定日など、確認前の推測情報は渡しません。AIに「たぶんこうだろう」と埋めさせると、その推測がそのまま文面に反映されてしまいます。確認が済んでいない項目は空欄のまま下書きさせ、人が数値を確認してから埋める、という順序を徹底します。

AIの下書きをそのまま送ってはいけない箇所の見分け方

下書きを確認する際は、文中に日付・金額・在庫数・可否（対応できる／できない）の断定が含まれているかを必ずチェックします。これらの項目は、AIが与えられた材料から推測で埋めている可能性があるためです。断定表現が入っている文は、送信前に必ず元データと突き合わせ、事実と一致しているかを人が確認してから送信します。

謝罪・返金・トラブル対応はAIに書かせない

上位型のうち、謝罪・返金・キャンセルといった金銭や信頼に関わるやり取りは、下書き段階からAIに任せず、人が書きます。理由は、これらの対応には会社としての損得判断や、個別事情への重み付けが必要になるためです。

定型文をそのまま当てはめると、事情の重さに見合わない対応になり、かえって信頼を損なう場合があります。速さより正確さと配慮が優先される型では、AIは使わず人が最初から最後まで責任を持って書く、という線を明確にしておきます。

型ごとに「速さ」と「正確さ」の優先順位を決めておく

配送状況の確認のように、事実がシステム上で即座に確認できる型は、速さを優先して当日中の返信を目標にできます。一方、仕様や適合の質問のように確認に時間がかかる型は、正確さを優先し、確認が取れてから返信する方針を先に決めておきます。

型ごとに優先順位を事前に決めておくと、担当者は毎回「急ぐべきか、確認を待つべきか」を都度判断せずに済みます。判断基準を仕組み側に持たせることで、対応者の負荷そのものを減らせます。

仕様確認のように即答できない型では、いったん「受領しました、確認のうえ改めてご案内します」という受領連絡だけを先に返す運用も選択肢になります。受領連絡を挟むことで、相手を待たせている時間の不安を減らせます。ただし、この運用は本回答と合わせて二度手間になる場合があります。確認にかかる時間が数時間以内で収まる型では、受領連絡を省いて本回答だけを返したほうが、全体の対応工数は少なく済みます。受領連絡を入れるかどうかも、型ごとに事前に決めておく判断基準の一つです。

  • 配送状況・注文確認など即答できる型: 速さを優先する
  • 仕様・適合・カスタマイズ相談など確認が要る型: 正確さを優先する
  • 謝罪・返金など信頼に関わる型: 人が判断し、速さより丁寧さを優先する

同じ問い合わせが繰り返し来るなら、商品ページを直す

型を作って運用を続けると、特定の型の件数が減らない、あるいは増え続けることに気づく場合があります。その場合に見直すべきは返信文の質ではなく、商品ページやFAQ、購入導線側の情報です。

同じ質問が繰り返されるのは、多くの場合、購入前に必要な情報がページ上で伝わっていないサインです。サイズ・素材・使用方法・納期の目安などをページや同梱物に先回りで記載すれば、問い合わせそのものが発生しにくくなります。返品理由を分類してページ改善に戻す運用は別記事で詳しく扱っていますが、問い合わせについても同じ発想で、月次に上位型の件数を振り返り、増減を記録しておくと改善の効果を確認できます。

記録の残し方は、問い合わせ管理シートに型ごとの件数と、ページ改善の実施日をあわせてメモしておく程度で十分です。月次で件数の推移を見返し、減っていなければページ側の記載を見直す、というサイクルを回します。

  • 型ごとの月次件数を記録し、増減を追う
  • 件数が減らない型は、返信文でなく商品ページ・FAQ側の情報不足を疑う
  • ページ改善の実施日を記録し、効果を月次で確認する

一人で運営している場合の現実的な対応時間の決め方

担当者が一人しかいない体制では、すべての問い合わせに即応することは現実的ではありません。対応可能な時間帯（例えば平日の決まった時間帯）をページ上やメール自動返信に明記し、その時間外に届いた問い合わせは翌営業時間にまとめて対応する、という運用を先に決めておきます。

対応時間を公開しておくこと自体が、相手の期待値を調整し、催促の再送を減らす効果があります。時間を区切らずに「なるべく早く返す」とだけ決めていると、対応できない時間帯にも気力を割いてしまい、他の業務に支障が出ます。対応時間の外では返さないと決めることも、型と分担の設計の一部です。