（※2022年9月1日より、社名がPOLからLabBaseに変更となりました。
記事内で旧名の記載が残っている箇所がありますがご了承ください。）

はじめまして、株式会社POLで「LabBase」という理系学生スカウトサービスのカスタマーサクセスを担当しているあやぱんと申します！😊

この度は、いつもお世話になっているCS HACKさん企画の「CS HACK Advent Calendar 2021🎄🎁」に参加させていただき、この記事を書いております❣️

あやぱんて誰？

↑顧客向けの自己紹介で使っているスライドです😆

なんの記事？

この記事は、カスタマーサクセス未経験だった私が、2年弱のオンボーディングの立ち上げを通して「取り組んだ４つのこと」、そこから見えた「オンボーディングの役割」についてお伝えする記事です🌷

新卒で入社した2年半前、カスタマーサクセスという職種に初めて出会い、何も分からないながらも、書籍・note・ウェビナー等で勉強し、チームメンバーや社内外の大先輩方へ何度も壁打ちをさせていただき、正解が分からずもがき苦しみながら、オンボーディングの設計を進めてきました。

それと同時に、学べば学ぶほど、学びを実践すればするほど、カスタマーサクセスの魅力や深さに惹き込まれていき、今ではCSという職種が大好きになっていました😆

この記事では、そんな私から、「CS初心者によるオンボーディング立ち上げ物語」をお届けできたらと思います📕

CSに初めて挑戦される方や、オンボーディング設計に携わっている方など、CS活動をされている全ての皆様にとって、この記事が何かのヒントとなれば幸いです！💌

前置き（読み飛ばしてもOKです!）

この記事では、私が自社で取り扱う「LabBase」というサービスの「オンボーディング」についてお話しします🎀

ここでは、前提部分である、サービスの概要やオンボーディングという言葉の使い方について説明しておきます。

「LabBase」サービスについて👩‍🎓🎓

「オンボーディング」について🛩
本記事の「オンボーディング」は、サービスを利用するユーザーに対して、サービス利用から得られる体験の満足度を高め、その後の継続的な利用を促すためのプロセス・施策のことを指します。

1年半前、オンボーディングが生まれた

オンボーディングチームが立ち上がった理由を、CS組織の変遷をたどりながら説明します👶

1年半前の2020年2月ごろまでのCSは、1チームで、1CSMが1企業の導入〜契約継続まで一気通貫サポートをする体制でした。

顧客にとっては、価値を感じてもらいやすい体制だったのですが、その一方で、CSの組織にとっては、以下3つの要因によりチャーンリスクが高まってしまう状況にありました😭

そこで、チャーンリスクを下げることと、属人的なプロセスを型化することを目的に、「オンボーディング」「アダプション・リニューアル」の2チーム体制へと変更しました🔁

こうして私は、オンボーディングチームの立ち上げに任命いただきました🎌

オンボーディング立ち上げで取り組んだ4つのこと

ここからは、1年9ヶ月かけてオンボーディングの立ち上げで取り組んだ事を4つのポイントに絞って説明します🌟

①オンボーディングのゴールを定義する

■なぜやるのか？

「オンボーディングが終了した段階でなってもらいたい顧客の状態」を定義することで、オンボーディングフェーズで設計すべきプロセスや施策が見えてくるため。

■どうやったのか？

🐣初期では、すごく簡単なカスタマージャーニーを引きました。

🐔つい先月チームメンバーと一緒に再定義した時はこんな感じで、初期よりかなり解像度が高くなりました！

■ポイント
✔︎一度でゴールは決まらないので、何度も再定義の機会を持ちブラッシュアップし続けること。なぜなら、事業戦略やサービス設計、組織体制が変わる毎にオンボーディングのゴールも変化していく必要があるからです😇

✔︎オンボーディングメンバーだけでなく、CS責任者・アダプション・リニューアルなど別部門のメンバーを巻き込んで再定義をすること。そうすることで、CSからオンボーディングに期待されていることが見えてくるのと、CS全体でゴールの共通認識が取れるからです。

✔︎細切れの時間ではなく、まとまった時間でアイデアの発散と収束をし、再定義すること。私のチームの事例だと、2時間半のオンサイトMTGで決め切りました。こんな感じでmiroを使ってみんなでプロットしました🎵

②ゴールを達成するための「期間」と「条件」を設定する

■なぜやるのか？

①で定義したゴールが達成できているかどうかを判断するには「基準」が必要だから。基準には、期間と、その期間内にクリアすべき条件が必要で、その２つが揃うと、オンボーディングの指標「オンボーディング完了率」も設定できる。

■どうやったのか？

やったこととしては、定義したゴールを達成するために必要なことを「ステップ」に分け、そのステップをクリアするために必要な「条件」を洗い出しました🍀

例えば...

条件が決まれば、期間が決まります。その条件を達成するために必要な期間がどれくらいか？を検討すれば良いためです。

■ポイント

✔︎オンボーディングで何が最低限クリアできれば、来年契約してくれるのか？を考えること。考えれば考えるほど、これもクリアしないといけないんじゃないか？と条件が高く詳細になってしまいがちです。そうではなく、あくまでもオンボーディングフェーズでクリアすべきことなんだと再認識させてくれる問いです。

✔︎「条件」の数値の妥当性は、初めは決め打ちで良い。過去オンボ実施企業を分析しないとわからないので、初めはなくて良いと思います。並行して数値の分析を行うと、条件が確からしいものに近づきます。

正確にいうと、期間と条件の設定はまだ完了しておらず、70%くらいの完成度です😰　引き続きこれからもブラッシュアップしていきます！

③条件を達成するためのオンボーディングプロセスを設計する

■なぜやるのか？

顧客に期間内に条件をクリアしてもらうためには、CSからの能動的なアクションや施策の投下が必要だから。何もしないと顧客はサービスから自然に遠のいていきます😈

■どうやったのか？

条件を達成するために自社からどのようなアプローチが必要なのか？を洗い出していきます。この作業はアイデアがたくさん出てくるので結構楽しいです🎵

👣初期にやったのはこんな感じで少し雑です。

🐼こちらは、直近でチームメンバーが検討してくれているプロセス再設計のイメージです。かなり進化してますよね！

プロセス設計が描けたら、顧客へのインパクト×社内の影響範囲 で優先順位をつけ、高い施策から取り組んでいくのみです。

特によかった施策の1つを紹介すると、「プログラム完了後にオンボーディングNPSを送付して満足度をはかるようにしたこと」と「リアルタイムにアンケート結果をSlackに飛ばして全社で見れるようにしたこと」です🚀

↑こういった顧客からの声で、仕事の疲れや悩みなんて全て吹っ飛びます😆

■ポイント

✔︎顧客の感情設計をした上で施策を検討すること。それぞれの条件をクリアする上で、クリアできない時の顧客の感情はどのようなものか？がイメージできると、どのタイミングにどのようなアプローチがあれば良いのかを考えやすいためです。

✔︎施策は、まずは関係部署が少なくチーム内でスモールに実施ができるものから先にやること。プロダクトを巻き込む必要がある大掛かりなものだと、長期化するのと、せっかく作ったけど実際に運用したらあまり効果がなかった場合工数の無駄遣いになるためです。

④プロセスの仕組み化・効率化・自動化

■なぜやるのか？

オンボーディングが目指すことの1つに、如何に少ない工数で大きなインパクトを出すか？があるため。そのためには、オンボーディング成功のパターンを見出し、それを全社へ展開できる仕組みを作るべき。

■どうやったのか？

こちらは、正確にいうと、仕組み化・効率化・自動化はまだ完了しておらず、進行中です。

これまでの3つと比較して最も進捗が遅いので多くは語れないのですが、現在やっているのは「仕組み化のための準備」です🐶

具体的にいうと、「こういう課題がある顧客へは、こういうアプローチをしましょう」という事例がまとまっている教科書みたいなもの（いわゆるPlaybook）の作成に取り組もうとしています。

その教科書を作るために現段階では、筋の良さそうな事例を探るため、顧客への全アクションとそれによる変化があったかどうかを一覧で見れるようにしています💫

■ポイント

✔︎取り組みの①〜③を実施したあとに、④を本格的に進めること。なぜなら、①〜③の全体設計ができてから④をしないと、先に仕組み化・自動化をしてしまったものに対して、①〜③の前提部分がひっくり返った時、④で行ったことが全て無駄になるからです。

🌟①〜④の取り組みの成果🌟

1年半の取り組みの結果、

「オンボーディング終了後のNPS平均8.9（回答数：約100社）」

までくることができました！💐

取り組みの結果、わかったこと

取り組み①や②を進めていくと、どうしても最終的に「そもそも私たちのサービスの1番の価値ってどこなのか？」「そしてCSはどのような役割を果たすべきなのだろうか？」という問いに行きつきます。

これはピンチでもありチャンスである🌹と感じました。というのも、私たちの状況として「サービスの価値がわからない」よりは、「各々がイメージしているサービスの価値はあるけど、それがCS内で統一されてないだけ」という状態だったからです。認識が揃っていない状況はピンチなのですが、逆にこれを機に揃えられるとというのはチャンスだと思いました。

現状だと、オンボーディングのゴールに関する共通認識がCS内で取れているところまできているので、これからはオンボーディングチームから、LabBaseの価値の言語化や再定義等の提案ができると、すごく面白そうだな😆と思っています！

取り組み①のポイントにもあるとおり、オンボーディングフェーズの設計は、サービスや体制が変わる度にブラッシュアップされる必要があります。

オンボーディング立ち上げから1年半の間でも数回、サービスのバージョンアップや体制の変更、サポート内容の変更があり、その度に考え直してきました。

きっとこれからも変わりづづけていくものなので、オンボーディングの設計もそれに伴い変え続けようと思っています。

オンボーディングが果たすべき役割

これまでの取り組みを踏まえて私がたどり着いた、オンボーディングが果たすべき役割はこれです。

（to顧客）チャーンする最大の要因を潰しておく

オンボーディングゴールの定義・ゴール達成のための条件の検討に取り組んだとき、以下のようなという問いが頭をぐるぐるしていました。

そのような中、オンボーディングが果たすべき役割の中で一番しっくりきたのが、「顧客が行動変容を起こしやすい条件が揃っているオンボーディングフェーズにこそ、チャーンに繋がるリスクを潰しておくこと」でした。

確かに、オンボーディング時の顧客の状態は特別だと思います。どう特別かというと、こんなイメージ。

この条件が揃うのはオンボーディングフェーズしかなく、チャーンの要因を潰すのに効果的なタイミングだと言えます。

（to社内）サービスの価値に一番向き合い続ける

オンボーディングフェーズでは、自社サービスの価値を考えさせられる機会が多いです。

というのも、

オンボーディングゴールや設計を考えていると、最終的に「そもそもサービスの価値ってなんだっけ？」「どこに強みがあるサービスなんだっけ？」という問いに帰着するケースや、

導入初期の顧客に触れると、「御社のサービスの〜〜に魅力を感じて導入したんです！」「御社の〜〜に期待しています！✨」という導入への期待感を直接聞けたり、顧客がサービスで成功体験を積み始めると「このサービスを使ったおかげで〜〜ができるようになりました！🌻」など顧客が価値を感じている瞬間に立ち会う機会が多くあります。

このようなオンボーディング特有の「自社サービスの価値に立ち返ることができること」を武器💪に、オンボーディングチームから自社サービスの価値や魅力を発見し、発信、再定義していく役割を率先して担うことができたなら、すごく楽しいだろうなと思っています💝

------------------------🙇‍♀️------------------------

最後までお読みいただきありがとうございました！この度は、CS HACKさんのアドベントカレンダー企画の一部としてブログを書かせていただきました。

これまでの自分の取り組みと学びを言語化・整理することができ、大学4年に卒論を書き終えたような感覚で、とっても最高な気分です🎓🌸

CS HACKさん、今回も貴重な機会をいただきありがとうございました！

明日の方へバトンを繋いでいきます〜！🏃‍♂️

CS HACK アドベントカレンダーはこちらです🎄🎁

------------------------✌️------------------------

私たちカスタマーサクセス部は、新たな仲間を募集しています！ご興味がある方はぜひお気軽にご連絡ください💌

もちろん、CSについて情報交換したいな〜という方も大ウェルカムです！🍻