顧客理解の重要性とカスタマーサクセスの役割
今回は、強いカスタマーサクセス チームをつくるにはというテーマ
で話していきたいなと思っています。 これまで、我々って顧客理解っていう
テーマでいろいろ話してきたんで、 その顧客理解っていうのをちゃんと
組織に適応して根付かしていく っていうところを改めて考えたいな
と思っています。顧客理解の話は さざ話してるんですけど、もう一回
復習会みたいな感じでこれを議論 していければなと。
よろしくお願いします。
よろしくお願いします。
じゃあ、今回の話の内容にいき たいと思うんですけど、その前に
一個お知らせとしては、前回カスタマー サクセスってどんな職業っていう
テーマでも4回分の話してきたんで、 記事にしてます。営業とサポート
とマーケティングとコンサルっていう 違う職業での比較してきたんで、
いつもみたいにまとめて1本の記事 っていうよりかは、4本作っていって
営業の記事から順次上げていこう と思ってるんで、リンクはまた
概要欄に貼っていくんで、よければ ご覧いただければなと思ってます。
あとはあれですかね、結構ブログ の分量も溜まってきて、書籍化
したいなと。そのときにグラって 顧客理解にこだわって話している
はずなんで、やっぱりこのテーマ ちゃんと語らないといけないかな
と思ってます。多分これが出来上がる と書籍としてのパッケージ作れるん
じゃないかなと思うので、いつに 出来るかとかは分かんないですけど、
作りたいという意思表示だけして おいて、ちゃんと形にしたいな
と思ってるんで、また出来たらPodcast とかで話していければなと思います。
本編の話に行きたいなと思うんですけど、
カスタマーサクセスって何で顧客 理解ってこんな大事にしてんの
っていうのと、この顧客理解にこだわる ことによって何で強いカスタマー
サクセスチームができるのかっていう ところを改めて話をしていきたい
なと思ってます。カスタマーサクセス って何でそういうことを考えなきゃ
いけないのって話って、本当に初回 のときに話してるんですけど、カスタマー
サクセスのやることって何ですか。 これって我々の中では二つのことを
大きくやるべきこととして整理 していて、その1個目が期待値を調整
カスタマーサクセスの期待値調整とカタカ
するっていうことですね。その後に 調整した期待値に対してカタカ
しながらスケールさせていくっていう その2点の話があって、期待値調整
とカタカ。期待値調整ってお客さん の求めてるところに対して自分たち
ができる部分、それがどういうふう にサクセスにつながっていくか
っていうのをうまくコントロール しながら調整していくっていう
ところなんで、主に個人のパフォーマンス に依存するというか、個人でやる
ところの領域が大きいかなと。 一方でカタカはカタカするところ
っていうのは全体組織に広める ためなので、その先頭を切るところ
は個人の突破力みたいなのも大きい んですけど、基本的には組織力
に依存する話かなと思ってます。 この辺りの話、客理解っていう
フォーカスでいうと、期待値調整 の中の内容をかなり話してきたんで
そこの話から組織力につながる っていうところをまた改めてちょっと
考えていきたいなと思ってます。 この顧客の期待値調整を先導して
やっていく人って誰っていう話 なんですけど、これもPodcastの最初の
シリーズで整理しましたけど、 顧客理解に必要なカスタマーサクセス
の心得参加上っていうのがあるよね って話をしてきたと思っていて
繰り返しになるんですけど、1点目が 自身が課題を理解してない可能性
があるという前提を置いて顧客 と対峙すると。2点目が顧客から
答えを引き出す姿勢を持つと。これは 顧客伴奏とかカスタマーサクセス
の姿勢にも通ずるところかなと思います。 3点目が事前に業界知識や顧客と
対話する上での必要な知識を備える と。この3点っていうのがカスタマー
サクセスが顧客理解をする上で 必要ですと。このベースがあった
上で、お客さんと伴奏しながら 期待調整をしていくっていうところ
がポイントになると。これって どういう人たちがまず最初に
先頭を切ってやっていくかっていう と、そういうことがうまくできて
いる人たちがやるってなること になるかなと思うんで、カスタマー
サクセスのリーダー層とか、実際に チームを率いている人が主導して
顧客理解のベースとリーダーの役割
いくところかなと思うので、この カスタマーサクセスのチームを
出力するためには、それを推進する リーダーが必要になるかなという
ふうに思ってます。このあたり 議論はしてきたんですけど、改めて
今、カスタマーサクセスのリーダー がやらなきゃいけないこととか
求められてることって、どんなふう に見えてるのかなっていうのを
現時点での認識として、丸田さん いかがですか。
まさにおっしゃっていただいた とおり、きちんと顧客の理解を
ベースにしながら、どういった課題 を解決していくことでサービス
の活用につながるか。どういった 事業課題をサービス活用によって
解決して、顧客を成功に導くか っていうことを描いていく。その
ロードマップなり、実現方法なり、 そのための支援策なりっていう
のを描いていくというのが、CSの 最も基本的な、最も大事な業務の
部分かなと思います。そのために 顧客理解というものは必要ですよね
というのは、まず最初に求められる もの、ベーシックなものという
ものであるんですけど、最近、もしくは これから1,2,3年ぐらいのスパン
で考えていったときっていうのは、 さらに上のレベルを求められて
きているなというのがあって、そこの 顧客理解に基づいてきちんと
サクセスプランニングをして、お客 さんの支援をしていくっていう
のが、もはや何もできることとして 求められてきてしまっているので
そのさらに上の、より支援策という のをデジタル化していく、テックタッチ
化していくっていうところができない のか、より少ないコースで同じ
ようなクオリティの支援ができない か、あるいはお客さまが必要として
いるものだったりとか、持っている 課題感みたいな、その深い顧客理解
に基づいて、CSの人手の支援策を 動向していくではなく、プロダクト
の機能改善にお客さまの理解という 声というか、というものをどんどん
反映させていって、プロダクトタッチ ではないですけど、よりCSがプロダクト
と密に連携をして、プロダクトを どんどん進化させていく、ドライバーに
CSがなっていけないというところ がますます求められてきているんだろう
なというふうには感じています ので、やっぱりここ最近CSに求め
られてきているもの、CSにとって 大事なものというのが、レベルが
1、2段階ぐらい業界全体で引き上が ったんだろうなというようなことは
感じます
吉田 ベースとか大事な部分は変わらないん
だけど、顧客理解っていうベース を活かして、CSとして活躍するとか
パフォーマンス発揮するレベル 感としては、やっぱり要求水準
ちょっと上がってきているかな というところなんだなというのが
理解できました。それってある種 業界が成長しているっていう証拠
でもあると思うので、それは健全 っていうか、嬉しいことかなと思
いつつ、以前ってできるCSの人が 組織引っ張るとか、俗人化してる
みたいなところの課題感とか 取られてたんですけど、やっぱり
そこを出してチームとして強くなる とか、組織として活動して、ちゃんと
プロダクトフィードバックを早く して、プロダクト改善にカスタマー
サクセスが効くからと引き出して きたニーズとか、本当にやらなきゃ
いけないことっていうのを素早く 製品反映していく。そんなところに
求められるレベル感に変わって きているというか、要求レベルが
成長してきているっていったら いいんですかね。そういうふうに
高度になりつつあるのかなっていう 感じかなと思ったんですけど
おだしょー そうですね。まさに おっしゃるとおりだと思います。
大平 そういう意味だと、結構リーダー の人が一人で頑張ってるっていう
状態は健全じゃないっていうところ かなっていうところがあるので、
やっぱり組織として強くしていかな きゃいけないってなると、結局
その組織力を高めていくみたいな ことを考えていかなきゃいけない
っていうところですよね。ただ 一方で全ての人が同じように
均一にできるわけではないので、 やっぱり堅かしていって、ちゃんと
誰でも必要最低限のことを達成 できるように引き上げていく
部分はいるのかなと思うと、やっぱり 顧客理解を通じて自分たちの
自己理解みたいなことも大切なの かな。これもシーズンの1回目の
ときに話が出てるんですけど、結局 自分の強みっていうのを理解して
いないと、お互いチームの中で最適な 配置とかチームとしてのパフォーマンス
を上げていくっていうところも 難しいので、デジタル化してでも
やっていかなきゃいけない領域 に来てるっていう感じですね。
なるほど。そうなってくると、この 部分って我々の中だと、自己理解
とか顧客理解っていうことをやる ベースの力っていう話がモデリング
力ですっていう提案もしていて、 これも以前話してるところなんですけど、
モデリングっていうのは、ある物事 や対象を理解する行為っていうこと
になっていて、そのモデリング力 というものが高いと、いわば一押し
って10が分かるみたいな状態っていう ところなので、カスタマーサクセス
のリーダーの人は基本備えていて、 そういう状態っていうのを自分
だけじゃなくて、組織に広げていかな っていけない部分があるのかな
ってなると、このモデリングの話 って、我々の中では業務プロセス
にちゃんと着目して、お客さんの 業務という対象を正しく理解する
活動をすると、そこが高まっていく よっていうお話もしてきたんで、
そのときに少し成果物視点っていう、 我々なりの提案の内容の話とかも
踏まえて会話してきたんですけど、 モデリングの観点ってなると、
ヤギさんに改めて聞きたいんですけど、 今みたいにリーダー一人じゃちょっと
難しくて、チームとして活動して いかなきゃいけないってなった
ときに、リーダーがカスタマーサクセス の組織を肩貸して推進するために、
どういう成果物をちゃんと作って いかなきゃいけないとか、コメント
あればいただきたいんですけど。
大平 構造化のところではないけど、
もともとプロセスのモデリングが 発達したというか、研究なされたのって、
ソフトウェア開発のところで一つ あるんですけど、そこももともとは
ソフト開発って、できる開発者と 普通の人の差が倍どころじゃなくて、
10倍ぐらい違うとか言われる業界で、 とてつもなくプログラミングができる人、
設計ができる人っていう人がいる 一方で、一般の人はそこまででもない
思考の壁打ち
みたいな差が激しいというふうに 言われていて、その中でどういう
品質を組織として担保していくんですか というところで成り立ってきたもの
っていうのがまずあって、おそらく カスタマーサクセス業界、前田さん
言っていただいたとおりのところで 起こっているのちょっと近いのかな
と思います。なので、ある意味 トップの人が引っ張るのではなくて、
ある程度底上げしていくっていうの 一つが多分カタカンみたいな話で、
かつそこを今で言うと、例えばテクタッチ とかプロダクトタッチみたいなところに
フィードバックすることで、ある意味 人手から離していくみたいなところ
起こっている話なのかなと思います。 なので、カタカンというのは非常に
重要で、これが正解かは分かんないん ですけど、4プロセスみたいなもの
っていうのをカタカンしていく っていうのが一つの手なのかな。
それは自社内およびお客さんの ほうも含めて両方持ってます。
成果物、最終になっているものと、 あとキーになるマイルストーンとして
重要な成果物っていうのは必ず抑える みたいなところは非常に重要なのかな
と思います。そこってぶれづらくて、 お客さんの中のプロセスとして
見たときも、最後に何が得たいですか というところと、フェイスゲートみたいな
なりそうなものっていうのはしっかり 抑えておくと、そこってお客さんに
よっての差があまり出ないんで、 最低限抑えなきゃいけないところを
最初に抑えていって、そこを標準化 の一番最初のキーにしていくっていうのが
多分一つなのかなと思います。
八木さんのおっしゃっていただいた話って、 これまで話してる本質的なところは
変わってないことになるかなっていう 理解で、やっぱりお客さん理解する
ときに何が共通言語として見れるか って話になると、多分お客さんの業務
になるかなっていうのは間違いない かなと思っていて、それをちゃんと
プロセスを型化していくっていうのが 組織的な引き上げには大事で、
そのプロセスをちゃんと型化していく ときに、どういうアウトプットを
ちゃんと出していきたいんですか っていう、最終ゴール踏まえて
そこから必要なマイルストーン っておっしゃってましたけど、結局
中間成果物、中間のアウトプットって どういうのがあるのかっていうのを
ちゃんと洗い出して、それを我々だと 構造化して、最初アウトプットと
中間アウトプットがどう繋がっていくか っていうのを整理していくっていう
感じになってくんで、それをやることによって 多分組織力はかなり引き上がって
いくかなっていうところですよね。
そういう意味だと、標準化するってなると さらに、我々の活動みたいな
ところのニーズが高まってきたのかな みたいなところもちょっと感じる
型化の実践
部分かなと思ってて、我々ってある種 そういうふうにカスタマーサークスの
リーダーの人をサポートしていく とか、CSの組織を強くしていく
っていうところに貢献していく 活動してるかなと思うので、要は
リーダーをサポートしていく存在 になってるかなと思うんですよね。
その時に、どういうサポートや活動 っていうのが必要なのかって話に
ちょっと移ってきたいなと思います。 被対地調整の話って、さっき言った
ように顧客理解ベースで、そこの レベルの引き上げっていう話は
出てきたんで、やっていかなきゃ いけないんですけど、やっぱり
仕組み化してくってなったら、それを ちゃんと引っ張ってた人のナレッジ
とか知見とか経験っていうのをうまく 標準化していかなきゃいけない
っていう話があるかなという一方 ふで、やっぱりそういうリーダー
の人って孤独になりがちというか、 差があるがゆえに巻き込んでいろんな
人を味方にしていかなければ難しい かなと思う部分もあるんですよね。
だからリーダー一人で全部打破できる わけじゃないと思ってるので、どんな
サポートとかリソース活用とか もしくはツール活用、この辺りの
必要性っていうのがこれからますます 問われてくるかなと思うと、マルザさんは
今は独立されてますけど、以前は カスタマーサクセスの現場リーダーで
この辺り引き入ってた経験もある と思うので、実体験ベースでこういう
ふうに型化推進していくときに、どんな サポートとかリソースとかツール
とか、もしくはこういう活動を自分が 推進していくときに決め手になった
こととか、改めて伺いたいんですけど。
やっぱり思考の壁打ちみたいな ことをしてくれる方と、型を形に
してくれる方、あとはその型みたいな ものを運用アップデートしていく
ための顧客の動きを可視化するような ツールと、その型を実践に落として
いくときに、実際に実動していく ような方がいるといいなという
のは思います。
思考の整理、壁打ちみたいなところは、 結局、自分はたまたま過去の直
歴でデータ分析、マーケティング 営業、コンサル、人材育成みたいな
ちょっとCSに必要そうな知識を割と 広範囲に薄く広くかじってたので
なんとなく分かる部分がちょこちょこ あったんですけど、足りない知識
とか経験もいっぱいあって、お客さま をどう成功に導いていくか、どう
型を作っていくかとかで、僕は別に 業務標準化のプロでもなければ、
全職の小売マーケティングのプロ でもないので、やっぱりそういう
いろんな知見を持った方と、今お客 さんと接しててこういうふうに
カタカオしていきたい、こういう ふうに成果を出していきたいんだ
けど、どういうふうなアイデアが あるんですかね、みたいな。
脳みそが全然足りないので、そういう ところの壁打ちでアイデアなり
ヒントなりフィードバックなりを いただけるとすごくいいなと思
いましたし、僕の場合は実際、社内 にちょっと違う分野ですけど、もの
すごいいいサポートを壁打ちをして くださる方がいたので、そこがすごく
助かったなというのはあります。 あとは、そういう壁打ちを経て
いい型を作れたとしても、それって あくまで構想ベースで、そこから
何かドキュメントに落としていく とか、コンテンツに落としていく
とか、ルールを作っていく、多部署 とコミュニケーションをしていく
とか、やっぱりお客さんをケアしながら、 そういういろんなものを同時並行
で進めていかないといけないんですよ ね。やっぱり描いた型をきちんと
形にしてくれる、実装してくれる 人なりサポートなりツールなり
サービスなりっていうのはすごく あったら嬉しいなっていうのを
思ってます。やっぱり実体ベース でコンテンツとか、そういうレベル
で型があったとしても、結局リーダー 一人だと生産性向上の度合いが少ない
かなって。やっぱり型化することの メリットって人がたくさんいた
ほうが成果は出やすいって。あとは 作った型を実践どんどんしていかない
と猫に拒んになっちゃうので、 せっかく作った型をどんどん実践
していくようなチームなり人なり っていうのはすごく欲しいなっていう
仕組みとリソースの運用
のは感じましたね。あとは、これ ものすごく実体験であった課題
感なんですけど、採用頑張って採用 した結果、鬼のように育成コスト
が実業務に乗っかってきたっていう のがあるので、新しく増えた人の
エンプロイヤーオンボーディング なり育成なりっていうのが、高
数ゼロで最短で実現される外部 ケア、外部サポートみたいなのが
あったら、つらい体験の二の舞い にならなくていいなって思います
ね。あと、作った型っていうのを 運用アップデートしていくための
顧客動向を可視化するツールの ところで、型を作ったとはいえ、
それってあくまでも仮説ベースで 合ってるかを検証しないといけない
し、仮に合っていたとしても、お客 さんとかプロダクトって進化変化
していくので、それに応じて型なり 戦略なりってどんどんアップデート
していかないと、チューニングして いかないといけないと思うんですよ
ね。それをより深く深くきちんと 正しく正しくやっていくためには、
顧客理解のアップデートが必要だ と思ってて、ただお客さんに聞く
ことって、お客さんが話すことも 訂正的な場合、曖昧な場合、間違
ってる場合もありますし、自分の そこから得た理解、解釈も間違ってる
場合もありますし、バイアスも かかりますし、データが全てだとは
言わないですけど、でもデータを 見れば、大体のことがものすごく
正確にファクトベースで分かるんですよ ね。なので、お客さんのツール
の活用状況だったり、出ている成果 だったり、いわゆるヘルススコア
みたいなもの、CSのタッチスコア みたいなものとか全部含めて、やっぱり
お客さんの動き、お客さんとの やり取りのアクションとか、そういう
ものが全部数値で見える化されている と、その型がどれくらい有効だった
のか、型のどこを改善すればいい のかとか、そういう仮説を作るところ
検証するところっていうのがすごく 早く、かつ定量的というかロジカル
というか、正確に分かれて、そういう 顧客理解を深めるためのデータ
なりツールなりがあった上で、型 を作る、アップデートするができる
と非常に楽だなというのは、結構 感じていたので、それはやっぱり
あると強いなと思います。
おだしょー 最後の実践の部分っていうのは、
仕組みみたいなものっていうので いうと、プレイブックとかそんな
感じのイメージですかね。
三沢 実践っていうのは、さっきの 話の中で少し混ざっちゃったんですけど、
プレイブックという型を作りました とか、プレイブックに沿って説明資料
とか説明動画を作りました、コンテンツ がありましたっていうのを、結局
その説明動画を送ってくれるCSM とかプレイブックに沿って顧客
をサポートしてくれるCSの担当者 とか、CSのメンバーが実際にいない
と型ってワークしづらいと思って 実行してくれる人、やっぱりどんどん
増えていってくれたほうが型の威力 が発揮できるなと
おだしょー なるほど。ある程度 うまく仕組み化しないと、さっき
マルトさん言った鬼のように育成 コストが増えちゃうっていうこと
になるってことですよね、今の。
三沢 そうですね。
おだしょー ありがとうございます。今 4ついただいて、思考の壁打ち、型化
っていうのをちゃんと実践の形に 仕上げていくところと、そういう
存在、あとはそれを運用するための 仕組みとリソースで実際にして
いくメンバーみたいな感じかな と思うんですけど、マルトさん
の中で実際に社内にメンターがいた みたいなので、思考の壁打ち自体
は前職というか以前の経験でも 助けてくれる人がいらっしゃ
お客さんとのブリッジをするための要件
ったと思うんですけど、例えば 型化を形にしていくとか、顧客
どうかを可視化するとか、その辺り っていうのはサポートとかあって
実際こうやったってお話だった のか、あればよかったのにっていう
感じだったのかって、実際どうだったん ですか
三沢 型を作る上での思考整理みたいな
ものをサポートしていただいた のであって、型化自体に対しては
やっぱりサポートは直接的には なかったので、そこのサポート
はやっぱり欲しかったなと思います。
おだしょー なるほどですね。
三沢 ただやっぱり型を作っても、それが
頭の中とかフォルダの中に埋もれ ちゃったとかそういうのがあった
ので、自分の頭の中とか手元のどこか の資料とかで、こうすればうまく
いくか、こうやっていこうっていう ルールなり、価値パターンなり
作っていくっていうところまでは ギリギリできたかなとは思います
けど、やっぱり何かしらそういう 型を作るサポートがあったほう
が、半分とか三分の一とかもっと 早いスピードでそれが実現でき
たなというのは思いますね。
おだしょー なるほど。可視化のところ はさっきヘルススコアみたいな
お話もあったんで、実際はヘルス スコアでいろいろ試行錯誤しながら
運用を成熟させていったとか、そんな イメージですかね。
三沢 そうですね。いろんなデータ を見ながら、あとはお客さんの
声も実際に聞きながら、どうすれば お客さんが活用度が進むか、課題
が解決できるかとか、そういうの をいろいろ練りに練って、実際に
お客さんに試してみてっていう のを繰り返しながらのイメージ
ですね。
おだしょー 今のマルチさんのお話 だと、ほぼやってきた経験から
いうと奮闘されてたっていう感じ かなと思うので、今の話で言えば
このカタカナのサポートみたいな ところっていうのをもうちょっと
できる存在があったら、より立ち上がり が早くなったのにっていう感じ
ですよね。指向の株打ちみたいな のは本当にメンターなんで、そういう
相手って社内にいるのはすごい 理想的なんで、そういう人たちは
必要ですし、実際にそこで自分の モヤモヤしたものをある程度青
写真にして、その青写真をちゃんと 設計して実行できるような形として
成果物作って、その成果物を元に 実際運用して、どういうふうに
それがうまく機能するかどうか っていうのを確認して、実際に
それを回す人員の人も入れてみたいな 感じだと思うんで、それぞれと
同時並行的にやりながらっていう 部分はあるのかなっていうところ
で、そうすると大変だっていうのは 話聞いてても感じるんですけど
この辺りも我々の話してきた中で 言うと、1人だと厳しいっていうのは
まさにそうで、仕組み化する上でも やっぱフィードバックってすごい
大事なんだなと思ってて、実際に 自分の考えてる内容っていうのを
ぶつけられる相手がいるっていう ほうが、出てくるアウトプット
多分今回で言うと型化していく っていう基本的な活動の設計図
になる部分っていうのは1人終わり で作るよりは一緒に作るとか
まるささんの場合は壁打ちして 頭の部分の整理は手伝ってくれた
人はいたけど、実際に落とし込む ところはCSの組織の中でやってた
と思うんで、そこのサポートできる 人がいたら心強かったのかな
と思います。それだとフィードバック すごい大事だなって話したし
カスタマーサクセスの重要度とブリッジの役割
あとやっぱりそういうのってそれぞれ 専門家とか外の人使ってでも
立ち上げ早くしていくっていうことが より求められていくっていう
感じになるのかなと思います。
ヤギさんにまたモデリング観点で 少し聞きたいんですけど、リーダー
が今こういったやらなきゃいけない こと説明してもらったときに
品質担保が難しいような活動の 肝になるみたいなところとか
もしあればどんなふうに捉えて いたり見ていらっしゃいますか
ヤギさん モデリング観点という よりはちょっとプロセス改善
お話するんですけど、諸説あるんで 信憑性がどれほどあるかは
あるんですけど、ある程度その 専門的にプロセス改善のカタカを
支援するとか、型を用意するとか それを形にするとか、ツールで
サポートするとかっていう人の 人員比率が言われてるのがあって
2パーセントとか5パーセントとか なんか言われてます。価値創造に
関連する人たちの人員に対して それぐらいはいるよねって言われて
多分ある程度大きな会社さんとか おそらくオプスみたいな人たちが
いて、その人たちが社内でできる と思うんですけど、そういう形だ
と思うんですけど、それでない場合 はおそらくライブリポース使う
とか、少なくともそういう担当者 みたいな人をちゃんと置くべき
だよね。じゃないと型にならないし 標準化はできないよねと言われて
います。ある意味そういう人たちを ちゃんと用意するというのが大事
で、リーダーにそれを任すっていう のは流石にちょっと乱暴というか
逆に言うと多分ボトルネックに その人がなっちゃうんでもったいない
っていうのが個人的に思います。
顧客理解の重要性とその向上
なるほど
逆にどんどん客先行ってほしい し、どんどんカタカナになるため
の情報をガンガン集めて、どんどん 仕事回してもらったほうがいい
ので、その人をカタカナをさせる ためのエネルギーに使ってはいけない
という感じかなとは思います。ちょっと 質問の趣旨とは外れてるかもしれない
ですけど
いやいや、まさにその辺りのプロセス 改善っていうのも、結局は業務自身
をどういうふうに変えていくか っていう話なので、繋がってくる
かなって。今いただいた2から5% っていう数字のお話って、20人の
組織いたら1人ぐらいそういう役割 持たないといかんですよっていうこと
ですね。
っていうことですね。
なるほど
できれば1000人って言われてます けど、兼務されちゃうと多分だいたい
あんまり良くないっていうパターン
そうですね。兼務は良くないですよね。 だからやっぱり20人いないような
やっぱり組織とかで本質的な部分 で価値提供してくっていうことになった
場合は、チーム自身やっぱり伴奏 してくような存在。中に作るよりは
外に求めたほうが、ひょっとしたら そのフェーズだったらいいのかもしれない
ですね。
そうですね。
なるほど。その辺り試行錯誤とか 必要な部分っていうのは見えてきたん
ですけど、結局そういうのやって ある程度型とか形作っていった
ときって、どういう状態になるのか っていう話をちょっと次に移り
たいんですけど、これはさっきマルザ さんもおっしゃってた、結局プロダクト
フィードバックとか要求水準上が ってて、CSの活動でどういうところ
にフィードバックかけていきます かっていうところかなと。それまでは
基本的にはお客さんのやりたいこと っていうのをうまく翻訳して伝える
っていうところで、代弁者みたいな 部分もあったんですけど、それが
もうなるべく組織全体でプロダクト の改善にすぐ直結するような形で
うまく設計していかなきゃいけない っていう部分になっていくとしたら
我々の文脈の会話で言うと、ここって 結局、お客さんとのハブになるっていう
意味でブリッジって言いましたけど、 ブリッジしていかなきゃいけない
っていう話で、それお客さんとの ブリッジかつ、社内組織のブリッジ
にもならなきゃいけないよねっていう 話をしてきたかなと思います。
結局、ブリッジしていくっていう ところの重要度って、ますます
今の話聞いてても上がってきてるんだろう なっていうふうに思っていて、
そうなったときに、ブリッジをする には何必要ですかって話も、前回
少し触れてるんですけど、やっぱり 共通言語を作っていく必要があるよね。
あと、共通言語を作って、それを 常にアップデートしていかなきゃ
いけないよねって話があって、それは 顧客理解の解像度をちゃんと高めて
いって、常にどういうゴールを置いて、 何のためにそこをやるべきかっていう
のを、組織内で共有できるように していかなきゃいけないと。
そういう活動を継続していくと、 ちゃんとお客さんとの信頼関係
が生まれて、強いカスタマーサクセス のチームになっていくみたいな
話があったかなと思うので、ちょっと まだ2つ伺いたくて、ブリッジする
っていうカスタマーサクセスに対する 期待っていうのは、変わらずあって
さらに高くなっている状況かな と思うんですけど、どうでしょう
っていうのが1点目と、あとは、そういう 活動をするベースの担保になるのって
突き詰めると、お客さんの業務を 正しく理解するっていうことで、
顧客理解の解像度を高めていくことに ベースは繋がるんじゃないかな
と思うんですけど、そこに関しては、 どういうふうに今の現状を見て
捉えてますかっていう、2点の質問 あるんですけど、いかがでしょうか。
寺田 そうですね。やっぱりここは、
ますますCSだけで完結しなくなって きている。より組織全体でカスタマー
セントリックな文化を形成して、 カスタマーサクセスをしていく
っていうのが、当たり前に求められる レベルまで来ている。
そうで、それをどうやって実現するんだ ってなったときには、本当にその
ベースに、うちのお客さまがこういう ものを求めている、こういうところに
苦しんでいる。こういうことをした くて、そのためにこういうような
プロダクトの使い方なり、業務なり、 生活なりの組み込み方をしているから、
うちはもっとこういうアシストを していかないといけないんだっていう
多分、会話をしていかないといけなくて。 サイモンシネックでしたっけ。
Yから始めっていう。
ゴールデンサークルですね。
おだしょー それですね。ゴールデンサークル
に基づくと、多分、カスタマーサクセス がブリッジ組織を築くときに発信
するWhy、How、WhatのWhyが、おそらく うちのお顧客がこう言っている
からとか、うちの顧客をこういう 姿に導くためにっていうところ
なんですよね。なので、本当にその Whyが最初に来るっていうのと同じく
顧客の話、顧客の理解が最初に来る っていうのはないと、CSが組織の
ブリッジになっていくというのは 不可能だと思うんで、そういう意味
でもものすごく顧客理解が基盤 になっているだろうなとは思います。
今、まとめて2つの回答
いただいたって感じで、やっぱり 顧客理解をアップデートし続け
なきゃいけないっていうのは、ますます 重要になってきてるっていうところ
かなというので、そこに関しては もう変わらないんだなっていう
ブリッジ組織の特徴
感じですね。ヤギさんにもこの辺り の組織の立て付けみたいな話、
どういう組織を作っていくかみたいな ところ、割り分担みたいな話っていう
と、プロセスから見たときも、多分 最適な配置とか望ましい形って
見えてくると思うんで、ブリッジ 組織に対してどういうふうに見立て
られてるのかなみたいなのをちょっと 伺いたいんですが。
ブリッジ組織の特徴があるかと 言われるとあれなんですけど、組織
の形として見たときに不整合が起こる の、目的と実際求められている成果
物が不一致するとうまく回らない なので、特にブリッジしなきゃ
いけないっていうミッションが与 えられてる組織だと、よりそれが
強くなると思うんですよ。ここで 言うと、顧客さんと開発とか社内
の別の部署みたいなものなんですけど、 その間をブリッジしようとすると、
それぞれの目的に対する業務プロセス がそれぞれ別々にあるので、それぞれ
別々の成果物がいてっていう状態 になるので、しっかりとどういう
目的でどういう成果物を生まなきゃ いけないかという設計がなされた
状態じゃないと、片方によったり とか矛盾することを言ったりとか、
そういうことが起こり得る可能性 があるので、設計上すごく難しい
だと思いますが、ブリッジ組織という ものを作ろうとするっていうのが。
もちろん擦り合わせて決めていく 部分とか、人系で何とかしていく
部分はあるかもしれないですけど、 組織論的に言うと、その目的と
何を生み出す、成果物を生み出す かというところと、それに基づく
人の動きのための評価基準みたいな ところも含めての設計をちゃんと
しないといけないっていうのが 大変そうだなと。
ここって多分今のいただいたように 目的とアウトプットがぶれると
うまくいかないっていうのは 多分全てに共通するところだと
思うんですけど、ブリッジ組織の 話で言うと、多分CSってもともと
お客さんのサクセスのために活動 するっていう、お客さまの成功
っていうのが目的にあるっていう のは、大きい目的としては変わんない
と思うんですけど、その目的達成 するための中間マイルストーン
みたいなところが、ブリッジって いうことが明確になってきてる
と、従来であると俗人的対応でも 済んでたところが、いやそれじゃ
済まなくなってきてるっていう、 その辺りでどういうふうに変えて
いくんですかっていうところが ブリッジ組織としては今後求め
られていく形とか、ブリッジ組織 ちゃんと立ち上げるときに必要
になるポイントっていう感じですよ ね。
顧客理解
おだしょー ありがとうございます。
ちょっとおさらい会になったら すごいこれまでの話もあるんで
だいぶボリューム増えちゃいました けど、結局リーダーの人がそこを
うまく推進していくのもリーダー 一人じゃ無理なんで、やっぱりサポート
していく存在があって、組織として 引き上げて活動していかなきゃ
いけないだけれど、要求水準は 上がってるっていう変化はあります
が、ペースは変わってないっていう ところなので、すべての活動の前提
って、やっぱ顧客理解が非常に大切 だと。お客さんの業務どう変える
っていうところから、CSっていう か、サービスやってる企業の活動
も決まってくるので、お客さんの 理解をちゃんとどういうふうに
するかっていう話は整理していく 必要があるし、それを踏まえた上で
ブリッジ組織ってどう作っていく かっていう話かなと思うので、顧客
理解とブリッジ組織っていうのは それぞれまた詳細に議論できれば
なと思います。ということで、次回 は顧客理解っていうところにフォーカス
してまた話せればと思いますので お願いいたします。
おだしょー お願いします。
