AIによるプロアクティブなカスタマーサービス：顧客から連絡が来る前に動く
Turn this article into takeaways for your work.
Each assistant summarizes the article only for you and suggests best practices for your work.
AIによるプロアクティブなカスタマーサービスとは、顧客に影響する問題（障害、荷物の遅れ、まもなく失敗するカード決済など）をモデルで検知し、顧客が問い合わせる前に、状況の説明と次の行動を添えて連絡することです。 監視と予測を担うのはAIです。何を伝えるか、何を約束できるか、返ってきた返信を誰が対応するかは、これまでどおり人が決めます。
多くのサポートチームは、受け身で運営されています。顧客が問題に遭遇し、ヘルプセンターを検索し、それからチケットを起票します。プロアクティブなサービスは、この順序を逆にします。サポートマネージャーにとっては、「注文はどこですか」「サービスは止まっていますか」といった種類の問い合わせをまるごと減らせる点が有用です。また、悪い場面を「すでに対応してくれている」と顧客が感じられる場面に変えられます。一方で、予測の誤り、メッセージの送りすぎ、許可なく送るアウトリーチといった、決まった形の失敗も起きます。本記事では、仕組み、職種別の例、導入計画、効果測定の方法、そしてつまずきやすい点を解説します。
本記事はカスタマーサービスにおけるAIの概要を土台にしています。また入力データの質に左右されるため、チケットや注文のデータが整っていない場合は、AIのためのサポートデータの準備を先にお読みください。
重要なポイント
- Locusが米国の消費者1,000人と英国の消費者2,000人を対象に行った調査では、米国の消費者の93%が、プロアクティブな連絡は配送遅延による悪い体験を和らげると回答しました（Customer Experience Dive）。
- 同じ調査で、小売業者が高速配送や配送保証の約束を常に守っていると考える消費者は、米国で9%、英国で7%にとどまりました。つまり遅延は例外ではなく、日常的に起こることです（Customer Experience Dive）。
- この調査で、英国の消費者の94%が、実際には届いていないのに「配達済み」と通知されることを最も不満な配送体験に挙げました。誤ったプロアクティブな連絡は、何も伝えないよりも悪い結果を招きかねません（Customer Experience Dive）。
- Atlassianは、顧客に影響が続いているインシデントでは、1時間以上更新なしの状態を作らないこと、そして各更新で次の更新時刻を伝えることを推奨しています（Atlassian）。
- 米国連邦の規則では、自動発信装置や録音音声を使って携帯電話番号へ発信する通話やテキストには事前の明示的な同意が必要で、広告やテレマーケティングの場合は事前の明示的な書面による同意が必要です（47 CFR 64.1200）。
カスタマーサービスが「プロアクティブ」になるとは
受け身のサービスは、連絡を待ちます。プロアクティブなサービスは、自分から連絡を始めます。簡単に聞こえますが、実際には3つのレベルがあり、本格的にAIが必要になるのは最後のレベルだけです。
- ブロードキャスト。 既知の問題を知らせるステータスページ、バナー、一斉メールです。送信を決めるのはチームの誰かです。
- トリガー型。 システムのイベントが起きたときに、ルールがメッセージを送ります。たとえば決済の失敗、配送業者のスキャンが「遅延」を示した場合、予約が明日に迫っている場合などです。
- 予測型。 何かが起こりそうだとモデルが推定し、イベントが確定する前に警告します。たとえば、統計的に期日どおりに届かない可能性が高い荷物、エラーに遭遇しそうな利用パターンの顧客、拒否されそうな決済などです。
ルールだけでかなりの範囲をカバーできます。「決済失敗」のWebhookに機械学習は要りません。AIが力を発揮するのは、シグナルにノイズが多い場合、多数のシステムにまたがる場合、あるいは「はい・いいえ」ではなく確率が必要な場合です。ACE Frameworkで言えば、これはAnomaly Agentパターンにあたります。Ingest（イベント、チケット、ログ、配送業者のフィード）、Analyze（ベースラインと比較）、Predict（発生確率と影響を採点）、Execute（メッセージを送る、またはタスクを起票）という流れです。同じ構造は異常検知や予測分析にも現れるため、基礎となる技術を学ぶならこの2ページが適しています。
AIが問題を早期に見つける仕組み
主に4種類のシグナルが活躍します。
自社への問い合わせ件数の急増。 「ログインできない」という問い合わせが1時間で3倍になれば、監視ツールがサーバーは正常だと示していても、何かが壊れています。問い合わせ理由ごとの現在の件数を、その曜日と時間帯の通常パターンと比べるモデルであれば、マネージャーがダッシュボードを見るよりも早く検知できます。
システムとイベントのデータ。 エラー率、レイテンシ、配送業者のスキャンイベント、決済ゲートウェイの応答、在庫数などです。これらは構造化されていて量が多く、タイムスタンプが付いているため、異常検知に向いています。
顧客の行動。 失敗する同じ操作を5回繰り返すユーザー、注文に含まれる商品が欠品になった購入者、来週カードの期限が切れる契約者などです。
自由記述のテキスト。 レビュー、チャットの記録、SNSの投稿からは、どのシステムイベントにも表れない問題が見つかることがあります。たとえば、新製品の説明書に分かりにくい指示があるといった問題です。
顧客、注文、アカウント、会話がきちんと結び付いていなければ、これらはどれも機能しません。どの顧客が影響を受けるのかが分からなければ、一斉送信しかできません。「この312人のお客様の出荷が遅れています」と言えることが、連絡を画一的ではなく、一人ひとりに向けたものにします。
職種別の例
オペレーションと物流。 小売業者のモデルは、配送業者のスキャン履歴、天候、倉庫の滞留を組み合わせ、約束の日に届かなさそうな注文を検知します。影響を受ける顧客には、追跡ページを確認し始める前に、新しい到着予定日とキャンセルや日程変更の選択肢を添えたメッセージが届きます。Locusの調査はこの重要性を示しています。米国の購入者の93%が、プロアクティブな連絡は配送遅延の不快感を和らげると答えました（Customer Experience Dive）。
請求と経理。 決済が失敗する理由は多岐にわたり、その多くは回復可能です。Stripeのドキュメントによると、Smart RetriesはAIで再試行のタイミングを選び、支払い方法を提示したデバイスの数や、支払いに最適な時間帯といったシグナルを扱います。また、発行会社の拒否コードには「ハード」なものがあり、新しい支払い方法がなければ再試行できないとも記されています（Stripe）。サポートの役割はその周辺にあります。ハードな拒否が起きたら、何が起きたのかを顧客にはっきり伝え、カードを更新する1ステップの手段を提供します。サブスクリプションが何も知らされないまま失効する状況にしないためです。
ITおよびプロダクトサポート。 ある機能でエラー率が上がると、異常検知モデルがオンコールのエンジニアとサポートリードに同時にアラートを出します。サポートはステータスの更新を公開し、「止まっていますか」という問い合わせを、あらかじめ答えることで抑えます。Atlassianは、専用のステータスページを主要チャネルとし、メール、SMS、プッシュ通知はそのページへ誘導するために使うことを推奨しています。また、詳細が分かる前でも、問題を迅速に認めるべきだとしています（Atlassian）。
カスタマーサクセス。 ヘルスモデルが、連携の失敗をきっかけに顧客の利用が落ちたことを検知します。一般的な様子うかがいの代わりに、アカウントマネージャーはその具体的な連携エラーについて連絡し、解決策を提案します。
サービスの予約。 フィールドサービスのチームは、前の作業の所要時間と交通状況から、遅れそうな訪問を予測します。そして、顧客が午後に休みを取る前に、翌日の顧客へ修正した時間枠を連絡します。
チャネルの選び方
プロアクティブなメッセージは、顧客の目に触れる場所に届いて初めて役に立ちます。緊急度と、取得している許可に合わせてチャネルを選んでください。
| 状況 | 最適なチャネル | 理由 | 注意点 |
|---|---|---|---|
| 広範囲の障害 | ステータスページ、およびそこへ誘導するメールやプッシュ通知 | 情報源が1つで、全員に対応できる | 更新が古いまま。次の更新時刻がない |
| 個別の配送遅延 | メール、SMS、またはアプリ内メッセージ | 個人向けで、新しい日付と選択肢を伝えられる | 送信前に内容が正確でなければならない |
| 決済の失敗 | メールとアプリ内バナー | 顧客がすぐに対応できる | ハードな拒否とソフトな拒否では、メッセージを変える必要がある |
| 不正やセキュリティの疑い | 確認済みのチャネルのみ。認証情報の入力を求めるリンクは絶対に載せない | 信頼を守る | 文面が不注意だとフィッシングに見える |
| 予約の変更 | SMSまたはメッセージアプリ | 読まれる率が高い | 同意とテンプレートのルール |
AIが複数のチャネルでどう動くかについて、より広い内容はサポートチャネル全体でのAIをご覧ください。
同意、ルール、メッセージのカテゴリ
プロアクティブなアウトリーチも、アウトリーチであることに変わりはなく、ルールはチャネルや地域によって異なります。
米国では、自動発信や録音音声による通話・テキストに関する連邦規則が、携帯電話番号への発信には事前の明示的な同意を、メッセージが広告やテレマーケティングの場合は事前の明示的な書面による同意を求めています。また、同意はあらゆる合理的な方法で撤回でき、「stop」や「unsubscribe」といった返信もそれに含まれること、停止の依頼は10営業日を超えない合理的な期間内に履行しなければならないことも定めています（47 CFR 64.1200）。配送の通知は情報提供ですが、クーポンを加えると別の性質のものになるため、サービス向けのメッセージに販促を混ぜないでください。
メッセージングプラットフォームにも独自のルールがあります。MetaのWhatsAppのドキュメントによると、テンプレートが「ユーティリティ」に該当するのは、販促の意図がなく、ユーザーが依頼した内容、またはユーザーの注文、アカウント、取引に関するものである場合に限られます。ユーティリティとマーケティングの内容が混在するテンプレートは、マーケティングに分類されます（Meta）。実務上の教訓は、どのチャネルにも当てはまります。サービスのメッセージはサービスについてのものに保ち、誰が、いつ、どのように連絡に同意したのかを正確に記録しておくことです。現地の法律は異なるため、新しいチャネルや地域を有効にする前に、法務やプライバシーの担当チームに相談してください。
プロアクティブなAIサービスの導入手順
- 予測しやすいイベントを1つ選ぶ。 頻度が高く、コストがかかり、顧客にとって明らかに好ましくないものを選びます。たとえば配送遅延、繰り返し起こるログイン失敗、カードの有効期限切れなどです。安全性、法的リスク、資金の移動が関わるものは、今回は見送ります。
- 現状でそのイベントが生む問い合わせ件数を数える。 1件のインシデントあたりのチケット、チャット、通話の件数と、対応時間でみたコストを把握します。これがベースラインであり、ビジネスケースの土台になります。
- 影響を受ける顧客を特定できるか確認する。 イベントと顧客レコードの間に、信頼できる結び付きが必要です。対象者のリストを出せないなら、何かを構築する前にそこを直します。AIのためのサポートデータの準備のデータ作業がそのまま当てはまります。
- ルールから始め、ルールで足りないところに予測を加える。 単純なトリガーのほうが説明もデバッグも容易です。より早い警告が必要なとき、またはシグナルのノイズが多く固定のしきい値では扱えないときに、モデルを加えます。
- 確信度のしきい値と、アクションの階層を決める。 たとえば、確信度が高ければメッセージを自動で送信し、中程度なら人がレビューするタスクを作成し、低ければログに残すだけにします。これは、アウトリーチに適用した自動化か支援かの判断です。
- 人と一緒にメッセージを書く。 何が起きたのか、誰が影響を受けるのか、こちらが何をしているのか、顧客に何ができるのか、次はいつ更新するのかを伝えます。明確な行動は1つだけ提示します。文面と約束の責任は、人が持ちます。
- 返信を対応しやすくする。 プロアクティブなメッセージは返信を生みます。担当者が元の通知を確認できるよう、コンテキストを付けて振り分け、顧客がすぐに人へ連絡できるようにしてください。ここはアシスタントが役立つ場面でもあり、自動化か支援かで解説しています。
- ホールドアウトグループを置いてパイロットを行う。 影響を受ける顧客の大半に送信し、無作為に選んだ少数のグループには送らずにおくことで、問い合わせ率を比較できます。ホールドアウトがなければ、自分たちの効果と季節的な変動を区別できません。
- 毎週、見逃しを見直す。 誤報（起きなかった問題へのメッセージ）と見逃し（検知できなかった問題）を確認します。モデルだけでなく、しきい値も調整してください。
- イベントは1つずつ広げる。 前のイベントで数字が維持できたことを確かめてから、次のイベントを追加します。
効果の測り方
つい送信したメッセージ数を数えたくなりますが、それは活動量を測っているだけです。必要なのは、問い合わせをした顧客が減ったこと、そして問い合わせた顧客の不満が小さかったことの証拠です。
| 指標 | 分かること | 読み方 |
|---|---|---|
| 影響を受けた顧客あたりの問い合わせ率 | 通知によって問い合わせを防げたか | 通知したグループとホールドアウトグループを比較する |
| 問題の発生から最初の顧客向けメッセージまでの時間 | どれだけ早く連絡できたか | 短いほどよいが、正確である場合に限る |
| 誤報率 | 起きなかった問題について警告した頻度 | 上昇すると信頼が損なわれる。しきい値を調整する |
| メッセージへの返信率と苦情率 | メッセージが作業を生んだのか、苛立ちを生んだのか | 「なぜこれが届いたのですか」という返信の急増は警告サイン |
| 影響を受けた顧客と受けていない顧客のCSATやセンチメント | 体験が改善したか | メッセージ後ではなく、解決後に測定する |
| 回復率（失敗した決済、再手配した配送） | ビジネス上の成果 | 慎重に帰属させる。メッセージがなくても再試行で決済が回復することがある |
| オプトアウト率 | 送りすぎていないか | メッセージの種類別に追跡する |
注意点が2つあります。1つ目は、防いだ問い合わせは定義上、目に見えないため、ホールドアウトとの比較がなければ把握できないことです。2つ目は、デフレクションしたチケット数だけでなく、インシデントあたりの対応コストも追跡することです。400件の問い合わせを減らす一方で、150件の怒りの返信を招くプロアクティブな通知は、見出しの数字ほど大きな成果ではありません。
避けるべき落とし穴
誤った情報を送る。 Locusの調査では、英国の消費者の94%が、実際には届いていないのに「配達済み」と通知されることを最も不満な配送体験に挙げました（Customer Experience Dive）。予測が外れたときは、そのことを速やかに伝えて訂正してください。社内アラートよりも、顧客へのメッセージのほうに高い確信度の基準を設けます。
送りすぎる。 遅れている荷物1つについて通知を5通送るのは、ノイズです。顧客1人あたり、期間あたりのプロアクティブなメッセージ数に上限を設け、可能な限り更新をまとめてください。
画一的にする。 「問題が発生しています」では、誰も何をすればよいか分かりません。具体的な注文、アカウント、機能、影響、次のステップを盛り込んでください。
守れないことを約束する。 モデルは新しい配送日を見積もれます。しかし、人または承認済みのルールが認めていない限り、返金や補償を約束してはいけません。
サービスと営業を混ぜる。 サービスの通知にオファーを加えると、同意の要件が変わり、プラットフォームによってはメッセージのカテゴリも変わります。両者は分けてください。
逃げ道を忘れる。 メッセージを読んだ顧客が、それでも人に連絡できないなら、不満を取り除くのではなく移動させただけです。拡大する前に、AIサービスに対する顧客の期待を確認してください。
人の責任者を置かない。 すべてのプロアクティブなフローには、停止できる担当者を明確に決めておく必要があります。午前2時に何か問題が起きたとき、2万人の顧客へのメッセージを止めるために、コードのデプロイが必要であってはなりません。
次に読む記事
顧客が繰り返し不満を口にするイベントを1つ選び、影響を受ける顧客のリストを作成し、少数のホールドアウトを残して、大半の顧客に正確なメッセージを1通送り、問い合わせ率を比較してください。それがうまくいけば、2つ目のイベントは1つ目よりもはるかに低いコストで進められます。
Customer Success Operations Manager