00:03
こんにちは。また引き続き、ヤギさんとマルタさんで顧客理解、本当にできてますか?っていうテーマで、なんと3回目。なかなか顧客理解の話が尽きないですけど。
前回まで、カスタマージャーニーマップやプレイブックどういう風に作っていくのがいいんだっけっていうので、ちょっと逆説的に活用の壁みたいな話をしたんですけど、
その中でやっぱり出てきたのって、お客さんをちゃんと理解するっていう顧客視点の目線が大事だねっていうのが出てきて、その中でなんでうまくできてないのかっていうところで、
現状理解と理想的なとか将来的なお客さんの理解っていうところで、現状把握でちゃんと実態見て確認できる話と、将来的だから願望とか想像で補ってみるお客さん像の理解ってところにギャップがあるよねみたいな話をしてきました。
今日はそういう話を踏まえて、じゃあこの顧客理解っていうのをまずちゃんとうまく組織の中でワークしていくってことを多分考えなきゃいけないんだろうなっていう気がしますと。
それについて少し話していきたいなと思うんですけど、やっぱりジャーニーマップやプレイブックをうまく使うためにも顧客理解は欠かせないっていう話があるから、
なんとか顧客理解をうまくやらなきゃいけないんだけれども、それをどういうふうに乗り越えていくか。
ここについては多分、顧客理解をちゃんとできてるかできてないかっていうところを、どれだけCS組織とか、われわれっていうのはCSカスタマー作成を実行する人たちが把握できてるかっていうところにつけるんじゃないかなっていうところで。
改めて問われると、ホリさんって本当にあなた顧客理解してますかって言われたときに、はい、バッチリですって言えるかって、ちょっとまあ自信はないところではあるんですよね。
多分、どうやって把握していく必要があるのかなみたいなところを考えていかなきゃいけないかなと思います。
そのときに言って、皆さんの中で、これ話の中で顧客理解っていうのが出てきたから、取り組みやってるやってないはあるんですけど、じゃあ今回はヤギさんからいこうかな。
業務プロセスを整理する観点で、さっき顧客目線でやるよっていうところは前回言ってたんですけど、そのあたりって自分がどれだけできてるできてないとか、
そういうふうに現状把握をするっていうところってコツとかポイントってあったりしますかね。
03:00
ポイントというか、僕がやるのは業務をモデリングするっていうことなんですけど、ちょっとこれ別のとこでも喋ったんですけど、
モデリングって一般的な定義じゃないんですけど、モデル化とかモデリング、ある目的を持って対象を理解しようとする行為。
そうなんですね。
これって、例えば顧客の業務を理解しようとするために色々書くんです。絵で書いてみる。あってかどうか分かんないけど、まず理解しようとするっていう行為であって、
できあがるモデルができあがるじゃないですか、絵として。それはその対象をどう理解したかって表現されたものなんです。
僕はこれをこう理解してます。あってかどうか知っておいて。
顧客をちゃんと理解できてる状態っていうのは、どういう状態かっていうと、書かれたものから得られる示唆とかがあるじゃないですか。
例えばこういう業務プロセスだとこう動くでしょうとか、こういうことが多くなるんじゃないでしょうかみたいな予測が立つんですけど、
それがあってればまあまあ理解できてるっていうのが基本型かな。
なのでやりたいのは、顧客の動きとか業務をモデリングすることの意味は、
顧客の業務を理解しようとする行為であって、業務モデルそのものはそれを使うことで、
顧客が今後どういう動きをするのかっていうのが予測ある程度できる。
外れてもいいんですけど多少。ある程度動きがわかるみたいなのが予測できた時点でそれっていいモデルになっていて、よく理解できてる。
そういう言葉、なんかモデリングって言葉ってちょっと汎用的な意味合いで使われることが多いじゃないですか。
自分のイメージだと仕組みみたいなのとか、回すための、
ビジネスモデルって言葉に僕は引っ張られてるんだと思うんですけど、
でも確かに今の話を言うと、ビジネスモデルもビジネスのことを知ろうとする行為ではあるなと思うと仕組みじゃなくて、
その仕組みを作ることによって、その形を理解するっていう行為そのものだと。
大事なのが対象があるということです。対象そのものと一致はしないです。
同じものじゃないって。同じものだとそれを持てばいいんですけど。
その対象と写影するというか、形取ってる、全情報の取り除かれてる情報で基本的には考えなきゃいけない。
それ取り除かれる情報がどうなっているのかっていうのを考えるためのもの。
考えるのがモデリングで、その結果出てきたものがモデリングですね。
06:03
なるほど。正しい例えかわかんないですけど、今の話って影を、写影って言ったんで影をイメージして聞いたんですけど、
例えば僕が立ってますと、ヤギさんが僕に対してライトを当てます。
その時にライトで当たって出てきた僕の影、それって正面からライト当てれば壁に影ができます。
その時は僕の多分全体のシルエット、頭から上半身があって下半身があってっていう、いわゆる正面から見た影が出るっていうんだけど、
それを例えば横からヤギさんが移動して切り取ると、僕の前身の形っていうよりは割と長方形って言ったらいいのかな、横的なものですけれども、
僕の全体シルエットとしては正面から捉えたものよりはちょっとわかりづらいけど、影として出てくるっていうのがありますし、
極端に言えば上から照らせば影がちゃんとうまく出ないので、なんかよくわかんないなみたいな、というか今イメージして聞いたんですけど、
それだとモデリングっていうのはヤギさんが移動して光源を、要はライトを当てる位置をいろいろ動かすのがモデリングで、
出てきた影がモデルっていうイメージですか?
そうですね、その通りだと思います。いい例えだと思います。
いい例え。ありがとうございます。
実現によって変わりますし、目的によっても変わるんですよ。
例えば、ソフトウェアの設計とかだと、ソフトの構造モデルっていうデータの関係性で書かれたりするモデルがあって、
そのデータの関係性が一面です。もう一面が振る舞い面っていうのがあって、そのデータがどう流れていくとか、
この機能が起動した後、この機能が起動するみたいなのが振舞い面としてあります。
最後に機能面っていうのがあって、データがこう流れることってどういう機能を与えているのかっていう局面。
3側面を基本作りなさいねっていうのがあったりするんですよ。
それぞれは一つのものに対して、それぞれ見方の違う3側面で見るっていう。
なるほど。
目的に応じて変えていくっていうのがモデリングがすごく重要。
それって対象はそういう理解をするんですね。データの関係性で理解する。
動きによって理解する。そういう機能であって理解する。
3つできてる。ソフトウェアの場合ですけど。
そういうのがそれぞれあるっていうのが。
やっぱルールがないとダメですよね。
基本は縛りがなきゃダメです。
今の話を聞いてて思ったのは、さっきの影の例えもそうなんですけど、
たぶん建築の図面みたいなやつとかも同じような感じだと思うんですけど、
あれも正面とか側面とか、上からなのかな。
09:01
いくつかの面から見て立体構造を平面でモデル化できるようにやる手法だから、
あれもたぶん建築家の人はあれで見る訓練してるので、
あれを見るとたぶん実体の家の構造がわかるんですね。
そうですね。
家具の配置、家具じゃないか。
上から見た配置。よく僕らが見るときに見る絵がある。
あの絵とか、あとは展開地図とかもありますよね。
そういう見方によってそういうのが変わるんですね。
そうね。でもそれがないと家ってできないもんね、確かに。
あれを元に材料を集めて、ちゃんと家の構造が作られて、
外壁を張ったりとか、中に水回りのものを入れたりとか、窓を貼っつけたりとか、
結局設計図のモデルがないと想像じゃ作れないし、
あれを見る見方もちゃんとみんながわかってるからあれができるっていう。
あるルールがあるんで見れると。
あるルールとかに照らして見たときに、
ちゃんとそれが切り取れるかどうかっていうところがひょっとしたら、
顧客理解を図る上では良さそうなアプローチに今見えるな、なるほど。
例え話が多くなっちゃったんですけど、今の話とかで、
丸田さんの意見をぜひ聞きたいです。
質問がすごい聞きにくいことがあって、
今のモデリングの話はすごい大事ですし、
そういうことをきちんと考えてやっていけば、
前回もPersonaの話でありましたけど、
Personaを売らなくてもきちんと顧客理解できるよね、であったりとか、
やっぱりCSの中ですごく悩みの一つとしてある、
顧客の業務理解であったりとか、業務の構造感みたいなところを含めて、
うまくできると思うんです。
ただ、モデリングってやっぱり何かしらスキルというか、
コツというか必要だと思いますし、
誰でもできることではないと思うんですよね。
そういう意味で、きちんとモデリングできるようになるためのコツというか、
例えば、モデリングをやったことがない人にモデリングをやりましょうと言って、
それがちゃんとワークするようになるまでどういうふうにしていけばいいのか、
その辺のアドバイスとかをすごい伺えると嬉しいなと。
基本的には筋トレに近いです。
12:00
僕がやってる業務モデリングのやり方そのものも、
実際使える人がほとんどいないっていうのは、
多分そこにしてる部分があると。
ソフトの開発系の人たちってモデリングよくするんですけど、
それもちゃんと使いこなせてる人ってすごい少ないんですね。
何でかよく分かんないんですけど、
一般的にマニュアル通りやったらうまくいくよねっていう世界を好きな人が
世の中多いのかなっていうのがちょっとあって、
順通りやればできますよってなりがちじゃないですか。
料理のレシピとかあるじゃないですか。
あれはあれで、あれ通り作れば出来上がるじゃないですか。
カレーライスとか。
なんですけど、例えば寿司とか、
すげー技術いいよねとか。
あれ通り作ったって作れないじゃんみたいなのが多分あって、
それ修行なんですよねきっと。
修行が必要で、その修行を好まない人が多いなとは思う。
物理的なのを好んじゃう傾向にある人がすごいいっぱいいる。
そこはちょっとあると思うんですけど。
それはでもひょっとしたら何にでも共通することかもしれないですよね。
さっきの図面の話でもそうですけど、
僕らだって図面描こうと思えば描けますけど、
家が建てられるような図面を描けるかっていうのはまた別問題ですよね。
だからそれはやっぱりそれ相応の訓練とか、
ちゃんとそういうことを技術的とか知識的に身に付けて取り組まないと、
複雑なものは作れないけど、
ただ日曜大学的に犬小屋ぐらいならできるぞみたいな話も一方ではあって、
でもそれって多分職人の世界として考えた場合って、
経験とか技術を積んでいくことによって
できることが増えていくっていう話も近いので、
最初は犬小屋しか作れなかったのが、
日曜大学やってたら机作れたとか棚できたとか、
下手したら家作っちゃうっていう人も中にはいるじゃないですか。
多分そういうのって、
また別の領域で職人芸を発揮してるのかもしれないですけど、
ただそれをちゃんと他の人に伝えるようにしようと思ったら、
図面ってすごくいいドキュメントというか、
ナレッジの共有するための手段ですよね。
それを描ける人っていうのはひょっとしたら一握りかもしれないけど、
ただ一方で図面描けなくても、
読んでそれでちゃんと作れる人っていうのもいるじゃないですか。
大工さんとか、
家を作るのにかかってるいろんな人たちは、
あれを見て寸法を測って設置していくので、
15:03
ある種ここは知っときゃいいっていうポイントも
なんかありそうかなっていうふうに思うと、
ひょっとしたら全部知らなくてもOKとか、
この部分だけ分かっておくと、
ちゃんとうまくコラボレーションできるよとか、
共同作業できるよみたいなところはありそうですよね。
経験値とかはいるんですけど、
丸田さんに対する答えとして、
コツがもしあるとするならばなんですけど、
モデリングの技術っていうのを習得することを
モデリングしたらいいのかなって気がします。
なるほど、深いですね。
かっこいい。
僕も業務のモデリングのやつって、
第一人者の方と一緒に仕事をずっとさせてもらうことがあって、
それを横でずっと見てて、
これ何をやってるんだろうっていうのはずっと理解しようと。
この時ここに線を引くんだけど、
これってどういう意味かなっていうのは
結構紐解きながらやってたんで、
そうすると自分の身にもなるんですよ。
なるほど。
早く身につくので、
モデリング版の方じゃないですけど、
相手を理解する、対象を理解するっていうことを
ちゃんと習得っていうことが、
習得するにはすごく早く進むのかなって気はします。
確かにそうですよね。
モチベーションというか、
思いみたいなところって
やっぱり自分の行動に大きく影響を与えますから、
もともと好きだとか、
そのお客さんのことを知りたいっていう気持ちが強いと、
すごくいいモデルが、
実はあんまり基礎知識なくても描けるとか、
そういうことができる人とコラボレーションすると、
いいモデルが作れちゃうとかありそうですね。
ちなみに僕は人に興味がないので、
その人のこと好きになることはないんですけど。
行動が好きなモチベーションが。
ヤギさんが好きになるんじゃなくて、
ヤギさんともし誰かがコラボしたときに、
そのコラボする人が、
そのお客さんのことを好きになってくれる。
それが早そうかもしれないですね。
ヤギさんに好きになるとは言ってないんで大丈夫です。
人に興味がないので。
興味には興味ない。
そういうモデリングをモデリングするっていうのは、
大事だし、それがひょっとしたら何でしょうね。
技術的にいろいろ実はサポートすると、
知識不足とか技術不足や経験不足を補うようなことにも
つながりそうだから、
そういうところをヤギさんに興味がないので、
今の話でいうと、
モデリングでそこで切り取る軸も言えると、
やっぱりそういう意味だと裾野を広げていかないと、
18:02
今みたいな話って、
今みたいな話ってすごく大事で 良さそうだと思う反面
やっぱり共有できないと 宝の持ち腐れになっちゃうところもあるので
カスタマーサクセスの話に少し話を戻すと
CS人材みたいなところの話でも やっぱりそういうことをやり方とか手法が
ジャニーマップやプレイブックに埋め込めたりできたとして
それがみんなが上手く使えるようにしていくっていうのが非常に重要ですよね
結局結構マルタさんとかだと多分いろいろオファー来ると思うんですけど
CS界隈って人材不足 鼻裸しいじゃないですか
でも鼻裸しいんだけど 結構よくよく話聞いていくと
ややこしい事態をいろいろ巻き起こしている状況があって
一個はCSMっていうジョブアサイメントが 中途半端になってるっていうか
結構センサー番別になってるっていうので
そのCSMっていうことを求人出して求められているものが
ケースバイケースになってるって話もあるっていうのも一点だし
さらにもう一点はやっぱり欲しいCSMの能力って結構スーパーマンなんですよね
ちょっと前回とかも少し話できましたけど
やっぱりターンを防いでかつアップセルクロスセルできるCSMみたいな人なると
マーケも知ってりゃ営業も分かればコンサルもできてみたいな
どんな人だみたいなっていう風になってくるとそういう人欲しいってなるんですけど
市場にはなかなかそういう人っていないから
その辺りもジレンマなんですけど
でも人材問題って多分解決しないと
CS組織の中でも今言ったような顧客理解をちゃんとやっていくんだっていうことが広がらないんで
まずそういうことを理解してくれる人が大事だし
それが使えるようにするっていうのは必要だったっていうところで
やっぱり人材育成プログラムみたいな話もセットで
ジャーニーとかプレイブックみたいなところも
今みたいな顧客理解っていうのをちゃんと大事にしていくんだとしたら
入れ込んでいくっていうのが必要だなっていうのをつくづく感じましたね
そういうのがあると多分いいジャーニーとプレイブックが作れて
それをみんなが見てやりたいことが伝わって
ちゃんと正しくモデリングされたもの
さっきの建築図面みたいな感じで
それを見るとみんなこういうアプローチを取ると
21:01
お客さんちゃんとオンボーディングできるとか
作実できるみたいなことが
そこなく共有できるところまでいくと
すごくいいジャーニーマップやプレイブックになってるんだろうなと
とはいえそんなのどうやって作るんだみたいなところは
多分また逆の問題としては大きくあるんですけど
多分そういうとこ目指すとこですよね
話的にジャーニーマップってモデルなんですよ
ある意味で
朝間ジャーニーマップってモデルで
さっき言ったいいモデルって何ですかっていうのは
予測できることなので
朝間ジャーニーマップから顧客の動きが予測できること
ってなってるといいジャーニーマップですよね
定義的に考えて
そうですね
例えばプレイブックのこの動きを取ると
カスタマーが動くっていうのが予測できること
すごく良い状態になって
よく理解できてる状態っていうのは
カスタマージャーニーマップを使うことで
予測が立つことだと思います
前回前々回だったかな
まるさんも話してくれてたんですけど
結局センサー版別のところをどこまで
うまく捉えるかっていう問題にぶち当たるので
そのあたりのモデリングとしては
要はコードレベルで書いていくと
やっぱりちょっと
書籍というか分厚い辞書みたいなものができちゃう
それするときついですよね
それをコンパクトにしないといけないって話かな
何で抽出してくるかっていうところが重要
何と何が同じであるとかっていう定義を
多くの部分で予測が当たることということと
完全に当てることっていうことを
ちゃんと切り分けなきゃバランス的にはいけないですね
モデリングとコードレベルって
少ない要素である程度当たるっていうのが
良いモデルなので
そうですよね
建築図面の話で何回も戻っちゃうんですけど
あれも3枚で立体コードを示してるんだけど
結局立体って
縦横高さの
多分3次元なので表現できるんですけど
逆に言うとその3次元でうまく
立体の中の空間をちゃんと表現するように
遮蔽してるわけだから
多分顧客理解をうまく遮蔽できるモデルを
作れればそういうことができるはずだということですよね
そういうことですね
なんかすっげえ難しい話になってきたな
やることは分かったけど
すごいそれをどうやっていくんだみたいな話に
悶々とするから
一旦その話は置いときましょう
そういうことを目指すことがあるんだろうなと思ったんだけど
ただ一方でやっぱり自分たちが今どれくらい
そういうことちゃんとできてるかっていうのを知ることも
大事かなと
お客さん理解でちゃんと自分たちでどんだけできてるんだっけみたいなのって
端的に言うとチェックリストみたいなものとか
24:00
そういうのでレベル感確認できると
実は今いいんじゃないかなって
密かというか話しながら思ってたんですけど
いいと思います
丸田さん一般論でもいいですけど
CSの中とかでチェックリストみたいなのって
そういうの多分アプションとか
トゥードゥとかはあると思うんですけど
顧客理解っていうのを強化したチェックリストみたいなのって
あったりしますか
そこに特化したチェックリストはまだ作れてない
そんなチェックリストみたいなのはあるんですか
これ裏で話してて
このチェックリストの話になったんですよね
ちょっと今いくつか書いていったんで
見せれるような形になると
役に立つんじゃないかなってちょっと思ってます
ここの中で言うとこうとなっちゃうんですけど
10個何かぐらいあるといいかなと思ってて
5つがお客さんに対して
対お客さんに対して
1人のCSMとして取り組むときに
どういう視点でできてますかっていうのを測るのと
もう1つはチームとか組織として
これができてるかっていうところが
チェックリスト的にはあるといいのかなと思ってます
順にいってくと
1点目お客さんに苦言を呈することができる
これ結構できそうでできなくないですかって
僕ちょっと思ってるんですけど
苦言呈すってちゃんと分かってないと
言えないよなって思ってるんですけど
1点目何でしょうどうしよう
ツッコミあったら止めていくスタイルにしましょうか
そうでいいですよ
じゃあ2点目
お客さんからお客さん自身の業務について
アドバイスを求められる
これもやっぱり信頼されてないと
そんなこと相談されないので
よく分かんないとか頼りないと思われてたら
どうしようかなみたいな感じですよね
あとお客さんの業務プロセスについて
ちゃんとKPIを設定しているか
これができてるかっていうのもあるかな
CSMもあるあるですけど
お客さんと話すときに
自社の機能しか話せず終わってしまうって
よくある話だと思うんですけど
そうじゃなくてちゃんとお客さんが気にする関心事項を
ベースに議論できるか
KPIがベースかなと思います
それがちょっと4点目のチップにもあるんですけど
ちゃんとそういうことをベースにして
定量的な議論ってできますか
何パーセント良くするとか
現状よりもどれぐらい
ぺけぺけ時間とかぺけぺけ分速くなるとか
ぺけぺけパーセントのロスをカットするとか
多分そういう会話ってサービスだとかなり重要なので
そのあたりがバクっとしてるとか
最適化しますとかっていう話になると
ちょっと辛いかなというところで
27:00
お客さんの業務良くなりますとか便利になりますみたいな
話じゃない一歩踏み込んだ議論できますかっていうのと
あと5点目はですね
お客さんのニーズを常にアップデートして
把握できているか
これも結構前回かな
ジャーニーとかプレイブックの前に
ペルソナ話をしてましたけど
ああいうのも結構難しいのって
1回作った後にどんだけアップデートし続けるかっていうところって
作ったら満足してしまう病気みたいなのって常にあるので
このあたりとの戦いかなというところですね
チェックニュースだから主観的なんですけど
こういうのに自信を持ってチェックつけられるかどうかっていうのは
結構実は重要じゃないかなと思ってます
型化と若干相反する部分があるんですよね
型を作ったらそこから外れにくくなるっていうのがある
壊さなきゃいけなくなる
そういうのと相反しやすい
ただその型が常に有効かどうかって分からないので
やっぱりサービスの差がだと思うんですけど
現状維持しちゃダメじゃないですか
そうですね
なのでやっぱりそこですよね
だから常にアップデート
それは多分サービスは常にアップデートしてるんだけど
ジャーニーマップとプレイブックがアップデートしてなかったら
それっておかしいから
やっぱそれがどっかやっぱりついにならないとダメだなとは思いますね
ここまでがお客さんに対するCSMの話で
次から組織の目線なんですけど
CSM間でも顧客理解に認識の底がない
皆さん同じこと思ってる
前回の話もしましたけど
僕は豚肉でヤギさん牛肉でマルザさんのラム肉ってなってないですよね
みたいな話ですね
みんな豚の豚カルビ食べたいって思ってる
豚による
一応豚に自分に寄せました
っていうのが1点目
2点目が
あとはプロダクトチームとちゃんとサービス開発で揉めずに
機能開発の話できますかっていうところですね
これはよく千葉揉めみたいな話が
お客さん目線の話によっちゃうと起きがちなので
要はお客さん満足っていうところを第一に頑張って動くと
お客さん以外の人をテキトーになしてしまうと
それは本末転倒なので
そうなってないですよねみたいなことで
ちょっと入れてます
同じ話でセールスチームと顧客獲得で揉めることが
これもなんでこんな顧客取ってきたんだみたいな話って
よくあるんで
この辺りも顧客理解のずれで起きるよなっていうところを思います
なのでちょっと違う話ですけど
30:00
マーケティングの話で言うと
正しい顧客に売りましょうって結構口酸っぱく言いますけど
あるいは裏返すと
売っちゃいけないお客に売っちゃダメよっていう話なんで
結構やりがちですから
それをやると結構悲劇の始まりなので
それがないようにするっていうのもすごく大事かなと
次がですね
経営の層のメンバーと
要はお客さんのターゲッティングの話や
課題について常に共有していると
結局そこがずれていると
経営的な期待の返りが生まれちゃうんで
ここもちゃんとお客さんのイメージや
今のマーケットの規模みたいなところっていうのを
常に共有できているかっていうところが大きいかなと
それを踏まえた上で
経営からの期待に対して
イエスと言えるか
ノーという場合はどういう代替でノーというか
みたいなところの作戦にもつながるかなと思います
最後
プレイブックとジャーニーの話したんで
CSM全員が常にプレイブックを参考にして
アクションを撃っている
これができているかっていうところですよね
これも結構作って満足していると
多分見なくなるっていうのがあって
見なくなるっていうのは慣れてきたっていう
裏返しでもあるんですけど
ただちょっとさっきも話したように
アップデートしてるはずなので
アップデートがあったら把握するために
参考にするはずなので
その差分がなくて見ない状態が続いていると
それはそれでまずい状況かなというふうに思います
こんな感じでチェックリストを考えているんですけど
どうですか
完全に思い込み
思い込みじゃなくて僕の主観で作ってるんで
なんかツッコミあれば
一旦いい感じ?
いいと思いますけど
うん、大丈夫だ
じゃあこれをチェックリスト作って
皆さんに
多分これチェックのついた数で
状態もなんか見えるかなって思ってるんですよね
1点だけもしあるとするのは
プレイブックを参考にアクションしてるのもあるんですけど
ジャーニーマッププレイブックって
2個にしておいてもいいかなっていう
そうですね
これは確かにおっしゃる
あとはいいかな
うん
なんか一発合格みたいな感じで
嬉しいんですけど
ありがとうございます
はい
なんだろう
全部できるってことあるんですかね
いや、逆にそれですよ
このチェックリストの設計ですけど
一応参考にしてるのって
ゲインサイトのカスタマー作品の成熟度曲線を
ちょっと見習って
丸の数をちょっとチェックの数をイメージしてるんですよね
なるほど
33:00
あれの成熟曲線も
リアクティブがレベル1で
レベル2がインサイトアンドアクションで
レベル3がアウトカムで
レベル4がトランスフォームなんですけど
トランスフォームなんて世界中探しても
数えるほどしかいないぐらいのレベルじゃないですか
セールスフォースとかが
多分アウトカムとかトランスフォームとか
その辺の裸にいるようなレベルじゃないですか
そうなるときに多くの企業は
リアクティブを出して
インサイトアクションのレベル2に向かってたりとか
インサイトアクションから
アウトカムに向かっているところのレベルなので
大体チェック的には
5、6個ぐらい付くぐらいが
現実的なのかなみたいな風に思いながら
チェックリストを設計しました
これ全部付いたら
多分僕らのこの会話聞く意味ないです
できとるし
こんな話別に聞かなくても知ってるし
当たり前でしょみたいな
っていう話にしかならないで
どっちかというと
これでチェックつかないっていう人に
参考になるような話が
今後できるといいのかなみたいなのが
逆に言うと
僕らのできることかつ
読者の方としての想定っていう感じですかね
そんな感じで
チェックリスト的には厳しめな感じなんですけど
でも振り返るにはすごくいいのかなみたいなのを
ちょっと思いながら
これ次回を込めて言ってるんで
実際じゃあ
あなたどれだけできてるの?っていうのは聞かないでほしいんですけど
プールとしてはこういうのもいいんじゃないか
ないんだったら
ぜひサイトとかで公開して
活用してもらえると嬉しいなというふうに思います
はい
ちょっとそういうところで
顧客理解の話
いろいろしてきて
最終的にはチェックリストを作ったんで
こういうので少しチェックしてみてはいかがでしょうか
みたいなところまで聞きたんで
ちょっと一区切りかなというふうに思います
はい
今日は以上にしますか
はい
ありがとうございます
ありがとうございます
