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