見出し画像

カスタマーサクセス立ち上げの失敗学 -こうしておけば良かった?CSの始め方-

はじめに

 こんにちは、カミナシの細見です。
2024年8月に、カミナシは3つ目のプロダクト「カミナシ従業員」を正式リリースしました。

私も新規事業チームに移籍し、これまでの「カミナシレポート」での3年間の経験を活かしつつ、マルチプロダクトでのカスタマーサクセス立ち上げに挑戦しています。

私自身3つ目のSaaSプロダクトに携わり、そのうち2回目の0→1フェイズでのチャレンジになりました。
 カスタマーサクセスの役割や機能は、プロダクトの特性、利用するユーザー、事業フェーズ、そして会社の状況によって大きく異なると感じています。私の体験からも、必ずしも「こうすれば良かった」と一概に言えるものではありませんでした。今回は、「こうしておけばよかった」や「こうしたことで失敗した」という、いわゆるしくじりパターンを、自分の経験をもとにご紹介します。
このnoteを通じて、読者の皆さんのカスタマーのサクセスをより効果的に導けるヒントになればと思います。

このnoteはこんな方におすすめできそう

  • カスタマーサクセスの概念をこれから構築しようとしている方

  • 0→1のカスタマーサクセス立ち上げに奮闘している方

  • マルチプロダクト化のカスタマーサクセス戦略に興味のある方

このnoteの前提の考え方

  • 主にBtoBサービスを前提に記載しています。

  • 私がマルチプロダクトの2つ目以降のサービスを立ち上げる環境で働いているため、それに基づく認知バイアスがややあります。

  • 細かい前提条件はここでは全て記載しきれないため、もし興味があればぜひ直接お話しましょう…


結論

カスタマーサクセスの立ち上げを担う上で、振り返ると次のような落とし穴に気をつける必要があったと振り返ります。



1. カスタマーの成功状態を”チーム全員”で定義できていない

 プロダクトの構想段階では、そのプロダクトが誰の何をどのように解決するのかをチーム全体で議論することが多いと思います。しかし、その議論が事業進行とともに薄れ、最悪の場合、忘れ去られることがしばしば発生します。

カスタマーサクセスの成功状態を定義することは、単にサクセス部門の責任ではなく、プロダクトに関わる全員で共有すべき問題です。開発チームはもちろん、マーケティングや広報など、すべての関係者がカスタマーの成功状態を正しく共通言語化し、認識を同期したうえで、取り組むことが極めて重要だと感じています。(その理由は後述しています)

すべての機能が同じ理想像で考えていることが重要

2. サービスにおけるカスタマーサクセスの存在意義をチームで明確にできていない

 カスタマーサクセスの最も重要な役割は、当然、「お客様に自社のサービスを長く利用していただくこと」です。同時に、アップセルやクロスセルなど、プロダクトの特性や顧客の属性によって、カスタマーサクセスが求められる役割やミッションを変える必要があります。

たとえば、初期契約段階では、試してから始める必要性が高いプロダクトの場合、はじめは小さい契約からスタートし、利用が進むと同時にいかに顧客の裾野を広げていくか?重要な観点になってきます。
この様に、漸次的に利用範囲を広げるプロセスが重要な場合もあり、そのためカスタマーサクセスの指標を定めていく必要があります。

また、カスタマーサクセスは、「ご契約いただいたプロダクトを滑らかに導入してもらうこと」”だけが” 役割ではありません。あくまで導入を滑らかに支援するのはあたりまえで、「利用いただくことでなんらかの価値を顧客が享受できることを支援する」ことが本質だと考えています。

このような考えのもと、単なる「導入支援」を超えた存在価値を議論し、『継続率を高める以外に、このプロダクトにおいて、「今」カスタマーサクセスの最も重要な役割はなにか?』を正確にチームで定義することが大切だと考えます。

これは、経営層やマネジメント層も正しく認識し、フワッとした役割定義になっていないか?の定期レビューを行うことも重要かもしれません。


3. プロダクトの利用状況を初期段階から取得可能な設計にしていない

 カスタマーサクセスに携わったことがある方なら、一定のタイミングで顧客の状態を定量的に把握することの重要性を感じるのではないでしょうか。しかし、プロダクトが成長してから必要な利用状況を取得しようとすると、開発チームに大きな負担がかかってしまうことがしばしば発生します。

前述したような、カスタマーサクセスの定義をチームでしっかりと決め、その定義に基づいた逆算的なプロセス設計を行うことで、あなたが必要なタイミングで必要な顧客の利用状況を取得できるようになっているはずです。
そのため、早い段階から取得を念頭に置いた設計を行うことを、開発に携わっているチームと連携を行っておくと吉です。


4. すべてのミーティングに目的やゴールを設定できていない

 カスタマーサクセスの時間の多くは、顧客との打ち合わせです。オンボーディングプログラムを設計する際にも、このミーティングを基準に考えることが多いです。しかし、ミーティングごとの目的や機能を決めておらず、無意味な時間になってしまうことをこれまで多く経験してきました。
例えば、60分のキックオフミーティングであれば、終了時に顧客にどのような状態・感情を期待するかを決めます。そして、そこから逆算してミーティングの内容や、顧客に事前に準備してもらうことを決定しておくことが大切です。

 これらを、成果を実感してもらうことから逆算できれば尚理想的です。それが難しい場合は、導入支援の完了(2〜3ヶ月程度)を目安にして、短期的なサイクルで逆算して考えることも有効です。

各ミーティングに魂と意志を込める

5.プロダクトの展望や実装時期をチームと同期する機会を設けていない

 初期段階のサービスでは、機能の実装時期や優先順位が頻繁に変わることが日常茶飯事です。カスタマーサクセスは顧客への説明、サポートプログラムの調整、ヘルプページの更新などを迅速に行う必要がより多くあります。特に、開発チームとカスタマーサクセスが物理的に別チームである場合、情報が自動的に伝わるのを待つのではなく、カスタマーサクセスが主体的に情報を取りに行く仕組みを構築することが重要です。これは、後述する「顧客との期待値調整」にも大きく影響します。


6. 顧客からのフィードバックを迅速に開発にフィードバックする仕組みを作っていない

 カスタマーサクセスは、ユーザー体験の最前線で重要な情報をインプットする(できる)役割を持っています。この情報を、どれだけ迅速かつ正確にチームに還元できるかが、初期の成長ドライブにおいて非常に重要だと考えています。
開発チームとの定例ミーティングを待つのではなく、発生したその日のうちに、情報を共有する仕組みを整えることが大切です。また、少人数で運営している時期は、その負荷がより最小化された仕組みを心がけておくことも重要です。

VoCの回収運用フロー※あくまでイメージです

また、ただの情報共有ではなく、その背後にあるユーザー行動やその必然性を捉え、「As-Is(現状のユーザー体験とその発生する経緯や理由)」と「To-Be(ユーザーが理想する行動や期待)」を理解したうえで共有することが重要です。特に、初期段階では、ユーザーがなぜその行動を取るのか、その背景や情景を正確に理解することが貴重な情報源になります。社内還元する情報の質と量に迷ったときは、エンジニアやプロダクトマネージャーにヒアリングして構築することもお勧めです。


7. 顧客との期待値調整を丁寧に行っていない

 初期段階のプロダクトは機能が不十分である場合が多く、それでも契約をいただく顧客は、サービスの特筆した課題解決力や将来の展望に期待してくださるケースが多いです。カスタマーサクセスは、その状態に対応するために、サービスの展望や実装スケジュールを顧客に滑らかに伝える必要があります。
特に、営業段階で意図せずサービスの魅力が過大に伝わっている場合もあります。正確な情報を、速やかに絶えず顧客と共有する習慣をつくることも大切です。


8.プロダクトの最終的な関所として機能していない

 新規プロダクトでは、まずご契約いただく数を早期に伸ばすことが重要視されます。そのため、売れるための機能や改善が優先されがちです。(これは当然のことです)
しかし、顧客との折衝を通じて、どの改善が重要なのかを正確に社内に伝えることもカスタマーサクセスの重要な役割です。

イケイケドンドンのムードだけに流されず、冷静な視点を持ち続け、ゴールキーパーとしての役割を果たすことが求められます。
特に、スケールした際に、「ユーザーの運用負荷になってしまう機能」や、「利用拡大の足かせになってしまうユーザー体験」は、利用してみないとわからないことも多く特にカスタマーサクセスは社内にほどよい危機感と、一次情報を連携することが重要だと考えます。

右側はカスタマーサクセスでないと気付けないことが多い

9. 仕組み化を優先しすぎて、N=1の顧客事例がつくれていない

 少数で多くの顧客を担当している場合、契約顧客が次々に増えていき、プログラム通りに進めることに追われてしまいがちになることもしばしば。

しかし、初期段階のカスタマーサクセスに求められるのは、自社のサービスを活用して顧客に価値を提供した成功事例をいち早く作ることも忘れてはなりません。これにより、マーケティングから受注までの共通項をいち早く見出し、プロダクトの早期PMF(プロダクト・マーケット・フィット)を促進できます。時には、「多くの顧客を安定的にするために『仕組み化ばかりに注力する』ことよりも、『この業界での、あるいはこの企業での成功事例を作る』ということを優先する」判断が必要になることを忘れないようにしています。


10.最初から完璧を目指してしまう

 ここまで様々な点を挙げてきましたが、最も重要な考え方の一つだと感じるのが、「最初から完璧を目指さない」ことです。
カスタマーサクセスの初期段階では、プロダクトも成長途中であることが多く、プロダクトの方向性や価値が変わることは日常茶飯事です。
そのため、変化を前提にして、メンタルとバイタリティを保ちながら取り組むことが重要です。「明日にはこの仕組みもプロダクトも変わるかもしれない」と考えておくことで、健全かつスピード感を持って取り組めるような気がしています。


最後に

最後まで、お読みいただきありがとうございます!
これまでの体験や経験から、カスタマーサクセス立ち上げ時のしくじり事例についてご紹介しました。
ぜひ、みなんさんのご経験されている、しくじりもぜひ教えてください〜

このnoteを最後まで読んでくださった方は、カスタマーサクセスの立ち上げにきっとお好きな方・・・のはず・・・一緒にやってみませんか(まずはカジュアルにお話しませんか✋️)


いいなと思ったら応援しよう!