Gainsight導入奮闘記：後篇 ～設計に関する話～
お疲れ様です！
カミナシでCS（カスタマーサクセス）をしている石井といいます。
23年9月の拙稿「カミナシカスタマーサクセスの新機軸！「焚き火理論」とヘルススコアについて」、ありがたいことに社内外の方から「なかなかオモロいやないかい」と反響をいただきました。
今回は、「では、実際に焚き火理論をヘルススコアに落とし込んだ”その後”は何をやっていたのか？」について書きたいと思います。
”運用に関する話”と”設計に関する話”の前後篇となります。
こちらは後篇：設計に関する話です。
前篇はこちらです
長いですが、お手隙でお目通しいただけますと幸いです。
これまでのあらすじ
焚き火理論が社内で日の目を浴びるのとほぼ同時期に、カミナシではGainsightの導入が決まっていました。
その時点では「たぶん、これで正しそう」という感覚しかありませんでしたが、カミナシのバリューは「β版マインド」。
まずは動いてみようぜ、ということで、焚き火式のヘルススコアを元にGainsightの基盤構築を進めることになりました。
（焚き火理論とヘルススコアについてはこちら）
後篇では、具体的にどのようなCall To Action（CTA）を作っていったのか？について書いていきたいと思います。
（「CTAってなんぞや？」という方にはこちらの記事がわかりやすくおすすめです！）
やったこと
①継続に向けたヘルススコアの要素を更に分解した
諸先輩方には釈迦に説法ですが、ヘルススコア自体が目的化してしまうことは絶対にあってはいけません。まずは「何のためのヘルススコア/CTAか？」を明確にしました。
Gainsight導入時に社内で決めたことの1つに、「まずはチャーン阻止に集中する」というものがありました。カミナシCSのKPIツリーとしても当然「アップセル」はあったのですが、今回設計するCTAは「継続」に関するもののみ、としました。つまり、完全にリスク関連、「守りのCTA」に振り切るということです。
順番としては
といったイメージです
②CTA/Playbook/Taskをカミナシなりに定義した
Gainsight内では
1.CTAが発動する
2.各CTAに対してPlaybookが用意される
3.Playbook内のTaskが割り振られる
という流れに基づいてCSの活動がガイドされます。
※ルー大柴的な表記ですみません、機能名なのでこのまま英語表記で失礼します
それぞれのCTA/Playbook/Taskの実施状況はGainsight内で追うことができるため「やばい！あの案件漏らしていた！」「案件多すぎてどこまで対応してるかわからない！」といったことを無くせる、パーヘッドの悩みが尽きないSaasCSにとっては夢のような仕組みです。
一方で、こういった言葉ほど認識のズレを生みやすい（現に「プレイブック」という言葉もメンバによってマニュアルとして捉えていたりTips集として捉えていたりと様々でした）ので、議論の前に「Gainsight設計におけるCTA/Playbook/Taskの定義」を運用メンバー内ですり合わせました。
議論を踏まえ、現在は以下のように定義しています。
ここでのキモはPlaybookを変数が多い「お客様の状態」ではなくコントローラブルな「CSの状態」で定義したことです。CTAが解決されているときにCSがどういう状態になっているべきか？を考え、そこから逆算してアクションを定義している、という順番です。一般的な「プレイブック」という言葉からは離れるかもしれませんが、段階を整理する方法としては現状ベストだと考えています。
言葉の認識が揃ったので、ここからは定性の感覚も踏まえながら各CTAを定義していきました。
できあがったものが以下です。
できあがったCTA/Playbook/Task
やってみてどうだったか
いきなり全部のCTAを動かすのは難しい
いざCTAが出来上がり、ルールエンジンも組んで、準備万端！…その後何が起きたか、皆様ならお気づきかもしれません。
そう、「捌けないほど大量のCTAが飛びまくった」のです笑
結果、まだPlaybookとTaskの管理までは至っていません。
まずは「各CTAが正しく動いているのか？」を検証するところで時間を使い切ってしまいました。
これは完全に私の考慮ミスです…欲張りすぎたなと反省しています。
（伴走して下さっているGainsightのCSの方からも「最初に”少しずつ”って言いましたよね…？」と呆れられました笑）
もはや言うまでもありませんが、今後CTAの導入に取り組まれる皆様においては、CTAの検証は「確からしいものから少しずつ」を強く強くおすすめいたします…。
最初は客観定量で自動化できるものが良さそう
焚き火理論のnoteにて、「（焚き火のヘルススコアは）CSの主観に寄りすぎた設計にも感じられるかもしれません。まだまだ改良の余地ばかりですが、この設計こそ、ヘルススコアと顧客の実態を繋ぎ止め乖離させないための私たちなりのこだわりでした。」と大見得を切ったのを覚えていらっしゃいますでしょうか。
結論から言います、主観のヘルススコア（焚き火理論で言うと”薪”に関するもの）は計測とハンドリングがものすごく難しかったです。
最初に検証したCTAが「キーマンが不在」というものだったのですが、メンバーに現状をプロットしてもらう工数と、それを持続的に更新し続けるオペレーションをデザインする必要があるため、かなりガッツリ腰を据えないと非常に難易度が高いと感じました。繰り返しますが「できないことはないが、めっちゃ難しい」です。
アクティビティと連動できて重要度も高い「POとCSの接点が半年間空いている」や自動で算出できる活用状況に関するものから取り組むのが良さそうと身を持って感じました。
今後に向けて
前篇にも記載した通り、今後は新生CS OpsチームがGainsight設計のオーナーを担ってくれます。
既に「このCTAは運用ちょっとキツイな」というものについては非アクティブにすることを決定しており、「正しいCTAが正しく回り続けること」をこれから目指していく予定です。
進める中でヘルススコアやCTA自体を変えていくことは今後もどんどんやっていこうと思っていますので「こうするといいよ」「ウチではこうやってるよ」などあれば、是非ご教示いただけますと幸いです！
おわりに
以上を以って「後篇：設計に関する話」は終わりとなります。
どのような時系列で運用を進めていったのか？については前篇にまとめましたので、是非併せてご一読ください。
※特に回し者とかではないのですが笑、本記事を読んで「Gainsight良いな～」と思ってくださった方は以下もどうぞ。ログインのたびにWowがある素敵なツールです！
https://www.gainsight.co.jp/
…さて、随分時間が空いてしまいましたが、私の「ヘルススコア＆Gainsight勝手に3部作（その1/その2/その3）」はこれにていったん完結となります。
今後はスター・ウォーズよろしく「続・3部作」や「新・3部作」に続いていくかと思います。ご期待ください！（私は何周か回ってEP Ⅶ推しです）
We're Hiring！
CTAの中身、情報の集約方法、アクション管理、etc…
カミナシCSはここに書いた内容で終わりではなく、絶えず変化と進化を繰り返しています。
共にスクラップ＆ビルドを楽しんでくれる仲間を大大大募集しています！
少しでも面白そうと思ってくださったそこのアナタ！
まずはカジュアル面談でざっくばらんにお話できたら嬉しいです。
ここまで読んでいただきありがとうございました！
それでは！
この記事が気に入ったらサポートをしてみませんか？