# 採用プラットフォームCSのオンボーディング設計のポイント 皆さん、おはようございます。 スタートアップCSベースプレゼンスゼロから始めるCSラジオです。 このチャンネルでは、シーズを任されたけど何から手を付ければいいのかと悩んでいる方に向けて、 毎週月曜日の朝に次の一手を一緒に考えていく番組です。 私、進行役の岩田と申します。よろしくお願いします。 今日は、太陽プラットフォームCSのオンボーディング設計をお届けしていきます。 お話を伺うのはこちらのお二人です。どうぞ。 皆さん、おはようございます。 僕は新規事業立ち上げ、カスタマーサクセスの経験10年ぐらいありまして、 その経験をもとに新規事業であったカスタマーサクセス組織の支援をしている エティ代表スタートアップCSベース社員の白田です。よろしくお願いします。 皆さん、おはようございます。 今、HRのスタートアップでCS立ち上げからずっとマネージャーを務めておりまして、 今は10名以上の組織のマネジメントを務めております。中川と申します。よろしくお願いします。 このお二人にお話を伺ってきます。 それでは最初に今日のポイント3つご紹介します。 まず1つ目、オンボーディングのゴールは初回PDCAを増し切ること。 2つ目が初期キッティングは完成ではなく仮設設計。 3つ目がオンボーディング中に運用判断ができる状態を作る。 この3つについてお話を伺っていきます。 それではまず1つ目なんですけれども、 オンボーディングのゴールは初回PDCAを増し切ることということなんですが、 こちらいかがでしょうか。 はい。これまずオンボーディングのイメージなんですけれども、 イメージしていただきたいのは、新しく営業の方が案件を取ってきてくださって、 カスタマーサクセスがオンボーディングしますというところを イメージいただければなというふうに思っているんですけれども、 いわゆるオンボーディングというのが、 他のバックオフィス系のSaaSであれば職設定が終わっていますとか、 請求書1個読み込み終わっていますみたいなところがあると思うんですけれども、 採用プラットフォームだとちょっと違うかなというふうに思っています。 例えばスカウトの文面登録しましたとか、求人票を作って公開しましただけだと オンボーディング完了というのはお客さんの目線で言えないのかなというふうに思っていて、 やっぱりその理由としては、採用のプラットフォームのサービスが スカウト設定して終わりでもなく、求人を出して終わりでもなく、 応募が来るとか、いい方と巡り合えるというところを もっかのゴールにしているかなと思うので、 その状態を作れるところまでしっかりと数字を見て、 ダメなところはダメとお伝えをして、改善をして、 1回PDCがひと回り回してみてどうでしたかというところまでやり切るというのが オンボーディングの完了なのかなというふうに思っています。 設定して、実行して、数字を見て、もう一回調整してというふうに、 そこまで一周やり切るというところが、カスタマーサクセスとしては オンボーディングでやるべきことなのかなというふうに思っています。 そのお客様と一緒に体験をしてあげるというか、 お客様に体験させてあげることがCSの価値かなというふうに思っております。 1つ目ですね。ここ白田さんどうですかね。 そうですね。この部分って前回の放送でもお伝えした 前提の部分があるかなと思っていて、 作業プラットフォームが今長谷さんがおっしゃってくれている 成果創出型という形で、導入したら効果を実感できるという 精神のプロジェクトではないと思っていて、あくまでも 急に公開しました。スカウト部分決まりましたというのが、 しただけだと人を取れるわけではないので、あくまでも スタートラインからまずは採用、例えば一名する。 エントリーを取るまでに仮説を立てたものを実行してみて、 その仮説に対してやってみた結果、良かった、悪かった みたいなところを分析をした上で、いわばPDCAと呼ばれるものを まず最速で一周回していかないと、そもそも採用成功までの 実感をお客さんもできないですし、支援するCS側も このうちでいいのかというのを判断できないので、まずは その仮説を立ててPDCAを回していくというところが非常に 重要なのかなというところは思いますというところと、 あとはこれ次の回ではのお話になるかなと思うんですけど、 比較的それじゃあ搬送しようと思うとほぼコンサルみたいな 動きになるんですけど、コース数とか支援頻度とかも考えると、 じゃあそれCS側で全部やるってかなりハードなものになると思うので、 そういったPDCAの回し方をお客さまと一緒に回していく、 いわばそのPDCAをお客さま自身で回していく状態を作るための 最初のファーストステップっていうところが結構重要なのかな と思うので、そのPDCAの回し方を一度体験するかみたいなところで 設定すると比較的成功まで一緒に回していけるのかな というところは体感としてありますね。 ありがとうございます。それがまず一つ目のポイントですよね。 二つ目なんですけれども初期キッチンは完成ではなく 仮設設計ということなんですけど、これってどうですか? そうですね。この部分はしろたからお伝えできればなと思うんですけど、 ちょっと一個前でも触れたとおり、いわば成果創出型ではない 業務改善型みたいな形で、導入したら完了する、導入したら成果が体感できるような バックオフシャースとか、業務改善系のプロダクトの場合は、 いわば元々のオペレーションを移し変えられたら、DX化できたら 一定効果出るよねっていうところかなと思いつつ、 作業プラットフォームはそもそもその企業の課題に応じて どういうふうにプラットフォームを使っていくと作業成功に至るのか っていうところが肝になっていくところになるので、 まずは仮設設計をしていきましょうっていうところが重要かなと思います。 これもこういう採用要件で、このぐらいの規模感だと だいたいこういうふうに支援をしていけばいいかっていう ふわっと抽象的なものは形化できるんですけど、とはいえ その企業のリソースとかお客様の利点らしいとか採用要件って 比較的個別性が高いので、まずはその個別性の高い支援においては 前提、こういうふうな進め方をしたら採用成功にいくんではないか みたいなところの、仮設設計っていうところをゴールに置くと 初期の、まず最初のサクセスを感じていただくっていうところは 進みやすいのかなと思うので、その仮設設計、いわば10人 今年中に取りたいみたいな目標に対して、じゃあそのターゲットであれば いつまでに何件スカウト送って、面接を何件して、いつまでに 内定何件取れると、今年中に10人取れますよみたいなところの設計 かつそこに対して、じゃあどういう文面送ってあげるであったりだとか あとはその仮設の中に、よくあるケースとしてはスカウトの 返信率が下がるケースがあるので、その返信率が下がったケースの場合は プランBでいくとリカバリできますよみたいなところの 戦略というと大それた話になるかもしれないですけど そういった方針の設計をして臨んでいくっていうところが 重要なのかなっていうところですね。その方針を一周回して じゃあその方針に対して、どういう考え方で次の仕事を考えていけばいいのか っていうのをお客さまと一緒にやっていくと、お客さま自身でも 自分でピリッシュを回せるようになるので、そういったところを 初期のマーケティングというかオンボーディングのフェーズに関しては ゴールにしていくと良いのかなというところですね。 ありがとうございます。あと私ちょっと気になったんですけど キッティングってあんまり他のCSで使わない言葉なんかなと ちょっと思ったんですけど、対応プロットフォームで よく使うんですか?何を足すんですかね? これあれかもしれないですね。僕はどちらかというとバックオフィスサースとか 業務改善型のCS経験もあるので、そっち側で使う言葉かもなと思っていて キッティング、例えば設定するべき項目って一定バックオフィスサースとかだと 初期設定にするものが決まっているので、そういったものをある程度 設定しきるみたいなところを、キッティングみたいなところの 言葉を使って知ったりするかなというところですね。 なので、対応プロットフォームにおけるキッティング、初期設定 というところでいくと、さっきりょうさんもおっしゃっていた まずは最低限進む上で必要な設定。媒体の求人の公開であったりとか スカウト分の作成であったりとか、そういったところを指すのかなというところですね。 わかりました。ありがとうございます。 ちなみに2つ目について、中川さんは何かありますか? そうですね。難しいことのように聞こえると思うんですけれども 仮設設計って何かというとPDCAをたくさん回しましょうということも 大事かなと思っていて、バックオフィス系のサースのように 設定これで合ってましたっけとか、複雑な設定があるものでは 多分ないと思うんですよね。対応プロットフォームというものが。 なので、言葉を選ばずに言うと、早く出して早くスカウトを送って 結果を見て改善をしていきましょうというほうが うまくいきやすいのかなと思っています。対応プロットフォームにおいては。 なので、100点とか60点のものを出して、毎週毎週10点ずつ上げていったほうが 結果はうまくいきやすいのかなというふうに思いますね。 CSとしてサポートをご支援していても、そのように感じています。 わかりました。ありがとうございます。こちらが2つ目のポイントでした。 それでは3番目のポイントをお話し伺っていきます。 オンローディング中に運用判断ができる状態を作るということなんですけど こちらいかがでしょうか。 はい。こちら運用判断ができる状態を作るというふうに言っているんですけれども 採用プラットフォームのCSとしてあまり望ましくないなという状態が 常にお客様に対して、次これやってください、これやってくださいというふうに To Doだけお渡しをしていくということはあまりよろしくないのかなというふうに思っています。 それをしてしまうことによってスカウトの反応率が悪いときに お客様自身で改善ができなくなってしまうとか、求人に応募がないときに お客様自身で求人のどこが悪くて、どこを改善したらいいのかというのを 試行する機会を奪うことにもほかならないので ここはCSとしての関わり方としての正解は 一緒に数字を見て要因を一緒に原画化をして カスタマーサクセスとして持っている他社の知見とか マーケットの知見を組み合わせて一緒に改善策を出してあげるということだと思うんですよね。 ハウツーとか次のネクストアクションだけお客様に提示をしてあげるのではなくて 一緒に数字を眺めて同じチームの中で 次は何をしていきましょうかというふうに合意をするという プロセス自体を一緒に追体験をしていただくということが CSとしては大事かなというふうに思っております。 確かにこれはある意味お客さんをマネジメントしていくという要素が 結構この生活創出型活採用プラットフォームだと重要なのかなというのは 今中川さんのお話もしていて僕自身も思いますというところで 全然お客さん側にこれをやってくださいでも回るし 逆にこれ最初の期待値調整してないと そもそもやって欲しいことを教えて欲しくて契約してるんだけど みたいな感じになっちゃうので 全体の期待値調整は必要なのかなとは思いつつ いわばカスタマーサクセスとしても 毎日お客様と同じ解像度で同じ時間で ご支援提供できるわけではないので ある意味全体の考え方自体をお客様にインストールしていくことによって お客様がスピーディーに社内で内製で判断できるようにしてあげると 採用って比較的目の前の候補者の方であったりだとか もともと立てていた求人票に対して マッチしてるのかマッチしてないのかであったりだとか スピーディーにPDCを回していくことが重要なので 考え方自体をご自身で考えられるように お客様を育てていくというと 語弊があるかもしれないですけど お客様が自立実装で運用できる状態を作っていけるというところが 結構採用成功におけるピースになりやすいので まさに思考停止させないというところが結構重要なのかな というのは長谷さんのお話を聞きましたね ありがとうございます 短期的に見るとタスクだけ渡したほうが楽かな なんて思っちゃいますけど 長期的に信頼関係を結んでいくというか そういう場合はしっかりお互いに考えながら っていうのが必要なのかなと思って この三つ目のポイントすごく大事だなというふうに 私も思いました ありがとうございます それではこの三つのポイントをお話ししました まとめますと今日のポイント 1つ目オンボーディングのゴールは初回PDCAを回し切ること 2つ目は初期キッティングは完成ではなく仮設設計 3つ目はオンボーディング中に運用判断ができる状態を作る ということでした お話しいただきましてありがとうございました それで次回は太陽プラットフォーム周期における 独身的な支援から平準化された支援両立のポイントを お話を伺っていきます それでは来週日曜日の朝にスタートアップ CSベースプレゼンツゼロから始めるCSラジオでお会いしましょう ありがとうございました ありがとうございました