チームの心理的安全性を可視化しよう！今すぐできる超簡単ワークショップ「片思いマッピング」
TECH
2022.12.23
ヘルススコアをアップデート、設計で気づいた重要ポイント
writer
2022.11.30
2022.12.27
こんにちは。自社開発SaaS「SEARCH WRITE」の開発チームの伏野です。
現在はバックエンド開発をメインに担当していますが、他にもエンジニアリングスキルを使ってカスタマーサクセス(以下CS)領域の活動を改善するという、社内向けの施策を実行する役割も担っています。PLAN-Bではこうした役割を「CSOps」と呼んでいます。
先日、SEARCH WRITEで使っているへルススコアをアップデートしました。
ヘルススコアとは「お客様がサービスをどれだけ活用して成果を出せているか」を数値化したものです。お客様がサービスをうまく活用できていない場合、その理由を早期に発見して改善するために使います。
ヘルススコアの設計は、対象となるプロダクトの性質やビジネスモデルによって形が大きく変わるため、設計の難度はかなり高いと思います。
本記事では、CSOpsとしてヘルススコアをアップデートした体験談をベースに、これからサービスのヘルススコアを考える方のヒントになるように、ヘルススコアが実際の現場でどのように設計・実装されているのか、を具体的に書いていきます。
SEARCH WRITEのヘルススコアのアップデートは以下の流れで進めました。
- 旧ヘルススコアの課題を探る
- お客様の理想的な状態を新たに定義する
- 見るべき指標と配点を決める
- 実装・運用フローを決める
- ヘルススコアの妥当性を検証する
旧ヘルススコアの課題を探る
SEARCH WRITEでは1年ほど前から「サービスの利用状況」を指標化したヘルススコアを使っていました。
お客様の理想的な状態を「SEARCH WRITEを継続的に利用していること」と定義し、「各機能の月間利用回数」「月間アクティブ日数(サービスを実際に利用した日数)」「お客様のメディアのセッション数の増減率」などを使ってヘルススコアを算出していました。
ヘルススコアが高い順にお客様をA~Eの5段階にセグメント分けし、CSはスコアが低い(継続的に利用できていない)お客様を優先的にサポートしていました。また継続的にお客様のスコアの変化を確認し、スコアが悪化してランクが落ちていた場合は、即座にアプローチするという方法で運用をしていました。
課題の探索
1年近く運用したところで、ヘルススコアと解約率の関係に乖離があることが見えてきました。
ヘルススコアと解約率との相関性が高いと、サービスの指標として良い状態だと言えます。
ただ実際にランクごとの解約率を算出してみると「Cランクの解約率 > Eランクの解約率」となっており、ヘルススコアが実状を正しく表現できていないことがわかりました。
つまりヘルススコア上では一見健康そうでも、予期せぬ解約に至る理由があり、それをキャッチアップできていなかったということです。解約理由の中には「SEOを実施しなくなった」「体制が変わり運用を継続できなくなった」などがありました。
もちろん体制や方針の問題はありますが、解約に至るということは、お客様に支払っていただいている金額以上の価値を感じていただけていなかったということです。
こういったお客様の状況をより早く知ることができれば、もっと価値を提供するために、サービスとして改善していくことができます。サービスの利用状況以外の部分でも、お客様の状況の変化を知る仕組みが必要であることがわかりました。
解約率とヘルススコアが乖離しているという事実は、ある程度の期間運用することで初めて見えてきました。
個人としては、ヘルススコアの課題発見にはある程度運用期間が必要であることを学びました。
発見された課題は「サービスの利用状況だけでは解約を予見できず、サービスを改善するための情報として不十分だった」ということでした。
他にもAmpliudeという分析ツールを使ってヘルススコアの妥当性を検証する試みもしています。
お客様の理想的な状態を新たに定義する
ヘルススコアをより実状に近づけるべく、「DEARフレームワーク」を参考にして、お客様の理想的な状態を4つの観点から整理しなおしました。
DEARフレームワークとは、ヘルススコアを設計する際に用いるフレームワークです。「Deployment」「Engagement」「Adoption」「ROI」という4つの観点でお客様の状況を可視化する考え方です。
DEARフレームワークを参考にSEARCH WRITEとして整理しなおしたお客様の理想的な状態:
Deployment: 主要機能の使い方をお客様が把握できている
Engagement: お客様を支援するうえで必要なコミュニケーションがとれている
Adoption: サービスが継続的に利用されている
ROI: お客様のメディアのセッション数が増加している
旧ヘルススコアでは「サービスの利用状況(Adoption)」と「成果(ROI)」のみで判断していましたが、新ヘルススコアではDeploymentとEngagementという観点が加わったことになります。
特にEngagementの追加により、お客様とのコミュニケーションによって状況をより明確に知れているかを測り、旧ヘルススコアの課題の解決につなげたいと考えました。
見るべき具体的な指標を決める
さらに、DEARの４つの観点それぞれについて、見るべき具体的な指標と配点を決定しました。
Deploymentについて
Deploymentは「主要機能を一度以上利用できているか」という指標で評価することに決めました。SEARCH WRITEを使い始めたお客様が、主要な機能の使い方を理解して利用できているかをこの項目で確認します。Deploymentの数値が低い場合はサービスの利用が軌道に乗っていないと考えられるため、早急にCSが導入支援などのサポートを行います。
Engagementについて
Engagementはお客様との導入/活用支援の打ち合わせにおいて「必要な情報を把握できているか」「目標を一緒に設定できているか」という指標で評価します。
CSがお客様の状況を把握してサクセスに導くためのサポートを十分にできているかを確認します。
定性的で判定しづらい指標であるため、これまではCSチームの中でも属人的になっていた部分でした。ヘルススコアとして具体的な指標を決めることで、CSチームとして取るべきコミュニケーションの基準が定まりました。
Adoptionについて
Adoptionについては「主要機能の月間利用回数が減っていないか」という指標を用いています。先月までは順調に利用できていたのに、急に利用回数が減った場合は、これまでと同じようにサービスが利用できない理由が発生したと考えられるため、早急に状況を把握するべきだといえます。
新しいヘルススコアでは主要な機能に絞って利用回数を指標化しています。例えばSEARCH WRITEでは、「記事の構成を考えるための機能」「記事を作成するタスクを管理する機能」「記事の成果を確認する機能」が、お客様がサービス上で施策を実施する上で重要な機能になります。
このようにお客様がサービスを利用する上での動きに沿って指標化する機能を絞ることで、うまく活用できているかを知ることができます。
ROIについて
ROIは「お客様のメディアへのセッション数が増えているか」「お客様と決めた目標数値を達成できているか」という指標を用いています。
点数配分を決める
それぞれの指標を決めたあとは点数配分を決めました。
合計100点満点で、お客様がサービスを活用して成果を出すためにどれだけ重要かを尺度に、点数を振り分けます。
SEARCH WRITEでのDEAR項目ごとの点数配分:
Engagement(35点) = Adoption(35点) > ROI(20点) > Deployment(10点)
PLAN-Bではお客様とのコミュニケーションが最も重要であると捉えているため、Engagementの配点を大きくしています。
実装・運用フローを決める
実際にヘルススコアを算出するために必要な情報をどこに蓄積し、算出したヘルススコアをどこに集約するかを決めていきます。
機能の利用状況は定量的なデータであり、元々データベースに蓄積されていたので簡単に抽出することができました。DeploymentやAdoptionの指標のほとんどは、SEARCH WRITEのデータベースからCSVで抽出し、Salesforceにインポートしています。
ヘルススコアは「実際に運用してみて初めてわかることがある」と学んだので、なるべく早く運用を開始したいと思っていました。データのインポートについてはAPIを使えば作業が楽になりますが、開発に時間をかけるよりも早く運用を開始することを優先して、手動でのインポートにしています。しばらく運用や改善を回して指標などが固まってきたら、APIでのデータ連携を進めたいと考えています。
今回特に難しかったのは、定性的な情報の集め方でした。
新たに指標として追加したEngagementを算出するために、まずはSEARCH WRITEのCSM(カスタマーサクセスマネージャー)と協力して、お客様のサポートのために本当に知るべき情報はなにかを洗い出しました。データを入力してもらうためにCSメンバーの業務フローを考えなおしました。 結果、CSチームにはお客様との打ち合わせが終わった後に議事録を全てSalesforce上に項目ごとに細かく残してもらうことになりました。
そうして集められた情報はSalesforce上で集計されます。
保存された議事録情報を参照し、「決められた項目が正しく入力されているか」という基準を用いて毎朝スコアが自動で更新されるようにしました。
業務改善への利用
最終的な合計スコアをSalesforce上でお客様ごとに確認できるようにしました。
CSメンバーはお客様のヘルススコアを見ながら、数値が低い部分の改善を進めます。
登場人物と情報の関係図
情報を評価する流れのまとめ:
- 機能利用状況をデータベースから CSVで抽出しSalesforceにインポートする
- Engagementの指標はCSメンバー記入の議事録を参照して日次で自動更新
- CSメンバーはお客様のスコアをSalesforce上で見ながら改善アクションをする
ヘルススコアの妥当性を検証する
算出されたスコアが実状を表現しているかどうかを判断するためには、実際にお客様に相対しているCSメンバーの肌感もとても重要です。直近半年以内に解約したお客様のスコア推移を算出し、一緒にヘルススコアを眺めて違和感がないかを確かめてもらいました。結果、旧ヘルススコアに比べて実状に近いという感想を得ることができたため、運用を開始しました。
これからの課題
今回の運用を開始する際に新たに感じた課題は、「全てのお客様を1つの尺度で評価することは難しい」ということでした。サービスを使い始めたばかりのフェーズのお客様と、既に1年以上利用しているフェーズのお客様とでは、重要な指標は少しずつ違います。これから運用していく中で、よりフェーズごとに合わせた指標に改善していきたいと思います。
まとめ
今回はヘルススコアをアップデートした際の流れを具体的に書きました。
ヘルススコアはプロダクトごとに、扱う指標も集計方法も業務フローも千差万別です。
だからこそ設計は困難でしたが、「お客様がサービスをうまく活用するために私たちが知るべきことは何か」を考え続けることで、どうにか前進できたと考えています。
皆さんが携わるサービスのヘルススコアを考えるヒントになれば幸いです。
CSOpsがエンジニアリングを用いて CSの業務を加速させるのと同じように、 マーケティングやインサイドセールスの業務をエンジニアリングで加速させるMarketingOpsに関する記事もあるので、興味があれば是非読んでみてください。
株式会社PLAN-Bに新卒入社して、未経験からエンジニアへ。複数の自社SaaS開発、ビッグデータ系の受託開発など、入社から1年半で4つのプロダクトチームを経験。AWSでのバックエンド開発を中心に、最近はフロントエンドも勉強し自作アプリの開発も。「互いの人生に良い影響を与えられるようなチーム」を作りたい想いから、開発業務だけでなく、チームビルディングワークのファシリテーションや、メンバーのコーチングなどにも積極的にチャレンジ中。スクラムマスターの社内コミュニティ、スクラムマスターギルドのメンバー。最近身長が1cmのびて185cmになった。
