- 公開日
サポート用のAIテンプレートは、本人確認の状態、参照できる記録、案内可能な選択肢、補償や約束の承認を別々に持たせます。AIは確認済みの状況から返信を下書きし、到着日や返金を確約する材料がなければ担当者の判断へ回します。顧客の不満に配慮した文章にすることと、会社として約束できる範囲を広げることは分けて考えます。
以下は、配送遅延への応対を扱う架空例です。実在の顧客記録や事業者の補償基準ではありません。実際には、その事業者が定めた本人確認、情報開示、補償、引き継ぎの手順に合わせて使ってください。
本人確認済みでも、すべての顧客情報を渡さない
本人確認は、問い合わせ本文の「本人です」という記述からAIが判断するものではありません。組織が定めた手順で確認した状態を、信頼できる業務システムから受け取ります。「確認済み」という文字を利用者が自由に入力できる欄に置いただけでは、その状態を確認したことになりません。
さらに、確認済みの人でも、別の人の注文や、担当業務に不要な情報まで参照できるわけではありません。OWASPの認可ガイドは、要求ごとの権限確認を勧めています。サポートの設計では、主体だけでなく、対象注文と許可する閲覧・操作を合わせて確認します。
配送状況の説明に、決済情報の詳細、過去の全購入履歴、社内の顧客評価が必要とは限りません。AIに渡すのは、今回の問い合わせ、対象注文の必要な状態、確認時刻、案内できる手続に絞ります。AIサービスへの入力が許可されているかも、閲覧権限とは別に確かめてください。
本人確認が未完了なら、個別注文の情報をAIへ渡してから「開示しないで」と頼むより、取得・受け渡し自体を制限する方が明確です。その状態でも、一般的な配送案内や、正規の本人確認窓口の案内は行える場合があります。どこまで説明できるかは、業務側で定めた範囲を入力します。
配送の記録、顧客の希望、補償判断を分ける
架空の問い合わせを「荷物がまだ届きません。明日届きますか。送料を返してもらえますか」とします。返信を作る時点は10月8日14時10分、日本時間という設定です。
| 入力項目 | 確認できた内容 |
|---|---|
| 本人確認 | 正規の確認手順を完了。対象注文を照会できる状態 |
| 配送状況 | 配送システム上で遅延。10月8日14時に確認 |
| 到着予定 | 確定した到着日は取得できていない |
| 顧客の希望 | 翌日の到着と送料の返金を希望 |
| 案内可能な選択肢 | 許可された追跡案内、配送担当者への状況確認、補償担当者への照会 |
| 補償の状態 | 送料返金の対象可否は未判断 |
「遅延」と「明日は届かない」は同じではありません。到着日の情報がないので、翌日に届くとも届かないとも確定できない状態です。また、顧客が返金を求めたことは、返金対象であることの確認にはなりません。
記録が古くなっている場合も、現在の状況として書かないようにします。この例では確認から10分後に下書きを作っていますが、それがどの業務でも十分な鮮度という意味ではありません。配送情報の更新頻度と、送信までの経過時間に応じて、再取得が必要かを決めます。再取得できなければ、確認した時点を限定して説明します。
応対文と内部の引き継ぎメモを分けるテンプレート
角括弧を差し替えて、次のように依頼できます。本人確認と参照権限は、確認済みの業務記録から設定する項目です。
「[問い合わせ内容]への返信を下書きしてください。本人確認の状態は[確認結果と根拠元]、参照を許可された範囲は[対象注文・必要な記録]です。
確認済みの事実は[状況・資料・確認時刻]、顧客の希望は[希望内容]、案内可能な選択肢は[承認された手続]です。補償や到着日については[承認の有無と対象条件]を使ってください。
未確認の到着日、返金、交換、特別対応を確約しないでください。情報が不足するときは、案内できる部分と担当者へ確認する部分を分けてください。本人確認が未完了なら、許可された一般案内と確認手順に限定してください。
出力は、顧客向け返信案、使用した根拠、担当者への引き継ぎメモの三欄です。顧客向け文面へ社内の判断メモや不要な個人情報を含めず、送信・返金・注文変更は行いません。」
変更してよいのは、問い合わせ、確認済み状況、正規の案内文、文体などです。補償条件や権限を変えるときは、担当者が承認内容を確認してから更新します。「強く苦情を言っているから全額返金」のような基準を、AIがその場で作らないようにします。
「親切に」「安心させて」といった文体指定を加える場合も、確約できないことを約束して不安を消す方向へ誘導しないことが大切です。確認できた情報と、次に取れる手続を丁寧に示すことを求めます。
返信案で、何を伝え、何を保留するか
先ほどの架空記録に基づく本文部分は、例えば次のようにできます。これは送信前の作例です。
「お届けをお待たせしており、ご不便をおかけしています。10月8日14時の確認では、配送に遅延が生じています。到着日はまだ確定していないため、現時点で明日のお届けはお約束できません。配送状況と送料の返金対象になるかについて、担当窓口で確認する内容として整理します。」
この文面は、翌日到着や返金を約束していません。一方で、「整理します」という対応を実際に行える運用かも採用前に確認します。担当者への引き継ぎが完了していないのに「確認を依頼済みです」と書くと、補償の確約がなくても、実行状態を誤って伝えることになります。
引き継ぎメモには、対象注文の識別、遅延状況の確認時刻、顧客の希望、到着日が未確認であること、返金の判断を求める事項を残します。担当者が元の記録へ戻れるようにし、顧客の発言とAIの要約を区別します。批判的な言葉を、顧客の人格や将来の行動の推測へ変えないようにします。
顧客へ案内できる追跡ページがある場合は、システムで確認した正規のリンクだけを使います。注文番号や個人情報を含むURLを推測して作らず、相手に開示してよいリンクかも確かめます。リンクを付ければ個別情報の開示制限がなくなるわけではありません。
状態が変わったときの書き換え方
本人確認が未完了だった場合は、上の個別配送状況をそのまま出力しません。許可された案内として「ご注文の確認には、所定の本人確認手続が必要です」とし、正規の確認方法へ誘導する案を作ります。氏名や住所を知っていることだけを、本人確認の代わりにしないでください。
送料返金が後で承認された場合は、誰が、どの注文について、どの金額・方法を認めたかを確認します。承認されたことと返金処理が終わったことは別です。「返金します」「返金手続きを受け付けました」「返金処理が完了しました」は状態が違うため、業務記録に対応する表現を使います。入金日が未確認なら、日付を付け加えません。
配送担当者から到着予定が届いた場合も、「予定」と「保証」を区別します。天候等の留保を含む記録なら、その条件を落とさずに案内します。古い到着予定と新しい遅延情報が食い違ったときは、新しい日付へ機械的に置き換えるだけでなく、何を確認できたかを担当者へ照会します。
顧客が途中でキャンセルを希望した場合は、配送状況の説明に加えて、注文変更という別の処理が発生します。キャンセル可能な状態か、必要な確認や承認は何かを既定の手続へ戻します。返信テンプレートの出力を、そのままキャンセル実行の指示に変えないようにします。
送信前に、記録と約束と相手を照合する
最終確認では、まず本人確認と対象注文が合っているかを見ます。別の顧客の記録を参照していれば、文章を丁寧に整えても使えません。対象が曖昧なら個別の情報を含む送信を保留し、正しい対象の確認へ戻します。
次に、配送状況の出典と時刻、補償の承認状態、作業の実施状態を確認します。AIが「担当者へ連絡済み」「返金済み」と書いた場合は、対応する業務記録があるかを見ます。記録がなければ、未実施または確認できていない状態を保った表現へ直します。
最後に、顧客向け本文に社内メモが混ざっていないか、案内する手続やリンクが現在使えるか、送信先が正しいかを確認します。個人情報を扱う場合は、個人情報保護委員会の注意喚起も踏まえ、利用目的に必要な範囲かと、使用するサービスの条件を照合します。
このテンプレートを導入する際は、通常の遅延、本人確認未完了、到着日不明、返金未承認、記録の食い違いを含む架空の確認例を用意できます。機密情報を出さないことだけでなく、許可された案内を続けられるか、必要な担当者へ不足事項が渡るかも見ます。テンプレートだけで応対品質が保証されるとはせず、実際の確認結果に基づいて改善してください。
回答案の作成でAIへ渡す個人情報を必要な項目へ絞る方法は「個人情報をAIへ渡す前に、目的に必要な項目へ絞る」で解説しています。
カスタマーハラスメントへの対応で、沈静化と担当者保護を分ける方法は「AIのカスタマーハラスメント対応で、沈静化と担当者保護を分ける」で解説しています。
