# チャプター1 皆さんこんにちは。スタートアップCSベースゼロから始めるCSラジオです。 この番組では、カスタマーサクセスの危険をドメインごとに解き明かしていきたいと思います。 今回ですね、HR鉄拳第6回というところで始めていきたいなと思います。 今回のシリーズの大山場というところで、テーマはCSはどこまでやるべきか。 役割範囲と支援領域みたいなところをテーマでお伝えしていきたいなと思います。 ボリュームゼロでこのシリーズを始めるときに、一番このどこまでやるのかみたいなところは、 割と僕たちも事前に考えるときに、皆さんが興味を持ったところなので、 そこについて自分たちの経験も含めて言語化していきたいなと思うので、よろしくお願いします。 早速ですが、自己紹介から始めていきます。 まずは私からというところで、私が新規事業開発でやっている、 カスタマーサクセスの支援を提供しているエッキーの代表、 そして、カスタマーサクセス向けコミュニティのスタートアップCSベースの主催をしております、 しろたと申します。よろしくお願いします。 そしたら改めて、今日はサブMC、大脇さん、ゲストパーソナリティ、 あやべさん、たきささんでお送りしたいなと思うので、改めて今日もよろしくお願いします。 よろしくお願いします。 では、自己紹介を大脇さんからお願いできればなと思います。 改めまして大脇です。 普段はアプリケーションプラットフォーム系のサービスで、 CSの立ち上げとマネジメント6年ほどやりまして、 今年から新しくPMMに挑戦しています。 HRテックの経験はないんですけど、CSが大好きなので、 勉強させてもらうような気持ちで参加させてもらっています。よろしくお願いします。 よろしくお願いします。あやべさん、よろしくお願いします。 初めまして、あやべと申します。 これまではですね、HRテックのSaaS企業でCSとか、 あとは組織のマネジメント、事業開発をやってきました。 今はCSの支援であったりとか、 あとはCSのキャリア設計というのを独立してやってます。 本日はよろしくお願いします。 はい、お願いします。 じゃあ、たきさくん、お願いします。 はい、たきさと申します。 私はHRテック、SaaSの企業で今8年目ですね、CSやってます。 組織自体がちょうど立ち上がりのタイミングで、 サービスも立ち上がってすぐのタイミングで入って、8年経験しておりますので、 本当にCSという業務を一通り経験した上で、 今日この場に臨んでます。よろしくお願いします。 はい、よろしくお願いします。 じゃあ、今日このテーマ、結構抽象度高いんでね、 ちょっと始めていきたいなと思うんですけど、 今日はちょっとやり方を変えてみて、 僕が今までMC回してたんですけど、 今日は大脇さんにMCを担当していただこうかなと思うんで、 変に緊張せずに、 お願いします。 じゃあ、ここから大脇さんにバトンタッチします。 はい、HRテックのCSにおいて、CSがどこまでやるべきかというテーマですけれども、 まず最初にCSがやるべきことの各コアのところって、 特にお二人から見て、改めてどう思いますかというところを聞いてみたいと思うんですけれども、 それぞれちょっと抽象的な問いですけど、 大脇さんの方からいかがですかね。 そうですね、結構フェーズによるという前提がすごい重要になってくるかなとは思うんですが、 やっぱり一つは、 特に初期のフェーズとかは、 お客様のアウトカムに創出に必要なプロセスというところ、 ここについては全てやるみたいなところができるのかなと思ってます。 ただやっぱり、プロダクトの一つ注意しないといけないのは、 全てやるといっても、 プロダクトの成長につながらないようなこと、 特に初期フェーズにおいてはですね、 についてはあまりやらない方がいいんじゃないかなと思ってまして、 具体的には例えば、 お客様の初期設定の代行を無償でずっと引き受けてしまうようなプロセスを構築してしまうとか、 っていうのをやってしまうと、 本来ですね、 プロダクト、お客さん側が設定して、 プロダクトで完結しないといけないことっていうのが、 機能として成熟しないので、 その反対で、 例えば会社を拡大していこう、 会社とか事業を拡大していこうってなったときにですね、 そうするとやっぱりCSの、 お客数の増加に伴ってCSも過剰に増やさないといけないみたいな、 つながってしまったりとか、 CSの負担が増えてしまって、 例えばアウトカムに向き合うっていうところが、 時間が取れなくなるみたいな事象につながっていったりするので、 なのでちょっとフェーズによるという回答にはなるんですが、 プロセスはすぐに全てですね、 結構こうやっていく、 やるにしてもやっぱりプロダクトの成長につながらないことは、 やらないほうがいい。 なるほど。 初期設定の代行とかですね。 っていうのは無償で引き受けるってことは、 やらないほうがいいかなっていうふうには思います。 なるほど。 結構なんか僕、 論点をもうちょっと広げてみたいなと思うんですけど、 CSとしてどこかってやるかというより、 なんかこうセールスとかマーケとか、 この俗に言うザモデルの中で、 セールスはここまでやって欲しくて、 CSはここまでやって欲しいみたいな、 ポイントの観点でいくと、 どういう考え方でそれぞれやられてたのかな、 っていうのはちょっと聞いてみたいなって。 めっちゃ理想は、 めっちゃ理想はセールスが、 なんて言うんでしょう、 アウトカム素質までのプランニングまでできてる、 みたいなのが、 個人的には理想かなと思ってます。 確かに。 結構規模によって難しかったりとか、 あとは一回商談したら受注しちゃった、 みたいなケースもあるので、 一概に難しいかなというところではあるんですが、 やっぱりアウトカム素質に向けて、 どういうプロセス、シナリオで、 プロダクトを進めていくかってところが、 固まってない状態で受注すると、 お客さんのほうでなんか違う解釈をしてしまったりとか、 あとはなんかもっとこういう支援が受けると思っていた、 みたいなちょっと認識損が生まれてしまったりする可能性はあるので、 期待する成果に対して、 どういうようなプロセス、 どういうような支援を受けられるかみたいなところも、 そのプランニングまでは行ってもらえると、 非常に引き継ぎがスムーズなのかなという気はします。 なるほど。 結構あれですね、 結構その目の前のお客さんとか短期のことを考えれば、 CSが代わりにやっちゃえばいいかな、 みたいなところがあると思うんですけど、 より長期の視点で見ると、 やっぱりプロダクトで解決できるようにしていかないとですとか、 ちょっとセールスの方がどうやってアウトカムを、 セールスのタイミングでお客さんに訴求できるようにしていくか、 そうなっていくと、 自然とCSが人手をかける領域がどんどんシャープになっていくと思うんですけど、 そこをちゃんと目指しながらCSやっていくってところは大事。 そうですね、そこが一番個人的には大事かなと思うんです。 あとはCSがどこまでやるかみたいなところに関しては、 結構SaaSプロダクトの、 特にHRCSの中のそのドメインによって変わってくるかなというでしょうか。 ちょっと一概にここまで、 具体的な例が挙げづらいんですが。 確かにそこも奥が深そうですよね。 プロダクトとかドメイン系とか、 そうですね、給与とか、 そういった業務領域とか、 によって結構異なってくるでしょうがあるので、 一概にちょっと言えないかなと。 ありがとうございます。 ありがとうございます。ほとんど。 さっきの質問はどうでしたか。 この後は。 ドキドキして何言おうかドキドキして。 もしちょっと共通するようなところが多い場合は、 やっぱりよりHRテクだからこそみたいな領域も聞けたらなと思うんですけど。 前半、お客様がご契約いただいて利用して活用を進めるという中で、 利用するまでのところを重点的にお話ししたいと思うんですけど、 僕はもう究極、ちょっとこういうこと言っちゃうと怒られるかもしれないですけど、 オンボーディングは人がやらないのが理想だと思う。 初期のセットアップ。 どう使っていくかっていうところ。 使い方の部分をお客さんも知りたいわけで、 それぞれのプロダクトを使ってやりたいことがある。 どう実現するかっていうところがお客さんはやっぱりわからないし、 そういう例が欲しいというところで求められてると思うんで。 セールスに関してはどう良くしていくかっていうところよりかも、 戦略みたいなところは言えると思うんですけど、 それをどう実現していくか。 戦術みたいなところはやっぱりCSの回答が高いですし、 それをやるのがやっぱりCSだと思うので、 どんどん活用の幅を広げさせるために、 お客さんの業務を理解してそこを改善しにいくみたいな。 そうすることによってどんどんシステムをインフラ化していって、 お客さんの業務としても楽にできるし、 事業としてもチャームを減らせるっていう、 その他の行動に対する大原則かなと思っています。 なるほど。 結構プロダクトを使うっていうところの先のところまでやっぱり踏み込んでいくところは、 CSが介在する価値があるし、 そこに寄っていくっていう感じですかね。 プロダクトを使う前提のところはやっぱり、 なるべく人が介在しなくてもいいようにっていう。 そうですね。やっぱりこのHRの界隈って、 そろそろ法律が絡んだりだったりとか、 会社の制度が変わるっていうところに対して、 どれだけそのシステムに対して就職してたとしても、 その変わったものをどうやったらフィットさせられるんだろう。 やっぱりイメージつきにくい部分があると思うんで、 そのためにそのシステムとしてこうできます、 ああできますっていうのを実際に介在していっていくのもそうですし、 お客様がどれだけ今の状態がいいと思ったら、 もうちょっともっとこうしたらこうよくなるみたいな。 この例を足し算で求めて把握しているのが、 やっぱりユーザーよりかも、こちらベンダー側だと思うので、 もっともっとお客様成長させるために何ができるのか。 それがお客さんが今イエスと言ってなくても、 強制的に振り向かせるっていう。 そうすることができたら、 より深度、カスタマーの作成みたいなところに近づくのかな、 っていうような印象になりました。 すごい。CSの本質っていう感じですよね。 確かにHRテック特有、特に人事論文とかだと、 結局データ移行とかが入ってくるから、 果たして過去分の情報を移行することを、 作業的なものにお客さんが時間を使って、 使い始めを遅れて、 結局そこで飛んざしてしまうので、 本質にたどり着く前に飛んざしちゃうことが。 そういうのは、それこそデータ設定代行なのか、 あるいは自動でCSで取り組むのか、 それこそAIとかで設定はやっていけると、 まあ良いよなっていうのは、 僕、前職の人事論文のCSやってる時も、 まさに痛感しました。 ただこれが難しいのが、 これを僕たちでやるのか、 AIっていうワードが出る前は、 結局僕たちが持っちゃうと、 構数の問題になっちゃうんで、 構数面出できるか、 ROIがあるのかっていう観点で、 お客さんにやってもらうのがベストだよね、 っていう反応しました。 結果、設定ってほぼ一回、 最初の初期って言ってないので、 やってあげちゃった方が、 最終ROIは出やすいのかな、 っていうのが初感としてありました。 この後、実際にAIちゃんと使って、 そこの自動設定みたいなところは、 もっと修練できると。 顧客もベンダー側もハッピーになるんじゃないかな、 っていうのが特にHRテクだと思いますね。 BPOとかも出てきてますしね。 BPOとかAIとかで、 なるべくCS以外のリソースを使って、 なんかできないかな、みたいなのは。 ビジネスなので、お金はもらわないと、 やはり事業として成り立たなくなってくると思うので、 そういった代行ニーズが強いようなプロダクトなんであれば、 そういう有償のプロフェッショナルサービス、 代行サービスっていうのを、 作っておくってことが非常に重要なのかな、 お客さんにとっては喜ばれそうですしね、 それはあると。 仕事をやってしまうっていうのは、 ちょっと違うかなっていう印象がありますね。 そうですね。 ウィンウィンな形にやっぱりしていかないと、 持続可能じゃないというところで。 ありがとうございます。 ちょっと次の論点に行こうと思うんですけど、 今ちょっと触れてた話も被るかなと思うんですけど、 逆にCSがやるべきでないこととか、 引き渡すべきところ、 今まさに話してたような初期設定とかも含まれると思うんですけど、 それ以外で何かありますかね、 HRテックならではの感じるポイント。 そうですね。 これも個人的にはあって、 やらないほうがいいっていう、 これもちょっと段階によって分かれるんですけど、 例えば最初は、 例えばそのタレントマネジメントとかでいくと、 評価の設計とかですよね。 評価制度の構築に関して、 例えばまだそういうニーズがあるお客様がいたとして、 そこのコンサルに関して無償でやるとか、 サービス設計を前提としてやるはいいと思うんですよね。 ただやっぱりそれで有償サービスができましたってなったときに、 でもやっぱりそこを何とか無償でやってもらえないかみたいなところで、 無償でそういうサービスを提供しちゃうみたいなのは、 これは当たり前ですけど、 当たり前ですけどやらないほうがいいということに 分類に入ってくるのかなと思うので、 なのでリターンがある状態で無償で支援するのは最適だと思うんですよね。 例えば評価設計のサービスの構築中でベータ版ができているので、 例えばまだベータ版ですけどどうですかみたいな感じで提供するのはいいかなと思うんですが、 そうではなくてサービスとしてはあるけど、 実はみたいな形でやってしまうと俗人化してしまいますし、 CSとしては疲弊してしまうし、あまり良くないかなと思うんです。 CSって結構そこの最後の調整弁になりやすいというか、 最後こちら側が妥協するときの最後の取りでになりやすいので、 退役しますって言われたり無償でみたいなのがありがちになりますね。 そういうのは避けるっていう風にしておいたほうが良いかなと思います。 やっぱり俯瞰して長い時間軸とか持続可能性とか、 今後のプロダクトの成長っていうところを見据えて、 本当にその1回やるべきなのかっていう、 ちょっとメタに見たほうがいいっていうところですよね。 確かに。 武田さんいかがですか。 お客さんに対しても、社内の他のポジションに対しても、 ここは営業に任せたほうがいいかなとか、ここは開発にとかって。 そうですね。やっぱりお客さんとの対応みたいなところですと、 これはプロダクトの会社の規模だったらフェーズのやっぱりこれも変わってくるんですけど、 不具合の対応とかトラブルシューティング系、 これはやってしまうと沼にハマってしまうので、 これは避けたほうがいいなと。 コースが取られるもそうですし、 やっぱりその不具合対応ってプラスの感情は受け取らないんで、 やっぱり相対しているメンバーとしてもメンタルが来るものがある。 本当はサクセスに時間を使いたいのに、 マイナスをゼロにする作業しかできなくなってしまうので、 やっぱりそこから遠ざかってしまう。 もちろん場合によっては大事だと思いますし、 その会社の体制によってはスピード感みたいな課題もあると思うので、 やったほうがいい時はあると思うんですけど、 ベース受けるみたいなことは避けたほうがいいのかなっていうのは コミュニケーション的な問題でそうするは思いますね。 なるほど。 最初でも僕らも立ち上がる時は全て受けて、 受けたほうがお客さんの苦しみみたいな感じじゃないですけど、 回答度が上がるっていうところを受けてはいたんですけれども、 そこを理解できたら、 あとはオペレーション的に横に流すっていうのさえできれば、 そこの理解を持っておいてお客さんに対しての細かな気遣いだったりとか、 スピード感みたいなところで、 何か受賞を受けたとしても、 この人に何かあれば安心、頼めるわっていう、 一輪窓口にならなければそっちに流しておいて、 それでも会計してなければこっちみたいな感じで。 会計にやってもらうと、CSとしても他のところに時間が使えますし、 お客さんとしても最後のそれとしてこの人が任せられるんだったら、 この窓口に従おうみたいなこともなれると思うんで、 それはやっていったほうがいいのかなっていうのはすごい思いますね。 それってあれですよね。 これって不具合起きてるんですけどみたいなのを、 CS、カスタマーサクセス、マネージャーが対応するんではなく、 テクニカルサポートにちゃんと窓口を移行することによって、 ちゃんとテクニカルの部分は専門部罪に対応してもらって、 自分で抱え込まないっていう意味ですよね。 確かにそれはそうです。 しかも結構重要ですよね。 独自的に一人で対応しちゃうと、 何が起きたっていうログデータも残らなかったりとかするので、 ちゃんとテクニカルサポートの導線に導く。 ただ難しいですよね、これ。 お客さんからすると聞いとるんだから対応してくれよって思いつつ、 ここにちょっと一緒に入力しましょうかとか、 そこら辺のバランスは結構バランス感覚が重要ですけど、 そこをしっかり目的意識を持って導くっていうのは結構重要かなと思いましたね。 そうですね、確かに。 なんかでも不思議ですよね。 2Bって今のような世界じゃないですか。 2Cってそれ普通じゃないですか。 はい、確かに。 でも電話かけた時に、この人は1王みたいな。 この方は2王みたいな。 そこで分けられますもんね、わざわざ。 2とか全然それが普通なのに、 なんでこう2B同士になるとそこのズレが落ちるんですかね。 でもなんかこれドメインの性質もありそうですよね。 例えばこれ極端の例かもしれないですけど、 マーケティング系のプロダクトとかだと、 お客さん側も少数性で試作とかシステムに明るい人がいる場合って、 割と自分で考えて自己解決できるけど、 そもそもじゃあ中小企業で兼務されてる方とかだと、 そもそもシステムに明るくないし、 法的なものとか給与計算ってミスが伴っちゃうものだから、 自分で解決するのが怖いみたいな性質もあるかもなと思いますね。 ベンダー側の人に聞いて、ベンダーさんの何々言ってたから大丈夫だって、 安心を買いたいみたいなところが心的な部分としてあるのかなって思いました。 確かに。 あとその入れてるソフトウェアのテクニカルサポートに問い合わせるということ自体に慣れていなくて、 フロントのCSの人がいれば逆に安心ってそこが価値になってるみたいな側面もありそうですよね。 自社のことをちゃんと分かっている人に教えてほしいという心理もあるかと思いますね。 だからテクニカルサポートとかも、 何々社さんですね、こういう設定されてるっていうのを認識した上で対応しますっていうのが お客さん側が分かっていたら多分安心して問い合わせできるのかもしれないですね。 そうですね。 確かになんかスカイですね。 P2Bのサポート対応。 なんかHR領域だからこそのコミュニケーションとかってあるんですかね。 今みたいなドメイン特性っぽい話というか。 なんかあれじゃないですか。 独占業務、私業ができる範囲に定職しないことをちゃんと守るっていうのが結構重要なんじゃないかなとは思いますね。 例えば制度設計、タレマネとかやってても制度設計とか投給制度とかまだまだギリ政府なのかもしれないですけど 例えば、労働時間をどうやって改善しましょうかとか 例えば給与支払いの統計設計とかも含めてやると結構法的知識が必要だったりとかするんで それをCSがやっちゃうと自然的に法令重視じゃないことをお伝えしてしまってたりとかもする可能性があるんですが ここまではあくまでも仕様としては設定できますけど ローム的な部分は社長室の方にご確認くださいみたいなところが ちゃんと線引きしないとお客さんが誤った方向に導いてしまうっていうのがあるんで そこは僕は結構意識的に線引きしてたかもなって それはめちゃくちゃありますね。言い切ることのリスクっていうのがすごくあるんで やっぱり一つ間違えてしまうと訴えられるとかっていうのもありますし それで勝ったら負けたりっていうとかよりかも そういう問い合わせが来てそれに対応するコースっていうのも考えると かなりいろんな人のいろんな時間を使ってしまいますしお客さんも幸せになれないし だったら専門的な方に聞いてもらった方がいいっていうところはお客さんに伝えるようにしてます ユーザーとしてもこういうシステムっていうのがそっちの道のプロなんでしょっていう イメージはすごく持たれてしまうので そこはあくまで我々ってシステムのプロであって法律のプロではないっていうところではあるので そこは切り分けてお伝えしてそっちの方がうまいことお客さんとしてシステムを扱えますし っていうところはお伝えすればご理解いただけるんですけど 何もしないとどっちものプロでしょって言われて お金がよくないっていうのはよくあるんですよね 最初から導入の時に顧問シャロウ氏の先生の方もこのプロジェクトに アサインいただけないですかみたいなコミュニケーションを取って 僕と割とスムーズにいくっていうケースを大西さんは 確かにそうっすね 同化制度の時も報酬の話には必ずなるんですけど あくまで線引きとしては報酬体系 この例えば等級グレードは年収これぐらいからこれぐらいまでみたいなとか あと小級ルールみたいなところは作りますけど それを例えば基本給いくらで手当ていくらでとか そういうところの設計については何かここは暗黙の了解かもしれないけど お客さん側も何となく分かっていて その細かいところに関してはやっぱりシャロウ氏の方とか 労務の方がやってくれてるというような印象はありますかね なるほどそういう線引き僕は初めて知ります あと一個思い出したんだけど 例えば上場準備でバックオフィスの入れ替えしてる時とか 僕マジ対応に困ったのが このシステム入れてたら上場に適応してるってことですよねって言われて それは多分監査法人に聞いてくださいね あくまでもこのプロダクトを使って上場いただいた事例はありますが 実際ちゃんと客観的に金代とかを取れるということを満たすという 条件においては客観性は持てますけど これを使ったから上場基準満たすとかは それは監査法人に聞いてください そうですね あとは何だっけ 情報の個人情報とか ISMSでしたっけ トックとかそういうシステム それに遵守してますかみたいな やってることは私たちがそれを取得しているという監査に合格しますかみたいな そのまま聞かれると それはちょっとじゃあ遵守してるか 項目をいただければそれに対しては回答できますがみたいな 結構こう流出りが入るみたいな性質の何かをやるときに そのまままるっとご質問されちゃうケース 人を不快感なく 特殊ですけど バックオフィスでデータを取り扱う 結構バックオフィス独特かもしれないですね あまりうちのサービス ISMSとか上質の方と相対するときにはもちろん出てきますけど 社長室の方にとかってあんまり経験がないので 結構ヒヤヒヤするというか 若干ツナあたりみたいな ミスらないようにしなきゃみたいなところある 表現とかここは多分お願いした方がいいなっていうのを ちょっと考えながら話さないと そこのイネーブルメントとかもまた結構大変そうですね 大変というか そうですね なるほどありがとうございます では最後のテーマにちょっと行きたいかなと思うんですけど 4人でCSの役割ってなんだろうっていうのを 一文で定義するという 一文とはみたいなところなんですけど これは多分HR お二人は多分HR文脈でいいと思うんですけど 今日結構本質的な話もできたので 僕とかは多分もうちょっと抽象化して HR関わらずになるのかな 一文 結構これ考える時間が 僕はカスタマーサクセスの役割というのは 世の中的にも概念とか言われていて 僕スタートアップCSベースをやって このクローズコミュニティを立ち上げたのも一個あるんですけど その時にカスタマーサクセスという言葉を使わずに どうやって表現できるんだろうということを考えたことがある その時に思ったのは 既存顧客地点で 顧客満足度と事業価値を想像できる ということ 要はお客様と自社の価値をいかに想像できるか っていうことなのかなって僕自身思っていて だから俗に言うお客様のためには そもそも最低限のラインであって そのカスタマーをサクセスさせることが目的ではなく カスタマーをサクセスさせるということは スタートラインであるっていう そこのスタンスは結構重要なのかなっていう ちょっと俯瞰してみると 冷静に考えておくよ それはお金お支払いいただいてるんだけど お客様のサクセスの 駅務提供として最低限だよな それに対して事業成長の いろいろ事業開発だったりだとか ちゃんとプロダクトを成長させるとか エクスポンションさせるっていうところもできる カスタマーサクセスの役割なんじゃないかな っていうのを僕は思ったんですね なるほど はい 似たような感じだね いいんじゃないですか別にそれは 似通ってても そうですね似通ってますけど 違うことは言って 僕は事業の生命線だと思ってるんで やっぱり入り口はやっぱり 一応やっぱりセールスの方が取ってきて 初めてお金が入って っていうときもありますけど それを維持するのも伸ばすのも やっぱりCSお客さんに買い代して その買い相度を上げて プロダクトないしは サービスの設計もそうですし サポートのあり方もそうですし セールスの取り方 全てに対してのフィードバックができる あとこっちにできる 僕らならではの常に ここがいかに どれだけコミットするかによって その会社内の事業が どういう方向性に成長していくのか そのスピードで変わってくると思うので その観点でやっぱり生命線なのかな っていうのが一言出ると感じますね なるほど確かに CSが良いCSだと より太い生命線になっていくと感じて 事業もどんどんドライブしていくし プロダクトも良くなっていくし すごい変な言い方ですけど カスタマーサクセスってことは 世に出てから どの会社もカスタマーサクセスやろう ってなったりとか でもその中には カスタマーサポートみたいな人たちも サクセスみたいになっちゃったりして サクセスって言葉だけ 一人歩きしてますけれども やっぱり本質でサクセスするため なんでサクセスするんだって考えたら 事業伸ばさないといけない ただただオンボーディングして 使わせるようにするためだけのサクセスは もうサクセスじゃないじゃないですか ちゃんといろんなところに フィードバックをしないといけないし フィードバックさせた上で 伝えるだけじゃなくて 伝えたものをちゃんと反映 そしてコミットさせるところまでやらないと やっぱりそこは意味がない そうなるとどんだけ声を台にして 力をつけないといけない っていうのももちろんそうですし それをやらせきる もちろん間違った方向に 行くのはダメですけれども ちゃんと自社っていうものに対しても サクセスしていかないと 結局お客さんもサクセスできないんで ここをどうやっていくのかっていう これをできるのがやっぱり カスタマーサクセスだなっていう 生命線っていう言葉を聞いて 僕もふと思い返すと カスタマーサクセス組織の状態が悪いと プロダクトの事業としての状態も悪いな 結構CSが疲弊してて 結構暗い雰囲気になってたり 退職がポツポツ出始めてるときって 結構プロダクトとしても 事業としても危機的状況 でもそれ何でなのかなって思ったときに 結局提供してるお客様に対峙してる クライアントの健康状態を モロに食らうのが カスタマーサクセスだと思うんで あくまでもお客様の鏡としての状態が もしかしたら現れてるのかなって もうちょっと僕言語化しきれてないですけど 感覚的に やってみて思ったところが マーケティングとか それこそPMMのメッセージって ある意味ビジョンを 夢を語れると思うんですけど CSってやっぱり現実に向き合い続けなきゃいけないと思うんで 今の話はそういうところにつながるかもしれないですよね 綾部さんいかがですか 被る部分はあるんですけど サービスの価値を伝達する役割だと思いますね サービスの価値って結構抽象度高いんで わかりやすい例でいくと サービス名は言えないんですけど Rから始まるパーソナルトレーニングを 提供してる会社あるじゃないですか あの会社が出してる2つのサービスが すごいわかりやすくて 1つはパーソナルトレーニングのサービスと もう1つはジムの場を提供してるじゃないですか でもその2つって サービスのターゲットも違えば 価値もちょっと違うじゃないですか そんな形で 例えばそのジムを提供しているサービスに パーソナルトレーニングの トレーナーとかが付いたりすると おかしなことになるじゃないですか 気軽に来たらめちゃめちゃムキムキな人が 本気出しましょうみたいな 3000円ですかみたいな 感じになって それはなんかやっぱりその サービスのターゲットと あとそのサービスの設計が成り立ってないから 結局その事業としても 多分うまくいかなくなっちゃうと思うんですよね なのでカスタマーサクセスっていうのは そのやっぱりターゲットとなるお客様に対して やっぱりそこのニーズに応えるような プロセスを設計したりとかする役割に 本来になるべきなんだかなという風には思っています 確かにこれもなんか僕最近 飲食特価の CSとかESを高めるプロダクションに関わってて あらためてサービスプロフィットチェーンの 考え方みたいなのを 僕ちゃんと学んでないなと思って 完璧じゃないですけど見ていく中で やっぱ面白いなと思ったのが お客様の満足度って 価格に対して 適切な料理とか サービスの空間と接客 これが適切であるっていうのが重要で これ1万円の コースを食べられるところが 汚くて遅くて まずいだったらあれなんですけど 逆に1000円のサービスを リッチな接客でやりすぎると それは成り立たないし トゥーマッチすぎるから これ別にやったところで お客様の満足度を 引き上げるわけじゃないので お客様の期待値に対して 適切なラインで サービスを提供するっていうのが 僕はそっち側を 学んでみて これCSでも トゥーマッチすぎるなーって 悩んだときのヒントになるな めっちゃその通りで 例えば吉野家の牛丼で この牛丼の牛肉は?って説明されて とりあえずサクッと 10分で牛丼一緒に食べたかったんだよ めっちゃ説明されるやん 価格とサービス内容が 見合ってない支援って そういうことなんじゃない? その辺りは改めて マーケットの市場ニーズとか 市場価格に対して 今のサービス提供が 割に合ってるのかとか 水に合ってるかとか そういうのは考えるべきだなと 僕は思いますよね 最高 そうですね 僕もまだまとまってないんですけど 事業とか プロダクトのビジョンを やっぱり現実に していく役割かな って思っていて 例えばプロダクトとしてこういう世界を 作りたいっていうビジョンが大きいものがあったときに 最初って 現実のプロダクト自体はちっちゃいじゃないですか で、やっぱりその間を埋めると お客さん側の 努力だったりリテラシーか こちら側のサービスのレベル 埋めていくしかないかな って思ってるんですけど さっきあやめさんが言ってた それがプロダクトのビジョンから外れたところをサービスしちゃうと プロダクトの成長に効かなくなるので この範囲がどこなのか っていうところをCSが 動いていってフィードバックを 集めていくことで プロダクト自体を成長させていったり あるいはプロダクトでカバーできないのであれば 次はサポートとか コミュニティとか エコシステムを作っていくことで このビジョンの隙間をどんどん埋めていこう みたいな感じになっていくのかな と思っていて さらに会社のビジョンっていうのは さらに今のプロダクトビジョンの外側にもあるぞ ってなった時に 新規事業としてこういうところに広げると 繋がりが良くなるんじゃないか みたいなことはCSが発見しやすくなったり するのかな それを ワンとワンでやったりとか あらゆる手段を使ってそれをやっていくっていうのが カスタマーサクセス それは結果的にお客さんの成功を 最大化してそして自社がやりたかった ビジョンに向かって自社の成功を 最大化していくっていう そういうサイクルになるんじゃないかな 僕は極端ですけど カスタマーサクセスの仕事を 無くすためにずっとカスタマーサクセスを してるみたいな 結局ギャップ 購入いただいて 僕たちがつかないで すぐ使えて 効果を実感できるんであれば それに越したことはない 気がするんで それも思いつつ 今の大巻さんの話で僕も思い出して これはしくじりなんですけど できないことを逆に ハックした結果 プロダクトへの実装を送らせて 工数が膨れ上がっちゃったみたいな アンケートとか 集計周りの機能が なかったんでこれCSVで吐き出して Googleのワークスペースの機能を使えば レポーティングできますっていうのを ある意味ハックで生み出しちゃった 結果 ダッシュボード機能が成長せずに お客さんに届けられる価値が 縮小してしまったっていうのは 僕もしくじりの中にあるんで サービスを埋めることをやってもいいんですけど それをあくまでもちゃんと プロダクトに実装させるとか サービスとしてちゃんと 提供するっていう概念を持って ギャップを埋めないと 誤った方向にプロダクト成長させて しまうっていうのは 僕も実体験としてあるんで そこの責任を担ってるっていうのは 持ちながら 対応した方がいいなと思いましたね PDM的な視点も必要ですし PMM的な マーケット広げていく みたいな視点も必要です 本当に面白いポジションです だからCS経験しておくと どっちのキャリアにもいけるって いうのもあるかもしれないですね そうですね ありがとうございます ありがとうございます 押しましたか いいですか 40分くらい撮ってる 奥深いテーマだったので これはもう大丈夫です いつも20分なんですけど こんくらいかかるだろうと じゃあすいません 今日もありがとうございます 改めてまとめさせていただくと CSのやるべきことの各 みたいなところであったりだとか どういう線引きをしたらいいのか あとは スタマーサクセスの役割とは なかなか 皆さんが聞くと言語化するのは おこがましいですけど 僕たちなりの言語化をさせてもらいました というところです このシリーズ最大のまといとして 僕たちも言っていた CSはどこまで役割を持つ的なのか みたいなところは 言語化できたのかなと思います これはもう少し語ってもいいかな 次回はですね HRサースとAI 従業員データの活用 みたいなところを 収録していきたいなと思います AI時代に CS職種がどう変わるのか みたいなところを テーマで議論していきたいなと思うので よろしくお願いします 今日は改めてありがとうございました ありがとうございました