問い合わせ対応の返信文を生成AIで ── テンプレート化する手順と、そのまま送ってはいけない場面
問い合わせ対応に生成AIを入れる話になると、たいてい「返信が速くなりますか」と聞かれます。速くはなります。ただ、それは本題ではありません。
現場で効いてくるのは、返信の品質がそろうことのほうです。同じ質問に、ベテランは3行で的確に答え、入社半年の担当者は10行書いて要点が抜ける。この差がクレームの種になり、二次問い合わせを生みます。返信を型にしてAIに下書きさせると、この振れ幅が小さくなります。
この記事は二部構成です。前半で、過去ログからテンプレートを作るまでの5段階を書きます。後半は、AIの下書きをそのまま送ってはいけない場面を、独立させて書きます。後半のほうが実務では大事です。登場する数字と場面は架空の想定例で、実際の顧客事例ではありません。
速さではなく、振れ幅が縮むことが効果
返信が5分早くなっても、顧客はたいてい気づきません。気づくのは、回答が担当者によって違うときです。
相談は時間短縮の話から始まることが多いのですが、社内で実際に問題になっているのは、たいてい次の3つです。誰が答えても同じ結論になるか。過去の回答と食い違わないか。新しく入った人が、ベテランの水準に近づくまでどれくらいかかるか。
テンプレートとAIの下書きは、この3つに効きます。所要時間はその副産物です。
手順は5段階
1. 過去の返信を集める
直近3か月ぶんの送信済みメールとチャットの返信を、まとめて書き出します。件数が少なすぎると分類の傾向が見えず、多すぎると読み切れません。目安は300〜500件です。
このとき、対応した担当者の名前も残しておきます。「誰の返信を型の下敷きにするか」を選ぶ材料になります。
2. よくある問い合わせを分類する
集めた返信を、質問の内容で分類します。数え方は単純で、同じ趣旨の問い合わせを1つのグループにまとめ、件数の多い順に並べるだけです。
分類の粒度で迷ったら、次の基準で切ります。
- 回答の文面がほぼ同じになるものは、同じ分類にする
- 回答の結論が分かれるものは、分けた分類にする
- 件数が全体の1%未満のものは、いったん「その他」に入れる
- 分類は10〜15個までに収める。それ以上は運用できない
このやり方で並べると、上位10種類で全体の7割前後を占めるケースが多くあります。残りの3割に手を広げる前に、上位10種類を固めたほうが早く効きます。
分類をAIに手伝わせることもできます。指示の出し方は業務で使うプロンプトの型の4要素で組み立ててください。
3. 型を作る
分類ごとに、返信の型を1つ作ります。作り方は、その分類でいちばん出来のよかった返信を1通選び、顧客固有の部分を空欄に置き換えるだけです。
ゼロから理想の文面を書き起こす会社もありますが、あまりうまくいきません。実際に送って問題が起きなかった文面のほうが、社内の合意も取りやすいためです。
型に入れる項目は、おおむね次の5つで足ります。
| 項目 | 書くこと |
|---|---|
| 状況の確認 | 顧客が書いてきた内容を、こちらの理解として1文で返す |
| 結論 | できる/できない、いつまでに、いくらか |
| 理由 | 結論の根拠。長くしない |
| 次の手順 | 顧客にしてもらうこと、こちらでやること |
| 問い合わせ先 | 続きを誰にどう聞けばよいか |
4. AIに下書きさせる
型と、その問い合わせの内容をAIに渡して、下書きを出させます。渡すのは型と本文だけで、顧客の氏名・メールアドレス・注文番号は伏せます。
下書きの段階で指定しておくと手戻りが減るのは、分量と語調です。「300字以内」「敬体、謝罪の言葉は入れない」のように先に決めます。謝罪の扱いは後半で書きます。
5. 人が確定して送る
出てきた下書きを、担当者が確認して送信します。確認するのは4点です。結論が社内の基準と合っているか、事実と違う記述が混ざっていないか、約束していない期日が書かれていないか、この顧客に送ってよい内容か。
送信後、修正した箇所を型に反映します。ここを回さないと、型は3か月で古くなります。月1回、修正の多かった型を見直します。
そのまま送ってはいけない場面
ここからが本題です。下書きをそのまま送ってはいけない問い合わせが、はっきりあります。
クレーム。 顧客が怒っている問い合わせは、型から外します。文面の巧拙より、誰が、どの立場で応答するかが問われる場面です。
返金・補償の判断。 金銭が動く回答は、社内の決裁を経た内容だけを書きます。AIは過去の返信をまねて「返金いたします」と書くことがありますが、判断はしていません。
不具合の原因説明。 原因が特定できていない段階で原因らしき文章を出させると、もっともらしい推測が混じります。調査中は「調査中である」としか書かない、と型のほうに書いておきます。
契約内容の解釈。 規約のどの条項がどう適用されるか、という質問です。ここは法務または責任者の確認を通します。
謝罪が必要な場面。 次の節で分けて書きます。
この5つは、型の一覧に「AI下書き対象外」と明記しておくのが確実です。担当者の判断に任せると、忙しい日に線が動きます。
お詫び文をAIに書かせると、何が起きるか
謝罪の文章は、AIが最も器用に書く種類の文章です。そして、最も危ない種類でもあります。
よく起きるのが2つあります。ひとつは、責任範囲を勝手に広げること。こちらに非がない部分まで「弊社の不手際により」と書かれる。送ってしまえば、それが会社の見解になります。
もうひとつは、事実でない原因を書くこと。「システムの一時的な不具合により」という一文が、調査前に入る。あとで原因が別だと分かったとき、訂正の連絡がもう一往復増えます。
対処は、謝罪文を型から外すことではなく、謝罪の範囲を人が先に決めることです。「お待たせした点を謝罪する。原因には触れない」と決めてから下書きを頼む。この順番なら問題は起きにくくなります。
社外に出す文書の確認者を決める考え方は、提案書の初稿を出す4ステップでも触れています。作成者以外が確認する、という点は共通です。
顧客の個人情報を入力しない運用
問い合わせ本文には、氏名、住所、電話番号、注文番号、ときには事情まで書かれています。そのまま貼り付ける運用は、最初に止めます。
現実的なやり方は、貼り付ける前に置き換えることです。
| 元の情報 | 置き換え |
|---|---|
| 氏名 | 「お客様」 |
| 注文番号・会員番号 | 「(番号)」 |
| 住所・電話番号 | 削除する |
| 具体的な日付 | 「◯月◯日」に置換、または残す |
| 商品名・型番 | そのまま残してよい場合が多い |
下書きが出たあと、担当者が実際の氏名と番号を戻します。手間は1件あたり十数秒で、慣れると気になりません。
人手に頼らない方法として、問い合わせ管理システム側で伏字にしてから渡す構成もあります。ただ、仕組みを作るのに時間がかかるので、まずは手作業で構いません。入力してよい情報の線引きの決め方は、社内ルールは第3条と第8条だけ先に決めるにまとめました。
よくある質問
テンプレートを使うと、返信が機械的になりませんか?
型で固定するのは、結論と次の手順の並べ方までです。状況の確認の1文は、顧客が書いてきた言葉を使って毎回変わります。実際には、型がないほうが「よくあるご質問をご参照ください」のような定型で済まされがちです。型を決めるほうが、個別の事情に触れる余裕が生まれます。
分類は最初から完璧に作る必要がありますか?
いいえ。上位10種類ができれば運用を始められます。残りは「その他」に入れたまま、月1回の見直しで件数が増えたものを分類に昇格させる形で足ります。最初から30分類を作ると、担当者がどれを使うか選べなくなります。
問い合わせ対応は研修のテーマになりますか?
はい。過去ログの分類と、型を1つ作るところまでを演習にした形を想定しています。分類は自社のデータがないと作れないため、受講者が自社の問い合わせを匿名化して持ち込む前提です。実業務への展開は、研修後に受講者自身が行います。
型を作る前に、送らない範囲を決める
手順を5段階に分けて書きましたが、順番を入れ替えたほうがよい会社もあります。クレームと返金と原因説明をAIの対象外にする、という線を先に引いてから、残った範囲で型を作る順番です。
線を引かずに始めると、いちばん難しい問い合わせにAIの下書きが使われます。そこで一度事故が起きると、使える範囲まで含めて全部が止まります。
自社の問い合わせのどこから手をつけるか整理したい段階でも、お気軽にご相談ください。