2021年8月から全5回にわたって、ALL STAR SAAS FUNDのメンターであり、カスタマーサクセスストラテジストの山田ひさのりさんを迎えて開講した『SaaS CS集中講座』。1200名を超える方々から参加登録があり、各回のアンケートでも高い評価をいただきました。
一方で、CS組織の体系化やノウハウの吸収はできたものの、「自社に活かすために、より身近な実践例や具体例を知りたい！」という声も寄せられました。
そこで山田ひさのりさんに加え、実際CS組織を立ち上げ、推進しているスタートアップ企業2社より、現役CSとして活躍している2名を加え、講座の「番外編」を実施しました。ゲストにお呼びしたのは、株式会社hacomonoの朝倉康之さん、株式会社ログラスの矢納弘貴さんです。
CS組織作りの経過や、オンボーディングの変遷を聞き、その秘訣を教わりました。モデレーターは『SaaS CS集中講座』の企画者でもあるALL STAR SAAS FUNDの神前達哉が務めました。
この記事では、全3部からなった「番外編」より、第1部の「CSの立ち上げと組織づくり」、第2部の「オンボーディングとアダプション」の内容を抜粋しました。
hacomonoのCSチームは、2020年8月に発足
朝倉：hacomonoは創業から9期目、約70名の規模になり、シリーズAからまだまだ成長しているフェーズです。僕らは社名と同じく「hacomono」というSaaSプロダクトを、フィットネスクラブ、ダンスやゴルフといったスクール業界に向けて提供しています。いわゆるバーティカルSaaSといえるでしょう。入会手続きの事務作業、予約の管理、決済といった店舗運営をすべてオンラインで完結させられるのがメリットです。
フィットネスクラブに通われた方ならご理解いただけると思うのですが、アナログなシステムが多く、非効率的な業務も多いのが現状です。予約にしても、電話で聞いて紙で管理していく。入会申込書は手書きで、会員情報もそれらをファイリングしたり。月謝の決済にしても自動化ではなくスタッフがパワーを割く……と、効率化されていない面が多いです。
hacomonoはそれらをオンラインで完結できるようにするプロダクトです。山田さんのお話に出てきた「ライトサクセス」で言うと、導入することで業務効率化が早期に実現できます。さらに、その先の「ディープサクセス」も見込めます。
会員さまが受けているプログラムや利用状況といった行動データがすべて取れますから、それらに基づいた店舗経営が可能です。サービスがスタートしてから2年ほどですが、急成長できている背景の一つが、この利便性にあると捉えています。
カスタマーサクセスチームは、2020年の8月頃に発足しました。プロダクトの正式リリースから約1年後ですね。現在は14名から成り、「ハイタッチチーム」と「Opsチーム」という2チーム体制です。まだまだ、ハイタッチやロータッチといったタッチ区分はできていません。全クライアントに対してハイタッチ対応を行っています。
hacomonoのCSチーム立ち上げ時に「やっておいてよかった3つのこと」
私が入社してからの1年間で、カスタマーサクセスチームを立ち上げる際に「やっておいてよかった3つのこと」があるので、今日はそれをお伝えします。
一つ目が「CSの理論・原則と、自社の状況を加味して取り組むことを決める、または絞る」です。
hacomonoはプロダクトの特性上、予約や決済といったコア業務に絡んでくるため、オンボーディングが確実に終わると同時に利用され、ライトサクセスが発生します。なおかつ会員管理も絡んでくるため解約が起きにくいプロダクトです。
一方で、初期のセットアップにおいてクライアント・CSM双方に負荷がかかってしまう事象が起きていました。原因はオンボーディングの標準化が進んでおらず、全ての案件に対して個別対応する必要があったためです。このままだとクライアントの満足度が低下しますし、CSMがオンボーディング以外に時間を使えなくなります。hacomonoに蓄積されたデータを活用した店舗運営の実現や、プロダクトの強化につながるような深いヒアリングもできない、といった問題もありました。
そこで私たちは、オンボーディングの型作りに集中したんです。結果的に、これはとても良い判断だったと思います。
二つ目の「やってよかった」は、hacomonoが実際に使われる現場で業務を体験させていただいたこと。各メンバーが実店舗で丸一日かけて、一人のスタッフとして働いたことで、どういう現場で、どんな方々に使われているのか、といったリアルな空気感を体感できました。バーティカルSaaSを提供する者としても本当によい時間でした。
三つ目は「CS Opsチーム」を早めに作ったのはよかったですね。
組織の変遷として、この1年間くらいで3つのフェーズをたどっています。2020年9月から2021年3月までは、言わば「全員CSM期」ですね。必要な資料やコンテンツはすべて手分けしながら作り、全員でお客さまに対応していました。しかし、資料作成が全く追いつかなくなってくると、スピード感をもってオンボーディングのPDCAが回せなくなるという課題が起きました。
そこで2021年4月にCSMが5名になった段階で、その中から1人にOpsへ移ってもらい、Opsチームを正式に立ち上げました。専任者を置いたことで、コンテンツや仕組みを作ることに専念できるようになったんです。
Opsが担う役割としては、大きくはオンボーディングプログラムの設計と、それに必要なコンテンツ制作です。また、それらの進捗と成果の可視化ですね。今後はさらに顧客データの整備も任せていきたいと思っています。
Opsとして必要なスキルや志向性はCSMと異なる面もあります。仕組み作りが得意で、ものごとを抽象化して考えたり、構造的に捉えられたりする人が活躍しやすいと感じています。
ただ、Opsが1人だと、その人だけに負荷が集まりやすいという課題も出てきました。そこで2021年8月には2人にジョインしていただいてOpsチームも3人になり、今まで以上にPDCAを早く回せるようになりました。このように早めにOpsをチーム化したのは、振り返っても「よかったこと」の一つですね。
ログラスのCSチーム、立ち上げ時に「やる価値のあったこと」
矢納：ログラスでカスタマーサクセスを務める矢納です。お手柔らかに、よろしくお願いします。
ログラスが提供するのは、企業価値を向上させるための「経営管理クラウドサービス」です。経営管理の業務プロセスを効率化し、精度の高い意思決定をサポートするための機能を備えています。導入は、上場企業を中心にエンタープライズの比率が高いのも特徴的です。
創業からここまでのカスタマーサクセスの立ち上げについてお話しさせていただきますと、私自身が入社させていただいたのが2020年の6月で、社員は5名程度。現時点では数十名規模の会社になりました。体制としては、ビジネスサイドとエンジニアサイドで大きく分かれますが、基本的にはフラットな構造を築けていると思います。
会社の成長を支えるカスタマーサクセス組織になれるように努めていますが、いろいろなトライをしてきた中で、「立ち上げ時にやる価値のあったこと」を共有させていただければなと思います。本当にいろいろやってみた、というのが結論ですが（笑）、今回は3つに絞って紹介します。
一つ目は、お互いに意見を言い合えるようにするために、情報を正確に、素早く開示できる体制を作ったこと。
二つ目が、カスタマーサクセスとエンジニア組織との距離を近づけるべく、顧客解像度を上げるための取り組みを行ったこと。ログラスのフェーズですと、カスタマーサクセスチームから出てくる声がプロダクトの進化に直結しますから、重要視しました。
三つ目は、立ち上げ経験のある方には共通するかもしれません。何かとツラいことが日々多いフェーズになるので（笑）、振り返りの機会を持つことです。ツラい原因を過大にも過小にも評価せず、ありのまま受け止めて、しっかり乗り越えるために振り返りをする。この3点を重視をしながら、立ち上げを行ってきました。
「企業研究」と「振り返り」がチームを強くする
他にも「立ち上げ時からやっておいてよかったこと」の具体策については、今回はすべて紹介する時間はないので、いくつかをピックアップしていきます。
まずは「Logpose（ログポース）」という取り組み。かんたんに言うとクライアント研究の場です。もともと私に経営企画の経験があったので、そこで使っていた企業研究のフレームなどを用いています。
クライアントごとの解像度を上げるために、取り組まれている事業、現在お持ちの課題、社名に込めた想い、市場からの評価などをまとめる企業研究を通じて、ログラス社内に向けて契約の経緯や背景を説明しています。これは初めてのクライアント様から受注をいただいてから継続中です。
hacomonoさんのお考えとまさに近いのですけれども、Logposeには実体験からの感想も含めています。アミューズメント施設を運営するクライアントであれば、実店舗を客としてログラスのメンバーで利用してみる。アプリ開発企業であれば、メンバーで一緒にダウンロードをして使ってみる、といったことです。
これらの実体験はビジネスサイドだけでなく、エンジニアを中心に巻き込むことは、特に意識しています。
次に「顧客目線ワークショップ」です。カスタマーサクセスにおいて、お客さまのペインを理解するのは重要な一方、想像だけではわからない部分もあります。そのペインを全員で共有するためのワークショップを開いています。
たとえば、私が経営企画役を務め、エンジニアチームやビジネスサイドのメンバーたちには事業部長役などログラスにかかわる登場人物として、役を割り振ります。そして、擬似経営会議として「ログラスを使わない世界」で経営会議をしてみるのです。
初回発表で出てきた資料に対して、ログラス代表の布川からは「その予実分析、間違ってない？」みたいな厳しい指摘が飛びます（笑）。そうしてリアルな経営会議運営をしてみることで、「お客さまはこういうことに困っているんだ」と解像度をすこしでも高くした上で、みんなでペインを共有する場になっています。
最後は毎週木曜日の夕方に実施をしている「要望を解説する会」です。お客さまからCSチームがヒアリングをした「生の声」をPMやエンジニアチームに共有することで、開発のスクラムイベントへ反映し、プロダクトへフィードバックをする場です。
この会を経て、翌週の月曜日のプランニングに上げていくことで、開発サイクルにお客さまの声を仕組みとして反映させられています。
さらに、「苦しいことほど、ちゃんと振り返る」という文化を大切にしているのも、ログラスのカスタマーサクセスの特徴といえます。その一つが、エンジニアには有名なフレームワークである「ポストモーテム」を流用した振り返りです。
エンジニアでは、大きなバグや不具合が起こったときに、このポストモーテムのテンプレートを用います。ログラスのカスタマーサクセスでは、それを「解約が起きたとき」に設定して応用します。
「何が起こり、解約に至ったのか」というタイムラインから始まり、根本的な原因や共通した課題などを踏まえ、さらに「なぜ」を5回繰り返して問題の解像度を高め、最終的に対応のフォローアップを整理するものです。
この振り返りを経ることで、過去に起きた解約理由とその対応を、ログラスのメンバーであれば、誰もが同じ内容を把握できるようになっています。さらに、これから入社する方々にも情報として共有できます。有用である一方、解約に接した当人としては、なかなかにツラい取り組みではあるのですが……。
また、採用へのコミットは立ち上げ期における重要なタスクですが、採用候補者の見極めのためにロープレを実施してきたのも、「やってよかったこと」の一つです。これは、山田ひさのりさんからアドバイスをいただいて実践してきたものです。
候補者の解像度を高め、候補者にとってもログラスを疑似体験できるロープレの機会は、現在の採用体制にもつながっていますから、価値ある取り組みだったと感じています。
CSは、事業フェーズや事業の性質に合わせるべし
──ここまでは「やってよかったこと」を聞いてきましたが、むしろ「やるべきではなかった」という失敗談があれば、ぜひ共有していただけませんか。
朝倉：自分たちの事業やプロダクト特性に合っていない、しかもタイミングを外した「CSっぽいこと」に手を出したのは失敗でしたね。一例ですが、ヘルススコアの検討です。
hacomonoは解約率がおかげさまで非常に低くて、それほど変動もしません。それにもかかわらず、解約予測のためにヘルススコアを立てようと、3ヶ月ほど試行錯誤をしたのですが全く相関性を見出せない。そもそも、解約は月に1件発生するかどうかの状況。一般的にCSで大切とされる考えに引っ張られてしまって、自社の状況を加味できていませんでしたね。
矢納：今のお話は耳が痛くて、うなずきが止まらなかったです（笑）。
私もヘルススコアに振り回されたのが最初の失敗でした。経営企画業務を経験してきたので、データを取りたい、分析したいという欲求が強く、初動からログイン率などの数値をチェックしていたのですが、それほど差がなく……。
そして、最大の失敗といえば、CSの施策を我流でやろうとしたことです。現在も成果が出ているものを振り返ると、このSaaS CS集中講座で山田さんがおっしゃっていたことや、いわゆる「青本」に書いてあるような内容を、自分なりに咀嚼してログラス仕様に落とした込んだものだけなんです。
自分で「正しそう」と思えることを何となく始めると、この場で言えないような失敗を起こしてしまうよ、と過去の自分に言ってあげたいですね。
──いまのお二人の失敗談を聞いて、山田さんはどうお感じになりましたか。
山田：おっしゃる通りで、CSとしての施策は、自分たちの事業フェーズや事業の性質に合わせることが大事です。セールスやマーケは「リード集め」といった始め方が多い一方で、CSは「リニューアルセールス」「オンボーディング」「ヘルススコア」といったように注力すべき点がそれぞれで変わるのが難しい。変幻自在な持ち手が試されるともいえますね。
hacomonoのオンボーディング
──ここからは「オンボーディングとアダプション」というテーマでお聞きします。
朝倉：hacomonoはオンボーディングにフルフォーカスしているので、アダプションの話は全くできないことは、あらかじめご了承ください。僕らのオンボーディングは、セールスで受注が決まった段階で始まります。
お客さまが自社の予約サイトをhacomonoで作り、会員の方々が予約できるようにしていくことが、オープンをするうえでも重要です。また、hacomonoを入れると業務が紙ベースからウェブベースに大きく変わるので、業務の再設計・店舗スタッフさんへのレクチャーも欠かせません。また、オープン後にはhacomonoを使った店舗運営がうまくいっているかをヒアリングし、懸念点や不明点があれば解消していきます。
オンボーディング期間は1ヶ月から2ヶ月くらいですが、お客さまのオープン時期に合わせることもあり、期間が2週間になることもあります。接触回数は多めで、1時間〜1時間半のウェブミーティングをオープンまでに5〜6回ほど実施するのが基本ですね。
また、Notionでお客さまごとにマイページを設け、ミーティングで決まったこと、今後のスケジュールやタスク、打ち合わせの議事録などもまとめていきます。文面だけではわかりにくいことは、3分程で簡略的に説明した動画コンテンツも用意しています。
僕らの反省としては「オンボーディングの成功基準」をあまり決めきれていなかったことですね。その失敗の歴史も、大きくは3つのフェーズに分かれています。
まずは「とにかくオープンさせるんだ期」。カスタマーサクセスチームが立ち上がったばかりの頃で、予約サイトが無事にオープンを迎えられた状態を成功基準に置いていました。この基準だと失敗することはあまりないのですが、必ずしも「期日通りのオープン＝クライアントのサクセス」とはいえず、もっと踏み込んでいく必要性を感じていました。
そこで、次には「日々の業務でhacomonoの使い方も大事だよね期」として、オープン後の業務でも困らない状態にまで並走してこそ成功と定めました。以前よりはクライアントに正しく価値を提供できるようになったのですが、まだ定性的なので評価は難しいです。
みなさんに今日お伝えしたいこととしては、CS組織が4人くらいまでなら意思疎通が密にとれるのでオンボーディングの成功基準は定性的でもお互いの認識がブレず、PDCAはなんとか回せます。ただ、あくまで「なんとか回せる」だけでベストではありません。そして、人数が増えていくと密なコミュニケーションが難しくなり、認識にズレが生じてきてPDCAがうまく回せなくなるため、定量的な計測が必要になってきます。現在のhacomonoは、そこに立ち向かっているフェーズということです。
まだはっきりと形になっていませんが、今使おうとしている指標は3つです。
- オンボーディング中に実施したミーティング回数
- オンボーディング中にいただいた問い合わせ数
- オンボーディングに対する満足度
今は我々が至らないせいでミーティング回数が増えたり、オンボーディング中のお問い合わせも多くいただいています。この状態だとクライアント・CSM双方の負荷が高いので、自己学習しながら進められるオンボーディングコンテンツを提供しようとしています。
これら3つの指標は、そのコンテンツが実を結ぶことで好転する期待が持てます。私たちが目指しているのは、クライアントにとっても、CSMにとっても「なめらかなhacomono導入体験」をつくることです。
hacomonoは人数が増えていく中で、定性的な評価基準でPDCAを回し続けてしまったところがあり、仮説検証の壁にぶつかってしまったのが現実です。早い段階から成功基準を定量化するべきだったと、一つの失敗として感じています。
ログラスのオンボーディング＆アダプション
矢納：ログラスはエンタープライズ事例が多いのですが、一社ごとの重要性も高いため、オンボーディング体制はITシステムへの導入プロジェクトを組成するイメージが近いです。
最初にプロジェクト体制図を作り、プロジェクトオーナーの責任範囲、プロジェクトチームの責任範囲、各メンバーの責任範囲といったものを明らかにします。要素や機能などをご理解いただいたうえで、出席すべき定例ミーティングをすり合わせるようなコミュニケーションを図ります。
オンボーディングによるライトサクセスとしては、経営企画の方が「ログラスを使ってよかった」といえる状態を、およそ導入3ヶ月で達成することを目指します。使い方のマスターや、既存業務がログラスに全て移行されていること、といったチェック項目を定めて 伴走します。
そこからアダプションへ移って、ディープサクセスを目指す際には「企業価値向上」を掲げています。事業部長、役員、取締役といった方々が、ログラス導入後の経営企画を高く評価する状態です。経営判断に必要な情報があったときに、ログラスから情報を取れているのか。必要な情報が常にアップデートされているか。そういった点を、アダプションチームでは追っています。
ライトサクセスについては、これまでも取り組んできた領域であり、成功基準のチェック項目も置けるようになってきましたが、アダプションは各社ごとに状況が異なるのもあって模索中です。今後1年間をかけて、アダプションのさらなる高度化を目指していきます。
オンボーディングで意識しているのは「受発注関係にならない」ことです。キックオフでお伝えするのは、「私をログラスのカスタマーサクセスではなく、経営企画の一人だと思ってください」というメッセージです。細かいところでは、確かに資料上ではお客さまを「何々様」とお書きしますが、呼び方については「何々さん」で統一させていただいています。
スタンスがサポートになってしまうと、チームとしての推進が難しくなるのです。プロジェクト推進に携わる方なら、肌感覚としてもご理解いただけるかと思います。常に横に並ぶチームの一員として、御社が達成したい理想の姿を見ながら、それを「達成できる！」と心から信じて伴走することを徹底しています。
最近、「カスタマーサクセスの仕事は何か」と周囲の方から聞かれたときに、私は「登山における帰り道と一緒だ」といったように答えました。山を登るときは頂上がゴールですからわかりやすいのですが、下るときは地図をたどり、ちゃんと意識しながらでないと、全く違う駅に着いてしまったりするものです。
特にログラスのようなハイタッチに入って、お客さまの要望と密接しながら動かしていくプロジェクトの場合、「どこにたどり着きたいのか」がブレてしまうと、全く関係ないところにたどり着いてしまう。あるいは、道を進んで行く途中に、ふらっと脇道にそれてしまう。
下山時にきちんと行きたい場所を決め、そこに向かって適切にルートをたどっていくことを、カスタマーサクセスとしては意識していますね。
プロダクトへの自信がCS活動も後押しする
──オンボーディングについても、両社のスタンスの違いが見えてきました。最後に山田さんから、聞いていて気づかれた点や、特筆すべきポイントがあれば、ぜひフィードバックをお願いできますでしょうか。
山田：hacomonoさんのオンボーディング設計はすばらしいですね。オンボーディングは、お客さまのやりたいことを叶えるために行うように思ってしまいがちです。でも、
<yellow-highlight-half-bold>お客さまが成功体験を得られることを最短で実行する、というのがオンボーディングの神髄<yellow-highlight-half-bold>。それを失敗の中で身につけられてきたのだと、実感しましたね。
ログラスさんは、Twitterでも実況ツイートをしたのですが、「CS活動をパイプライン管理する」というのは、一見不可能そうに見えて、とても良い手法だと感じました。まだ手探りかもしれませんけれど、取り組まれている意義は大きいです。
CS活動は自分たちにイニシアティブがないと思われがちですが、意外とそうでもないんですよね。こちらが何かしらのアクションをやりきって、後はお客さまが動くしかない状況にまでやりきれれば、だいたい動くものです。それをパイプライン管理するとワークするんですね。ここでお客さまを主語に置いてしまうと、パイプラインは成り立たないでしょう。
hacomonoさんもログラスさんも、ご自身のプロダクトに対する自信が高いと感じます。みなさんも「どのSaaSベンダーに入社するか」に悩んだら、そういった心を持っている方が多い会社にすると間違いがないです。
両社とも進化がすごいな、と感じました。朝倉さんと矢納さんの発表から、業界の確実な進歩を感じて、私も嬉しいです！
