カスタマーサクセスの活動の起点
今回は、強いカスタマーサクセスチームを作るにはというテーマで話してきた
第2回目になります。初回は、やっぱり顧客理解っていうのが、
カスタマーサクセスの活動の出発点になっているというところは確認できた回だったかなと。
その上で、そこをベースにしながらブリッジしていくっていう話を
前回までしてきたかなと思ってます。今回は、改めて顧客理解というところを
話していきたいなと思ってます。
顧客理解って、我々も断るごとに大事ですよ、大事ですよっていうことは言っていて、
それだけ顧客理解にこだわるのかって話なんですけど、ひとえにカスタマーサクセスの活動の起点になるから
ここがちゃんとしてないと、その後の活動っていうのもうまく機能しないよねっていうところがあるんで
これだけ大事ですよっていうふうに言ってるかなと思います。
カスタマーサクセスの顧客理解って、今の現状でいうと
俗人的になってるっていう課題もあるよねっていうところが、これまで話してきたところかなと。
それはやっぱりチームとして強くしなきゃいけないし、今の状況だと今後2,3年とかで
さらに上のレベルとして、プロダクト範囲まで直結させるように
顧客から得てきたフィードバックを素早く製品繁栄していくっていうところまで
レベルが上がってきているので、そのベースの顧客理解がちゃんとできてないと
結局はそういった活動をより高速にさせていくってことも難しいでしょうと。
じゃあその顧客理解できてますか?みたいな話とかも踏まえて
少し会話していきたいと思うんですけど、一言で顧客理解って言っても
そんなに簡単じゃないかなっていうところがあって
基本的に顧客理解って足りてるっていう状況がないものかなと思います。
顧客理解っていうのはある種、自分たちが見たその顧客の視点の切り取りだし
それはその瞬間なので、常に変わっていくっていう意味で終わりがないので
取り組み続けなきゃいけないよねっていうところまでは
これまでも話してきたところなんですけれども
その辺りの原因とか顧客理解っていうのを
どういうふうに高い状態を維持しながら進めていくかっていう話をしていきたいなと思ってます。
そういう意味だと顧客理解を高めていかないといけないよねっていう話があって
この辺りもいろいろトピックが出てきたとは思うんですけれども
結局お客さんの業務どこまで個別具体にちゃんと認識して把握できるかっていうところの
深掘りするっていうことも大事なのと
顧客業務の明確化と構造解明
あとは我々の中だと現状の見えてるものと見えてないつながりっていうのを
明らかにしなきゃいけないよねって言っていて
これは何かというと見えてるものっていうのはお客さんの状態なんですけど
ただお客さんのその状態を引き起こしている原因って何に起因するんだみたいなところの話とか
この辺りって基本的には見えてないところなんで
それを明らかにしましょうっていう話があって
じゃあその顧客業務を明確にしていったときに
そのお客さんの業務の状態といわゆるその状態を作り出している原因を作っている構造
ちょっとややこしいからしましたけど
業務の状態と構造ですね
これを明らかにするところっていうのは我々の中だと
どんなアウトプット作ってるかが大事ですよ
そこを見ることによって状態だけじゃなくて構造も明らかになるので
より深い解像度で顧客理解ができるよねって話をしてきたかなと思います
結局生化物支店っていうのをちゃんと取り入れると
そこの解像度深まるよっていうのが我々の提案の内容かなと
ここって業務モデリングの観点から出てきた話かなと思います
なので八木さんにもう一回改めて生化物支店の重要性っていうのを
説明してもらえたらと思うんですけれども
そうですね まず生化物に集中するという話をさせてもらってたんですけど
これってある意味お客さんのことを理解するのって
お客さんと同じ業務をやるのが一番いいんでしょうけど
でもそうは言ってられないじゃないですか
要素で抑えなきゃいけない要点みたいのが多分必要で
それの一つの見方が多分生化物なのかなと思ってます
何でかっていうと 例えば同じような業態だとして
例えば同じ見積もりを作りますって言ったときに
見積もりツールとかでデータを入れたらできますってパターンと
一個ずつ全部計算して出しますってパターンと
いろいろあると思うんですけど 結果見積もり書を作るっていうのは一緒じゃないですか
その業務の要点は見積もり書をちゃんと作りますっていうのは
要点になっているはずなんで その要点を抑えるという
まずは生化物をちゃんと見るというのが非常に重要で
それがどういう意味を持っているのかも含めて
見ていくっていうのが多分一つのポイントになるかなと思います
かつ生化物ってある意味物があったりするので
例えば帳表があったりするので 理解はしやすい部分はあるんですけど
もう一点堀さんに言っていただいた構造の話
原因って構造から出てくるので 構造を見なきゃいけなくて
その構造のところは生化物の関係性でと我々的には考えてて
それが業務プロセスになっていて 業務プロセスって形がないんですよ
作業の連鎖なので 形がないものなので
どうにか表せないと理解もできないし
他の人と会話もぶれちゃうっていう問題があるので
そういった意味合いで 生化物とその関係性というのを整理して
構造化して理解してあげるというのが
顧客の業務を理解するという意味合いで 有効なんじゃないかなというので
お話しさせていただいたかなと思います
おだしょー 顧客さんとコミュニケーションを深めて
業務としての理解っていうのを擦り合わせるために
こういうのが必要っていうところかなと
形がないと皆さんの頭の中でしゃべったものって
言語化のシリーズでも言いましたけど
同じリンゴっていう言葉を言ったとしても
それだけだと同じリンゴをイメージしてるとは到底思えなくて
解像度を高めていかないと共有化できないって話で
結局 前提っていうところをうまく揃えていくっていう意味でも
生化物というお客さんが達成したいと思っている最終的なものを
作るのにはどういうものを積み上げて
成果として達成していかないと
それができないんですよねっていうのを表すっていうことが
お客さんとの前提を揃えるため
もしくは顧客理解を深めるために
我々的にはアプローチとして取ってるっていうところで
それが今 やぎさんの言ってくれたように
生化物にこだわるっていうのは
こだわるとコミュニケーションが非常に取りやすくなる
という話をこれまでしてきたかなと思いますけど
こういった生化物みたいな話って
普段のお客さんとの会話とかヒアリングの中でも
活用するっていう話はそんなにないとは思うんですけれども
これのメリットって さっき言ったように
単純お客さんが何か問題として言ったことだけじゃなくて
その問題を言った裏側の原因って
多分 こういうことなんじゃないですかねとか
業務の流れとか構造がこうなってるとしたら
こういうとこに困りそうだと思うんですけどとかっていう
より突っ込んだコミュニケーションとか議論が
測れるっていうところが大きいメリットかなと思うので
この辺りって結局 業務理解の解像度をアップデートするっていう
活動をしてるっていうところかなと
小個人のCS担当の方っていうのは
相対してるお客さまのことを理解度は高かったりするんですが
より深く広くお客さんのこと 業界のこと
お客さんの業務のこととかを
やっぱり理解しきれないっていうのは
課題感としてはあると思うので
そういったプロセスを理解するという意味で
お客さまが最終的にサービスを通じて
どういう成果を出さないといけないのか
逆にCSとしてもお客さまに対してどういう
支援プロセスの先にある成果を届けないといけないの
っていうところをきちんと意識して
全体像を整理 把握していただくっていうのは
大事なことだと思うので
そこはすごくやるべきだし
やる価値はあるんじゃないかなと思うんです
お客さんの困ってることをただ聞いてるだけ
とかになっちゃうと
結構解決策とかなくて
とりあえず話を聞いて
一緒に悩んでしまうみたいなことも
あるのかなと思うんですけど
今回みたいに構造をある程度
事前に眺めて理解しておくことで
そこに対してこんな取り組みしたら
より良くなるんじゃないかとか
こういう活動とか提案すると
お客さんってより成果出したり
喜んでもらえるんじゃないかっていう
当たりがつきそうな感じもあるんですけど
その辺についてはどう感じますか
そこの当たりがすごくつけやすいと思いますし
お客さんによって多分そこの答えって
変わってくると思うので
パターンみたいなものを全体像があることで
すごくつかみやすい
判断しやすいっていう状態になるんじゃないかな
と思います
聞きすぎちゃいけないよねと
我々思ってはいるんですけど
お客さんのこと聞きすぎるっていうのは
そうなりやすい部分が実際あって
どういうことかというと
それに陥っちゃうと
客によって成果が出ないという可能性があるので
なるほど
私の経験上もあるんですけど
新人を直接突っ込んだときにうまくいくのは
やはりお客さんがしっかりしてるとか
お客さんと一緒に行ってる
例えば上司とか先輩にあたる人が
しっかりしてるとかっていう人が
入らないといけなくて
何も分かんなくて入るとやっぱり
そのまま聞いちゃうんで
普通に考えると
そういうところが
そういうサポートできる人というか
そういう状態にならないといけないのかなとは
思いますね
それが例えば
顧客理解みたいなもの
モデリングみたいなものがあって
サポートできるんであれば
それはそれでいいのかなと思いますし
そういう感じかなと思ってます
そうですよね
解決策の話も少しあったと思うんですけど
結局把握してる内容っていうのが
ちゃんとこれ大事だみたいな判断とか
含めてやったときって
ある程度ちゃんとその構造見えてないと
言われたことにそれぞれ
100パーセント反応してたら
どれが大事かよく分かんなくなるみたいな
そういう話もあるかなと思って
結局何が重要かっていうのを
ちゃんと見極めていかなきゃいけない
やっぱりこういうふうに
ちゃんと正しく顧客理解しないと
正しい解決につながっていかないって
話もあるかなと思って
行き当たりばったりっていうと
言い方悪いですけど
お客さんの言われた
こととかつぶやいたことに
善ひろいとか
全て打ち返すみたいなやり方っていうのが
必ずしもいいわけじゃないですよね
っていう話が
我々さんにはしてきたかなと思ってて
結局正しい解決してますかっていう
裏返しでもあると思うんですよね
全て打ち返すことが正しいんでしたっけ
とかそれが本当により良いことになるんですっけ
っていうところって
そうじゃない
そうなったときに
効果が高いお客さんに対する
解決策を提示するってなったら
やっぱりお客さんがやってることとか
取り組んでる内容で悩んでたり
課題になってるとこ
ここですよねってちゃんと見えないと
打ち手が打てないので
その中で正しい打ち手に対して
やっぱり自信が持っていないと
お客さんの言うことに対して
全部拾いに行っちゃうっていう
現象が逆に言うと
起きちゃうっていうことじゃないかなと思うんですね
顧客理解の重要性
打ち手に関してある程度自信持っていれば
その解決よりも
こっちのほうがいいんじゃないですかっていうことを
逆に提案するっていうことも必要で
そういうことをやるってことが
ゆっくりお客さんとの信頼関係を作っていくのも
非常に大事ですよねっていうところですよね
この辺りは
多分これをちゃんと意識してやりましょう
っていうところで
話してたところなんですけど
結局ここって
顧客理解をした上でないと
正しい解決につながっていかない
っていうところかなと思ってます
なんで
ここから少し
八木さんにも前話してもらった話があるんですけど
こういう議論の中って
解決する話と問題発見する話が
混ざりがちなんで
ちゃんと分けましょうみたいなことも
言ってくれてたかなと思うので
改めてになるかもしれないですけど
結局問題と解決を区別するっていうのは
どうして大事なんだっていうところですよね
問題と解決の区別
ちょっとその辺りも含めて
解決に至るっていうところのアプローチの踏み方
顧客理解をした上で
どう進めていくかってところを
コメントもらえると
問題を見つける行為と
解決するのは当然違うんですけど
混ざりやすいですよねと
解決策が頭にこちらはあったりするんで
それに誘導しちゃう部分も結構あったりするんで
結構難しい点ではあるんですけど
やっぱなんか真摯にどういう問題なのかという
向き合うタイミングと
それをどうしたら解決するのかというタイミング
同じ人でも時間分けるとかしたほうが
より良いかなとは思っていて
一般論になっちゃいますけど
一方で実は問題をしっかり把握できると
8割ぐらいは解決してたりすることが
多いかなと思ってるので
できれば問題をしっかり事実を捉えていくっていうほうに
エネルギーをかけるほうが
顧客理解につながりますけど
ちゃんと理解するっていうほうにエネルギーをかけたほうが
少なくともサービス提供する側とすると
いいのかなと思います
自分たちソリューション持ってるんで
やっぱそっち側に軸足たがるというか
置いちゃうんですけど
ちょっと横に置いといて
できるだけ問題を理解するというほうに
集中するというほうが
お客さんにとっても嬉しいですし
おそらくそれが信頼関係にもつながると思うんで
解決策にはとらわれずに
いいんじゃないかと思います
今の話でもやっぱり
混ざりやすいのって
自分たちにソリューション持ってるがゆえ
っていうところだと思うんですけど
基本的にはここって
解決策に関しては
事前にいくつかパターンとか
こういう悩みだったら
こういうソリューションが喜ばれるって話は
もちろん用意してしかるべきかなとは思うんですけど
そういうソリューションがはまるかはまらないかを
ちゃんと精査するためには
お客さんが何に対して悩んでいて
それを生み出してる原因はこれであるっていうのを
お客さんとちゃんと合意できてないと
結局そのアプローチとか解決が
悩みを解消してもらうものになるんだっていうところに
たぶんたどり着かないと思うので
やっぱり課題把握と
その問題の真因をちゃんと
共有できるっていうのが
やっぱりいいのかなっていうところで
そういったところを逆に言うと
行っていく必要があると思ってて
なので今ヤギさんが言ったように
お客さんの話聞いたら
ソリューションとしての
自分たちの誘導させたがってくる気持ちも
分からんでもないですけど
お客さんの悩んでることに対して
今の自分たちのソリューションだと
全て解決できないっていうことになったところが
分かったら
逆に言うとどうするんですかみたいなところっていうのも
お客さんと対応するときの
信頼関係の作り方としては大事かなと思うと
顧客理解の組織への適用
あえてそこは今はできませんっていうのを
ちゃんと伝えるっていうことも
真摯な対応って意味だと大事だと思うんですよね
このあたりの信頼関係のところって
ピンやノーっていうところの
勇気も必要なんじゃないかなっていうところを感じるし
そういう話してきたと思うんですけど
その辺って丸さんの感覚とか経験で言うと
改めてどう思います
お客さんにとって一番正しい答えを提示していく
お客さんにとって一番プラスになる道に
引っ張っていくっていうのが
ゆくゆくは多分成果につながっていくと思いますし
やっぱり正しい道に導いてくれて
成果を出させてくれるっていうのは
一番強固な信頼関係を築けると思いますし
相手の言うとおりで動いてて
失敗して謝るよりも
こちらがお客さんのためになると思って
相手とは違う意見で導いて失敗して謝ったほうが
それはそれで信頼につながると思うんですよね
やっぱりそこはきちんと黒なら黒 白なら白っていう
相手の意見も組みつつではありますけど
正しいほうに導いていってあげるっていうのは
すごく大事かなと思ってます
この正しいほうに持ってく導き方っていうのは
これの参加者にも言ってましたけど
結局コンテクストを大事にしながら
やっぱりお客さんにそうだよねって思ってもらう話とか
例えば丸さんが言うんだったら試してみようかとかっていう風に
言えるところまで持ってて
そういう意味でやったけど失敗したってなったら
たぶんその失敗って
ある種この仮説じゃなかったってことが証明できるっていうところで
それ自体は大きな意味があるし
信頼関係を生むっていう意味でも
単純に言われたことをやるよりは全然大きいかな
そこって勇気いると思うんですけど
提案していくっていうことは本当は求められてるし
そういうことをやってほしいって思ってるお客さんも
実は多いのではないかなっていうふうに思うんですけど
ここはそうだとまさに思います
あとはお客さんがどっちを求めてるかっていうのも
把握するというか
掴む必要もあるかなとも思ってて
どこかの大学の教授が
ドリルを売るな穴を売れっていう話があるけど
それは大きな間違いだった
お客さんはかっこいいドリルを求めてるみたいな話をして
結構受けたことがあったらしくですね
いろんなことを考えて
かっこいいドリルが欲しいっていう人もいるかもしれないと思うので
そういうのもある種に極めは時には必要なのかな
かっこいいドリル穴が欲しいんだったら
穴開けたほうが本当はいいよねっていうのが
筋ではある話ですよね
ただ今おっしゃったように
ロジックだけでご了承しても良くないよねっていうところの話は
CSならではのタイミングとか
その状況を見極めながらやっていくっていう
現実的なところの話も非常に大事かなっていうのは
おっしゃるとおりですよね
じゃあちょっと一旦顧客理解の話って
結局お客さんの解決とか課題解決
信頼関係を築くためにいるから
これだけ話してきたんですけど
結局この顧客理解っていう話って
これをお客さんと作っていくことによって
自社の組織強化にもつながるかなと思いますと
お客さんがこうなってますとか
お客さんがこういう課題悩んでますみたいな話って
さっきの成果物資生の話の中でも何回か出てきたんですけど
結局 型化していくとか
組織としてその活動できるようにしていくっていう
ヒントや気づきみたいなものが
整理されていくところになるかなと思うので
それはやっぱりお客さん理解を通じて
こういう取り組みしなきゃいけないよねっていうところを
明確にしていかなきゃいけないと
そのときにその取り組みって
誰がどういう役割でやるんですかみたいなことって
社内を巻き込んでいかなきゃいけないっていうところがあるかなと
それはカスタマーサクセスが結局チームとして
社内の組織を引っ張っていって
お客さんの悩んでる課題解決っていうところを
ちゃんとリードしていくっていうことを
求められてるところかなと思うので
ここの組織理解っていうのも非常に重要かなと思ってます
まるささんにちょっと伺いたいなと思うのが
こういった要は顧客理解を通じて
組織理解を深めながら
実際にアクションに落とし込んでいくみたいなところって
まさにブリッジだと思うんですけど
この辺りの取り組みのトリガーとか
実際に社内巻き込んでいくっていうときに
結局顧客理解が共通言語になっていくんじゃないかなと思うんですが
基本は会社の中で一番経営に近いようなポジションで
かつ顧客理解が深い組織がやっていくといいのかなと思います
経営にどれぐらい近いかみたいなのは
組織のパワーバランスもあるので
あとはフェーズもあるので
会社によっては営業マーケットのほうが強いときもありますし
カスタマーソフトさんは強いときもありますし
やっぱり顧客理解を深めることで
サービスの質が上がるであったりとか
顧客支援の質が上がり
結果として満足度であったりとか
社内業績アップのきっかけになるっていうのを
まずは経営から理解してもらうっていうのが必要だなと思います
そうじゃないとやっぱり売ってこい
支援してこいっていうふうになってしまうので
きちんと顧客理解を深めて体系化して
組織の中に伝播していくっていうのは
単に顧客支援していくとか
単に売っていくっていうだけの行動よりは
プラスアルファ必要だと思うんですよね
まずは経営の理解を得る
顧客理解を得て
広げてどうするのかっていう絵を描いておく
よく分かりましたね
パタって閉じるとすごくもったいないので
顧客の声をプロダクトにどう反映するかとか
CSがどうチームとしてそれを活かして
支援策をアップデートしていくかとか
そこの絵とセットでやっていけるとすごくいいんじゃないかなと
思っております
カスタマーサクセスのテーマで
CSにちょっと寄りすぎちゃってたかもしれないですけど
まさに組織の中でいうと
この部分って経営がやっぱり
その判断というか決断して
進む道に対してちゃんと道筋を立てていくとか
線弁つけていくっていうことをしていく人たちが
主導していくっていうところで
CSが場合によっては
そこを主体で担わない場合もあって
サポートになるっていうのも
組織の状況によってはありますよね
っていうのはまさにおっしゃる通りですよね
この辺りのブリッジの話っていうのは
次回少し詳細に話したいなと思うんですけど
結局どういうアクション取るかっていうのとか
こういうふうな形に持っていくべきだっていうのを
判断する人はカスタマーサクセスじゃない場合も
あるかもしれないですが
お客さんがこういった形のニーズがあるとか
こういうことがやっぱり課題として大きいから
やっぱり事業として取り組まなきゃいけないっていう
事業判断の決定を促していくときに
基本的に顧客理解で得られてきた情報っていうのが
非常に重要だし
そこが起点になるんじゃないかなというふうに
思うんですけど
そこについてはどう思いますか
それはまさにおっしゃるとおりだと思います
本当にやっぱりそれができている会社さんほど
カスタマーサクセスチームの土台になる要素
素晴らしいサービスを作ってると思いますし
やっぱりCSの支援の部分も
お客さまに評価されてるんじゃないかなと思いますね
誰がやるか問題はあるんですよ
理解をちゃんとしてないと
今みたいな経営を巻き込んだ施策を打ったとしても
こけちゃうとか
うまくワークしないみたいな可能性もあると思うので
結局顧客理解をちゃんとした上で
組織理解
こういうことをやらなきゃいけないんだ
こういう取り組みしなきゃいけないんだ
っていうふうに繋がってくるっていうところは
今のお話を伺っても大切かなというふうに感じます
じゃあ最後ここまでいくと
結局はあとはやるだけなんですけど
やるときに武器っていっぱいあったほうがいいですよね
っていう話があって
ここって組織理解まですると
多分あとどういうふうに会計策を作って
実装していきますかっていう話なんですけど
このときにできればより早くて
より効果の高いやり方を取れると
一番いいかなっていう話かなと思います
我々は顧客理解から一気通貫で
施策に落とし込むところまでの話で
成果物資店みたいな取り組みとしてきましたけど
別にこれもツールというか
アプローチの一個のやり方ではあるので
結局いろんなアプローチや取り組みっていうのを
持っとくっていうことは
決して悪いことじゃないかなというふうに思います
なんでどういうアプローチややり方っていうのが
自分たちの中で必要なんだっていうことを
整理していくっていう
手法理解みたいなところの部分も
大事かなと思うんですよね
ここに関しては
顧客理解して組織理解した後に
必要になってくるところだと思うんですけど
この手法理解っていうところ
手法理解とその重要性
ヤギさんモデリングの中の話でも
少し説明してくださってると思うんですけど
このあたりの重要性とか
どういうタイミングでやっぱり
効果を発揮するよねみたいな話
改めて伺いたいんですけどいかがですか
ソフト開発の例で
7Sのカタカンみたいな話を
前回ぐらい語ったと思うんですけど
世の中結構先人がいっぱいいて
いい手法ってあったりするんですよね
もちろんこのまま使えないとか
そういうのはあると思う
自分たちで手法を編み出すことって
あまり意味がないので
使うほうが大事なので
世の中の手法があるんであれば
一回試してみるっていうのが
おそらくよくて
やってみないと
実際は合うかどうか分からないので
使ってみるっていうのが
一番最初にあって
その上で合わないならやめるとか
この場合だと合うよねとかっていうのを
見せられていくっていうのが
非常に重要かなと
研究者でもあるのでちょっと思ってて
私的には生活物で見たほうが
いろんなものを試した上で
使いやすいなというので
お話はしてますけど
それは私のメタ側面から
および私が適応してる範囲での話でしかないので
ある意味いろんなものを使ってみる
っていうのがいいのかなと
少なくとも自分たちで作ることに
あまり多分意味はないというか
みんな頑張ってやってきた昔の知見があるので
それは使おうぜっていうぐらいのほうが
楽かなと思いますので
使ってみて理解していくというのが
非常に重要かなと
試してよかったら
どんどん取り入れるぐらいの感じで
やっちゃいけないのは
車輪の再発明みたいな話ですよね
もうあるのに
同じようなの頑張って作っちゃったったら
非常にもったいないんで
この辺りその意味だと
深く取り組む必要が
どこまであるかはあるんですけど
ある程度のリテラシーとか
一般的知識の部分としては
ちゃんとこういうことに対しても
アンテナ張っていく必要があるかなと
思うんですけど
この辺りの主法に対する
感度とかアンテナの張る部分に関しては
マラさんはどんなふうに
捉えていますか
海外から来ているカスタマー作物に関する
何かの主法であれば
もちろんある程度皆さん
感度高いと思うんですけど
こと業務モデリングとか
コンサルティングの領域とか
マーケティングの領域とか
他領域から学べることも
たくさんあると思うんですが
そこにやっぱり踏み込んでいくと
アンテナの感度が一気に落ちてしまうので
そういうもったいなさがすごくあるな
というのはちょっと感じています
なるほどですね
それはなかなか難しいところではあるので
前回のシリーズでも話しましたけど
キャリアチェンジとか
仕事の接点が増えるだけでも
その部分の気づきとか学びって
本当だったら取り入れるところも
あるんじゃないかなと
理想論でいうとそんなことも感じるんですけど
そうですね
そういう機会はやっぱりどんどん増やして
いくっていうのはすごく大事だと思いますし
多分そういう多領域のところであったり
そういう人々からものすごく
CSの業務をアップデートしていく
ヒントが得られると思うので
そこは絶対必要だと思う
CSの中で標準的に作るようなものって
例えばジャーニーマップ作りましょうとか
プレイブック作りましょうとか
ヘルスコアで見ましょうみたいなことって
言われはしますけど
それだけやってればいいっていう話ではないので
感度を高めていくっていう意味だと
今みたいにいろんな人たちと連携していくことによって
レベルが上がっていくかなってなると
いろんな人たちとの仕事大事かなって
それって最終的には今
我々の文脈で言うとブリッジ組織だと思うので
ブリッジ組織っていう活動していくと
よりCSのレベルが高まっていくことは
間違いないんじゃないかなと思います
ということで次回は
そのブリッジ組織っていうところについて
議論できればなと思います
ありがとうございました
ありがとうございました
ありがとうございました
