こんにちは。Autify カスタマーリライアビリティエンジニアの堀です。 前回の記事から少し期間が空きましたが、この記事は「Autifyにおけるカスタマーサクセスツールの導入とデータドリブンな日々の活動が軌道に乗るまでの物語（前編）」の続編です。
昨年からはカスタマーサクセスチームの布陣も変わり、「カスタマーサクセスエンジニア」は「カスタマーサクセスマネージャ（CSM）」と「カスタマーリライアビリティエンジニア（CRE）」の二職に分かれ、私は正式にCREとしてCSMの活動を主にデータ・コンテンツ面から支える業務の比重を高めて活動することとなりました。 その裏話につきましては、こちらの記事「『CSM』と『CRE』の2職種を新たに設けた背景や舞台裏」をご覧ください。
さて、本記事では、前編でご紹介したカスタマーサクセスツールを活用し、私たちの活動が軌道に乗るまでのお話を進めていきます。少し長いので目次もご用意しました。
データを手に、チームを心に
自明のようではあるものの、顧客データがある程度整備されたあと、その価値を大きく左右するのは利用者である人間です。 投入されたデータを手に、何に着目してどのような行動を取るかを考えはじめることは、データの活用とその継続的な改善をするための第一歩となります。
特にデータは一度投入して終わりではなく、プロダクトの成長やカスタマーサクセス活動で重視する領域とともにニーズが変化するため、利用者からのフィードバックを得ながらの継続的な改善が不可欠です。 一方で小さな組織では、データ収集の実装者と利用者が同一であるケースも少なくありません。 私自身はまさにそのような兼任者でしたが、自分の物の見方だけではデータ利用者の視点としては心許なく感じられました。
そのような絶好のタイミングで、前職から技術的なプロダクトのカスタマーサクセスに携わってきたメンバーが新たにチームに加わってくれました。 彼の提案で最初に始めたのは、日次のデータ投入に合わせて、毎朝内容を一緒にチェックする朝会です。
カスタマーサクセスツール利用の初期段階における、データを毎日見ることの習慣化には、今振り返ると以下のような効果があったと思います。
- 数値に対する肌感を養い、チーム内で共有する
- データの質を上げ、継続的に追っていく対象の値を増やす
上記の 1. については、特に個人プレイからチームプレイに移り変わりつつあった組織の段階からしても、認識共有の面でも大きな価値がありました。各プランを契約されたお客様がどのくらいの数いて、Autifyでどのくらいのテストを実行しているのが理想的な状態といえるのかなど、同じデータを見ながらメンバー同士で議論することは、チームにおけるカスタマーサクセス活動の基礎となりました。特に前職でのカスタマーサクセス経験者の視点が加わったことで、以前は注目していなかったようなことに対する気づきが得られるようになった点にも大きな利点がありました。
また 2. のデータの質については、初めのうちはシンプルにツールに投入されたデータと、実際のお客様の利用状況を見比べながら齟齬がないかを注意して見ています。疑わしい値については集計のクエリを見直したり、データソースの管理者に元データを確認してもらったりと、地道なサイクルを経て精度を上げていきました。
加えて、お客様の利用状況を一緒に見ながら会話していると「こんな目的で○○のデータも足してみたらどうだろうか？」と追加で取得したい項目のアイデアが出てきます。そのような場合には自分たちでデータ収集のクエリにサクッと追加してしまうなど、データ収集の実装者とデータの利用者が一致していたためにチーム内で素早く対応できたことは、円滑なフィードバックを回す上で大きな利点であったかと思います。
セグメンテーション in Action
私たちが現在利用しているカスタマーサクセスツールのChurnZeroでは、特定の状態のお客様に関するアラート通知を行うにも自動化フロー（Play）を組むにも、基本単位となるのは常にセグメントでした。 このため、投入された契約情報・プロダクトの利用情報・お問い合わせなどのデータをもとに、「どのようなお客様の状態」に「どのようなにアプローチできそうか」を考えながら、ツール上でセグメントを作成していくことになります。
最初は気負わず、思いつくことから始めました。
- 「○○を利用していないお客様へ」「活用するためのアドバイスを送る」
- 「○○の利用が多いお客様に」「△△をおすすめする」
あるいはもっと単純に、まずは「お客様XがYの状態になったら気づきたい」といった場合もあるでしょう。 そのような対象を見つけたら、投入された利用状況のデータを用いて条件式を設定してセグメントを作成していきます。
アラートのための条件式や閾値も、初めから完璧なものを用意する必要はありません。 チームのSlackチャンネルに通知が届いたら、お客様の実際の利用状況を詳しく見に行き、アクションを検討したりアラートの閾値を調整する「とりあえずやってみる」スタイルは、活動を軌道に乗せる上でよい出発点となりました。
このようなアラートの内容も朝会でチェックしていましたが、徐々に既知の内容が増えてきたり、必要なものの取捨選択が進むにつれ、確認は非同期で行えば十分になってきました。 やがて朝会の開催はその役割を終えて終了しましたが、チームメンバーが増えた現在から振り返っても、この頃の活動はチームによる活動の基礎を確立するのに役立ったと考えています。
継続と改善と3つの動機
では、ここで前編の記事で書いていたカスタマーサクセスツール導入に対する動機を振り返ってみましょう。
📈 お客様の数とCSチームの成長に応じた「スケーラビリティ」
お客様の数や対応にあたるチームメンバーが増えてもデータ量に圧倒されることなく、特に注目すべきお客様に関してアラートを上げるなど少ない労力で割り出せるようにする
自動化できるワークフローは自動化することで、本来注力したいお客様のケアに手を割けるようにする
🔎 観測情報を一箇所に集めた「オブザーバビリティ」
多様なツールに散らばったプロダクト利用情報・契約情報・お問い合わせ情報を、お客様毎に対応づけた形で一箇所で見られるようにする
集約した情報をもとにお客様のヘルススコアを算出し、値の変遷を時系列で観測できるようにする
📝 自分たちの行動と、顧客の変化を記録する「トレーサビリティ」
どのお客様にどのようなアクションを取ったかを記録し、それに応じた顧客の変化を追えるようにする
ひいては、仮説に基づく行動をとった上で、結果を定量的に見返せるようにする上記の3点について、それぞれ実際やってみてどうだったかを、順にご紹介していきます。
スケーラビリティ：何を手動で行い、何を自動化するか
特に人的リソースの限られたカスタマーサクセスチームでは、大勢いらっしゃるお客様に対していかに効果的なアクションをとるかは大きな課題となります。 しかしながら、そもそもどんなアクションが有効かが分かっていない時点では、何かを省力化しようと思ってもその対象が不明瞭です。
このため、以下のようなモデルを（当時は頭の中でなんとなく）想定し、最初は特定の条件に合致するお客様についてアラートを上げる自動化をレベル1、それに対するタスクの起票を行う自動化までをレベル2、実際にアクションを行うまでの自動化をレベル3と捉え、手動によるアクションによる手応えを確認しながら、段階的に自動のアプローチを増やしていくことを考えました。
結果はどうだったでしょうか？ 運用を開始して数ヶ月が経過した後も、レベル3まで運用が定着したものはそれほど多くなく、実際は「アラートを上げる」レベル1、「タスクを起票する」レベル2までに留めたものが中心となりました。 これは特に、リスク検知に対するアクションは自動化できるような形で定形化できるものが少なく、手動でフォローアップを行うのが妥当だと思われるケースが多かったためです。 一方で、利用状況を定量的に把握できる機能のおすすめのように、アクションした成果として測定可能な結果が得られるようなケースでは、レベル3までの自動化が効果的に機能しました。
お客様へのアプローチの自動化は、カスタマーサクセスツールを導入する動機のひとつではありましたが、求められるアクションの性質に応じてレベル1. 2. 3.をいかに効果的に使い分けるか重要であることが、実際にやってみると明らかになりました。
オブザーバビリティ：スコア推移の観測と未知の発見
システム監視の文脈におけるオブザーバビリティは、既知の監視項目をシンプルに追っていく従来のモニタリングに対し、複雑で未知の事柄が多いシステムに対する発見を行えるようなシステムの特性として言及されることが多いかと思います。 カスタマーサクセスも似たところがあり、継続的に追っていけばよいと初めから分かっている指標は限られていて、むしろ活動をしている過程で発見されることがよくあります。 しかしながら、その指標の候補となりそうなデータを時系列で取得してさえいれば、何かがあったときに遡ってみることも可能です。
そこで強力なツールとなるのが、お客様の健全な状態をはかる目安となるヘルススコアです。 最初に作成したヘルススコアでは、利用状況のデータから代表的な値（テストの実行数など）を5, 6個パラメータとして選定した上で、各々に重みづけをした和をもとに算出し、時系列で記録できるようにしました。 あわせて、算出したスコアに対しては良好な順に緑・黄・赤の色分けを行い、リスク検知のトリガーにできるようにしています。 スコアが黄や赤になったときには、いつと比べてどのパラメータが悪化したのかに加えて、スコアの算出に使っていない数値や実際の利用状況を詳しく見ていきます。
理想的には、スコアが良好であればあるほどお客様がサービス利用を継続・拡大しやすい状況、またスコアが思わしくない場合にはカスタマーサクセス担当者が積極的にお客様の課題へアプローチできるような状況を実現できていることが望ましいです。
しかしながら、これは一朝一夕にはいきません。 書籍「カスタマーサクセス・プロフェッショナル」（英治出版）第9章には、以下のような言葉があります。
手持ちのデータでヘルススコアを設計しよう。
完全に網羅的なデータが揃うことなどない。
おもしろいもので、利用すればするほどデータの質は向上する。実際、スコアを継続運用する中で、私たちのスコアは何度もアップデートを重ねてきました。 特に、スコアの想定が覆されるような状況が発生した際は、絶好のチューニングの機会です。
代表的な例としては、利用状況をはかるスコアが良好にも関わらず利用継続を希望されないお客様が、思った以上に現れるケースがあります。 いわば「不都合な真実」に向き合う時間ですが、これひとつをとっても考えられる仮説や対策はたくさんありました。
- 「利用状況の良好さ」と「利用継続可能性の高さ」は必ずしも一致しない
- 「利用継続可能性の高さ」をはかるための、定量的なパラメータが不足している
- 定量的なパラメータに加えて、ミーティング等でお客様から伺ったご意見などに基づく定性的な側面も考慮する必要がある
上記 1. と 2. に対する対策としては、それまで暗黙的に「利用状況が良好ならば、利用継続可能性も高い」としていた前提を見直し、「利用継続可能性の高さ」をはかるスコアを新設して、「利用状況が良好さ」をはかるスコアとは別のものとして計測するようにしました。 「利用継続の可能性の高さ」をはかるスコアについては、それまでスコアリングに使っていなかった過去データの傾向を振り返り、新しい変数を導入しています。 加えて 3. もきわめて重要な点で、機械的に算出するスコアと、実際にお客様とコミュニケーションをとった結果に基づくインプレッションの両面からお客様のヘルスを管理するようになりました。
現在でも、実際にお客様の継続利用を予測をするときなどには、スコアとインプレッションの両方を用いるようにしています。このような定量的なスコアと定性的な情報の併用の度合いは、今後より良いバランスを探っていきたいと考えています。
トレーサビリティ：振り返り可能なアクティビティの記録
お客様に対していつどのようなアクションをとったか、すなわちスコアの変化に応じて利用状況を確認したり、ミーティングを実施したりしたときは、その内容をアクティビティとしてChurnZero上に記録しています。 また、アクティビティの記録は自動化されたフローからも行えるため、アクティビティには手動・自動の両方の記録が残ります。
すると、特定のお客様に対してある時点で振り返りを行ったときに、手動・自動を問わず過去にアクションが取れていたか、あるいはそのアクションが何らかの変化の契機になっていたかをスコアの変化とともに遡ってみることができます。 もし、なんらかの条件下でのアクションを契機に良好な変化が起きている傾向が読み取れた場合には、これを再利用可能なプレイブック化に落とし込むこともできるかもしれません。
また、このようなアクティビティの記録は「直近アクションが取れていないお客様」のようなお客様のセグメンテーションや、さらには各カスタマーサクセス担当者がどのくらいのタスクをこなしているかを把握するためのチームマネジメントの側面からも有用です。
チームを超えたデータのアクセシビリティ
これまでは主に、お客様のデータを利用したAutifyのカスタマーサクセスチームの活動についてお話をしてきましたが、今後の活動の柱となっていきそうなことのひとつにデータへのアクセシビリティがあります。 すなわち、カスタマーサクセスの活動や進捗を「カスタマーサクセスチーム」内に閉じることなく、積極的にお客様や他のチームと共有できるようにしていきたいのです。 Autifyでは、主にデータウェアハウス内のデータを可視化するのにHolisticsというツールを使っており、これをカスタマーサクセスに活用した直近の取り組みや、今後の展望をご紹介をして本稿を締めくくれればと思います。
目標と進捗をお客様と共有するためのレポート
カスタマーサクセス担当者は、お客様の目指すゴールを把握した上で、達成までの道筋を示しながら共に歩む必要があります。 その過程では、お客様と私たちが同じ視点を共有できるような定量データに基づくレポートがあると、定めた目標に対して何をどこまで達成したかを把握いただく上で便利です。 私たちは個別のお客様向けの利用状況レポートをHolistics上で容易に出力できるようにしており、お打ち合わせ時などに持参することがよくあります。
また直近カスタマーサクセスマネージャーとして加わったメンバーが、お客様のオンボーディングにおける定量的な目標や、その進捗をはかるスコアを設計してくれており、これらに沿った新たなレポートの実装も考えています。 サービス提供者側が一方的に考えたものではなく、オンボーディングセッションを通じてお客様と共有した目標に沿ったスコアリングとレポートは、お客様にとってもより納得感の得やすいものになるのではないかと期待しています。
全社的にアクセシブルなカスタマーサクセスへ
もう一つ、今後いっそう強化していきたいと考えていることは、社内の他のチームへのお客様の状態の共有です。 せっかくのヘルススコアなどのデータも「カスタマーサクセスツール」内に閉じてしまっていては、他のチームはその内情を窺い知ることができません。
幸いなことに、ChurnZeroはOData（Open Data Protocol）に準拠したAPIを提供しており、さらに私たちがデータ集約に利用しているデータパイプラインツールCData SyncはOData準拠のコネクタを持っていたため、ChurnZero内に記録されたデータは容易にデータウェアハウス（Redshift）へ流し込むことができました。 すると、Holisticsで元々見ることができていたプロダクトの利用状況や契約情報とあわせて、お客様のヘルススコアやカスタマーサクセスのアクティビティ情報を可視化できるようになりました。 これは非常に強力で、ボードメンバーや他チームが見ても把握しやすい、お客様全体の状況を俯瞰できるレポートの作成に役立っています。
最後にもう一度、「カスタマーサクセス・プロフェッショナル」からの引用です。
カスタマーヘルスは全社で共有しよう。
プロダクト、テクニカルサポート、営業に至る全部門で共有するのだ。
ヘルススコアを活用し、カスタマーと彼らの成功のために最善の意思決定をしよう。私たちのデータ基盤やカスタマーサクセスツールも、チームが活動を続けるかぎり「完成形」になる日は来ないでしょう。 だからこそ、絶えずチーム内・外と連携をしながら継続的な進化を続けていければと考えています。
最後に少しだけ宣伝です。 私がCTO松浦と共訳した書籍「カオスエンジニアリング――回復力のあるシステムの実践」がオライリー・ジャパンより発売されました。
https://www.oreilly.co.jp/books/9784873119885/
カオスエンジニアリングは、大規模なソフトウェアの分散システムに限らず、あらゆる複雑なシステムに対して適用可能な手法です。 本書でも人間の組織における実践例などが紹介されており、もしかしたら「カスタマーサクセスにおけるカオスエンジニアリング」なども、将来的に実現するかもしれません！