この記事は、業務ごとにCodatum Notebookの使い方を紹介する「Codatum Notebook活用シリーズ」の1本です。今回は、カスタマーサクセスの顧客ヘルスレビューで、利用状況、問い合わせ、QBRメモ、次アクションを同じ流れに置く使い方を扱います。

SaaSのカスタマーサクセスでは、顧客ヘルスを見る目的が、いつの間にか「赤信号のアカウントを探すこと」に寄ってしまうことがあります。

もちろん、利用率が落ちている顧客、問い合わせが増えている顧客、契約更新日が近い顧客を早く見つけることは大切です。ただ、カスタマーサクセスやアカウント担当が本当に知りたいのは、スコアが赤いかどうかだけではありません。

なぜ利用が落ちたのか。前回のQBRで何を約束したのか。問い合わせは一時的なものなのか、導入が止まっている兆候なのか。次に顧客へ連絡するとき、どの事実を持って、どんな会話を始めるべきなのか。

顧客ヘルスの数字は、前回の約束や次の連絡内容までつながってはじめて、契約更新前の会話に使える材料になります。

Codatum Notebookに顧客ヘルスレビューをまとめると、利用状況、サポート問い合わせ、契約更新日、QBRメモ、次アクションをひと続きで扱えます。アカウント別の状態を一覧で見て、根拠と考察をドキュメントに残し、顧客ごとの変化を要約し、必要に応じてQBR共有へつなげる流れです。

この記事では、カスタマーサクセス、アカウント担当、RevOpsが週次で見る「顧客ヘルスレビュー」というNotebookを作る流れを扱います。

顧客ヘルスはスコアだけだと説明に弱い

ヘルススコアは、顧客の状態をひと目で見るためには便利です。カスタマーサクセスチームが数十社、数百社を担当していると、すべての顧客について細かい利用状況を毎朝読み込むことはできません。

ただ、スコアだけを見ていると、次の会話に進みにくくなります。

• ヘルススコアが62まで下がった

• 利用者数が18%減った

• 未解決の問い合わせが4件に増えた

• 契約更新日まで72日になった

この一覧を見れば、何か起きていそうだとは分かります。けれども、担当者が顧客へ連絡するには、もう少し前後の材料が必要です。

利用が落ちたのは、主要機能を使う管理者が変わったからなのか。問い合わせが増えたのは、導入が進んでいるからなのか、それとも不満が溜まっているからなのか。前回のQBRで合意したアクションが止まっているなら、顧客側と自社側のどちらで止まっているのか。

契約更新リスクは、単一の数字よりも、こうした変化の組み合わせに表れます。スコアは入口であって、カスタマーサクセスが顧客と向き合うためには、その裏にある事実と前回までの会話を追える状態が必要になります。

週次ヘルスレビューで見るべき変化

顧客ヘルスレビューでは、最初から複雑な予測モデルを作るより、担当者が毎週見て、会話に使える変化を置く方が運用に乗ります。

たとえば、最初のNotebookではこのあたりを同じページにまとめます。

• 利用状況: 利用者数、管理者ログイン、主要機能の利用、前週差分

• サポート: 問い合わせ件数、重大度、未解決期間、問い合わせカテゴリ

• 契約: 契約更新日、契約規模、プラン、担当カスタマーサクセス、アカウント担当

• 顧客接点: QBRメモ、前回の約束、次アクション、担当者コメント

これらを別々の画面で見ると、「数字は見たけれど、何を話すかは別途思い出す」状態になりがちです。ヘルススコアの一覧はBIにあり、サポート履歴はZendeskにあり、QBRメモはNotionにあり、契約更新日はCRMにある。カスタマーサクセスが週次レビューのたびにその間を行き来すると、顧客を見る時間よりも、材料を集める時間の方が長くなります。

Notebookにまとめたいのは、すべてのデータを無理に1つの表へ押し込むことではありません。担当者が「この顧客は今どんな状態で、次に何をすべきか」を説明できるだけの材料を、同じ流れで読めるようにすることです。

Notebookにまとめ、説明できるヘルスレビューにする

CodatumのNotebookは、MarkdownとSQLを組み合わせた分析ドキュメントで、ドキュメントページ（DocPage）とグリッドページ（GridPage）で構成されます。

顧客ヘルスレビューでは、DocPageに指標定義、実データ、チャート、考察、QBRメモを残し、GridPageでアカウント別のヘルスダッシュボードを見ます。スコアの一覧から気になる顧客を見つけ、同じNotebookの中で利用低下や問い合わせ増加の根拠を確認し、担当者のコメントまで残します。

たとえば、顧客ヘルスレビューの最小構成はこのくらいで始められます。

1. 今週のヘルスサマリー

2. アカウント別ヘルス一覧

3. 利用状況の推移

4. 問い合わせの変化

5. 契約更新リスクの深掘り

6. QBRメモと次アクション

冒頭には、今週の見方を短く置きます。「赤い顧客が何社あるか」だけで終わらせず、担当者がどこから確認すべきかが分かる形にします。

今週は契約更新日まで90日以内で、利用率が15%以上下がった顧客が4社ある。うち2社は未解決の問い合わせも増えており、前回QBRで決めた次アクションが未完了のまま残っている。まずはエンタープライズプランの2社について、アカウント担当とカスタマーサクセスが状況を確認する。

このサマリーがあると、週次レビューの参加者は最初に見るべき顧客を揃えられます。

GridPageには、アカウント別にヘルススコア、利用率の前週差分、未解決の問い合わせ件数、契約更新日、担当者、次アクションを並べます。ここは固定ビューとして使い、担当者が毎週同じ形で状態を見られるようにします。

一方で、なぜその状態なのかを確認する部分はDocPageに残します。利用状況の推移、サポート問い合わせの変化、前回QBRの約束、担当者のコメントが同じページにあると、ヘルススコアの理由を説明しやすくなります。

スコアの裏にある変化を同じ画面で見る

ヘルススコアが下がったとき、最初に確認したいのは「何が変わったのか」です。

利用率が落ちているのか。管理者ログインが止まっているのか。問い合わせが増えているのか。契約更新日が近いだけで、利用そのものは安定しているのか。どの変化かによって、担当者が取るアクションは変わります。

たとえば、利用状況は次のような集計から始めます。

このSQLを見せたい理由は、読者にSQLを覚えてもらうためではありません。ヘルススコアの裏にある集計条件と実データを、担当者が後から確認できる状態にするためです。

実務では、利用者数の定義、対象期間、除外するテストアカウント、管理者だけを見るのか全ユーザーを見るのか、といった条件が効いてきます。Notebookに集計条件と結果が残っていると、「なぜこの顧客が赤くなったのか」をチームで確認できます。

サポート問い合わせも、利用状況と一緒に見ると読み方が変わります。

問い合わせが増えていても、導入が進んで質問が増えているだけなら、リスクというよりオンボーディング支援のサインかもしれません。逆に、利用率が落ちているうえに重大度の高い問い合わせが増えているなら、契約更新前に担当者が状況を確認した方がよい。

ヘルスレビューでは、1つの数字を大きく扱うより、顧客の状態を説明できるだけの変化を並べて読む方が実務に合います。

Agentは確認すべき変化を集める

顧客ヘルスにAgentを使うときは、「この顧客は契約更新しそうか」を当てさせるより、担当者が確認すべき変化を集める役割に寄せる方が実務に合います。

たとえば、週次レビューの前にAgentへ次のように依頼します。

契約更新日まで90日以内で、ヘルススコアが前週から10ポイント以上下がった顧客を要約してください。利用率の変化、未解決の問い合わせ、前回QBRで決めた次アクションを確認し、根拠のない推測は入れないでください。

この依頼で欲しいのは、最終判断ではありません。担当者が短時間で確認に入れるように、変化の候補を集めることです。

Agentの出力は、次のような形でNotebookに残します。

アクメ製造は利用者数が24%減少し、管理者ログインが10日間発生していません。未解決の問い合わせは1件から4件に増え、うち2件は権限設定に関する問い合わせです。前回QBRで決めた「管理者向けトレーニング実施」は未完了のままです。担当カスタマーサクセスは、管理者変更の有無とトレーニング日程を確認してください。

この要約だけで判断が閉じないよう、すぐ下に実データ、問い合わせカテゴリ、QBRメモがある状態にします。担当者はAgentの要約を入口にして、根拠を確認し、必要ならコメントで補足します。

Agentは、過去のNotebookやQBRメモを探す役割にも向いています。

「この顧客は前回も管理者ログインが落ちたはず」「前回のQBRで、データ連携の完了を約束していた気がする」。こうした記憶は担当者個人に残りがちですが、Notebookに残っていればAgentが探しやすくなります。

Agentには、担当者が顧客と話す前に見るべき事実をそろえる役割を持たせます。顧客ヘルスでAgentを使うなら、この距離感が現実的です。

QBRと契約更新前アクションにつなげる

顧客ヘルスレビューは、社内で眺めて終わるものではありません。契約更新前の会話、QBR、次回アクションへつながってはじめて意味があります。

たとえば、週次レビューで次のような判断を残します。

• 利用率が落ちた2社は、担当カスタマーサクセスが管理者変更の有無を確認する

• 問い合わせが増えている1社は、サポート責任者とアカウント担当が同席してQBR前に論点を整理する

• 次アクションが期限切れの3社は、QBR資料に進捗と未完了理由を明記する

この判断がNotebookに残っていると、翌週のレビューで「前回どこまで確認したか」を追えます。Slackに流れた会話や個人メモだけに残すより、数字と同じ場所に置いた方が、担当者が変わっても前回までの経緯を引き継ぎやすくなります。

顧客に共有する内容は、社内の深掘りとは分けて整えます。Codatumでは、Notebookで社内レビューを行い、顧客に見せる内容はReportとしてまとめ、必要に応じてGuest共有で届ける流れを作れます。

社内向けには、問い合わせカテゴリや担当者コメント、内部のリスク判断まで扱います。顧客向けのQBRでは、利用状況の変化、成果、未完了のアクション、次の合意事項に絞る。この切り分けがあると、QBRが数値報告で終わらず、「自分たちの状況を見てくれている」と顧客が感じやすい場になります。

顧客ヘルスをNotebookに残す価値は、契約更新率だけの話ではありません。担当者が毎週同じ根拠を見て、顧客ごとの変化を説明し、約束したアクションを追えるようになると、顧客接点の質が安定します。

契約更新前に慌てて「最近どうですか」と聞く形から、利用状況と前回の約束を踏まえて「前回のQBRで話した管理者トレーニングの件ですが、今週の利用状況を見るとまだ定着に余地がありそうです」と話せる状態に変わる。これは、顧客にとっての体験がまったく違います。

週次アラートにして、レビュー前に気づける状態にする

顧客ヘルスレビューは、毎週人が開いて確認するだけでも役に立ちます。ただ、契約更新リスクはレビュー会議の日だけに発生するわけではありません。

次のような条件は、Workflowで週次アラートにできます。

• 契約更新日まで90日以内

• ヘルススコアが前週から10ポイント以上低下

• 利用者数が20%以上低下

• 重大度の高い問い合わせが2件以上

• QBRで決めた次アクションが期限切れ

毎週月曜の朝に該当アカウントを抽出し、担当カスタマーサクセス、アカウント担当にSlackで送る。レビュー前に担当者がNotebookを開き、必要なコメントを残し、会議では判断と次アクションに時間を使う。

この流れがあると、顧客ヘルスは「月末に見る一覧」から、チームの介入リズムに変わります。リスクを見つけるだけでなく、誰が、いつ、どの顧客に、どの根拠で動くかまで決めやすくなります。

固定ビューと深掘りを分ける

カスタマーサクセスチーム全体で見る画面と、データチームやRevOpsが深掘りする場所は、役割を分けた方が使いやすくなります。

GridPageは、アカウント別のヘルス状態を固定ビューとして見る用途に向いています。ヘルススコア、利用率の前週差分、未解決の問い合わせ件数、契約更新日、担当者のような列を並べ、担当者が毎週同じ形で確認できるようにします。

DocPageは、なぜその数字になったのかを深掘りする場所です。利用低下の集計条件、問い合わせカテゴリの内訳、前回QBRのメモ、担当者のコメントを残します。

Report/Guestは、顧客に見せる内容を整える場所です。社内コメントや内部リスク判断は含めず、顧客と共有したい利用状況、成果、次の合意事項に絞ります。

同じ顧客ヘルスでも、社内レビュー、深掘り、顧客共有では見せる粒度が違います。Notebookの中で固定ビューと深掘りを持ち、共有用にはReportとして切り出すと、カスタマーサクセス、アカウント担当、RevOpsと顧客のそれぞれが必要な情報を受け取りやすくなります。

まとめ

カスタマーサクセスの顧客ヘルス管理では、スコアを見るだけでは契約更新リスクを扱いきれません。

利用率の低下、問い合わせの増加、契約更新日、QBRメモ、次アクションは、それぞれ別々に存在していても、担当者が顧客と話す前にはひと続きで読める必要があります。スコアが赤い理由を説明でき、前回の約束を確認でき、次に何を話すかまで決められる状態になって、はじめて顧客ヘルスは実務に効きます。

Codatum Notebookでは、DocPageに実データ、集計条件、考察、QBRメモを残し、GridPageでアカウント別のヘルスビューを見られます。Agentは顧客ごとの変化要約や過去メモ参照に使い、担当者が根拠を確認する。Report/GuestでQBR共有へ、Workflowで週次アラートへつなげると、ヘルスレビューがチームの介入リズムになります。

顧客ヘルスは、危険な顧客を探すためだけの仕組みではありません。契約更新前の会話を準備し、顧客ごとの変化を説明し、約束したアクションを追い続けるための仕組みです。

毎週のレビューを1つのNotebookにするだけでも、カスタマーサクセス、アカウント担当、RevOpsが同じ根拠を見て動きやすくなり、顧客にとっても「状況を分かってくれている」と感じられる接点を作りやすくなります。

次の一歩

顧客ヘルスレビューの形が見えてきたら、次は共有と定例運用に広げられます。社内の契約更新リスク確認をSlackに流すならWorkflow、顧客向けのQBRに届けるならReport/Guestが次の候補になります。

Notebook活用シリーズ / 関連記事

• Notebookで分析レビューを翌週へ引き継ぐ考え方は、プロダクト分析でユーザー理解を積み上げる — Codatum Notebookでも扱っています。

• 広告費から商談までを見直す施策レビューの例は、広告費から商談までを見直す — Codatum Notebookで扱っています。

• 週次レビューをSlackに流す運用は、KPIの定期配信でチームのリズムを作る — Codatum Workflowにつなげられます。

• QBRや顧客向け共有では、社外向け分析レポートを安全に共有する — Codatum Report/Guestが近いテーマです。

• 顧客向けの分析画面をプロダクトに組み込む場合は、顧客向けダッシュボードをプロダクトに埋め込む — Signed Embedを参照してください。