B2B SaaSの価値「顧客体験サイクル」とは何か？
先日「顧客体験サイクル」というフレームワークを紹介する記事をengagemateで執筆しました。
今回のnoteでは、このフレームワークをB2B SaaSやカスタマーサクセスの文脈で説明することを目的としています。
よろしければengagemateの記事もセットでご覧ください。
追記：B2C文脈のnoteも追加執筆致しました。
数年前のある日のこと
私は、あるクライアントさんから悩み相談を受けました。
「岩田さん。ユーザーの継続率が改善されなくて困っています。。。アプリをインストールしたユーザーがある機能を使ってくれないのです。」
「その機能を使ってもらえればサービスの価値を体感し、継続しやすくなることは分かっているのですが、、、なぜかその途中で離脱してしまうのです。」
私は、Reproのメッセージ配信機能を使ってつまずいているユーザーを救う施策を提案しました。これは他社でも改善実績がある施策で、まず間違いなく効果が見込めるものでした。
参考イメージ：Slideshare p6を参照
「それは良さそうですね！配信したいと思います！！」
クライアントはそう言ってくれましたが、しかし、その後メッセージを配信してくれることはありませんでした。
・なぜメッセージを配信してくれなかったのでしょうか？
・何か私の支援やサポートが適切でなかったのでしょうか？
・それともプロダクトの機能が不足していたからでしょうか？
何がいけなかったのか？当時の自分には理解できませんでした。
なぜなら、その要因を見つける視点を持ち合わせていなかったからです。
「顧客体験サイクル」というフレームワークのレンズで見通せなかった当時の自分は、その理由に気付く事ができませんでした。
顧客はジョブを片付けるために体験を雇用している
そのレンズと出会ったのは、クライアントに導入インタビューを行った日の事でした。
「なぜ当社のプロダクトを導入したのですか？」
私は質問しました。
するとクライアントは
「素早くPDCAを回したかったのです。」と答え、続けます。
「ビジネスサイドとしてはすぐに仮説を検証したい。しかし社内の開発リソースが限られているため気軽にエンジニアに頼むことが難しかったのです。」
「『その施策、本当に開発の工数をかけてまでやるべきなの？』というエンジニアサイドからの反論に対し、ファクトをもって立証できなかったんですよね。」
「だからエンジニア工数をかけずにPDCAを高速に回す為に、御社のプロダクトを導入したのです！」
その言葉にハッとさせられました。
そうか、だから契約してくれたのか。だからツールを活用してくれるのか！
私は気付きました。顧客は「エンジニアに工数を借りることなく素早くPDCAを回したい」という『ジョブ*1』を片付ける為に、サービスを雇用していたのです。
より正確に言うなら
・アナリティクス画面から分析を行い施策を企画し
・マーケティング 機能を使い施策を実行し
・配信結果画面から分析評価し
・さらなる改善につなげる
という「体験プロセス」を雇用していたのです。
つまり、クライアントはジョブを片付けるために、体験プロセスを雇用し、その結果としてKPIを改善しサービスを成長させる「成功」を望んでいた。
新しい視点をもたらす「レンズ」を発見した瞬間でした！
「SaaSは機能を売っているのではなく体験を売っている」そう言われる理由が明快に腹落ちしました。物事の構造が鮮明に見えたのです。
「顧客体験サイクル」というフレームワーク
「顧客は状況に沿ったジョブを片付ける為に、体験を雇用し、結果として成功を望んでいる」
この視点に気付いてすぐに他の顧客の状況はどうか？と観察しました。
すると、エンジニアを外部の開発会社に委託しているケースもあれば、同じチームメンバーとして機動力高く動けるクライアントもあり、状況は様々でした。
クライアントの状況ごとに「片付けるべきジョブ」も異なっていたのです。
しかし、雇用される体験は共通していました。
・ツールの導入の設定をする
・管理画面から現状と目標数値を確認する
・アナリティクス画面から分析し課題を発見する
・課題を解決する施策を立案し企画する
・マーケティング施策を配信する
・配信結果画面から分析と評価を行い
・マーケティング施策を改善する
どのクライアントも共通して一連の体験プロセスを繰り返していたのです。そして循環する体験プロセスの中で、体験に該当する機能が利用されていました。
その姿はぐるぐると循環するサイクルのようでした。
「顧客体験サイクル」
私は新たなレンズに、そう命名し、定義しました。
顧客はこれらの体験プロセスをぐるぐると繰り返し、プロダクトの機能を利用していたのです。この体験サイクルの回転に沿ってマーケティングのPDCAを回すことが、顧客のKPI改善を生み、成功を導いていたのです。
顧客体験サイクルの回転により成果や成功が得られるからこそ、継続して月額費用をお支払い頂ける。つまりLTVに繋がるのです。
とてもシンプルな姿でした。
顧客はそれぞれの状況に沿ったジョブを片付けるために、顧客体験サイクルを雇用していたのです。そして顧客は、その顧客体験サイクルの回転が生み出す成果と成功を望んでいたのです。
プロダクトバリューとコミュニケーションバリュー
顧客体験サイクルはとてもシンプルなモデルです。
顧客体験サイクルを定義し、価値提供してサイクルの回転にフォーカスすればよいのです。
では、どのように価値提供していけばよいでしょうか？
大きく2つの価値があります。
・プロダクトバリュー
・コミュニケーションバリュー
です。
プロダクトバリューはその名の通りプロダクトの機能価値です。
例えば、マーケティングのABテスト機能を開発することで、簡単に施策を評価できるようになります。この機能の開発により「評価する（Check）」における体験価値を引き上げます。より手軽にマーケティングの効果検証が行えるようになり、顧客体験サイクルが回転しやすくなります。
コミュニケーションバリューは、顧客体験サイクルの回転を促すコミュニケーションの価値です。
使い方が分からない顧客は、機能を使いこなせずプロダクトバリューを享受することができません。エラーに直面しても、ドキュメントが不足していれば、自己解決ができず機能本来の価値を体感できません。メール、動画、SNS、コミュニティ等のコミュニケーションチャネルを活用し、コミュニケーションバリューを磨き上げることでサイクルの回転を促すことができます。
したがってカスタマーサクセスやカスタマーサポートもコミュニケーションバリューに該当します。
CSの役割はあくまでサイクルの回転促進です。顧客をプロダクトバリューポイントまで届けるのが仕事です。CSがプロダクトバリューを越える価値を提供することはできません。*2
あくまでプロダクトバリューのギャップを埋める位置づけなのです。プロダクトバリューとコミュニケーションバリューは明確な主従関係にあり、体験価値の上限キャップはプロダクトバリューに依存します。「カスタマーサクセスは価値のギャップを埋める仕事である」と言われる事からも理解できます。
図：CSは製品価値のギャップを埋める仕事（The Customer Success Professional's Handbook）
回転価値にフォーカスせよ
顧客体験サイクルというレンズで見通せば「機能か vs サポートか」という二項対立の不毛さに気が付きます。
シンプルに回転にフォーカスすればよいからです。
・素晴らしいプロダクトバリューがあってもサイクルが回らなければ意味がありませんし
・またプロダクトバリューが低ければ、どれだけCSがゴリ押し提案しても、サイクルが回転することはありません。使い物にならない酷い機能を活用する顧客はいません。
サイクルの回転という視点に立てば、プロダクトバリューとコミュニケーションバリューの両輪が必要なことに気がづきます。
摩擦係数ゼロの自動回転を目指せ
顧客体験サイクルの理想は、風車のように「自動で」回り続ける状態です。
CSMが人力でグリップし、ゴリ押しで体験サイクルを回しているケースの場合、CSM担当者がいなくなった瞬間にサイクルが止まり、解約に繋がります。
一方で、顧客自身の力で体験サイクルを回し自走している顧客は、CSのサポートの手を緩めても体験サイクルが回り続けます。
上述したようにプロダクトバリューが低くPMFを達成していないプロダクトの場合、顧客自身の手で体験サイクルを回すことはできません。またCSがゴリ押しで回転を促しても摩擦が大きく相当なパワーを必要とします。
オンボーディング支援で一度使い方を教えてあげれば、自動で体験サイクルがくるくると回転する。そんな摩擦ゼロの風車が理想的な顧客体験サイクルです。
イメージ図：理想は摩擦係数が低い風車
摩擦を減らし回転力を加える
では顧客体験サイクルの摩擦を減らし、回転力を加えるためにはどうすればよいのでしょうか？どのようにコミュニケーションを改善すればよいのでしょうか？*3
ペインの発見と対策が必要ですが、顧客体験サイクルは抽象度の高いモデルであるため、このまま活用することはできません。なぜなら顧客の状況によって片付けるべきジョブが異なるためです。抽象から具体にブレイクダウンする必要があります。*4
例えばN1分析*5 やデプスインタビューを行い体験プロセスを詳細にブレイクダウンするアプローチが効果的です。
ここで冒頭でお話ししたクライアントへの提案ストーリーに戻りましょう。
「良さそうですね！配信したいと思います！！」
そう言ってくれた顧客は、活用してくれませんでした。
なぜ使われなかったのでしょうか？
これを顧客体験サイクルのフレームワークで見通し、「企画」→「実行」のプロセスを詳細にブレイクダウンしてみます。
すると、デザイナーへの依頼プロセスが必要だったことが分かります。
そう。
・クライアントはデザイナーの工数が確保できなかった
・そして、デザインレギュレーションレビューを通すことができなかった
という２つのペインに直面していたのです。担当者の方は施策を実施したくても、できなかったのです。
私は「あなたの課題解決にはXXな施策がオススメですよ！」という事例紹介のレンズでしか物事を見れていませんでした。顧客体験サイクルというレンズで見通し、成功に向けた支援を行うべきでした。
もっとコミュニケーションバリューを工夫すべきでした。*3
キックオフミーティング時にデザイナーの工数が必要である旨を伝え、工数確保を依頼する必要がありましたし、レギュレーションチェックフローを顧客内に組み込んで頂くよう支援するべきでした。
このように、摩擦を減らし回転力を加えるためにはペインの把握が必要です。そしてペインはジョブの状況ごとに異なるため、抽象から具体へのブレイクダウンが効果的です。
初速のサイクル回転速度「Time To Value」
風車をくるくると勢いよく回転させるには、どのタイミングに力を注ぐべきでしょうか？
言わずもがな、風車が停止しているタイミングです。ペダルの漕ぎ始めに強く力を入れれば入れるほど、速く、長期間にわたり回転が持続します。
顧客体験サイクルでも同様の事が言えます。
初速の回転速度が最も重要なのです。
つまり価値を感じるまでの時間Time To Vale（TTV）を短くする事に等しいのです。
TTVは契約更新、アップセル、解約に最も影響を与えるドライバーです。*6
実際に、良好な関係を築き成果を出せた顧客と、上手く成功を届けられなかった顧客、それぞれをプロットしたデータを見ると、早期に成功体験を届けることがKSF（Key Success Factor）であることが分かります。
TTVの遅れは致命的です。
ツールの導入設定作業をズルズルと長引かせると、担当者の契約初期のモチベーションが失わます。こうなっては最後、どれだけ頑張って提案しても挽回することが困難になります。最悪、解約に至ります。
顧客体験サイクルの初速の回転速度を速めて、TTVを短くし、早期に価値を届けましょう。
回転だけでは不十分。成果を届けよ
顧客体験サイクルにフォーカスし回転数を上げる。そうすれば機能利用頻度も向上します。しかし、それだけで十分でしょうか？
当然、否です。活用度が高くても成果に繋がらなければ解約に至ります。
成果と成功。これを顧客に届ける必要があります。
顧客体験サイクルの回転だけでは不十分。顧客の成果と成功に繋げることが必要です。Gainsightの提唱するカスタマーサクセスの方程式「CS = CX+CO」*7 からも分かるように、Outcome（成果）が必要なのです。
カスタマージャーニーマップへの変換
サービスを契約した顧客はどのような流れで、サイクルを回転させ、成果を得るのでしょうか？その軌跡を追っていくと
・顧客がプロダクト導入の設定を行い
・顧客体験サイクルを回しはじめ
・体験サイクルの回転に伴って機能を利用し
・最終的に成果を得る
というカスタマージャーニーマップであることに気が付きます。顧客体験サイクルを回転させ成果に繋げられれば、自動的にカスタマージャーニーマップのステップが進みます。このように状況に応じて２つのフレームワークを変換し、行き来しながら活用することが可能です。
またカスタマージャーニーマップを顧客体験サイクルに変換して考えることで２つの利点があります。
１つ目は、終わりのある一直線のファネル型ではなく、ぐるぐると回転する永続的なサイクル型として識別できる点です。一度成果を得た顧客であっても、１年２年経過すれば状況が変わり、顧客体験サイクルの回転数が落ちるケースもあるでしょう。また、担当者が退職し、突然サイクルの回転が停止する解約危機にも気付くことができます。
サブスクリプションモデルは永続的な関係性のビジネスであり、ゴールテープは存在しません。このレンズは永続的にカスタマージャーニーマップを捉え直す視点を提供します。
２つ目は、カスタマーエンゲージメントから逆算したCX改善（Customer Experience ）につなげやすい点です。
極端な例ですが「顧客との打ち合わせで高級茶を入れておもてなしするCX改善」はインパクトがあり効果的か？と言われれば否でしょう。お茶は極端ですが、「期待以上のサービスを提供しようとして過剰なおもてなしを行っても顧客ロイヤルティには影響がなかった」という失敗に我々はよく陥ります。*8
顧客体験サイクルを考えることで、改善したCXがサイクルの回転を生んでいるか？エンゲージメントに繋がっているか？顧客の成功につながっているか？という視点で判断しやすくなります。*9
引用元：engagemate：CE (Customer Engagement) と CX
まとめ
・顧客は状況に沿ったジョブを片付けるために体験プロセスを雇用し、成果を望んでいる
・その体験プロセスが「顧客体験サイクル」であり、サイクルの回転によって、機能が利用され、顧客は成果を得る
・回転価値にフォーカスすることが大切であり、プロダクトバリューとコミュニケーションバリューの両輪で価値提供する必要がある
・理想的な顧客体験サイクルは摩擦ゼロで自動回転する状態
・摩擦を減らし回転力を加えることが必要だが、具体的な対策を講じるためには抽象から具体にブレイクダウンする必要がある
・とくに初速の回転速度が最重要であり、Time To Valueの最短化そのものである
・回転だけでなく成果まで追う必要がある
・顧客体験サイクルとカスタマージャーニーマップ、２つのフレームワークを変換し行き来して活用することが効果的
とてもシンプルです。顧客の状況（ジョブ）に合わせて、顧客体験サイクルの回転を考え、成果を届ける。それが結果としてMRRに繋がるのです。改めてSaaSビジネスの美しさを痛感します。
なお、このフレームワークの別角度からの活用事例はengagemateにて執筆しています。ぜひご覧くださいませ。顧客体験サイクルというフレームワークのレンズが少しでも役に立てば幸いです。
追記：またB2C文脈のnoteも追加執筆致しました。
余談：このフレームワークが使い物にならないケース
フレームワークは便利な道具ですが万能ではありません。必ず活用が難しいシチュエーションが存在します。顧客体験サイクルのフレームが適応困難なケースを以下に記します。
1.抽象から具体にブレイクダウンしない／難しいケース
このフレームワークは非常に抽象度の高いフレームワークです。抽象度の高いまま扱っても良いインサイトは出にくいため具体化が必要です。そのためあまりにもシンプルすぎて体験プロセスをブレイクダウンできないプロダクトの場合、フィットしずらいでしょう。
例えば「えんぴつ」というプロダクトを扱う場合、シンプル過ぎて、顧客体験サイクルとは異なる視点で考えたほうが良いことは直観的に分かります。
2.片付けるべきジョブが多様に分散するケース
雇用される理由であるジョブが多岐に渡り、共通化が困難なケースでは適応しずらいでしょう。
例えばSpotifyは多様なジョブを持つプロダクトです。「落ち込んだ気分を解消したい」「TVで聞いた曲名を調べたい」など多岐に渡るジョブの解決が求められます。「聞く」⇆「出会う」というシンプルな顧客体験サイクルでは、有効な打ち手を立案する難易度が高いです。もちろんジョブの状況別に具体的な体験サイクルを定義すれば有効に働きますが、ジョブが多様であればあるほど活用困難になります。
3.関係性が不要な非循環型のビジネスモデルのケース
例えば1生に1度しか訪れない観光地では、体験がサイクルのように循環することはありません。顧客体験サイクルで考えるよりも「来店ジャーニーと価値のポジショニング」といったフレームで考えたほうが幾分か良いかもしれません。
4.顧客体験サイクルの回転が自社の売上に一切繋がらないケース
このフレームワークは「回転が自社の売上に繋がる」という前提条件の上に成り立っています。そのため「顧客体験サイクルが高速で回転しているのに、なぜか売り上げが立たない・・・」というビジネスの場合、このフレームは適応できません。顧客体験サイクルの定義を根本的に間違えており再定義が必要か、はたまたマネタイズ設計の見直しが必要だと言えます。
5.サービスの競争優位性を説明したいケース
顧客体験サイクルの改善にフォーカスすると「全ての体験をリッチに改善しよう」「全ての体験に投資しよう」という視点に陥りやすくなります。しかし現実は選択と集中の世界です。顧客体験サイクルは「本当にその体験価値に投資すべきか？」という問いに解を与えるものではありませんし、スイッチングコストを説明付けるものではありません。サービスの競争優位性を整理する場合は別の視点が必要です。
6.担当者、決裁者、代理店などのステークホルダーを考慮するケース
現場担当者の顧客体験サイクルが回転していても、決裁者の判断で解約に陥るケースがあります。このように活用するステークホルダーが複雑に絡み合う場合、その影響を正確にモデリングすることは難しくなるでしょう。
それぞれのステークホルダーの顧客体験サイクルをマージして統合モデルに組み替えたり、顧客体験サイクルにステークホルダー軸を加えてフレームを拡張したりする必要があるでしょう。
注釈および参考文献
*1：ジョブ理論 イノベーションを予測可能にする消費のメカニズム
クレイトン・クリステンセンは消費のメカニズムを解明する考え方「ジョブ理論」を提唱しました。「ジョブ」とは、ある特定のシチュエーションで顧客が成し遂げたい進歩のことです。顧客はジョブを片付けるために特定の製品やサービスを消費しており、その消費行為を「雇う（ハイア）」と呼びます。顧客体験サイクルはジョブ理論からインスピレーションを受けて考えたフレームワークです。
*2：「カスタマーサクセスがプロダクトバリューを越える価値を提供することができない」と書きましたが厳密には正しくありません。例えば、人によるサポートそのものが価値となるサービスはこれに該当するからです。サービスによります。また他には、プロフェッショナルサービスとしてプロダクト以上の価値を提供するケースは、プロダクト価値を越えます。ここについては礒野さんの図解（3枚目）が分かりやすいので参考にして下さい。
改めてカスタマーサクセスが向き合うべき2つのGapについて自分用に整理。顧客期待値が高すぎたりベクトルが異なっているときは「弊社では対応できない領域です」ときっぱり言うのもカスタマーサクセスの仕事の1つだなと思っています。もちろん代案の提示や関連パートナーの紹介などは忘れずに。 https://t.co/CfRWOF5oui pic.twitter.com/mI5epK9Fhv
— Wataru Isono (礒野 亘) @カスタマーサクセス兼インサイドセールス (@wataridori89102) June 14, 2020
*3：顧客体験サイクルはプロダクト開発視点で活用するフレームワークであり、本来はプロダクトバリューの改善も考える必要があります。しかし本noteではプロダクト開発文脈を割愛し、コミュニケーションバリューに焦点を絞って（カスタマーサクセス文脈で）解説しています。
*4：ブレイクダウンする際は、片付けるジョブのシチュエーションに沿って詳細化していくと効果的だと考えられます。ジョブのパターンが多くなるほどブレイクダウンのパターンが増えます。engagemateの記事でも説明しています。
*5：たった一人の分析から事業は成長する 実践 顧客起点マーケティング
たった一人のユーザーからインサイトを得る分析手法を「N1分析」と呼ぶ。
*6：Farm Don't Hunt: The Definitive Guide to Customer Success
Time To Valueのインパクトより
日本語要約はこちら
*7：The Customer Success Professional's Handbook
カスタマーサクセスの方程式 CS = CX + CO（Customer Success = Customer Experience + Customer Outcome）より
*8：おもてなし幻想
「期待値を上回ってもロイヤルティに影響がない。期待値を下回ることを防ぐことの方がロイヤルティに影響する」という調査結果より。
*9：「CEにつながるCX改善」という視点の有効性は、プロダクト開発文脈で考えるとより実感できます。例えばSaaSでは「大規模な目玉機能を開発したが一切使われず、細やかなUX改善の方が活用へのインパクトが大きかった…」という直観に反するケースに直面します。これもサイクル回転の寄与度で考えれば説明がつきます。サイクル回転に貢献しない目玉機能は全くの無駄だったのだと。