ディスラプトされる「管理」

AIに代表される新しい技術には、流行りも廃りもある。

AIがとりわけ流行っている(バズワード化していることも含め)背景には私たちの恐怖心がある。人間は未知のものを怖いと思うし、仕事を取られる、と報道されると私たちを不幸のどん底に陥れる見えない権化のように感じるかもしれない。しかも、このAIという化け物は「中間層」と呼ばれる普通の人たちに大きな影響を与えるという。

もちろん、こうした漠然とした恐怖はあまりタメにならないので、しっかり理解して怖がらないことは精神衛生上、良いことだろう。しかし、大変なことに我々はコンピュータやインターネットをそこまで理解していないのだ。インターネットの黎明期にインターネットとは何かを説明する機会が何度もあったが、今から思うと拙いし、その可能性の100分の1も語っていなかったのではないだろうか。言い訳も兼ねて説明すると、インターネットという概念は、通信を行うためのプロトコルと、プロトコルを利用してつながっているネットワーク、そのネットワークでやり取りされる情報を含むので、果てしなく成長しているのだ。この類の技術をしっかりと理解して・・・と腰を据えてやろうとすると、キリがない。結局のところ、わからなくて怖くなってしまう人もいるだろう。

忘れてはいけないのは、私たちはわからないままインターネットを使っているということである。飛行機がなぜ飛ぶのかわからないまま乗るし、インターネットを理解した上で使っている人も、薬のことは理解せずに飲んでいるかもしれない。逆にスマホを分解して完全に理解してから使うのはナンセンスだと感じるはずだ。

流行り廃りについて話を戻そう。
これは単なる現象のようにも見えるが、恐怖を乗り越えて使っている人に注目したい(実際のところ、初期のユーザーは怖いどころか好奇心満々でワクワクしながら人柱になっているのだが、どうなるかわからないという意味では似たようなものかもしれない)。産業革命によって機械化が進み、筋肉を要する重労働がたくさんの機械によってなされるようになったように、AIを使用し始めているのは、脳を酷使するような労働のサポートに対してである。

さらに、「多くの人がやっていることをやってくれる」「比較的つくりやすい」アプリケーションは、作り手の論理としても取り組みやすい。なぜなら簡単に作れて、めっちゃ儲かるからだ。多くの人がやっていて、頭を使っている割に、それほど複雑ではないこと、にAIを応用すると儲かるはずだ、ということで投資家もここに重点的に投資する。投資が集まると、エンジニアもたくさん採用でき、技術の完成度も高まり、プレスリリースもたくさん打てる、ということで流行る。

多くの人がやっていて、頭を使っている割に、それほど複雑ではないこと」がAIがもっとも伸び伸びと仕事ができることなのだ。その標的は「管理」をする仕事にほかならない。大きな会社になればなるほど管理の仕事が増える。現場の管理をする管理者を、管理する事業部長が、取締役に管理され、株主に報告する形 (少なくとも建前上は) をとっているのが一般的な会社である。もっと卑近な例では、会議室の使用も管理されているし、複写機の使用頻度も管理されているし、顧客の来店も管理されている。こうした会議室の予約管理や顧客情報管理は、どの会社でもITシステムを使うのが常識になっているのは、どの会社にも必要でありながら、AIとは呼べないようなローテクなITシステムで作れるからだ。会議室よりかは随分と複雑な人材を管理するAIサービスも出つつように、より複雑な管理をやってくれるAIは順々に登場するだろう。

こうなると別の恐怖が生まれる。仕事がなくなるかもしれない、と。特に中間層の管理職が減るのではないかと、言うのである。そうした管理は自動化されポストは減る方向性にあると私も信じている。前述した作り手の経済的な論理からもきっと優れた管理AIが増えるだろうと予測するが、そこには恐怖は感じない。なぜなら、減っているのは「労働」であって、「仕事」ではないからだ。産業革命によってなくなった「労働」は、みんなやりたくなかったような3Kの仕事ばかりだ。トラクターを使わずに畑を耕すことを考えてほしい。あるいは人力車で移動するのではなく、人力車を引っ張ることを想像してみるといいだろう。農作物がたくさん出来ることの方が、耕す作業そのものよりも大事だ。補足すると、ジョブ理論の観点からも「管理したい」というジョブよりも成し遂げたい仕事=ジョブに注目するべきだ。

AIが伸び伸びと仕事がする領域、つまり「多くの人が携やっていて、頭を使っている割に、それほど複雑ではないこと」 は、「一般的な業務」「デスクワーク」「創造性が低い」ということになる。 実は、そんな「労働」に私たちは恐怖を感じているということはないだろうか? 考えてみると、どこにでもあるクリエイティブではないデスクワークをやり続けることの方が怖いのではないかと思えてくる。「みんながやっている、ちょっとしか頭使わないこと」を離れ、身体が動いてしまうこと、考えたくてしかたないこと、思い描くのが楽しくてやめられないこと、を始める。そういう仕事はディスラプトされないだけではない。

Written by 津田 真吾 on 2019-01-20

起業家の前職は何をしてたのか?

ZENTECH DOJOというシードアクセラレーターを始めて、2年以上が過ぎました。振り返ると、10人以上の色々な起業家や起業予備軍とご縁を頂いたなぁと思います。
また、先日採択チームが発表されたKawasaki ZENTECH Accelerator では10社の若きハードウェアスタートアップの創業者をサポートしています。
こうした起業家って、一般には学生が多いというイメージかもしれませんが、案外、社会経験を経てから起業する割合はかなり多く、8割以上の方が何らかの社会経験をお持ちです。
だからと言って、社会人起業が良いと言いたいわけではありません。むしろ、起業は「資格」や「経歴」から一番遠い仕事です。
学生時代に起業して大成功した人の方が印象的かもしれません。例えば、マイクロソフトのビル・ゲーツは在学中に起業しましたし、ザッカーバーグも在学中にフェイスブックを作りました。
しかし一方で、アップルのスティーブ・ジョブズ(アタリ)、スティーブ・ウォズニアック(HP)は一度エンジニアとして就職しています。アマゾンのジェフ・ベゾスは投資銀行で30歳まで働き、かなり出世していました。さらにウォルマートを創業したウォルトンは40を過ぎて起業しています。
このような例からも、学生起業が良いのか?社会人経験があった方が良いのか?という議論は不毛だということはご理解頂けたと思います。
 
企業で勤めたことがマイナスに働くこともあります。(例:「営業」は営業担当者の仕事だと思ってしまうなど、変な癖がつく)。
一方で、会社での経験が役立っているケースもたくさんあります。
前職の経歴として多いものから順に、その経験のどういった部分が起業後も活かせているのか、述べてみたいと思います。
 
エンジニア

エンジニア出身の起業家が多いのは、誰もが認めるところだと思います。それは技術を扱いなれていて、ゼロから何かを作る感覚を持っているからだと思います。

対象がプロダクトであろうが、ビジネス全般であろうが、実験や試行錯誤から学び、修正していくプロセスは、さほど変わらないのではないかと感じます。もちろん、対象領域に対する知識も必要ですが、不確実性の高いスタートアップにおいては、事前の知識よりも学ぶスピード(ラーニングカーブ)が遥かに効いてきます。

例外:「エンジニア」という肩書きはついていても仕様書や設計書を書くばかりの仕事もあります。(エンジニアを採用するスタートアップもこういうエンジニアには注意しましょう。有名なプロダクトに関わっていたというエンジニアも要注意です。売れている製品にはリソースが沢山割り当てられるため、一人の業務範囲は小さくなりがちです。)

 
研究職

意外に思われるかもしれませんが、エンジニアと同じ理由で研究職も向いています。実験と試行錯誤を信条とする研究者は仮説を立てて、検証することにあまり抵抗がないようです。

一方で「専門領域」や象牙の塔のヒエラルキーに慣れ親しんでしまっていると、チャレンジをする力が削がれてしまうかもしれません。

研究者も、ある研究領域における知識を重視しているような方はあまり向きませんが、そういう方はあまり起業しないので問題ないと思います。

 
コンサルタント

DeNAの南部さんのように、M社やB社出身のコンサルタントが起業するのもよく見かけます。ある程度コンサルをやってしまうと、起業するのが割に合わなく感じられるようですが、そんなこと考えずにやっちゃう人は向いていると思います。

特にB2B系のビジネスであれば、色々な企業の組織力学を知っていることは固有知識としても役立ちます。文書作成能力が高いと提案書は通りやすくなりますし、ビジネス上の振る舞いが板についていると、他の企業と付き合いやすいはずです。基本的な取引を成立させ、ビジネスを軌道に載せる上でCOO的なスキルをコンサルタント時代に身につけているのだと思います。

 
マーケター

企業のマーケティングを経験してから起業される方もいます。このような方は、サービスの見せ方から入るので、とにかくキャッチーです。「つかみ」が上手でコミュニケーションに長けているので、スタートアップ初期のスピード感をどんどん出せるのではないでしょうか。

一方で、スタートアップの内部はさほどシンプルなコミュニケーションだけでは済まず、エンジニアとのコミュニケーションや様々な試行錯誤にフラストレーションを感じるようです。

 
セールス

わずかですが、営業マンから起業された方もいます。営業現場で顧客の状況を深く知り、深いインサイトと原体験をお持ちです。原体験がきっかけとなり、営業を超えて製品開発や研究へと守備範囲を広げる情熱は、周囲を巻き込みます。また、エンジニアと比べ、「個」で動くことに慣れているように感じます。つまり、一人で色々な問題解決をしながら事業を立ち上げるときのパワーが出やすいように見受けられ、「営業」というイメージに合わず万能な仕事ぶりを感じさせます。

 
色々と職種別にスタートアップで役立つスキルを挙げましたが、企業でどんな経験するかはその人次第なところ相当あるので、あてはまらない人も多いかもしれません。ですが一つ共通して言えるのは、「濃い」経験をして、会社での一つの職種を務めるだけでは解決できない問題に出会っているということくらいです。
解決したい問題を目の当たりにし、取り組んでみるものの会社や事業の限界を感じ、会社を起こす、という流れは一つのステレオタイプなパターンなのかもしれません。さらに、上手くいっている起業家はその「職種」ではなく、「課題領域」においての専門家となっている、というパターンがあるのも必然なのだと思います。

Written by 津田 真吾 on 2018-12-10

カスタマーサクセスを成功させる組織

カスタマーサクセスに関する3部作の最終稿です。
その1:カスタマーサクセスとは何か?
その2:カスタマーサクセスとJobs to Be Done, Time to Value
 
前回は、カスタマーサクセスをサクセスさせるために重要な3つの要素を挙げ、最初の2つの要素について書きました。
(1)「顧客の成功」をいかに的確に捉えるか ( 顧客ジョブの把握)
(2)いかに早くその成功に近づけることができるか (タイムトゥバリュー)
(3)組織化とプロセス
今回は「組織化とプロセス」です。
 
カスタマーサクセスの組織化やプロセス化を目指す前に、一つだけ注意をするとしたら、
PMF前にカスタマーサクセスはできない
ということです。
 
しばしば、PMFに到達する前にカスタマーサクセス部隊を作っている会社を見かけますが、「1勝もする前から勝ちパターンはない」ことに気づいた方がよいと思います。
PMFして、顧客がどんなジョブのために製品を使っているのかを把握できた後に、初めてそれをパターン化したり、組織として運用することが可能になります。逆に、そのパターンがあることによって、例外が際立ち、アクションもしやすくなるという循環も生まれます。
 

タッチを決める

カスタマーサクセスの方法論として、フィットしたプロダクトと顧客に応じて「タッチ」を設定するということがまず重要になってきます。
「タッチ」というのは、顧客接点、この場合はカスタマーサクセスの濃密さ、を指す言葉です。ホテルのサービスで言えば、超高級ホテルや旅館はハイタッチです。おもてなしを提供するための接触が濃密ですね。大規模シティホテルは中くらいでしょうか。ロータッチと言えると思います。ビジネスホテルは、セルフサービスが多いです。宿泊客が自助的に過ごしやすくする工夫はされていますが、ホテルの職員が積極的に顧客に関わることはあまりありません。このように、技術を提供することで顧客が価値を最大化する支援をすることをテックタッチと呼びます。
ビジネスモデルキャンバスに精通している方には、CR (Customer Relationships)と同じことを言ってる!とすでにお気づきだと思います。

 

プロセス&KPI

組織・プロセスを考える手順としては、
顧客のKPIを知る → PMFしたプロダクト・顧客に対してタッチを決める → タッチを決める → 顧客のKPIを高めるために必要な資源と活動を定める → 活動を行うための資源を準備し、スキルを集める → 自社の活動のKPIを決め、継続的に計測する
 
タッチは利益構造を決めます。高付加価値製品は、高単価ですし、顧客企業の経営レベルが購入の意思決定をするため、ハイタッチなサポートが必要です。逆に、担当者レベルが使用するようなSaaSであれば、一人一人に個別な対応は困難です。限られた利益が一度に吹っ飛んでしまいます。したがって、技術を使い、顧客の自助的な「サクセス」を促すような活動をカスタマーサクセス部門が目指すことになります。
この新しいカスタマーサクセス部門に適切なKPIを設定することができれば、活動を修正しながら、さらに高い効果が出るようにすることができます。理想は顧客のKPIを、自社のKPIにすることですが、さすがに計測が困難かもしれません。そういうときは、サービスの活用度や利用率といった、自社でも計測可能な指標を設定します。自社KPIを顧客KPIに基づいて決めることが何よりも大切です。ついつい、「売上」のような数値を設定しまいがちですが、これでは漠然としていますし、カスタマーサクセスに取り組む前と代わり映えしません。顧客の成功と直接因果関係のある指標を設定します。
営業支援サービスなら、顧客の売上、客単価、顧客数などが顧客にとってのKPIですが、さすがにこれらを把握することは難しいかもしれません。ですが、システムに登録されている顧客候補数や、顧客増加のためのキャンペーン数などがKPIとして良いかもしれません。
BoxやDropboxのようなオンラインストレージなら、有料無料かかわらず記録されているデータの容量とか、読み書きされた回数とか、共有されているユーザ数、デバイス数などが考えられます。

Written by 津田 真吾 on 2018-10-11

カスタマーサクセス・JTBD・Time-to-Value

前回の記事では、カスタマーサクセスとは何かを書きました。
カスタマーサクセスとは、「顧客が成し遂げようとしていることを支援するための考え方およびその組織、戦略、オペレーションである。」
という長い書き方と、
カスタマーサクセスとは、「顧客のジョブ解決をゴールとする組織とその機能」
という短い書き方とがありますし、数式が好きな人には
CS (Customer Success) = CO (Customer Outcomes) + CX (Customer Experience)
という数式の方が覚えやすいかも知れません。
 
このカスタマーサクセスをサクセスさせるためには、3つのことが重要になってきます。
(1)「顧客の成功」をいかに的確に捉えるか ( 顧客ジョブの把握)
(2)いかに早くその成功に近づけることができるか (タイムトゥバリュー)
(3)組織化とプロセス
 
 
まず(1)です。どうやったら的確に顧客の成功を捉えられるのでしょうか?
「カスタマーサクセス」という言葉が主にSaaSのようなB2Bビジネスに使われることを考えると、顧客のジョブは割とシンプルな質問でわかります。
「(顧客の)部署のKPI(目指す指標)は何ですか?」
もちろん、KPIがあまり明確に設定されていない企業や部署も多く、はっきりしないかも知れません。ですが、会話を通じて、その顧客が重要視している指標を理解することは可能です。
 
例えば、人事部の採用課が相手である場合を考えてみましょう。
「KPIは?」と尋ねても「は?」みたいな顔をするかも知れません。なので「採用を増やしたいのですか?それとも質を高めたいのでしょうか?」と尋ねてみます。
すると、「採用する人数は各事業部から上がって来るので、人数は決まってるんですよ〜。。。しかも誰でも良いわけではなく、実はAI系のエンジニアの採用が難しくて・・・」と返ってくるかも知れません。
この返事から、採用課が目指していることは「各部門の要望を満たすこと」であることがわかります。特に、開発部門からの評価が得られれば「大成功」です。
このように顧客の成功を捉えると、単に人材を紹介するだけではなく、各部門の要望を整理したり、分析したりすることの重要性が見えてくるはずです。仮に人材紹介のプラットフォームを提供している企業だとすると、カスタマーサクセス部門にとって重要な仕事は「人事部が、各部門の求める人材像を理解しやすくする」ことになります。
シンプルに捉えるなら、ジョブはその部署のミッションやKPIだと考えるとよいでしょう。
 
(2)はタイムトゥバリューです。
つまり、いかに早く顧客が価値を感じることができるか、です。先ほどの人材紹介プラットフォームなら、使い始めてできる限り早く紹介できる人材が伝わるとよいでしょう。サービスを使い始めたとしても、肝心の人材情報に行くつく前にたくさんのフォームを記入させたり、ややこしい説明が多かったりすると、その前に顧客は諦めてしまうかもしれません。諦めなかったとしても、顧客側の負担が大きすぎて十分な価値を感じられないことも考えられます。フェイスブックは、初めてログインしたユーザーができる限り早く友人と繋がるか、という指標を重視することで顧客のタイムトゥバリューを高めています。
総じて、多くのサービスはタイムトゥバリューの設計が甘いように感じます。顧客の要望をしっかりと聞いて、無駄やリスクのない状態で価値を提供しようとするあまり「但し書き」「準備」が先立ってしまいがちです。ウェブサービスの「UX」や「デザイン」の問題という風に認識されているかもしれませんが、要は「使い始めてすぐに価値を感じられるか?」という観点でとらえてはどうでしょうか?価値を提供する場面まで極力ストレートな導線を描くのです。
 

一昔前までは、ユーザがサービスを使いこなすにはマニュアルを読み込むことが当たり前でした。使い方を一通り読んで、それから使用してみて、試行錯誤しながら成果を出してやっと価値を感じることができる時代でした。
その後、「ヘルプ」が当たり前になりました。マニュアルをさほど読まなくても、使用中に「ヘルプ」をクリックすると手助けが得られるというわけです。
「ヘルプ」ではまだ、ユーザの質問に対応する受動的な手助けだということで考えられたのが「ウィザード」のような仕組みです。ウィザードでは、最初にいくつかのシンプルな質問にユーザが答えれば、結果や結果に近いものを即時的に出すようなUXを提供します。
また、優れたタイムトゥバリューを提供する手法として「テンプレート」が挙げられます。あらかじめ用意された複数のテンプレートの中からユーザは選ぶだけで、ほぼ完成したものを手にすることができます。例として、インスタグラムは、どんなフィルターなのかを説明することなく、ユーザの希望するであろうフィルターを複数提示し、タップするだけで写真におしゃれな加工を施します。前時代的インスタグラムが存在するとしたら、ぼかしの入れ方や、彩度や明度の調整方法を紙のマニュアルでユーザに読ませるようなものだったでしょう。これでは、素敵な写真を共有したいという目的に到達する前に骨が折れてしまいます。
長くなってきたので、(3)は次回に回します。

Written by 津田 真吾 on 2018-10-02

カスタマーサクセスとは何か?なぜ今注目されているのか?

「カスタマーサクセス」最近よく聞く言葉です。
カスタマーサポート、顧客中心、顧客第一、顧客満足、・・・同様の言葉が腐るほど生み出されてきましたが、掛け声だけで何も変わりませんね。
それなのに、今なぜ「カスタマーサクセス」なのでしょうか?
長々と書く前に、まずは自分なりの結論から書きます。
 
#顧客が成し遂げたいこと(=ジョブ)が成し遂げられることではじめて企業は成功する、からです。
 
 
 
まずカスタマーサクセスの定義から説明しましょう。
「カスタマーサクセスとは、顧客が成し遂げようとしていることを支援するための考え方およびその組織、戦略、オペレーションである。」
 
顧客が成し遂げようとしていることを考えているだけでは実行はできないし、組織がなければ業務へと落ちないし、戦略がなければ実行もおぼつかないので、単なる理念ではないことはもちろん大事なポイントです。
 
でも、これではカスタマーサポートといった過去の施策との区別がつきません。
カスタマーサクセスとカスタマーサポートの最大の違いは、カスタマーサポートは「顧客の不満」から仕事が始まる点です。カスタマーサポート部隊は、顧客の不満解消に向けてさまざまな手を尽くします。一方のカスタマーサクセスの起点は、顧客がサインアップすることです。新しい顧客が、サービスを使おうとしたその瞬間から顧客の成功を目指して支援します。
顧客の「不満」と顧客の「成功」、この2つは一見単なる表裏ですが、根っこはかなり違います。
例えば、ビジネスマンが2泊3日のシンガポール出張のために航空券とホテルをオンラインで手配するケースを考えてみましょう。顧客は、フライトの価格やスケジュールを見ながら比較し、予約を入れ、購入します。いざ出張に出かけると、フライトの遅延やホテルの不備を経験するかもしれません。このうち、顧客が本当に不満として声を挙げるとしたら、フライトの遅延やホテルの不備があった時くらいでしょうか。なぜなら、価格や価格表示がわかりにくければ、そもそも顧客化せず、黙ってサイトを去るだけです。一方で、顧客ジョブが成功することを軸に考えるなら、チケットの予約や購入は出張の本質ではないので、シンプルに手際よく済ませられたり、出張後の精算が楽だったりすることが重要だということがわかります。フライトの遅延やキャンセルの際には、迅速なサポートが求められることは言うまでもありません。
「顧客の不満」つまり、クレームを起点にしていると、知らず知らずのうちに顧客を失うことにもなりかねません。出張の計画を立てるのには不便だったりすると、顧客はクレームも言わずに黙って去るからです。これは静かにやってくる悲劇です。クレームもなく売上が下がると「サービスレベルの問題はない。きっと価格だ。」という論理から、価格を下げることで売上の回復を図ります。これもさらなる売上ダウンの要因となります。何が何だかわからないまま、売上ばかりが下がることになるのです。
 
カスタマーサクセスの必要性は、サブスクリプションやフリーミアムといったビジネスモデルの登場によって増しました。

サブスクリプションのサービスでは、顧客はサービスの利用権を月額や年額で購入します。簡単に言うと、顧客が使った分だけを支払う仕組みです。使わないモノを売り込まれて、タンスの肥やしになった経験が誰しもあるのではないかと思います。高額なソフトを導入したけれど一度も使われないものをShelfwareと言いますが、使う分だけしかお金を払わなくて良いサブスクリプションでは、売り手と買い手の利害が一致しやすくなります。
そもそも、サブスクリプションやフリーミアムといったビジネスモデルが登場した背景には、従来の製品販売型のビジネスモデルでは企業のゴールと顧客のゴールとが一致していなかったことがあります。企業の各組織は「販売量」「生産量」「売上」といった指標で仕事の成果を測る一方で、顧客はそれぞれの目標を持ちます。顧客の失敗を目指す悪徳業者も存在はしますが、悪意がなくとも、組織が分断しているために顧客の成功以外のために仕事をしているのが実態ではないでしょうか?例えばマンションの営業マンは、すべての物件が売れることを目標にしているのであって、そのマンションを買って入居する人が良い暮らしができるかどうかを業績目標にしていることはありません。

 
サブスクリプションやフリーミアムといったSaaSに用いられるビジネスモデルを採用している企業では、ユーザー数やサービスの使用期間に応じて売上が変わります。最初は数人で1カ月だけ使用してみたり、そもそも試用期間は無料だったりと、使って価値を感じるまでのハードルを極端に下げています。従来の製品販売モデルと比べると、最初に契約する金額が極端に低くすることで意思決定もスムーズな収益モデルを構築することができます。結果として、顧客とゴールが近い形での収益モデルになっているのです。
実は、SaaSの草分け的存在であるSalesforceの創業者 Marc Benioffが「カスタマーサクセス」という考え方を広めましたが、これまで述べてきたようなロジックで取り組んだわけではありません。Salesforceは画期的なSaaSではあったのですが、顧客を新規で獲得してもしても流出するという問題に直面しました。顧客の流出は「チャーン(Churn)」とも言いますが、Salesforceにとっては相当手痛いものでした。新規顧客の獲得には大変なコストもかかる割には、最初の契約は少額で、ろくに使う前から離脱してしまうのですから当然です。Benioffは、新規顧客への営業を一時的に止めて、既存顧客が成功するためにあらゆるサポートをするという戦略を立てました。ツールの使い方を丁寧に教えるのはもちろんのこと、Salesforceを導入する顧客のゴールである営業、営業管理に対する知見を惜しみなく出すなど、「顧客の成功」に向けた活動に集中したのです。Salesforceのツールを「使う経験」(CX=顧客体験)を通じて、営業成績が伸びるという「結果」(Outcome=結果)が得られた顧客はそのまま定着し、追加のユーザライセンスを購入し、Salesforceの営業成績も回復しました。『カスタマーサクセス サブスクリプション時代に求められる「顧客の成功」10の原則』の著者らはカスタマーサクセスを以下の数式で表しているのは納得です。
CS (Customer Success) = CO (Customer Outcomes) + CX (Customer Experience)
 
つまりジョブ理論をご存知の方には、カスタマーサクセスとは顧客のジョブ解決をゴールとする組織とその機能、と言ってもよいかもしれません。
長くなりましたので、ジョブ理論との関係や、具体的な活動については次回書いていきたいと思います。

Written by 津田 真吾 on 2018-09-25