AIで問い合わせ返信テンプレートを作る方法

問い合わせ返信テンプレートをAIで作るときは、文章だけを固定せず、「どの問い合わせで使うか」「どこを担当者が埋めるか」「何を根拠に答えるか」「どの条件なら送信を止めるか」を一緒に決めます。テンプレートは自動返信の完成形ではありません。確認済みの回答を素早く組み立てるための下書きです。

先に問い合わせを「同じ答えで解ける単位」に分ける

「料金」「不具合」と大きく分類すると、状況によって回答が異なる問い合わせまで一つの文面へ押し込んでしまいます。質問の見た目ではなく、必要な確認と回答根拠が同じかで分けます。

表は横にスクロールできます

大分類	テンプレート候補	別対応へ回す条件
ログイン	パスワード再設定の案内	登録メールを確認できない、本人確認が必要
請求	請求書の確認方法	金額差、返金、契約固有の条件
障害	障害状況と次回更新予定の案内	原因や復旧予定が未確定
使い方	操作手順と公式ヘルプの案内	画面が異なる、権限・プラン条件が不明
解約	契約画面での確認方法	解約期限、請求、返金など個別条件が関係

上記はテンプレート設計の例で、特定企業の現行サポート方針ではありません。実際の返信は、最新のFAQ、契約条件、障害情報を確認して作ります。答えが契約・本人確認・例外規則で変わる場合、共通文だけで解決したことにしないでください。

テンプレートを「固定文・可変欄・根拠・停止条件」で設計する

表は横にスクロールできます

要素	例	運用ルール
固定文	問い合わせへのお礼、次の確認事項	問い合わせ内容を決めつけない
可変欄	対象機能、確認期限、ヘルプURL	空欄のまま送信できないよう表示
根拠	Help Center、料金表、障害告知	管理者が更新できる正本へリンク
停止条件	返金、個人情報、法的申立て、原因不明	担当者または専門チームへ移す
次の行動	顧客が行う操作、担当者が返す期限	期限を守れる場合だけ約束する
更新責任者	Support Opsなど	owner、確認日、次回見直しを記録

可変欄は、本文に波括弧で書くだけでは十分ではありません。項目名、形式、入力例を決め、担当者が何を入れるべきか明確にします。たとえば「確認期限：[日時]」なら、社内の応答目標と時差を考慮した期限を入れ、未確定の場合は約束の文章を削るというルールが必要です。

AIへ渡す材料と指示

返信案を作らせるときは、顧客の問い合わせ、確認済みの事実、根拠リンク、返信方針、利用できない情報を分けます。注文番号や氏名などが不要なら、入力前に伏せるか、承認済みのサポート環境で処理します。環境ごとの入力・保存ルールを確認せず、実顧客の情報を個人向けAIへ貼り付けないでください。

【Prompt例】

あなたはサポート担当者の返信案を作ります。問い合わせの解決結果を確定しないでください。

確認済みの情報：問い合わせ分類／顧客へ伝えてよい事実／回答の根拠URL／次の操作／返信期限（確定している場合のみ）／停止・引き継ぎ条件。

出力：返信案／事実に使った入力項目／根拠URLで担当者が確認する項目／不足情報。なければ「不足なし」／停止条件に当てはまる場合は送信せず「担当者へ引き継ぎ」。

入力にない料金、返金条件、障害原因、完了予定を補わないでください。顧客を責める表現や、確認できていない謝罪・保証を追加しないでください。

初期の運用では、AI案をそのまま送信せず、担当者が根拠URLを開きます。承認済み環境であっても、モデルが最新の契約やアカウント状態を把握しているとは限りません。根拠が見つからないときに一般知識で埋めるのではなく、回答を保留して担当者へ回します。

IntercomのMacroと一般的な返信テンプレートの違い

IntercomのMacrosは、共通のメッセージ内容だけでなく、会話へのタグ付け、担当割当、snoozeやcloseなどの操作をまとめられます。Inboxでは適用後にメッセージを編集してから送信できます。つまりMacroは文章の再利用に加えて操作を実行する可能性があるため、「文面を入れるテンプレート」と「会話状態を変えるAction」を別々にテストしてください。

チームやComposer種別によって利用可否・権限が異なり、モバイルアプリではmacro actionに制限があります。現在の利用条件はIntercomの公式ヘルプと自社Workspaceで確認します。AIで文章だけを作る運用なら、Macroの動作を再現する必要はありません。既存サポートシステムの機能を使う場合だけ、その機能を前提に手順を書きます。

実案件を送らずにテストケースを作る

まず架空の問い合わせで、通常ケース、情報不足、個別条件、障害中、個人情報の五つを試します。操作ActionがあるMacroなら、送信せず確認できるテスト環境で割当・タグ・closeなどの副作用も確認します。

表は横にスクロールできます

テストケース	入力の状態	期待する案	送信前に見る箇所
通常のログイン案内	正本Helpがあり操作条件が明確	該当手順とリンクを提示	URLと画面名
対象アカウント不明	どのログイン方式か不明	追加質問を作る	方式を推測していないか
請求金額への異議	契約・請求情報が未確認	人へ引き継ぐ	返金を約束していないか
障害中	障害告知に復旧時刻なし	確認済み状況だけ案内	復旧予定を捏造していないか
個人情報の誤送信	不要な識別情報が入力にある	返信前に停止・社内手順へ	返信に情報を再掲していないか

通過しなかったケースは、文章を直す前に、分類・根拠・停止条件が足りるかを見ます。テンプレートに「丁寧に答える」と加えるだけでは、誤った回答の原因を解消できないからです。

送信前の確認を担当者の動線へ入れる

担当者が毎回長いチェックリストを覚えるのではなく、画面や運用手順で間違いを見つけられるようにします。返信案の直後に、以下の順に確認します。

1. 問い合わせの分類が合っている。

2. 返信の事実が現行のFAQ・契約・障害情報で確認できる。

3. 顧客固有の状態や入力欄を正しく照合した。

4. 空欄、仮文、期限切れのURLが残っていない。

5. 返金・契約・安全・法務など、引き継ぎ条件がない。

6. 会話へ付けるActionが文面と矛盾しない。

7. 返信を送ったあと、担当者と次回連絡の責任が明確である。

優先して人へ回す例は、契約固有の解約や請求、重大な不具合、個人情報の削除請求、法的な申立て、顧客の安全に関係する相談、回答根拠が見つからない質問です。ここで挙げた分類は一般例なので、実際の停止条件は組織のサポート・法務・セキュリティ方針に合わせます。

テンプレートを古くしない管理

公開FAQや社内規則が更新されると、返信テンプレートは静かに古くなります。Templateごとに、owner、使う問い合わせ、根拠URL、確認日、次の見直し条件を登録します。価格改定、画面変更、利用規約更新、障害対応手順の変更があれば、定期日を待たず見直します。

変更時には本文だけでなく、Macroに含まれるタグ・割当・closeなどのActionも確認します。削除や変更の権限が限られるWorkspaceでは、管理者の承認を運用に入れます。利用回数が多いから正しいとは限らず、誤回答や引き継ぎ漏れが見つかったテンプレートは一時停止できる手順を用意してください。

AIものさしの判断

問い合わせ返信でAIが価値を出すのは、担当者の知識を置き換えることではなく、確認済みの回答をわかりやすく整え、抜けた情報と引き継ぎ条件を見つけることです。固定文、差し替え欄、根拠、停止条件、送信前確認が一体になっていれば、テンプレートを再利用しても個別案件を雑に扱いにくくなります。

まずは問い合わせ分類を一つ選び、現行FAQを根拠にした架空ケースで返信案と停止ケースを試します。送信前編集やMacro actionの挙動を、自社のIntercom構成で確認してください。AI案を自動送信する範囲を広げる判断は、誤回答時の影響、監視方法、停止手段を決めてから別途行います。

導入前の確認表

運用へ入れる前に、実際の担当者がどの問い合わせでテンプレートを使い、どこで確認を止めるかを紙上で追います。

表は横にスクロールできます

確認点	問い
利用者	誰がテンプレートを選び、誰が本文を送るか
権限	共有、個人用、チーム限定のどれか。編集権限者は誰か
内容	回答根拠と更新責任者が明確か
Action	タグ、担当割当、snooze、closeのうち何が走るか
例外	未確定・契約固有・機微な問い合わせをどこへ回すか
停止	誤回答や古いURLが見つかったとき、誰が一時停止するか

一つでも答えられない欄があれば、利用を広げる前にownerを決めます。個人用Macroを共有化する場合や、チーム単位の可用性を設定する場合は、Intercomの権限とプラン条件を管理者に確認します。サポート担当者が編集後に送る運用と、AIが直接送信する運用は別のリスクとして扱い、後者へ変更する場合は別途承認を取ります。

返信品質を測るときは、誤りも同じ重さで見る

テンプレートを導入した後に「平均返信時間が短くなった」だけを見ても、顧客へ正確な案内が届いたかは分かりません。導入前後で対象となる問い合わせ、期間、受付チャネル、担当者の構成が大きく違えば、数字の変化をテンプレートの成果と断定できないためです。

表は横にスクロールできます

観測するもの	何を知るためか	変化があったときの確認
初回返信までの時間	返信準備が早くなったか	早くても必要な確認を省いていないか
再問い合わせ	1回の案内で解決したか	問い合わせの受付方法が変わっていないか
訂正・謝罪が必要だった返信	根拠や可変項目が正しいか	どのテンプレート版・入力欄が原因か
担当者への引き継ぎ	停止条件が機能したか	不要な引き継ぎ・引き継ぎ漏れがないか
顧客の未解決申告	文面が実際の問題を解いたか	FAQと手順が現行か、ケースが個別か

最初に基準期間と集計定義を書き、公開障害や料金改定など大きな変化を別に記録します。少数の利用で数値が動いた場合は結論を急がず、誤送信や訂正を含む実例をサンプルレビューします。返信速度だけを改善し、正確さや引き継ぎを犠牲にしていないかを確認できる形にしてください。