解約の兆候を早く見つけるには、すべてのチケットと顧客とのメールをAIに読ませ、短く名前を付けた兆候の一覧に照らして探させます。推進者の退職、繰り返される回避策、価値を疑問視する新たな関係者、改まっていく口調などです。各指摘には、そのきっかけとなった引用を添えます。アカウントを担当するCSMがそれを確認し、どう対応するかを決めます。
要点
- 解約の警告の多くは、更新のずっと前に、誰も読み返す時間のないチケット、メール、通話メモに書かれています。
- 汎用的な感情スコアよりも、チームで合意した短い名前付きの兆候の一覧のほうが効果的です。
- CSMがすぐに判断できるよう、すべての指摘には、そのきっかけとなった文をそのまま示すべきです。
- 対応を決めるのは人です。AIが懸念を抱えた顧客に自ら連絡することがあってはなりません。
- アカウントが少なく、一人のCSMがすべてを読んでいるなら、構築しなくても定期的に確認する習慣で十分です。
#CSMの1週間の中で、解約の兆候はどこに隠れていますか
兆候がヘルススコアに表れることはまれです。管理者が「回避策を作りました」と書いたZendeskのチケット、新任の財務責任者が契約の対象範囲を尋ねるOutlookのスレッド、推進者が組織再編に触れたTeamsの通話の中にあります。CSMはその一部を読み、サポートチームはもっと多くを読みますが、誰も断片をつなぎ合わせていません。
本当の問題は担当の手薄さです。TSIA(2024年9月)によると、CSMが付いているアカウントの解約率は、付いていないアカウントの半分未満であり、多くの企業ではCSMの担当が一貫していません。担当が最も手薄なアカウントこそ、書かれた警告が読まれずに終わるアカウントです。
#AIはどのような解約の兆候を探すべきですか
- 人:推進者や管理者が退職する、連絡が途絶える、新しい人に引き継ぐ。
- 価値への疑問:「これで何が得られているのか」といった質問や、財務や調達からの利用状況レポートの依頼。
- 回避策:顧客が、御社の製品やサービスの外でその仕事をしていると説明する。
- 繰り返される問題:同じ問題が何度も再オープンされる、あるいは一次対応を超えてエスカレーションされる。
- 競合:チケット、メール、通話の中で競合他社の名前が挙がる。
- 口調:返信が短く改まったものになる、あるいは利用者からマネージャーに相手が移る。
何かを構築する前に、この一覧をCSMとサポートの責任者と合意し、兆候ごとに実際の例を一つ書いてください。その一覧が仕様書になります。AIは、アラビア語と英語の何千ものメッセージからこうしたパターンを見つけるのは得意ですが、特定のアカウントにとってどれが重要かを見極めるのは苦手です。
新しいソフトウェアなしで解約の兆候の確認を始めるには、どうすればよいですか
- 最も重要な10のアカウントについて、直近のチケットと顧客とのメールをエクスポートします。
- 兆候の一覧とともに承認済みのAIツールに通し、該当するもの、その引用、日付を挙げるよう依頼します。
- CSMが各指摘に「本物」「ノイズ」「既知」の印を付けます。
- 本物の指摘は、次のアクションと担当者を付けたヘルスメモとしてCRMに残します。
- パイプラインやアカウントのレビューと同じ間隔で繰り返し、そのたびに兆候の一覧を絞り込みます。
この手作業版で、兆候を自動化する価値があるかどうかが分かります。指摘の大半がノイズなら、まず一覧を直してください。CSMが見落としていた本物のリスクを次々に見つけるなら、業務フローを構築する根拠になります。
そのためにカスタマーサクセスプラットフォームは必要ですか
必ずしも必要ではありません。GainsightやChurnZeroなどのプラットフォームは利用状況やアンケートのデータでヘルスをスコア化し、すでにすべての業務をその中で回しているチームに向いています。中堅のBtoB企業の多くは、HubSpotやSalesforceとチケット管理ツールで運用しており、見落としている兆候は自由記述の文章の中にあります。その文章を読み、各指摘を人が確認する仕組みは、今あるツールの中に置けます。
一つ注意があります。顧客からのメールは信頼できない入力です。OWASP Top 10 for LLM Applicationsはプロンプトインジェクションを第一に挙げています。受信メールを読む業務フローは、人に向けた指摘を出すだけにとどめ、自ら操作を行ってはなりません。
#Stennirが役に立つところ
StennirはたいていAIコンサルティングから始めます。AI機会診断で、解約の兆候の検知が御社チームにとって最初に取り組むべき業務フローかどうかを、コストと投資回収の見込みを書面にして確認します。AI導入では、御社のCRMとチケット管理ツールに読み取りと指摘の仕組みを組み込み、御社のルールが求める場所でホスティングし、名前のあるCSMがすべての指摘を確認し、すべての手順をログに残す形にします。
そのうえでAIトレーニングのAIオペレータープログラムで、CSMとサポートの責任者が指摘を判断し、それに基づいて行動できるよう指導し、前後の変化を測ります。
We are
Stennirは、御社自身のツールに解約の兆候を読み取る仕組みを組み込み、すべての指摘をCSMが確認し、対応を決める形にします。
We aren't
Stennirは中身の見えない解約スコアではなく、リスクが見つかったときに自動で顧客にメッセージを送ることもありません。
カスタマーサクセスの責任者は次に何をすればよいですか
最も重要な10のアカウントで手作業の確認を行い、気づいていなかった本物のリスクがいくつあったかを数えてください。サポートチームがキューを仕分ける方法はチケット振り分けのためのAIで、より広い視点はカスタマーサポート向けのAIでご覧いただけます。そのうえで無料の準備度診断を受けるか、30分の通話を予約することができます。
よくある質問
始めるにあたって、こちらから何が必要ですか。
一部のアカウントについてのチケット、顧客とのメール、通話メモへの閲覧権限、CSMがすでに注視している兆候の一覧、そして解約された、または解約されかけたアカウントをいくつかです。CSMのリーダーに各兆候が実際に何を意味するかを説明していただき、稼働後に誰が指摘を確認するかを決めていただきます。
どのような問題が起こり得ますか。
指摘が多すぎてCSMが読まなくなる、兆候の一覧があいまいすぎる、あるいは顧客のメールがモデルを誘導しようとする、といったことです。いずれも設計で対処します。絞り込んだ一覧、すべての指摘に添える引用、そして提案するだけで自ら操作はせず、判断は人が行う業務フローです。
アラビア語のメールやチケットも読めますか。
はい。アラビア語と英語に完全対応しており、顧客が二つの言語を切り替えるスレッドにも対応します。兆候の一覧は両方の言語の例とともに書き、CSMには各指摘の横に元の文が表示されるため、確認できない翻訳に頼ることはありません。
顧客データはどこに保管されますか。
御社自身のアカウントとクラウドの中で、契約やデータ保護のルールが求める地域に保管され、必要に応じて国内でのホスティングにも対応します。アカウント、データ、停止スイッチは御社の手元に残ります。Stennirが業務フローを動かすために、顧客のメールを自社の別のプラットフォームにコピーすることはありません。
