このブログの読者で、CSに関する方ならおなじみ、ALL STAR SAAS FUNDメンターの山田ひさのりさん。今回は、山田さんが独自に考案したというカスタマーサクセスにおける観点から見た「ライトサクセス／ディープサクセス」について、寄稿してくださいました。
この考えは、ALL STAR SAAS FUNDと山田さんで開講した「SaaS CS集中講座」でも取り上げています。以前の記事では、下記のように概念を説明しています。
「ライトサクセス」は業務課題を解決するサクセスのことで、顧客がQuick Winを繰り返し、結果として現場が満足するサクセスを実現できた状態。
「ディープサクセス」は、経営課題を解決するサクセスで、提供するプロダクトが業務の現場に完全に定着し、経営層が満足するサクセスを実現できた状態。
それぞれの違いを理解し、どのように活かすべきか。山田さんによる深堀り解説をどうぞ。
「Sansanだから通じるメソッドだ」は、本当か？
「ライトサクセス／ディープサクセス」の考え方は独自に考案したもので、国内外のSaaSやカスタマーサクセス界隈において一般的というわけではありません。
私は長らくSansanのカスタマーサクセス部門で戦略立案に携わる傍ら、カスタマーサクセスの情報発信にも力を入れてきました。発信する情報はSansanで養われ、鍛えられたCSメソッドの数々です。すると、こんなご意見をいただくことがありました。
「Sansanみたいに現場の支持を得やすいプロダクトであれば、そのメソッドも通じるかもしれませんが、うちのプロダクトは違う」
最初は自社への不満を漏らしているだけかとも思いましたが、主張をされている方々のプロダクトをつぶさに見てみると、提供している価値とそのサクセスの対象がさまざまであることに気づきました。つまり、サクセスしにくいプロダクトとしての共通性があるのではなく、他の観点によってメソッドが通じるか否かが判断されるようです。
そして、私はさらに観察を続け、「ライトサクセス」と「ディープサクセス」というカスタマーサクセスを整理する概念を考案するに至ったのです。
「『そのプロダクトが提供する価値は何か？』に向き合う（解を出す）のはカスタマーサクセスの重要な責務である」
これは私が常に主張していることですが、私自身、さまざまなSaaSベンダーを支援し、顧客のサクセスに向き合ってみると、プロダクトによって「サクセスのしやすさ」に差があることに気づいてきました。
より正確に言うと、そのプロダクトがサクセスさせるべき顧客内部にレイヤーが存在しており、プロダクトの浸透が進むにつれ、そのレイヤーが広がっていくことがわかってきたのです。さらには、プロダクトが進化する方向性を考えることと、サクセスさせるレイヤーを明確にすることに、深い繋がりがあることも知りました。
「SaaSにおけるサクセスとは何なのか？」
この記事では、SaaS業界の大きなテーマの一つであるこの問いについて、カスタマーサクセスの視点から考えていきます。
「2つのサクセス」という考え方
上記はALL STAR SAAS FUNDの「SaaS CS集中講座」の第2回で紹介したスライドです。
私は、CSにおける「サクセス」とは2種類に大別でき、それらを「ライトサクセス」と「ディープサクセス」と呼んでいます。
ライトサクセスの定義は（顧客の）現場にサクセスをもたらしている状態です。そして、ディープサクセスとは（顧客の）経営にサクセスをもたらしている状態です。
多くのSaaS関係者はこのことを体感していますが、明確に意識している人は少ないかもしれません。社内のビジネスサイドの方から「うちのプロダクトはROIを問われたときに弱い」といった会話が出てくるのであれば、この2つの概念を正しく理解していない可能性があります。
ライトサクセスとディープサクセスは「段階的に」発生する
典型的なSaaSプロダクトにおいては、ライトサクセスとディープサクセスが段階的に発生します。まずはライトサクセスで現場に業務改善効果を体感してもらい、それを増幅させて経営的な利益というディープサクセスへ繋げていくのです。言うは易しですが、実際には3年程度の時間をかけてジワジワと実現されます。
ただ、ビジネスサイドの方の多くはディープサクセスばかりに目が行きがちで、ライトサクセスを軽視する傾向があります。というよりも「顧客をディープサクセスさせなければいけない」という思いが強すぎて、ライトサクセスを軽視してしまう、あるいは全く考えることができないという思考に陥りがちなのです。
Sansanを例にとると、ライトサクセスとディープサクセスの関係は以下のとおりです。
ライトサクセス（現場が喜ぶ）
- 名刺を持ち歩かなくてよくなる
- 名刺フォルダーでデスク周りがかさばらない
- 名刺をもらった相手の連絡先をクラウド上で管理し、スマホから閲覧できる
ディープサクセス（経営が喜ぶ）
- オンラインとオフライン両方の接点をSansanに集約して顧客データベースを構築できる
- 人脈を社内で共有できるのでビジネスチャンスが広がる
「顧客がよりベネフィットを感じるのはどちらか？」と問われれば、明らかにディープサクセスでしょう。そのため、セールスフェーズにおいても、ライトサクセスで利便性をアピールしつつも、ディープサクセスが顧客の事業課題解決に資することを強くアピールします。
このような流れで受注した案件となると、顧客は当該SaaSの導入目的をディープサクセスに定めます。そうすると、案件を渡されたカスタマーサクセスも、自然とディープサクセスを至上命題として動いてしまうのです。
こう聞くと「それの何が悪いんだ？」と思われるでしょうが、上述したとおり、ディープサクセスの達成には時間がかかるのです。ディープサクセスは現場目線で見るとメリットが少なく見えるので、経営トップの強い意思と号令がなければ達成は難しいです。これはCRM導入に苦戦している日本企業の多さを見ても明らかです。
あるSaaSの購買を決定するのは、予算管理責任を持った経営に近いメンバーです。このレイヤーの方は、そのSaaSがディープサクセスをもたらしてくれることを期待して意思決定しますが、実際に使うのは現場です。よって現場の支持を得られていない、もしくは得る努力を怠っているケースでは、サービスが定着することは困難なのです。
カスタマーサクセスチームは、セールスチームからもたらされたディープサクセスへの期待（＝導入目的）を強く意識し、その達成を試みますが、実はその前にライトサクセスを達成しなければなりません。しかし、このことに気づいているカスタマーサクセス担当者は意外と少なく、長い時間と労力を要するディープサクセスを最短で達成しようとする道を選んでしまうのです。
ライト／ディープサクセス誕生以前の「Sansanのサクセス」とは
実はこのライト／ディープサクセスの発想には元ネタがあります。以前、私がSansan時代に活用していた「Behavioral Success」と「Operational Success」です。
この2つのサクセスの関係は、以下の図のように表していました。
上述のとおり、Sansanの価値はまず現場に表れます。それが図の中央にある「現場の習慣が変わる」です。これまで名刺を個人で管理していたのがクラウドに移り、ベテランの営業マンの間で「あるある」とされていたような、分厚い名刺ファイルの管理から解放されるのです。
また、Sansanは名刺をデジタル化するので、記載された情報の検索性や閲覧性も飛躍的に高まります。このように現場習慣の変容によってSansanが支持され、サービスが定着していくことは早くからわかっていました。
しかし、Sansanの真骨頂はここからです。われわれが作りたかったのは、名刺情報をはじめとしたあらゆる人脈情報がクラウドに集約され、それをビジネスに活かせるという世界です。私はこれを「現場の業務が変わる」と表現しました。今も昔も、Sansanはこの世界観を達成するために邁進しています。
しかし、私がカスタマーサクセスに従事していた2020年頃にあっても、上図右の「業務が変わる」にたどり着いている顧客ばかりではありませんでした。Sansanのプロダクト力が強いこともあって、中央の「習慣が変わる」が強く支持されてしまい、結果として「業務が変わる」への移行が積極的に行われないという問題も起きていたのです。そして、ビジネスサイドはこの現象を「業務に組み込まれるまでには至っていない」と表現していました。
上記の図は顧客への説明資料に記載されています。これを用いて説明する狙いは3点です。
- サクセスは段階的に発生するものである
- 顧客が真に望むサクセスに到達するにはそれなりの時間がかかる
- まずは、最初の段階のサクセスである「Behavioral Success」の達成を目指す
多くの場合、顧客はSaaSの導入が経営インパクトをもたらしてくれることを期待していますが、「ものには順序がある」ということを、顧客にも、社内のメンバーにも認識してもらうことが重要だと考えたのです。
今振り返ると、私はこのときにライトサクセス／ディープサクセスの概念を直感的に理解していたように思います。
さらに言うなら、Sansanの創業メンバーが今も昔も変わらずに主張していることも、Sansanのカスタマーサクセス戦略を練るのに役立っています。それは、「頭で『インパクトのあるサービスだ』と理解いただいていても、それが現場に定着するのは簡単ではない」といった意味の言葉です。
ライトサクセスがもたらす力
それでは、ここからは「ライトサクセス／ディープサクセス」について、それぞれ深堀りしていきましょう。
まずはライトサクセスの重要性について説明します。結論から言ってしまうと、ライトサクセスを達成できていれば1～2年程度の継続利用をしてもらえることが多いです。多くのSaaSは年間契約なので、顧客がライトサクセス状態であれば1回は更新してもらえる計算です。
なぜなら、私の経験上で、プロダクトが現場からの支持を得ていれば、たとえ経営が求める結果が出ていなかったとしても、継続の判断が出やすいのです。「現場が支持しているのなら、もう1年くらい様子を見てみよう」というわけです。
ところが、案件を担当しているカスタマーサクセスのメンバーがディープサクセスを意識しすぎると、現場のサクセス（＝ライトサクセス）が十分でないことが多く、ディープサクセスの道半ばで契約更新時期を迎えます。ここでセールスやカスタマーサクセスが決済者に働きかけ、「まだ道半ばなので頑張りましょう！」と鼓舞して合意を得られれば、事態は好転するかもしれません。しかし、現場も満足しておらず、経営成果も出ていないとなると、そのSaaSは間違いなく解約候補に入ります。
このような状況に陥っているSaaS事業者のなんと多いことか……そして、これが発生する主な要因は、ライトサクセスを意識したオンボーディングを行っていないことに尽きます。
プロダクト提供側は、そのプロダクトが理想的に活用されたときに顧客へもたらす経営インパクト（＝ディープサクセス）を熟知しています。なぜなら、顧客がその目的を果たすためにプロダクトが作られたからに他なりません。
しかし、プロダクトの考案・作成時にライトサクセスになる状態を意識してプロダクトを作っているSaaSベンダーは少ないのではないでしょうか。それはライトサクセスがROIを生み出しにくく、購買決定の主要因となり難いからでもあります。創業者の頭の中からこぼれ落ちやすいのです。
ただ、私の考えでは、提供するプロダクトにライトサクセスとディープサクセスの両方をもたらす力がないと、導入時点で間違いなく苦戦します。セールスやカスタマーサクセスの努力、そして何より顧客の業務リテラシーの高さや努力によって壁を突破できることもありますが、そう多くはないでしょう。
ビジネスサイドが「経営インパクトをなかなか実現できない」と嘆いている場合は、そもそもライトサクセスさせる要素が足りていない、もしくは顧客にそれを理解してもらう努力をしていないという点を見直すべきかもしれないのです。
ディープサクセス達成までの困難な道のり
ディープサクセスは、そのプロダクトがもたらす本質的なサクセスであり、顧客から見るとそのプロダクトの購買・導入目的になることが多いです（ただし、エンタープライズ顧客の場合は、ライトサクセスに着目して導入を決定されるケースもあります）。
しかし、ディープサクセスは顧客社内の企業文化や業務オペレーションそのものを変革させることと同義であることが多く、一般的には2～3年、もしくはそれ以上の年月を必要とします。
ERP（Enterprise Resource Planning）の導入は典型例です。導入の意思決定に大量の時間と費用を注いでいるため、その導入プロジェクトは経営層によってピン留めされ、皆がディープサクセスに向かって突き進みます。このときに、たまたまそのプロダクトがライトサクセス要素を持っており、かつ担当したカスタマーサクセスがそれを顧客に認識してもらう努力を怠らなければ、ライトサクセス状態になることもあります。
しかし、“たまたま”が発生しない場合、現場には「新たなツールとオペレーションへの習得」という重い負荷が課せられるだけであり、ディープサクセスが達成され、経営への効果が感じられるまで3～4年間は続きます。ディープサクセスを達成しきるには、長い年月と現場の忍耐が欠かせないのです。
その間に、事業方針の転換や導入決定者の異動が決まると、ディープサクセスは達成されず、ベンダーと顧客の両方に損失だけが残ります。
プロダクトの特徴と2つのサクセスの関係
このように書くと、まるで私がディープサクセスを否定しているように見えるかもしれませんが、そうではありません。あくまでも、<yellow-highlight-half-bold>ライトサクセスからディープサクセスに至るという順序を意識することこそが、SaaS事業が成功するポイントの一つ<yellow-highlight-half-bold>だと主張したいのです。
世の中にあるSaaSについても、ライトサクセス／ディープサクセスという観点から見ると、大まかに4パターンに分けることができます。
A：ライトサクセスのみが発生するパターン
B：ディープサクセスのみが発生するパターン
C：ライト→ディープが段階的に発生するパターン
D：ライトとディープが同時に発生するパターン
以下、細かく見ていきましょう。
A：ライトサクセスのみが発生するパターン
カレンダー調整アプリ、ビジネスチャットアプリ、経費精算アプリといった、経営課題になりにくい課題を解決するプロダクトに多いです。カバーする業務領域が十分に広い場合を除き、単体の機能しか持たないSaaSは、このパターンに区分されます。
このタイプのプロダクトは効果をすばやく実感できるため、現場の支持を得ること（＝ライトサクセス）は比較的容易です。導入目的も「現場の負荷軽減」にフォーカスされることが多く、カスタマーサクセスチームもそれに沿った支援をすれば、ライトサクセス状態になります。
欠点は、ライトサクセスしか発生しないため、便利ツールとしての域を抜けきれないこと。常に価格優位性のある競合他社との比較に晒され続け、価格がネックとなっての解約が多くなることです。
B：ディープサクセスのみが発生するパターン
CRMやERP、タレントマネジメントツールなど、導入・定着に期間を要するプロダクトが該当します。
ディープサクセスを成し遂げたときの経営インパクトは大きいのですが、そこに到達するまでに現場の心が折れやすく、セールスやカスタマーサクセスによる多くの支援が欠かせません。また、決裁者グリップによるキーマンへのアプローチも重要で、定期的な接触と関係構築が求められます。
そのようにこまめに活動しても、経営判断で導入プロジェクトが中止となり、突然の解約を申し出られるのもこのタイプの特徴です。顧客内部のパワーバランスに目を光らせる必要があります。
ライトサクセスがないため、顧客の現場から見ると「SaaSの導入によってかえって仕事が増えた」という印象だけが重くのしかかります。よって、カスタマーサクセスが顧客のモチベーションを引き上げて導入を推進させることが重要になってきます。
もっとも、経営インパクトが現場に返ってくるまで持ちこたえる必要があるため、支援側からするとかなりヘビーです。ただし、いざディープサクセス状態になると、プロダクトが顧客の業務にがっちりと組み込まれるため、長期継続を勝ち取ることができます。
C：ライト→ディープが段階的に発生するパターン
以前に『SaaS CS集中講座』において参加者アンケートをとったところ、全体の7割がこのパターンに属していました。
ライトサクセス→ディープサクセスが段階的に発生するため、まず現場の業務が効率化されることで顧客の支持を得た後に、その効果が経営にも波及します。ただ、ライトからディープへの飛躍が難しく、長い間にわたってライトサクセス状態に留まる案件も少なくありません。つまり、顧客からすれば「ライトサクセスのみが発生するパターン」と同じですから、コストカットに起因する解約の割合が増えます。
顧客の事業規模やステークホルダーが増えると、決裁者のグリップが重要になってくるという意味では「ディープサクセスのみが発生するパターン」と変わりはありません。ただ、カスタマーサクセスチームではライトサクセス→ディープサクセスへの変化の兆しを正確に読み取れない場合も多く、関係構築が後手に回ってしまうケースもよく見られます。
私の所感では、このパターンのプロダクトは、ライト→ディープサクセスと状態が変化することを狙ってデザインされたのではなく、「たまたまそうなっていた」というケースが多いようです。カスタマーサクセスチームも、これらの状態変化に気づかないまま顧客を支援していることも見受けられます。
カスタマーサクセスの活動が成熟しているSaaSベンダーにおいては、オンボーディングプログラムでライトサクセス状態に導くことを意識して活動しているところもありますが、非常に稀です。
D：ライトとディープが同時に発生するパターン
私自身もあまり見たことはないのですが、理論的には「現場課題の解決≒経営課題の解決」という式が成り立つプロダクトも存在します。おそらく、B2Bのバーティカルな業界をターゲットとしており、かつ小規模事業者向けのSaaSで発生しやすいと思われます。
顧客に対する基本的な向き合い方は「ライト→ディープが段階的に発生するパターン」と同様です。単にその移行期間が短いだけです。
2つのサクセスを意識し、プロダクト開発に活かす
それぞれのタイプにおける顧客支援の方針と注意すべきポイントはすでに述べていましたが、それらはビジネスサイドの話です。同時に意識しなければならないのは、プロダクトサイドについてです。「どのような機能を優先的に開発すべきか？」と密接に関係していますから、説明していきましょう。
基本的な開発方針としては、以下のいずれかであると考えています。
- ライトサクセスを後押しする方法がないので、それを支援する機能を作る
- ディープサクセスを後押しする方法がないので、それを支援する機能を作る
私は「プロダクトの進化は、そのプロダクトが持つミッションに基づいて行われればよい」と思っています。しかし、ビジネスサイドの現場からすると、顧客のサクセスを支援する機能がプロダクトに備わっていないために導入が停滞したり、解約に繋がってしまったりすることはよくあります。カスタマーサクセスにおいても特定の機能が充実していないために解約をほのめかされるのもよく出会うことです。
プロダクトサイドからすると、この種の要望に毎回応えていたのでは、いつまでたってもミッションを完遂できないでしょう。しかし、私のようなカスタマーサクセスに属する人間から見ると、「この要望は開発必須である」と判断できる軸がそれなりにあります。それが上述のライトサクセス／ディープサクセスから見る開発方針なのです。一つずつ見ていきましょう。
1.ライトサクセスを後押しする開発
すでに説明しましたが、ディープサクセスの達成には長い期間がかかる上に、達成までは顧客のメリットが薄いため現場の協力を得にくいという側面があります。もし、プロダクトがディープサクセス寄りであったり、現場のカスタマーサクセスチームに過剰な負担がかかっていると思われる場合は、ライトサクセスに資する機能を強化することでプロダクト戦略を筋肉質にできます。
一つの例を出しましょう。よく「SaaSはデータを保有したものが勝つ」と言われ、プロダクト開発においても重視されるケースがあります。確かにそれは事実です。価値あるデータを大量に保有できれば、狙うマーケットでの戦いは有利になります。しかし、このタイプのプロダクトはデータが大量に集まり、それに価値が宿って現場に戻って来るまでに長い時間を必要とするため、それまでの間は現場で使い続けるメリットが薄いのが欠点です。メリットが薄いプロダクトを顧客が契約し続けてくれる可能性は低いので、顧客をフォローするためにビジネスサイドへの人員投下を大量に行うことになる、と私は見ています。
仮に、あなたの所属する企業が提供するSaaSがディープサクセス寄りで、ビジネスサイドに大きな負担がかかっているとしたら、「われわれの顧客にとってのライトサクセスとは何か？」「そこに達するまでの期間をいかに短くできるか？」という発想を持つと良いでしょう。
ヒントとしては、
- カスタマーサクセスが当たり前のように行っている活動をプロダクトに埋め込む
- 顧客がクイックウィンを感じているとしたら、それをプロダクトドリブンでできないか考えてみる
などです。
ライトサクセスが弱いプロダクトは意外に多く、原因はそもそもビジネスサイドがライトサクセスを意識して活動していないことによります。カスタマーサクセスは自社の顧客のライトサクセス状態を定義し、自身の活動に「ライトサクセス状態まで顧客に伴走すること」を組み込むとともに、その達成に不足している機能をプロダクトにフィードバックすることに責任を持たなければなりません。
2.ディープサクセスを後押しする開発
私がSansan時代に苦労したことです。ライトサクセスまでは発生するものの、なかなかディープサクセスにたどり着かずに3～4年で解約されてしまうのです。ライトサクセスは顧客の現場から支持を得られている状態なので利用率も高く、カスタマーサクセスが油断してしまうことも少なくありません。
ディープサクセス未達のチャーンが発生すると、担当のカスタマーサクセスからは「現場からの意見で押し返しましたが、経営判断でやむなく解約となりました」という言葉が聞かれます。ディープサクセス未達の典型的な例です。そもそもディープサクセスは達成までに時間がかかりますが、経営目線で見ると経営インパクトのないサービスに投資し続けるのにも限界があります。
この場合、ディープサクセスを後押しする開発を行うことになりますが、この際も同じく「自社の顧客にとってのディープサクセスとは何か？」という問いに答えなければなりません。プロダクトのROIを算出する方法については以前の記事で書きましたが、そう簡単でもありません。
また、SaaSというものは元来、特定業務の問題を解決するためにサービス化されているので、顧客が真に望むビジネスサクセスを一つのSaaSだけで達成するのは、そもそも無理があるのです。
ここまで説明すると、ディープサクセスを後押しする開発が何なのかが見えてきます。それは周辺プロダクトの提供によるホールプロダクト化です。
先ほども書いたとおり、一つのSaaSで提供できるサクセスには限界があり、それがディープサクセス状態とまで言えないことは往々にしてあります。このような場合、プロダクトが解決すべき問題領域を広げることによってディープサクセスの「深さ」と「広さ」を向上させる手があります。
もちろん、一つのプロダクト上でそれを担っても問題ありませんが、新たな価値を既存のプロダクトに宿らせるか、別プロダクトで提供するかは慎重に判断する必要があります。一般的には、そのプロダクトが持つ価値をシンプルに表現・提供すべく、プロダクトを分ける判断がなされることが多いように見えます。
ただし、ディープサクセス状態に持っていけないからといって、必ずしも悲観する必要はないと思っています。いま流行りのProduct-Led Growth（PLG）がフィットしているサービスは、すべての顧客をライトサクセス状態にするものばかりです。PLGとライトサクセスは実は相性が良く、少ない人手で広いマーケットを取れるポテンシャルを秘めていると、私は見ています。現に、Slack、Miro、notionといったサービスは、すべてライトサクセスの色合いが強いのです（PLGについては、私が書いた別の記事もご参考ください）。
いま例に挙げたサービスは、ご存知のとおり非常に勢いのあるサービスであり、2022年現在では市場を席巻しています。スティッキーなサービスはいずれもライトサクセスを極めており、それによって現場ユーザーの支持を得ているので、突き詰めることにより市場で大きく勝てると証明されています。これが、ディープサクセスを持たないことを悲観しなくてよい理由です。
重要なのは「自社の顧客」の“サクセス”を知ること
私が最後に言いたいことは、これに尽きます。
<yellow-highlight-half-bold>重要なのは「自社の顧客」のライトサクセスとディープサクセスを知ること<yellow-highlight-half-bold>。
私も長年カスタマーサクセスに携わっていますが、顧客のサクセスに2つの状態があると気づいたのは1年半前、それを理論としてクリアに語れるようになったのはほんの半年前です。
おそらく、それほどにライトサクセスとディープサクセスは世間的にも業界的にも意識されておらず、セールスやカスタマーサクセスも「あいまいなサクセス」に向かって顧客支援をしているのが実態です。
しかし、自身のサクセス活動にこの2つの概念を入れて考えてみると、自社のプロダクトの強みや弱み、それらを踏まえた上で顧客を支援しつつ、プロダクト開発の方向性を検討することの重要性がくっきりしてきます。
私が支援しているSaaSベンダーにおいてはライトサクセスとディープサクセスを言語化し、「どの顧客が、どのサクセスまで達しているか」をマネージしているところも現れ始めています。その結果、顧客の状態をよりクリアに捉えられ、自社プロダクトの進化の方向性についても一定の気づきを得られているようです。
正直に言って私自身、この概念をカスタマーサクセスの活動に適用するのは、まだまだこれからといった感じです。ただ、「カスタマーサクセス（顧客の成功）」という抽象的な概念を整理するための切り口として活用できるよう、今後も探求しながら、関連情報を発信していきたいと思っています。
