Saasという「ある特定の仕事の課題を解決するためのソフトウェア」を提供して利益を出していくためには、ある程度定型的な、パッケージングされたカスタマーサクセスプログラム（支援メニュー）が必要であろうと思います。
しかしその実態は、定型的なメニューからしょっちゅう逸脱し、ベンダー側の思うようにオンボーディングが進まなかったり、サクセスしなかったりということが起きます。定型的に線形で進めたいのに、非定型的で非線形に進んでいく実態との狭間で悩むカスタマーサクセス担当者は多いのではないでしょうか。
この記事は、カスタマーサクセスを予見されたものとされていないもの、確実性と不確実性が分かちがたく混在するプロジェクト的なものとして捉えることによって、顧客を成功に導くための方法について考えたものです。

プロジェクトとして捉えるとはどういうことか？

まず、「プロジェクトとして捉える」とはどういうことかについて説明しなければなりません。
プロジェクトはルーティンワークと違い、未知・あいまいさ・予測を含みます。未知・あいさまい・予測を含むということは、インプットからアウトプット、アウトプットからアウトカムまでの因果関係が明らかになっていないということです。このことはプロジェクに取り組む人々に以下のことを要求します。

• プロジェクトは不断に見直しを迫られる。

• プロジェクトは当初の行動計画や目標を一途に追うのではなく、状況の進展に応じたその都度の決定を行う。

• あらかじめ定めた計画や手順であるよりも、過程それ自体のなかから浮上する価値ある諸要素によって進めていく。

• 見込違いや障害を逆手にとり、事故や過誤から利益を引き出す。

このように書くと「めんどくせー」「コスト高！」「非効率！」と思ってしまいますが、当然インプット→アウトプット→アウトカムの関係が明らかになれば、それ以降はルーティンワークのように仕事ができるハズです。（※プロジェクトは狭義の意味では有期の一回きりの仕事を指しますが、カスタマーサクセスは顧客は変わっても仕事は続きます。材質はプロジェクト的な仕事でも、ルーティンワークのようにCSの仕事を定型的なものにもっていかなければなりません）
もう一つ、未知やあいまいさと同様にプロジェクトを進める上での障害要因にるのが、クライアントの中の導入者と実際の利用者、それぞれの上司、自社のカスタマーサクセス担当者、営業や開発といった、多様なのステークホルダーの存在です。

インプット→アウトプット→アウトカムの因果関係が明らかになっておらず、複数のステークホルダーが存在するプロジェクトを進める方法は、「アウトカムを出すまでの仮説を立て、それをみんなでレビューし、合意する」になります。

アウトカムを出すまでの仮説を可視化する方法と道具

カスタマーサクセス及びオンボーディングをプロジェクトとして捉えることができれば、プロジェクトの仮説を可視化・構造化して、レビュー・合意するための道具である『プ譜』が役に立ちます。ここからプ譜を用いて、以下のことを考えていきます。

• オンボーディング及びカスタマーサクセスのインプット、アウトプット、アウトカムの関係を可視化・構造化する

• そもそもズレている顧客とベンダーのアウトプットとアウトカムの認識

• 用意しているプログラムがうまく作用しない場合の対応

• オンボーディングにおいて顧客と何を、どのように合意するべきか？その後のサクセスに影響を与えるオンボーディングの成功をどう定義するか？

※ちなみに、インプット・アウトプット・アウトカムの関係が明らかになっているプロダクト、プロダクトベネフィットが自然にアウトカムをもたらしてくれるものは、プロジェクトとして捉える必要はなくルーティンワークのように決められたことを、決まった手順で実行するだけでよいはずですので、これ以降の文章は読む必要はありません。というか、そのようなプロダクトは、そもそも上述した問題がないわけですから、この記事が目に入ることすらないでしょう。

プ譜で用いて話を進めていくにあたり、架空のSaasを対象にすることにします。このSaasは会議の効率と品質を向上させるプロダクトで、自動議事録や会議中にタスクが発生したら「@（メンション）、氏名、タスク：機能説明動画作成」などと詠唱すると、議事録にタスクとそれを担当する人物の氏名がリストになって表示される機能、会議内の発言・質問・進行を評価してスコアリングする機能があります（※妄想Saasなので細かい仕様は気にしないでください）。

カスタマーサクセスが抱える構造的な問題点

カスタマーサクセスの構造をプ譜で可視化すると、2つの大きな問題点が見えてきます。
1つ目が、顧客とベンダー間のアウトカムとアウトプットのズレ。2つ目が、
カスタマーサクセスがコントロールしきれないアウトプットとアウトカムです。

インプット・アウトプット・アウトカムの関係を可視化する

架空の会議効率化サービスのオンボーディングとサクセスを実現するための構造及び過程をプ譜で表現したものが下図です。

プ譜には勝利条件、中間目的、施策という項目があります。
勝利条件とは、そのプロジェクトが成功したといえる判断基準・評価指標のこと。Saasを導入して得たい成果、つまり「成功の定義」を書きます。中間目的は、勝利条件を実現するための要素とその「あるべき状態」。施策は中間目的を実現するための具体的な行動・作業のことを言います。勝利条件、中間目的、施策はそれぞれアウトカム、アウトプット、インプットと対応します。

インプットはオンボーディングやオンボーディング終了後に実行する様々な行動（※支援メニューやプログラムなど呼び名は各社異なると思います）になります。真ん中の中間目的はインプットをした後に現れるユーザーの状態です。このユーザーの状態をすべて実現すればオンボーディング成功というのか、いくつかの状態を実現すれば成功になるのかは、各社異なります。

サービスの多義性の高さはカスタマーサクセスを大変にする

獲得目標には、ベンダーがそのプロダクトで実現したいことを書きます。Saasの理念、Saasからのメッセージともいえます。顧客はこの目標に書かれていることに共感したり価値を感じたりして導入を検討します。しかし、プロダクトが顧客のプロジェクト（の文脈）に（部分・手段として）組み込まれたとき、「どんな成果を得たいか？どんな状態になりたいか？」＝勝利条件・アウトカムは、顧客によって変わってきます。
例えば、同じ会議効率化サービスを使っているけれど、営業会議で見込客の意思決定を促すために使いたい顧客もいれば、プロジェクトMTGでタスク漏れを防ぎたい顧客も、社内のあらゆる会議の会議時間を短くしたい顧客も、マネージャー層を対象に良い意思決定ができるようになりたい顧客もいる、という具合です。どんな目的で使いたいのかによって、プロダクトを使用する意味が異なる、というふうに言うことができます。
このようにプロダクトを多様な使い方ができる状態を「多義性が高い」と言います。
多義性の高さが意味することは、カスタマーサクセス担当者は顧客の使用する意味に応じて、定期的な支援プログラムの形を変えたり、プログラムから逸脱するものをカバーしたりしなければならなくなるということです。最初から多様なプログラムを持っているということは、まずないでしょう。目標と勝利条件の関係が1対1だったり多義性が低ければラクなのですが、そうではないプロダクトでは、ここがまずカスタマーサクセス担当者を悩ませる点になります。

顧客とベンダー間のアウトカムとアウトプットのズレ

もう一つ、顧客のプロジェクトに組み込まれたときに起きる問題があります。それが、ベンダーのプロダクトで得られるアウトカムは、顧客のアウトプットの一つというズレです。プ譜で表現すると下図のようになります。

ベンダーのプロダクトで得られるアウトカムが、そっくり顧客のアウトカムであれば何も問題はありません。問題は、マーケティングや営業が顧客のアウトカムを自社プロダクトで実現できると喧伝したりて売ってしまったりした場合、プロダクトが影響を与えらる要素は全体の一部分でしかないわけですから、チャーンになる可能性は高くなります。
結果的にCSは、顧客にプロダクトを使う価値があったと思わせよう・実感させようと指標をあれこれ考えて、提案書をつくり、関連する機能開発を約束したりして契約更新を得るために四苦八苦します。
カスタマーサクセスをプロジェクトとして捉えて進めようとするとき、自社のプロダクトは顧客の大きな計画のなかの、「どのアウトプットを実現するのか？」を特定して、つまり顧客の大きな計画という全体と、自社のプロダクトを使って行う小さな部分の関係を明らかにして、こんなアウトプットが出ていれば、プロダクトを導入した価値がありますねと言えるものを顧客と合意しなければなりません。
プ譜はそれを行いやすくる道具として使うことができます。

コントロールしきれないアウトプットとアウトカム

インプットにはプロダクトの機能も含まれます。プロダクトを使えるようにするための支援、プロダクトの価値を伝えるオンボーディングもインプットになります。
インプットを行うことそれ自体はベンダーがコントロールできます。プロダクトを操作することを教える。操作した結果できること（何かをつくる、増やす、減らすといったこと）を支援できる。これらは定型的なプログラムとして、ルーティンワークに近い形で実施することができます。
Saasはある課題解決のためにつくられているので、インプットすれば必ずアウトプットは出ます（見積書をつくる、動画をつくる、見込客の直近のデジタル上の行動状況や実行した販促施策がどのくらい売り上げにつながったかなどのデータがグラフやスコアで出る等々）。このアウトプットの品質や速度を上げたり、かける労力を下げたりするノウハウもベンダーにはあるはずです。
しかし、インプットしてもアウトプットが出てこないようなものもあります。このようなとき、問わないといけないのは、「アウトプットを出すためのインプットは適切か？足りているか？インプットするうえで障害になっているものはないか？」です。

インプットしてもアウトプットが出てこない典型は人間の要素・状態です。架空の会議効率化サービスを例にとると、中間目的にある「発言・質問が歓迎される・価値あるものであることが理解できている」という状態は、プ譜に書いてある施策で本当に実現できるようになるかが、オンボーディング実行前にはハッキリとわかりません。

また、アウトプットが出ても、それだけではアウトカムにつながらないものもあります。よく聞くものとして、「SFAなどでデータを得たけど、それをどう見たら・解釈したらいいかわからない」というものです。
「どんな発言・質問が評価されるのかが理解できている」という中間目的を例に取れば、この状態でアウトカムにつなげられる顧客もいれば、つなげられない顧客もいるだろうということです。できない顧客には別のインプット（施策の実行の仕方を変える、別の施策を実行するなど）が必要です。

インプットとアウトカムの関係があいまいで不確実なほど、CSは苦労する

インプットそのものはコントロールできても、インプットからアウトプット、アウトプットからアウトカムに移行するに伴い、コントロールできなくなってくる。影響を与えられる度合いは低くなっていきます。
このプロダクトがコントロールできない余地が大きいほど、影響を与えられる度合いが小さいほど、つまり、インプットとアウトカムの関係があいまいで不確実なほど、CSが個別対応しなければならない可能性が高くなります。人的なハイタッチ、顧客ごとのアカウントプラン作成などを行うことになります。こうした対応にCSは七転八倒することになりますが、それは状態を実現するための施策のレパートリーを増やすという利点もあります。ただ機械に対応するのは難しくなるので、サービスの利用料金が高いとか、有償のオンボーディングプランがないとやっていけない（やってられない）でしょう。

顧客との仮説を共有して合意する方法

インプットとアウトプット、アウトプットとアウトプットの因果関係があいまい・不確実なままマーケティングが喧伝し、営業がノリと勢いと期待で進めてしまうのは牽強附会、論理の飛躍です。そんなことで導入されることはあまりないと思いたいですが、それで導入されたとしても遅かれ早かれチャーンされるでしょう。
ですから、まずそもそもあいまいな部分があることをハッキリと目で見える形で認める・認めてもらう必要があります。そのあいまいさを、どのような仮説で埋めることができるのかを顧客と対話して、問いかけ、教えてもらい、考えなければなりません。
問うべきは、「成功のためにはどんな要素が必要で、どの要素にどんな変化が現れて（どの要素がどんな状態になって）いれば、アウトカムにつながりそうか？」です。
この「要素のあるべき状態を実現すること」が、因果関係があいまい・不確実なプロジェクトに取り組む際のオンボーディングの成功の定義になるのではないでしょうか。
会議効率化サービスであれば、「会議参加者の発言や質問の質が向上している」というアウトカムを出すために最も重要な要素と状態が「どんな発言・質問が評価されるのかが理解できている」という中間目的であれば、これを実現することがオンボーディングの成功であるということを顧客と合意します。

この状態を実現するためにカスタマーサクセスは定型的な支援プログラムを持ちますが、それでは状態が実現しない場合、下図のように別の施策（インプット）を新たに考案して実行しなければなりません。

こうして新たな施策を実行すると、実はアウトカムを出すために必要な状態は「どんな発言・質問が評価されているのかが可視化されている」ではなく、「どんな発言・質問が評価されるのかが実感できている」なのではないか？という新しい仮説が生まれることがあります。因果関係があいまいな仮説は更新され、あいまいさが明らかになっていきます。あるべき状態が再定義され、その状態が実現したことで、他の状態に影響を与えるということもあります。（下のプ譜は「どんな発言・質問が評価されるのかが実感できている」状態が「発言・質問が歓迎される・価値あるものであることが理解できている」状態を強化することを示したものです）

こうした仮説の更新や状態の変化の可視化がプ譜の得意とするところです。プ譜を用いて顧客とともに見て、考えることで、顧客との共通言語・共通基盤として対話・レビューがしやすくなります。目で見ることで、「ここが不確かですね」ということを発見しやすくなり、「この仮説がうまくいかなければ別の施策を考えましょう」ということが話しやすくなります。
プ譜は合意された文書となり、仮説実行後のあいまいさを徐々に明らかにしていく過程を記録することができ、カスタマーサクセスの資産としてアーカイブすることもできます。

なお、容易ならざるカスタマーサクセスプロジェクトを進めるための参考に、とあるSaasのカスタマーサクセス担当者が何度もタイムリープしてチャーンを阻止しようとする創作コンテンツを書いております。よろしければご覧ください。

プ譜がカスタマーサクセス・オンボーディングに使えるんじゃないかと期待をもって頂いた方は、下記に書き方動画を配信しておりますので、ご参考にして頂ければ幸いです。