PMFから事業化へ～200以上の医療機関へのカスタマーサクセス基盤をゼロから半年で構築した話～
こんにちは、UbieでBizdev / Customer Successをやっているhassyと申します。
カスタマーサクセス基盤の構築という事例を通じて、PMF後に、いかに事業化を行い、スケールのための土台をつくってきたのか？
事業化というと、様々な要素が必要だとは思いますが、その中でもカスタマーサクセス基盤の構築の部分をピックアップしてお伝えします。
スタートアップに限らず、新たな事業を生み出そうとしている方の何かしらの助けになることを願っています。またそれが自分にとっても大切なことだと思い、チャレンジの過程を積極的に発信しています。
約半年で、ゼロからカスタマーサクセス基盤を作り上げるお話
私は2020年8月に事業開発としてUbieへ入社しました。
前職でマーケティング系のSaaSのカスタマーサクセス立ち上げとPdMの経験があり、最初のミッションは医療機関向けのAI問診ユビーのカスタマーサクセス立ち上げ。
AI問診ユビーは2019年後半から本格的に拡販を開始しており、入社時点で約200の医療機関で導入いただいていました。しかし、その規模にも関わらずカスタマーサクセスが組織として存在していない…。
どうやっていたの？？？実は、個々の事業開発/営業メンバーが導入まで、その後はユーザーサポートがお客さまを支援している状態。手前味噌ながら、個々のメンバーが優秀だからこそ成り立っていました。
カスタマーサクセス組織が存在していないという状態から、残り数ヶ月で契約更新を迎えるお客様が数十、しかも契約更新の時期が11月～12月の2ヶ月あたりに固まっている…。
更新を迎える案件数の月ごとのグラフ
そんな契約更新の波を乗り越えた「垂直立ち上げ」のお話はこちらの記事をどうぞ。
この記事では、契約更新の波を乗り越える「短期の垂直立ち上げ」と同時進行で進めていた、「中長期の基盤づくり」をお伝えします。
ここで、短期と中長期の取り組みを、順番にやればよいのでは？という疑問もあるかもしれません。
しかし、物事を「順番に」やるという方法は、スタートアップの成長スピードに合わないこともあります。現に、AI問診ユビーも半年間でお客様の数がとんでもないペースで増えており、早くスケーラブルな基盤を作らないと、お客様に迷惑をかけてしまう。
一見、無茶なように見えますが、「半年間」という限られた期間で「同時に」やることが必要だと考えました。
基盤づくりの第一歩として、脱属人化を目指す
中長期のカスタマーサクセス基盤の構築をするにあたり、時間もリソースも限られていました。また、カスタマーサクセスにおいて、お客様の活用状況を、時間の経過とともに観測することが非常に重要であり、そもそも限られた期間の取り組みでは限界もあります。
そこで、基盤づくりを一気に「理想に対して100%」の状態を目指すのではなく、まずは「理想に対して40％」の状態を「とにかく早く、無駄なく」つくることを目指しました。
ここで「理想に対して40%」として、半年間のゴールに掲げたのは「プロセスを一周回すことによる課題の明確化」というテーマです。
前提として、2020年8月時点のUbieでは、以下のような状況でした。
・200を超える医療機関に対して自分を含めて5人程度しかリソースがない
・カスタマーサクセス経験者がいない
・カスタマーサクセスに関するデータがない
こうした状況を踏まえて、中長期的に事業を伸ばしていくためにはカスタマーサクセスとしての基盤をつくり、改善の道のスタートを切ることが必要だと考えました。ただし、そのためには荒くてもいいので早くプロセスを作り、一周まわす。そうして解決すべき課題を明確にしつつ、カスタマーサクセスを組織として取り組める状況を作ろうとしました。
まずは「プロセスを一周回す」という中でも重視したのは、「業務プロセス定義」と「データ基盤整備」でした。その2つにフォーカスした理由は以下の2点です。
・業務プロセス定義…未経験者でも何をなぜやるのかを理解できる
・データ基盤整備…未経験者でも客観的な情報をもとに意思決定ができる
これにより、意識統一がされ、コミュニケーションコストが削減されるとともに、各メンバーが自律的に動けるようになります。
プロセスをとにかく「荒く・早く」定義する
プロセス定義では、「何を、なぜやるのかを理解できる」ことを重要視し、とにかく「早く・荒く」定義することを意識しました。
というのも、時間をかけてじっくり考えたプロセスが「正しいプロセス」とは限りません。しかもその検証には、ある程度の時間の経過が必要です。明確なプロセスがない場合は、極端な話、えいやでいいので「まずは決めること」が重要。
ここで活用できるのが教科書的なセオリーです。カスタマーサクセスでは基本の型がある程度存在しているので、特に抽象度が高いレイヤーではそれに乗っかって、悩む時間を節約するのが良いと思います。
AI問診ユビーでも、一般的なセオリーに乗っかり、以下のようにプロセスを定義しています。
社内資料よりプロセスのサマリ
社内資料よりプロセス詳細
AI問診ユビーも、総合病院向けとクリニック向けがあり、以下は総合病院向けのプロセスです。
◯導入期
・フィールドセールスからの引き継ぎ
・お客さまのオペレーション整備＆レクチャーを行い、AI問診ユビーを使える状態にする
◯活用期
・オペレーションやプロダクトの課題を解決し、運用を定着する
・成果を出す
◯更新期
・今までの活動・成果を言語化する
・場合により更新時の契約交渉を行う
◯解約期
・解約決定した場合にいかにダメージを少なく、次に繋がるように体験良く解約対応をできるようにする
・解約理由のヒアリング等を行い、学びとする
総合病院向けはいわゆるエンタープライズに近く、ハイタッチなプロセスとしています。
こうして、ざっくりとプロセスと、各プロセスごとのゴールとタスクを定義。人によるブレが減り、コミュニケーションがかなり円滑になりました。ちなみに、カスタマーサクセスに関わる内容はnotionに「カスタマーサクセスポータル」というものを作り、そこに情報を集約。社内の誰でも閲覧可能な状態にしています。
カスタマーサクセスポータル
データ基盤を整備し、客観的な情報をもとに意思決定できるようにする
次に取り組んだのは「データ基盤」の整備でした。
短期的な契約更新の対応では、とにかくスピードを優先するために「スプレッドシート」を活用。
このような管理表を作り、
スプレッドシートの管理表
そのデータを関数で集計してダッシュボードとしていました。
スプレッドシートのダッシュボード
しかし、中長期の基盤としては、オペレーションの統一やデータの信頼性確保のために、いつまでもスプレッドシートに頼るわけにはいきません。
そこでフィールドセールスがすでに活用していた「セールスフォース」の整備にとりかかります。これが…地獄への始まりだった…。
さて、カスタマーサクセス用にセールスフォースのオブジェクトやフィールドつくるか…と思い、確認してみると「カオス」の一言でした…。
いわゆる、セールスフォース導入におけるアンチパターンにハマっていました。
まず、業務設計やデータ設計の考慮が不十分なままにオブジェクトやフィールドを設定してしまっているので、不要なフィールドが大量に…。しかもデータが中途半端に入っており、フロー等も組まれて影響が見えないので、下手にフィールド削除ができません。
商談のフィールド数が上限間近という絶望
しかも、私自身、セールスフォースそのものは触るのが初めてだったのですが、セールスフォースの「仕様」の壁にぶち当たることとなります…。
Sandboxを立ち上げ、5日間くらい触ってみて…
・3つ以上のオブジェクトがいい感じにJoinできない
・標準オブジェクトの独自機能が多すぎて下手にカスタムオブジェクト作れない
・レポートがUIがわかりにくい上に集計が遅い
・調べても出てこない仕様が鬼のようにたくさんある
・調べて出てきたコンテンツが本当に分かりにくい
等々、ここでは書ききれないくらいの壁にぶち当たり、そのたびに悲しみを覚える状態でした。もう無理。将来的に絶対にSFのコンサル入れて、根本的になんとかする。
地雷を踏み抜くたびにtimesで慰めてもらうこともしばしば
時間が無い中で、このままでは埒が明かないので、
・有識者を見つける
・カスタマーサクセスに必要最低限な変更に留める
・ツールの使い分けをする
という方針を決めました。
有識者は、本当にたまたま、セールスフォースに詳しい方と出会うことができ、セールスフォースの思想から、具体的な設定の相談、運用上の注意まで教えてもらいました。餅は餅屋。
また、オブジェクトは最低限の変更で済ませるために、
・商談オブジェクトに、カスタマーサクセス用のレコードタイプと10程度のフィールド追加
・「プロジェクト」という商談に関連付けされたカスタムオブジェクトをつくり、各プロセスの細かい情報を入れる
という構造に、まずは落ち着きました。
そして、セールスフォースは「データ入力用のツール」と割り切り、利用ケースを絞りました。セールスフォースのデータをBigQueryに吐き出し、Google Dataportalを「データ可視化用のツール」にしました。
セールスフォースのレポート機能では、データの複雑な集計のニーズを満たせない、集計スピードが遅くて辛い、というのが理由になります。（一部はもちろん使用していますが、重要なメトリクスの大部分はDataportarl化。）
また、BIツールは、他にもRedashやTableauが候補にあがりました。その中でも、「そこそこ高機能」、「SQLが分からなくても使える」、「Gsuiteを使用していれば権限管理が楽」、「コスト」という観点で、まずはGoogle Dataportarlを選びました。
ダッシュボードの一部（積み上げ面グラフも使える）
ダッシュボードの一部（パラメータで動的な期間フィルタも使える）
社内のエンジニアに相談しながら自らSQLでデータを加工し、このような形でダッシュボードを作成。こうして客観的な情報をもとに各メンバーが意思決定できるような状態が実現しました。
例えば、ダッシュボードで顧客の利用状況を確認して、問題があればすぐにお客様に連絡して原因を特定し、対策をとる。また、オンボーディング直後の顧客のデータを分析し、オンボーディングプログラムの課題特定と改善を進める。このように、各メンバーがデータを見て自律的に判断しながらアクションが取れるようになりました。
結果
このようなプロセス定義とデータ基盤整備の結果、「プロセスを一周回すこと」ができました。そして、「課題の明確化」にも取り組んでいます。
Miroによる顧客の利用プロセス可視化と課題のマッピング
Miroで顧客の利用プロセスを可視化し、そこに課題をリストアップ＆マッピングしています。そして優先順位をつけて対応を進めています。
これらの取り組みにより、個人の能力によるサポートから徐々に抜け出し、組織的なカスタマーサクセスを実行可能になりつつあります。そして、垂直立ち上げ編でもお伝えしましたが、リテンションレートはざっくり90%後半をキープできています。
ただし、まだまだ「理想に対して40％」であり、改善の道のスタートをようやく切れた状態です。ここから「理想に対して100%」を目指して、やるべきことだらけです。
例えば、以下のような取り組みも、いずれご紹介できればと思います。
・プロセス＋データを活用したヘルススコア＆モニタリング＆トリガーアクション定義
・CS Ops機能の実装
・利活用促進のための個別の改善
みなさんのご経験やご意見等、コメントやツイートでいただけると嬉しいです！
最後に
Ubieは「テクノロジーで人々を適切な医療に案内する」をミッションに掲げています。ミッション実現のために、医療機関（病院/クリニック）向けのプロダクトだけでなく、生活者向けのプロダクトや製薬企業向けの事業等を複数同時に立ち上げ、ワンプラットフォームを構築する「多拠点同時突破」にチャレンジしています。
これは一つの企業内で複数の事業/プロダクトを同時にPMF、事業化、スケールに、再現性をもってチャレンジするということ。
本記事のような事業開発のテーマは山ほどあります。ぜひ、0→1、1→10、10→100のいずれのフェーズであっても、刺激的な経験ができることをお約束できます。一緒に、医療体験を変えましょう。
-----ご案内-----
Ubieで働くことに興味がある方は、Ubie Dev採用サイト に詳しい情報を掲載されているのでご覧ください。
参考資料など
1. カスタマーサクセスの垂直立ち上げの記事
冒頭にご紹介した記事です
2. 山田ひさのりさんの書籍＆記事
カスタマーサクセスの教科書。赤本や青本よりも実践的で本当に参考になると思います。
カスタマーサクセス実行戦略 山田 ひさのり
ご本人の記事ではないものの、Q&Aセッションの内容がとても良かったです。記事化感謝です。
3. Farm Don't Huntの紹介記事
こちらもカスタマーサクセスの教科書。個人的には青本や赤本も重要なものの、実務をやっているとこの内容がしみる気がする。日本語サマリ感謝です。
4. Google データポータル等を教えてくれた百々さんの記事
元同僚の記事。ヘルススコアとかも参考にさせてもらいました。いつもありがとうございます！
※他にも参考にしているものがあるはずなので、順次追加します…！
この記事が気に入ったらサポートをしてみませんか？