カスタマーサクセスのブリッジの実行方法
今回は、強いカスタマーサクセスチームを作るには、最終回になります。
前回、顧客理解の重要性というところで改めて会話してきていて、
初回にも触れたんですけど、ポイントは顧客理解っていうのをベースに、
カスタマーサクセスがブリッジ組織として役目を果たしていかなきゃいけないよねっていう話をしてきたので、
今回はブリッジ組織っていうところの内容を話していければなと思います。よろしくお願いします。
カスタマーサクセス、顧客理解を通じて組織理解を促し、
かつ手法理解も学びながら、よりお客様の成功を通じて
プロダクティブサービスを成長させていくところの原動力になっていく必要があるよね。
その役目を達成するには、最終的にブリッジ組織として機能していかなきゃいけないと思います。
ブリッジっていうところのキーワードでは、少し話してきたことはあるんですけど、
一旦整理すると、カスタマーサクセスのブリッジっていうのをどうやって実行していくのかっていう話は、
結局は顧客理解をして、お客さんと自社の共通言語を作って、
そこをブリッジさせていくっていうところが一つあります。
さらに、そこで作った共通言語というのを基に、組織として取り組むべきっていうことを、
経営をトップダウンにした形として、ちゃんと企業の活動として実行していこうっていうところが大事かなと。
ここは前回の話でも、カスタマーサクセスが全てやるわけではないと思うんですけど、
カスタマーサクセスがそこの活動になるとしたら、基本的にはお客さんからの課題とか悩みっていうのは、
カスタマーサクセスがちゃんと確認して、業務としての課題の真意をちゃんと捉えて、
それを組織にフィードバックしていくっていうことを実践していくことになると思うので、
この経営と現場をつなぐっていうところの、まず動き出し、きっかけを作るっていうところで、
CSがちゃんと意識して動く必要があるかなと。
そういう意味だと、カスタマーサクセスっていうのが、結局はお客様理解から組織を変えていくきっかけを作っていかないといけないので、
ブリッジする起点はカスタマーサクセスの組織かなと思うんですけど、
これについてどう思いますかっていうので、丸田さんに伺いたいんですけど。
そうですね、やっぱりCSの一番強い部分っていうのは、
お客様の現場の深いところまで入り込んで、本当にリアルな声であったりとか、
現場の状況だったり、プロダクトをどう使っているか、
うちのプロダクトはどう顧客のビジネスなり、B2Cであれば生活なりに寄与しているか貢献しているかっていうのが、
やっぱり手触り感のある流度で見える、わかるっていうところだと思うんですよね。
なので、ものすごく具体的に詳しく細かく、
こういうふうにお客さんがサービスを使ってうまくいってます、こんなに喜んでいますっていう声だったり、
成功体験だったり、ベストプラクティスみたいなものを社内に届けていくっていうところから、
やっぱりスタートしていくっていうのがすごくいいんじゃないかなと思います。
やっぱり、実際にお客さんがどういうふうに自社のプロダクトでハッピーになっているのかっていうのを、
なかなか生で見る機会、生で聞く機会ってないと思うんですよね。
でも、かさまさく先生、それがすごくできるので、
なので、そのお客さんの声の代弁者になってあげるっていうところから始めると、ものすごくやりやすいんじゃないかなと思ってます。
その代弁者として、一時情報をちゃんと社内に伝えていくっていうところで、
非常に重要なところが役割としてカスタマーサクセスにあるかなというところで。
あとは、そこの中でいうと、ヤギさんとかもモデリングだったかな、
以前のシリーズでも、いわゆるお客さんに確認するべき観点ってポイントありますよみたいなことも伺ったと思うんで、
そこの話も踏まえて、今の話どう感じるかってコメントいただけると。
2点あるんですよね。ブリッジするのは、お客さんの社内の話を自社に伝える。
自社の中でそれを伝えるという話で、
丸田さんが言ってくれたのって、お客さんの情報を社内に持ち帰ってくるっていうところの、
まず最初のブリッジの話をしていただいたと思ってて。
そこの部分って、やはり何を持ち帰るかだと思うんですけど、
前に話したのは、お客さんがただ話したことを持ち帰るのって結構ある程度できるんですけど、
そうじゃなくて、お客さんがどう思っているかというか、
どういうふうに認知しているかというところをしっかり持って帰るというのは、
お客さんの感覚値に近いものになるので、話をそのままではなくて、認知をちゃんと聞く、
それを把握するというほうが重要かなと思ってます。
話っていう訂正的なストーリーだけではなくて、
それがなぜそういうふうに捉えられているかみたいなところの内容、
多分発言をしている背景にはこういうことがあるんじゃないかみたいな、
それってこういう認識に基づいてますよっていうところを構造として浮き彫りにしてる話かなと思ってます。
さらにあと付け加えるとしたら、定量的な情報とかも加えれるとよりベターなのかなというふうに思うんですけど、
この辺りに関してはマルスさんはどうですかね。
例えば何パーセントのお客さんが同じなこと言ってますだとか、
この課題に関してはこれぐらいの度合いでお客さんって問題意識が強いとか、
これぐらいの予算化したいと思ってますみたいに、
数字をセットで語るっていう重要性もありそうかなと思うんですが。
そうですね。基本はやっぱり数字やファクトっていうところと、
訂正や感覚、所感っていうところの掛け算はすごく大事かなと思います。
校舎の訂正、所感、感覚ってやっぱり寄り過ぎてしまうと、
それって本当なのかとか、まさに今おっしゃっていただいたような、
どれくらいのお客様が言ってるのかとか、やっぱり判断しづらくなってしまうんですよね。
だからこそ、カスタマーサクセスってデータをきちんと見ていくこととか、
そのヘルススコアとか最大の例だと思うんですけど、すごく重要されますし、
データ、ファクトとセットで語ってあげる、広めてあげるっていうのはすごく大事かなと思います。
やっぱりそこの数字がないと、組織としてこういう活動を取り組もうとか、
ここに収録しようっていう決断に持っていくには非常に難しいんで、
やっぱり数字とストーリーセットで語るっていう重要性が非常にあるかなっていうところですよね。
そこを通じてお客さんから得てきた内容っていうのを、
社内としてどういうふうに取り組もうかっていうところの、
方向性の道筋をつける部分っていうのは、CSが十分になっていけるし、
それはCSだからこそできる役割も大きいんじゃないかなってところが見えてきたので、
じゃあ次にお客さんと自社をつないでいくっていうときの、
顧客伴奏の重要性
CSならではっていう話で言うと、やっぱり顧客伴奏かなと。
ここも顧客伴奏シリーズでは話してきたことではあるとは思うんですけど、
顧客伴奏のやり方とか在り方って非常に大事だと思うんですよね。
フラットな関係を築いたりとか、個別化をしてちゃんと捉えましょうとか、
信頼関係をちゃんと作りましょう。
信頼関係の話は顧客理解の中でも少し触れてきたんですけど、
やっぱり正しいことを正しく言える関係性を持つとか、
そんなこともあったかなと思うんですけど、
今のこの現時点の状況で、丸さんの目から見て顧客伴奏って重要だと思うんですけど、
アップデートした話とかあれば伺いたいですし、
いやいや変わらずここってこういうベーシックな部分で求められてるんだよっていう話でもいいんですけど、
そのあたりの状況といかがでしょうか。
ここは本当に本質的に大事ですよというところは変わらずだと思いますし、
中長期で顧客を育成したり課題解決しながら、
成功に導いていく成果を出し続けるアシストをするってカスタマーサクセスならではですし、
やっぱりカスタマーサクセスが存在する一番コアな価値だと思うんですよね。
ただどれくらい伴奏するのかとか、どう伴奏するのかっていう中身、度合い、期間とかはやり方とかですね。
やっぱり上手くいく、いかないとか、よし足とか、適切、不適切とか、上手い、上手くないとかそれはもちろんあるので、
必ずしもとにかくゴリゴリに伴奏しろみたいな、昔で言う足で稼ぐ営業みたいなことがいいとは言わないですけど、
ただやっぱり伴奏することでお客さんに提供できる価値っていうのは間違いなくあると思いますし、
ここ本当に変わらず非常に本質的で大事な部分ですよというのはあります。
ここに関してはやり方っていうところはありますけど、多分観点みたいな話は、
顧客伴奏シリーズの中でも話してきたポイントっていうのは変わらず意識して取り組むってことが大事なのかなっていうところなんで、
その意味で言うとさっきの話したようなフラットな関係とか、ちゃんと信頼関係作っていく、
そこをやっぱり意識して取り組むっていうのがカスタマーサクセスが求められている役割だし、
カスタマーサクセスしかそこって多分体験できない醍醐味があるところかなという感じですよね。
もしアギさんから業務モデリング観点とかで伴奏に関してコメントあればちょっと伺いたいんですけど。
モデリングというかコンサルタントとしてですけど、伴奏するのが多分理想系かなと思って、
ビジネスやってるお客さんなので、自分がそれでビジネスしてるわけじゃないので、
そこら辺は自分で走って自奏していただかなきゃいけなくて、そういう意味で言うと伴奏という言い回しってすごく良い言い回しかなと思っているので、
それ通り伴奏できるというのがいいのかな。時に引っ張る場合はあっていいんですけど。
大層と伴奏みたいな話もしてて、まさにおっしゃる通りですよね。
思います。
共通ゴールに向けて一緒に取り組むっていう意味で言うと、コンサルタントとしてもそこのカスタマーサクセスのそのピュアにできる活動っていうのは、
ヤギさんから見ると羨ましくもあるっていう話は、コンサルタントとカスタマーサクセスの職業シリーズの中でもちょっとしゃべってもらった内容ですよね。
じゃあ結局その顧客伴奏っていうのは変わらず大事ですし、そこで信頼関係をちゃんと作れないと本当の課題にも迫れないと思うんで、
そこまでベースで変わらずやり、そこからちゃんと社内につないでいくっていうところで、
逆V字モデルのアプローチ
顧客さんから出た重要な情報っていうのをちゃんと数字も合わせて説明していくっていうのがブリッジしていく上では必要な観点かなというところで話してきましたと。
ここからカスタマーサクセスのブリッジっていうのをどういうふうに実行していくかっていうところの形とかあり方みたいな話っていうのも、
実は我々これまでのシリーズの中で話してきていて、これは構造化スキルの中で話したんですけど、
結局今の伴奏のあり方や組織に根付かせていくっていうところも、ある種型を作ってやっているようなものなんですよね。
ブリッジってやっていく上では、明確に把握した要素っていうのをどういうふうにつないできますかっていうところもある種形があるかなと思っていて、
そこは我々の中だと、逆V字モデルっていう活動をしていくっていうのが一つありますよって提案をさせてもらったかなというふうに思ってます。
この逆V字モデルっていうのは構造化の中のシリーズでも八木さんに説明してもらってますけど、
結局ソフトウェア開発ってV字モデルという形で、要件定義をして開発して実際に製品を収めていくっていうその工程の逆で、
現場のお客さんの現状を把握をした上で、あるべき姿の設計を経営の中で決めて、
それを現場に更に還元してお客さんにその価値を届けていくっていう逆V字だっていう話をしているというところですね。
これを実現するのに構造化がないとダメですよっていうところがあって、
その構造化するっていう意味でいうと、成果物資店でのアウトプットの話を引き合いに出しながら、
この逆V字モデルの重要性を説明してきたかなというふうに思うので、
改めてにはなると思うんですけど、この逆V字モデルのアプローチのメリットとか、
逆V字モデルとは
ブリッジする上で有用ですよっていうところの話って、お互いで言えばなと思うんですけども。
堀井さんに言っていただいた通り、もともとソフト開発のプロセスを例に、
V字モデルと言われるウォーターフォールのモデルを少し折り返したやつなんですけど、
ここの問題点が、要件のところを定義に難しいよねっていうのがまずそもそもあって、
逆V字はそれのために、要件定義する前の段階、超上流って言われたりするんですけど、
その領域で、かつシステム使うのって、今業務やってる人がいて、現状の業務があって、
より良い業務にしたいからシステムとか入れたいよねと、ソフトウェアを入れたいよねっていう話になるので、
まず現状をちゃんと分析して、そこからツーリーの業務を設計して、
それのために必要なソフトかシステムなんですかっていうふうにするといいんじゃないですかっていうのが、
逆V字モデルになってますと。ここで重要なのは、まずそもそも現行なんかやってる業務があるんですよ。
よくあるのが、企業が大きくなってきたりすると、組織分けていくじゃないですか。
分けていくと縦割りになっていくので、徐々に元々の意図と違うような動きをしたりとか、
機能ごとに効率よくするために分けていくので、なんで縦割りになっちゃうんですけど、
ただ価値を流すときって営業から設計があってとか販売があってみたいな横の流れになるので、
そこの流れがうまくいかなくなるっていうのがあるんで、それはもう一度何のためにやるのかと。
ある意味経営の目標みたいなところに立ち返って、それの整合性をもう一度取りましょうよというのが、
逆V字の話かなと思います。これをどう適用するかなっていう話かなと思ってて、
我々が言ってるのはお客さんの業務をサービス入れることで変えていくことになるので、
まずAzizからその業務をモデリングして、実際何が本来したっけ、どういう2Bにしたいのかというのを明らかにした上で、
じゃあ2B業務はこうあるべきですよね、そのためにはこういうサービスとかこういうシステム入れますよねっていう手順でいくといいんじゃないですかという話をさせてもらってるかなと思ってます。
もうちょっとカスタマーサクセスの文脈によっていくと、現場がやるようなライトサクセスみたいな部分とか経営課題までちゃんと解決するようなディープサクセスみたいな、
両方の話があって、構造化の中の話でも言ってると思うんですけど、結局目的って経営命題としてやるべきことがあるところに、
いろんな業務の目標が紐づいているので、その業務の内容を変えることで経営の目標にどういうふうに貢献して、どれが効果あるか。
だから経営はこういう内容をゴールとして目指すとか、新たに目標設定するんで、それを達成するときにここの業務をこういうふうに変えていくことをやりましょうっていうので落として、
実際にお客さんの課題にそれが解決するのにつながるっていう、いわゆる経営命題と現場の課題っていうところを両方つないでみえることによって取り組む意義をちゃんと明確化するってところが、
逆VGモデルの特徴というか、良い点というところでこういうやり方もあるよねって話をしてきたかなと思いますし、結局現場と経営をつなぐかつお客さんもつなぐから、
お客さんと現場と経営っていうその3者をつなぐところにカスタマーサクセスが主導して入っていくっていう部分としても、こういうアプローチってあるよねっていう話をしてきたかなというふうに思ってます。
カスタマーサクセスの組織強化
マルチさん、この逆VGのアプローチ、どういうふうに感じてるかコメントをいただきたいんですけど。
逆VGのモデルはすごくCSとしても本質的な考え方として使えるんじゃないかなと思いますし、まさにおっしゃっていただいたライトサクセス、ディープサクセス、どこまで狙っていくか、目指していくかっていうのはあるんですけど、
やっぱりお客さんの理解をきちんとして、お客さんとどこまでを目指していくか、そもそもそのAs-IsとTo-Beどうなってるのかとか、そういったことのコミュニケーション認識合わせのためにもすごく使えると思いますし、逆に言うと逆VGと呼んでいないだけで、
難しいことはやっぱり成果の出しているCSチームは、顧客側と多かれ少なかれすり合わせていったり作っていったりしているとは思います。
漁業式言っちゃうと、カスタマーサクセスをサクセスさせるようなアプローチとか仕組みでもあるかなとか思うんですけど。
カスタマーサクセスがきちんとうまくいくチームとして成果を出すためのすごくコアになるメソッドの一つなんではないかと。
一つのフレームかなとは思いますよね。
これは我々は成果物支店とかっていうところの話から見ていくと、こういうアプローチっていうのがブリッジにもいいんじゃないかなみたいな話で。
今、丸田さんの話でいただいたように、成果を出しているチームが同じようなことをやっているっていう意味で言うと、多分一定の効果を期待できるんだろうなっていうところですし、
実際にCSの組織をサポートするみたいなことで、我々考えているんで、こういうことっていうのを取り組むと、繰り返しますけど、
お客さんだけじゃなくて、お客さんと現場と経営ちゃんとつなぐっていうところのブリッジしていく組織にCSを成長させていくというか、
そういう組織になっていくっていうところが支援になるようなソリューションじゃないかなというところで、
カスタマーサクセスの組織とかチーム強くしたいっていうふうに感じている企業とかであれば、役に立つソリューションじゃないかなというふうには思っているんで、
一つの手法だと思うんで、こういう取り組みがあるんだっていうのを知っていただけると、我々としては非常に嬉しいですし、
ここに関してはサポートいろいろできますよっていうところになるかなと思います。
というところで、ブリッジの部分の話としては、逆無人モデルみたいな一つの型っていうのが、
一個の提案っていうところまでは見えてきたってところで、結局こういうことをやっていくと、
強いカスタマーサクセスチームが作れますし、そういうことをやる上では、やっぱり顧客理解っていうところがベースで、
その顧客理解をちゃんと深掘っていくっていうところの観点は、これまでのシリーズの中でもいろいろ喋ってきてるかなと思います。
何々の回で喋りましたけどっていうのがいっぱい出てきちゃったんですけど、
我々の話してる内容って復習回なんで、これまで話してきた内容につながってるかなっていうところで、
それぞれの話の内容をもうちょっと深く知りたいなっていうのは、前のシリーズちょっと聞いていただけると、
参考になるところがあるのではないかなと思っておりますんで、
そんなあたりも気になる方はぜひ聞いていただけるとありがたいなというところで、
今回のチームを作るっていうところの話は、説明できたかなというふうに思います。
ということで、こんだけ語ったんで、シリーズの最初に言ってた書籍化したいっていうところの話は、
たぶんコンテンツがほぼほぼできてきたと思うんで、
前も言いましたけど、また書籍化できたら改めて案内したいなと思ってますというのを、
結びに今シリーズは終わりたいと思います。
皆さんありがとうございました。
ありがとうございました。
