【SaaS CS集中講座 第4回】ヘルススコアの基礎知識と設計プロセス、運用のポイントは？

SaaS事業成長の鍵を握るのは、顧客との良好な関係を築き続けるカスタマーサクセス（CS）に他なりません。ともすれば属人的になりすぎる仕事を、しっかりと組織化していくためには、戦略や目標設計の観点が欠かせないでしょう。

そこで、CSを組織化する上での必須知識を、下記5つのテーマに分けて解説する『SaaS CS集中講座』を、ALL STAR SAAS FUNDで開講。

1. CS組織化のポイントとKPI・KGI設計
2. CSMの基本マインドとオンボーディング
3. リニューアルマネジメントとエクスパンション
4. ヘルススコアとデータ基盤
5. カスタマーマーケティングとコミュニティ

講師は、日本におけるカスタマーサクセスの第一人者である山田ひさのりさんをお招きし、豊富な実務経験をもとに解説。さらにALL STAR SAAS FUNDの支援先からもよく聞かれる課題もカバーしたカリキュラムとなっています。

ここでは第4回となる「ヘルススコアとデータ基盤」の内容を抜粋、記事化しました。カスタマーサクセスを含め、SaaS経営全般のナレッジを私たちのブログでは継続的に発信しています。これを機会に知ってくださった方は、ぜひ他の記事もご覧ください！

何のためにヘルススコアは存在するのか？

ヘルススコアの果たすべき責務を、まずは皆さん、ちょっと考えてほしいんです。ヘルススコアはいったい何のために存在し、どういう役割を果たすべきなのでしょうか？

一般的に考えて、サクセスしているお客さんがチャーンする可能性は、概ね少ないはずです。逆に「チャーンの可能性が低いからサクセスしている」とは、ストレートにいえない場合のほうが多い。このあたりを混ぜてしまうと、ヘルススコアはいったい何を測るためのものなのかが、よくわからなくなってしまいます。

たとえば、ヘルススコアを「チャーン予備軍の洗い出し」を目的に作った場合には一致しないことがほとんどです。作った目的と異なる用途で解釈して、用いないようにしましょう。ヘルススコアは万能のものさしではありません。いろいろと求めすぎないことが大事です。

さて、私が提唱するヘルススコアの責務は、おそらく一般的だと思うのですが、こういうふうに定義しています。

「ヘルススコアは顧客の健康状態を把握できる数字なので、上手く使えばチャーン予備軍を洗い出すことができます」

ヘルススコアは通貨と似ている、と考えてみる

ヘルススコアと通貨は似ています。なぜなら、ヘルススコアが成り立つ前提には「信頼」があります。

通貨も、その価値をみんなが信頼しているから、社会的な共通言語として機能するわけです。ヘルススコアも同じく、信じることでチャーン予備軍がつぶせると組織内の認知があると、ヘルススコアを使った改善策を打とうという話ができるようになります。つまりは、信頼感が大事なんですね。

よく「ヘルススコアを作りたてで信頼性が担保できない場合は、当たっているか否かがわかりません。あるいは、外れているかもわからない」と質問を受けます。作り方については後ほど説明しますが、大切なのは「継続率との関連性」があるという前提で作ることです。一旦はKPIを絞り込んで、「えいやっ」で構いません。ここは迷ってもしょうがないです。

直感を信じて、振り返りを行う前提で、勇気を持って決定してください。大事なのはあくまで振り返りです。

ヘルススコアの振り返りのために必要なもの

では、振り返り方はどうすればいいのか、Sansanのヘルススコア遍歴を元に説明してみます。

かつてはデータソースとなるのはSansanの利用率データしかありませんでしたが、現在でこそさまざまな変数からヘルススコアを導き出しています。お客さんのプロパティデータ、契約情報、「このお客様は良い感じがする」といったカスタマーサクセスマネージャーの定性データも含めて、Gainsightというカスタマーサクセスプラットフォームに集約して、ヘルススコアを作っています。

もちろんSansanのプロダクトデータ、利用率もしっかり入ってます。これの割合のほうがもう圧倒的に多いですね。

Sansanの機能が増えてきたことで、何が継続率に寄与しているか、ちょっと見えにくくなってきた時期があります。DAUだけを見ていても意味がないのではないか、という議論もあって、継続を決定づける主要因をシンプルに表現したかったんですよね。

下記は、初期の「Sansanスコア」の概要です。Sansanスコアは100点満点で表すコンセプトで、3つの指標を傾斜配点してスコアを算出していました。アクティビティ、データベース、カバレッジです。これらを2対2対1で割り出すコンセプトでした。この割合も「そんなもんじゃない？」と出してみた感覚的な数値ですが、決め方はそれでいいと思います。

アクティビティはWAU（ウィークリー・アクティブ・ユーザー）です。データベースは1人当たりの名刺の総取り込み枚数を10で割った数値。カバレッジはログイン・取り込み経験の割合です。

つまり、アクセスしているかどうか、名刺を取り込んだかどうか、ログインしたかどうかという観点からシンプルな3つの数字で表現しようとしました。これが初期のヘルススコアですね。

一方、現在のヘルススコアは全部で14の要素があります。結構多いですよね。

「チャーン案件の50％はヘルススコアが悪い案件」と以前説明しましたが、アベレージで5割、6割くらいだと、だいたい正確になることが、私の経験上では多かったです。

「ヘルススコアが低い顧客≒チャーンリスクが高い」

そして、ヘルススコアの値については、良し悪しを4色で定めています。

ヘルススコアは14の要素から、総合点である「オーバーオールヘルススコア」を見ながら、さらに細かく見ていきたい場合は要素も、そして数値までチェックしていきます。

オーバーオールスコアも4段階で示してあり、「対応が必要」なレッドから、「極めて良好」のグリーンまでを用いています。

Sansanのヘルススコアは、CSMの定性判断、そして過去1年以内に解約した顧客の傾向値を集計・分析して算出されています。結果として「ヘルススコアが低い顧客≒チャーンリスクが高い」という式が、理論上成り立っています。

また、ヘルススコア、顧客のライフサイクル、顧客規模に応じて、重要視すべきかどうかの適用比率が決められてるんですね。この点は、後で詳しく説明します。

カスタマーピラミッドを皆さんも作っていることとは思うのですが、Sansanの場合は従業員規模で分けています。ただ、ヘルススコアに限っては「MRRが50万円以上／未満」で分かれています。

というのも従業員規模で分ける方法も考えましたが、従業員規模1000人を超えていても、ある部署だけで使っているというのは、すごく限定的なはずです。従業員規模とID数が一致しないようなことが出てくる。なので、MRRはID数とほぼ一緒だと思っていただければいいと思いますね。

でも、Sansanの場合はID数課金ではなくて名刺のデジタライズの枠で課金しているので、MRRで整理することによって、利用規模がわかると判断しました。仕切りを50万円にしたことに、特に理由はありません。いろいろなデータをにらめっこしたら適当ではないか、と感じたからです。

次に見せるのは、Sansanのお客さんのカスタマーライフサイクルです。以下、こういうふうになっています。

オンボーディングが終わったあと、更新1年目、更新2年目と分かれているのですが、ヘルススコアは「オンボーディング中」と「オンボーディング後」で分かれます。先ほどはMRR規模で分けましたが、お客さんの導入期間でも分けるのですね。

DEAR Frameを活用する

Sansanヘルススコアを先ほど見せましたが、“DEAR Frame”といわれるヘルススコアの作成テクニックを用いています。Gainsight社が提唱するヘルススコアのフレームワークの一つで、DEARは4つの観点からの頭文字をとっています。

Deploymentはオンボーディングを主に指している部分。Engagementはお客さんとの関係性を示します。Adoptionは利用状況について。ROIは費用対効果が出ているか、長期的に顧客が使う準備が整っているか、といった形です。

では、項目を一つずつ見てみましょう。

Deploymentは「プロダクトを利用する上で理想的な環境かどうか」を示します。スマホベースのプロダクトだとすれば、そもそもお客さんのスマホ貸与率がどれぐらいなのかをちゃんと測らないと、プロダクトも使われません。ですから、使う前提をまず整える。

そして、各要素を見ていきます。Sansanの場合は、ID付与、オンライン名刺の設定、ログイン済、スキャン済、名刺枚数という項目を設定しています。オンライン名刺はデジタル上で交換できるもので、最近はリモートワークも増えてきましたから、利用されたほうがいいだろうとマイナーバージョンアップのときに加えました。

Engagementは「お客さんとの関係性が良好かどうか」を示します。中身から説明しますと、Direct TouchとKeyman Touchという2つの要素があります。

Direct TouchはCS担当または営業担当が直近1年間に交換した名刺を元に、顧客接点を数値化したものです。1年間でリセットされるようにしています。「名刺を持っている枚数×役職ランク＋接点のある部署数」という計算式で求めます。

たとえば、顧客の10部署にコネクションがあり、その中で部長格の人に何人会っているのか、といった計算をして点数を出すわけです。このDirect Touchの値を増やしていくことは、CSMのKPIになっています。

さらに、Keyman Touchという顧客のキーマン把握度も見ます。特にエンタープライズは重視する傾斜配分ですね。

Adoptionは「顧客のプロダクト利用状況が良好かどうか」を表します。これは単純に、プロダクトのWAUなどを見ています。ホーム、スマホ、名刺取り込み、スキャナ稼働率といった機能によるWAUですね。プロダクトのログからヘルススコアに毎回同期して、その数字がよければ問題はありません。

また、名刺枠消化率は、契約で定められている名刺データ化枠を理想的に消費しているかどうかの割合です。Sansanの場合は1年間に消費する名刺枠をお買い上げいただく、いわゆる従量課金のような契約形態をデフォルトにしていますので、これが純粋に消費されているかを見ています。この数値は非常に重要で、Sansanで言うと最大チャーン因子の一つです。

ROIは「お客さんがサクセスしているかどうか」を示します。

サクセスしているお客さんは、通常はチャーンしにくいものです。なので、ROIが出ている人やサクセスプランを握れているお客さんは、目標があってどんどん進んでいるので、一般的には辞めにくいであろうという考えで含めています。ここは主にエンタープライズの顧客を重視して見るような傾斜配分になっています。

内容としては、Success PlanとInfrastructureに分けています。顧客ごとにSuccess Planを作成し、Gainsightに登録しているのですが、それが適切な設定なのかを数値化して見ます。お客さんと「今後2年で目指すべきこと」を握り、それに向けて進捗しているかを管理するイメージです。ただ、手動で登録しなければいけない点と、全ての顧客と握れているわけではないので、数値にムラが出るのが悩みです。

Infrastructureでは、Sansanの機能のうち業務フローに組み込まれやすいものを特定して、その機能の利用率が高いお客様を「Sansanがインフラ化している」と定義しています。皆さんのプロダクトにもいろいろな機能があると思うんですけども、「この機能を使う人はやめにくい」というものが直感的にあるはずです。そういうのをSansanでもランクづけしています。詳細はSansanのことだけになってしまうので、気になる方は図表を参考に。

適用比率で傾斜配分を

次に、適用比率という考え方を説明します。

先ほどヘルススコアについて、MRR50万円以上と50万円未満で分けていること、それからオンボーディング前後で分けていることを話しました。つまり、4象限あるわけですね。このヘルススコアの4象限について、重要視する傾斜配分を定めているのが「適用比率表」です。

たとえば、名刺枠の消化に関しては、オンボーディングを始めたばかりのお客さんなら、まだ名刺枠を消化しないでしょうから、重要視しなくてよい数値になります。

こういった適用比率を決めずに、傾斜をかけないでいると、あるヘルススコアが非常に低く見えてしまうことがあります。なかなか職人芸のような部分もあるのですが、重要だったりします。

ヘルススコアの正しい設計方法

Sansanのヘルススコアについて説明してきましたが、ここからは重要なヘルススコアの正しい設計方法を考えていきましょう。

あくまで私の理論なので絶対ではないのですが……プロダクトに価値があることは土台であって、その上で経験則、データ、定性感覚という3本柱で設計していきます。

最近のGainsight DEAR Frameは、DEARにExperienceを加えるようになってきています。DEARの部分がCO（カスタマーアウトカム）といわれ、顧客が出す成果ですね。ここにCX（カスタマー・エクスペリエンス）を追加する。CO＋CXがトレンドであり、これらを揃えてお客様に良質な体験を与えられているかを測りましょうと。

なお、データがまだない場合は、AdoptionのみでもOKです。プロダクト利用率だけからはじき出しても、ヘルススコアはそれなりに機能します。一応はDeploymentも欲しいところですね。ただ、簡単にデータとして取れないケースも多いので、それが取れない場合は一旦あきらめて、とりあえずプロダクト利用率から開始してもいいでしょう。

思考の順序、ここ重要です。5段階で考えます。

1段目は、営業とCSの直感からヘルススコア要素を洗い出し。もう現場の人の直感で、まずは絞っていきましょう。2段目に、過去データがあればそれを使って正答率を確認します。要は作ったヘルススコアが当たっているのかどうかを確認しながらステップバイステップで進めていくというのが大事なんですね。

3段目、データが無ければデータを貯めることから始めよう。ヘルススコアを作っていったら、データがないことに結構行き当たりますから、その場合は貯めるところからです。そして、データが半年分貯まったら、また2段目に戻り、正答率が悪ければ1段目へ。

営業とCSの直感からヘルススコア要素を洗い出しますが、ポイントを説明します。まず、デプロイメントでは、自分たちのプロダクトのQuickWinとは何かを考えます。要は、お客さんが「このプロダクトいいよね」と感じる瞬間を知ることです。そして、顧客とプロダクトがどういう状態ならQuickWinが発生するかを考えます。

プロダクトにお客さんも慣れていかなければいけませんから、プロダクトがこういう状態に達したら多くのお客さんが一つの体験を得られているに違いない、そこにQuickWinが発生する、みたいなことを考えます。

ヘルススコアの正答率の確認は重要です。作ったヘルススコアが当たっているかどうかを計測しなければならない。ヘルススコアを作ったときも、運用しているときもです。ちなみに4色のカラーレンジで考えたときに、私が考える「顧客が存在する理想比率」は上記です。

ざっくり言うと、「概ねよい」のライム以上で60％ぐらい。60％ぐらいが健全なお客様、残りの40％が不健全なお客様です。私の経験ですけどこの割合には理由があって、不健全なお客様は基本的にはCSMがフォローしなきゃいけないのですね。ということは、CSMが現実的にアテンションを張り切れる程度の数でないとだめなんですよ。

なので、仮に継続率がよかったら、ヘルススコアもある程度よいお客さんが多くなるように設計すべきです。これぐらいはあってほしいっていうふうな理想でヘルススコアの閾値みたいのを決める人がいるんですけど、現実に継続率がある程度よければ、ヘルススコアもいいはずなんですよ。なので、そういうふうな考え方で作っていってください。

私が出したこれは、年間のチャーンレートが10％から15％ぐらいだったら、良いと思いますね。20％を超えているなら、黄色と赤の割合を増やしてあげる必要があるでしょう。ヘルススコアは数値からじゃなくて、意図を持って決める必要があるんですね。

で、毎月、各領域からのチャーン出現率をチェックする。ヘルススコアを作ってお客様をプロットしたら、それぞれのレンジからどれぐらいチャーンが出てるのかっていうのを確認するんです。これによって答え合わせができます。ここ、今日の一番のポイントかもしれないですね（笑）。

たとえば、あるSaaSベンダーでヘルススコアの作り方を指南したことがあるのですが、このようにプロットされました。

私が支援して修正した結果は、全体の比率がライムが60％、グリーンが6％、ライムとグリーン合わせて7割弱ぐらいになったわけです。そこはチャーンも低かったので、これぐらいで十分だろうとは思いました。

加えて、イエローが28％でレッドが6％だったんですね。月々、どのカラーレンジからどれぐらいのチャーンが出ているかの答え合わせをしました。そうすると、全体の6％しかいないレッドから4.5％のチャーンが出たんです。次いで、28％いるイエローからは3.0％です、ライムからは0.7％、グリーンからは1.0％です。答え合わせになりましたね。

理想は統合環境を構築すること

新規顧客と既存顧客の最大の違いはデータの量です。

新規顧客はリードデータがあり、セミナー参加の有無があり、従業員数や売り上げ規模といったプロパティデータもあります。受注までセールスがヒアリングしたデータも。

でも、既存顧客は、それら新規のときにあったデータを含め、さらなる追加データがあるわけですね。それら圧倒的にあるデータを有効に活用できているかというと、案外そうはなっていない。ですから、もっと既存顧客ほどデータを重視すべきです。

ただ、社内に散在するカスタマーデータを集約するだけでも至難の業ですよね。事業活動においていろんなSaaSを使われていると思うんですけども、SaaSを入れれば入れるほどデータは分散されます。「それらを統合してカスタマーデータとして利用しましょう、ヘルススコアのデータソースにしましょう」というのは、言うは易く行うは難しなんです。

要はサイロ化するわけですね。今はこのサイロ化したデータをどうにかするようなSaaSも出てきていますよね。理想は、統合環境を構築することです。

Sansanは、いろんな周辺データをGainsightに集めてきて、Tableauで分析できるようにしたり、CSMがGainsightでヘルススコアを見られるようになったりしています。理想的にはこういった環境を構築するのがベターです。ただ、Sansanでも構築には2年ほどかかったので、それなりに覚悟する必要があります。

構築としては、一旦はサービスの利用データと顧客のプロパティデータくらいで始めましょう。データが貯まったら検証＆候補出しです。大事なのは、まずは勘でいいから考えて、その答え合わせするというプロセスを回すこと。

データ基盤もその裏でちゃんと作っていき、なるべく精緻なヘルススコアを作り、チャーン予備軍を洗い出せるほうがいい。その確率をより高めるにはどうすればよいかというと、下記5つの方法が挙げられます。

a.顧客を適切にセグメントする
b.有効なヘルススコア要素を洗い出す
c.各要素ごとの適用比率を調整する
d.更新と可視化をできるだけ自動化する
e.正当性を確認できる仕組みを持つ

では、一つずつ見ていきましょう。

まずは「顧客を適切にセグメントする」。SansanでいうMRR50万円以上と50万円未満、オンボーディング中とそれ以降、という分け方です。

プロダクトの使われ方や事業次第によってセグメンテーションは変えてください。私の支援したお客さんだと、そもそも新規で獲得してくる顧客をセグメントされていたので、そのセグメントをカスタマーサクセスでもそのまま使いました。

「有効なヘルススコア要素を洗い出す」は、最大チャーン因子を発見できれば、ヘルススコアの精緻化までを早められます。最大チャーン因子はチャーンを決定づける因子のことですが、数学的手法を使うことで発見を早められます。

最大チャーン因子は継続している理由から見つけるのも一つの手です。「チャーンした人を分析する」というよりも、「継続している理由」を見ると、結構わかります。なぜかというと、継続のほうがイレギュラーケースが少ないからです。辞めるときはイレギュラーケースが結構あるんです。チャンピオンロストとか、コストカットが走ったとか。

継続している人を分析したほうが、最大チャーン因子にたどり着ける可能性も高くなります。たとえば、プライシングなど関係が深いポイントを探してみる。ヘルススコアを作るときに、実は重要なのがプライシングとの関係です。

チャーンの理由に「効果の割に高い」というのがよくあります。金額の多寡はカスタマーサクセスから見るとどうしようもできないように見えますが、プライシングギャップを顧客が強く感じるときにはやめやすい。それが現れてくる数値が取れるときがあるのです。

「要素ごとの適用比率を調整する」のは、DEARで考えるときのちょっとしたコツがあります。Deploymentはプロダクトの利用準備が整ったかどうかを計測できる値ですから、一度設定して変動が少ないものは適用比率は低くします。

AdoptionとEngagementのようにセグメントで数値が大きく変わる場合は、セグメントごとに適用比率を調整してください。エンタープライズとSMBで傾向が違う場合は、Sansanで言うとMRR50万円以下か、50万円未満かに分けるように整理してください。

最大チャーン因子となる部分は適用比率も高くなります。

「更新と可視化はできるだけ自動化する」。これは当たり前ですよね。プロダクトデータや顧客のプロパティデータを統合していくのも、主に自動化のためです。

自動化できると、お客さんの契約情報が取れたら、自動的にその適用比率を計算できるようになったりもします。ここまでできればDeploymentとAdoptionはだいたい構築できるので、それ以降はより付加価値の高いデータを統合できないかを検討します。

プロパティ情報、プロダクト情報を優先的に統合できれば、無駄が多少は減ります。ここではSaaSの活用も検討してください。今はヘルススコアが見れたりとか、データを統合するようなSaaSも出てきています。

「正当性の確認できる仕組みを持つ」については、答え合わせが重要だと言ったことにつながります。Sansanでは「DataRobot」を使っていますが、何でも構わないので、予測モデルを使ったデータ分析手法で、確からしさを確認しましょう。

これは、クラウド上で予測モデルを立ててくれるようなプロダクトで、Sansanではマーケで使っていたんです。マーケのリード情報のスコアリングをするためでしたが、カスタマーサクセスの正答率の予測にも使えるのではないかと、思い切って試してみました。

そうすると、私が立てていた仮説の中で当たるものもあったし、それよりもこっちのほうが重要だったこともあった。予測モデルは精緻なヘルススコアを作るのに、最終的にはやっぱり寄与しました。でも正直、私は数学的な観点での良し悪しは、あまりわかっていないです。

アクションプランと成果への影響

ヘルススコアを成果につなげるために、少し応用の話をします。以前にSansanでも、ヘルススコアが良いお客さんを担当する人たちと、ヘルススコアが悪いお客さんを担当する人たちとを分けて組織を作ったことがあったんです。

まず、組織を分離しました。ヘルススコアが悪い顧客をフォローするチームを「守り」とすれば、反対は「攻め」として、アクションも変えています。具体的には「守り」はエクスパンション目標とチャーン目標が低く、管理者への接触量重視に。人員も「農耕系営業」とでもいうのか、あまりガツガツしていない、寄り添い型の人を集めました。

「攻め」はチャーンリスクが低く、エクスパンションも一応の傾向が見られているので、決裁者への接触量重視で、エクスパンションを重視します。人員には「狩猟系営業」を集めると。

すると、目標達成が四半期で「守り」が110％、「攻め」は130％という結果でした。まさにへルススコアがしっかり機能し、みんなが信頼感を持っている状況だから成り立ったといいえると思います。

チャーンするお客さんの1割から2割はアンコントローラブルチャーンなこともあります。

チャーンにはコントロール可能なコントローラブルチャーンと、不可能なアンコントローラブルチャーンがあるとされています。アンコントローラブルチャーンは景気の後退、顧客の事業戦略変更、顧客のサービス導入推進者（チャンピオン）の異動や退職といった要因で発生しやすいです。まずは、アンコントローラブルチャーンが一定発生してしまうことを認識しておきましょう。

ヘルススコアの正しい使い方を、私なりの認識として合わせさせてください。「そもそもヘルススコアって何に使うの？」という話ですね。私は3つを挙げました。

1つ目は、顧客全体の健全性のグラデーションをつかむためです。つまり、健全なお客さんは増えているのか、減っているのかを把握する。

2つ目は、メンバーのCS活動の網羅度・徹底度を計測するためです。キーマンへのグリップが足りないとなったとき、ヘルススコアで「キーマンのグリップ度」を測れるようにすると、組織全体でその進捗を確認できるようになるわけです。

3つ目は組織として健全なCS活動がうまく実行しているかをつかむことができます。

つまり、ヘルススコアっていうのは主にマネージャーのためのものなんですね。それこそ、現場の人はヘルススコアを見なくてもいいと私は思ってます。現場は何より顧客を見ることが大切です。

CTAの構築につなげる

ヘルススコアを基本的に機能させられた先には、CTA（Call to Action）の仕組みづくりが可能になってきます。

CTAは、ユーザーが発した何らかの行動をトリガーとして、カスタマーサクセスマネージャーに行動を促すアラートと、そのアラートによって生まれたタスクをクローズまで管理する仕組みのことです。

Sansanの場合は上図のようになっています。左側にあるProductは契約データやプロパティデータ、サービスの利用データがあります。ここからID付与率が80％未満、名刺投入枚数が250枚以下、ヘルススコアがイエロー以下になったときにCSMにアラートをシステムが出し、タスク化されます。このタスクをシステムによってクローズまで管理される。

ヘルススコアをしっかりと整備されていれば、その変動にアラートを仕掛けて、CMSにそれを伝えられるのです。

Sansanだと攻めと守りのCTAがあります。攻めはエクスパンションを検知するためのCTAで、守りはチャーンを検知するためのCTAです。

年間の名刺データ化枠の消費が良いお客さんは、消化率80％に達したら、インサイドセールスに通知が出て、増枠をおすすめするアクションを取ります。あるいはID追加です。SansanはID追加を管理者がカジュアルにできるようになってるんですね。

また、共有IDでSansanを利用している兆候を見つけたらセールスに通知します。Sansanは基本的に共有IDでの使用が禁止になっていますから、約款違反として別IDを用意してもらう交渉を始めます。

守りのCTAは、契約更新の3カ月前、6カ月前になっても、名刺枠があまり消化されてないときなどに早めに手を打っていきます。インサイドセールスに通知し、お客さんに状況を聞く、そのあとCSが出ていくみたいなことをします。

CTAが機能し始めたら、プレイブックに基づいて行動することが基本的に推奨されます。プレイブックは、各社の経験や英知に基づく定石が書かれた戦略集です。マニュアルとは異なり、「この行動をすべき」ではなく「これをゴールとして動け」という目標をまとめていくものに近い。プレイブックはテックタッチでよく使われます。

プレイブックがあると、役割の明確化、トレーニングの簡素化、成果の測定などの効果があります。CTAで自動タスク発動、プレイブックに従ってタスクを消化が、よくやることです。Sansanの場合は、これによってエクスパンションのうち15％をCTA経由で稼ぎ出したことがありました。

ヘルススコアを精緻にしていくと、テックタッチオンボーディングが実装できるようになります。これも実はCTAが裏にあります。オンボーディングが悪いお客さんのCTAが飛んできて、CSがフォローするようにしました。ヘルススコアデータそのもののプロダクトの利用率から判断していましたが、18％から30％ぐらいのお客さんを自走させ、セルフオンボーディングできたこともあります。

ヘルススコアでデータ基盤を作ったあとは、テクノロジー活用して、CSMにアラートを発信して、タスク管理するCTAのような仕組みは、効率化する上では必須だと思っています。お客さんが少ないうちは手弁当でも可能ですが、皆さんのプロダクトが好調で、お客さんの流入が激しくなるほど、アテンションを張りきれませんから。

‍

著者：山田ひさのり

『カスタマーサクセス実行戦略』の著者。ゲームプログラマーとしてキャリアをスタートし、Web開発のPG/SEを経て事業開発にキャリアチェンジ。その後、Sansan株式会社にてCS部門の責任者を歴任。現在はsasket LLCを設立し、2年間で約20社へのCSアドバイザリーを経験。