カスタマーサポートを10年以上経験したプロダクトマネージャーが考えるカスタマーサクセス
前書き
カスタマーサクセスとして目指すゴールがふわっとしている、カスタマーサポートの経験を生かしてカスタマーサクセスを実現したい、そんな人たちの参考になればと思い、プロダクトマネージャー兼カスタマーサクセスとしての成功体験を基にまとめました。
改めましてフィードフォースの岡田風早です。好きなゲームは龍が如くです。
今まで会社ではポケモンの話に混ざれなかったのですが、1月からスジモンマスターを目指して会話に加わりたいと思ってます。そのスジの方々、よろしくお願い致します。
カスタマーサクセスバブルすごいですね。新卒がカスタマーサクセスに配属されたり、多くのコミュニティが作られカスタマーサクセスとしての戦略や指標を何にすべきかなどが議論されることは素晴らしい事だと思います。まだカスタマーサクセスという言葉が存在しなかった頃からカスタマーサポートをしていたので、未だに不思議な感じがしています。
私が4年前にフィードフォースに転職したきっかけは、受け身ではなく攻めのカスタマーサポートをやりたかった事が一番の理由でした。当時はユーザーからの問い合わせに対応する受け身のサポート主流だったため、コストセンターと捉えられがちでした。
そのような受け身の体制ではなく、ユーザーがサービスを利用する過程で躓くポイントを人力ではなくデータを活用して問い合わせが来る前に改善を繰り返し、かつ時代のトレンドを汲みつつ、時にはお客様へインタビューをしてユーザーの目的を最短距離で達成(課題解決)できるような新機能の提案を出来る、そんな攻めのカスタマーサポート(今で言うカスタマーサクセス)を実現したいと思い、フィードフォースではソーシャルPLUSのカスタマーサクセス立ち上げを経てプロダクトマネージャーをやりました。
提供するサービスが BtoC なのか BtoB なのか、手軽に導入・利用できるプロダクトなのか開発が必要なのか、継続的に画面を操作するサービスなのか導入したら手離れが良いのかなど、プロダクトの形によりカスタマーサクセスのベストなアプローチは異なります。
私自身がエンジニア含む15人ほどのチームで BtoB の SaaS プロダクトを成功に導いた経験を基に、BtoB のプロダクト視点でカスタマーサクセスが目指すべき形をまとめました。
前回の記事に続き今回も読了率を無視した長文になるので何卒よろしくお願い致します。
チームにおけるカスタマーサクセスの役割を明確にする
外部の人と話す機会でも新しくカスタマーサクセスを立ち上げたという話をよく聞くようになりました。なんとなくアップセル・継続率向上・解約を減らす事が目標になっているケースも耳にしますが、それらはカスタマーサクセスとしてやりきったうえでの最終的な指標になります。重要な事はその手前にどんな指標を置く業務設計にするかです。
カスタマーサクセスとはその名の通り、ユーザーを成功に導く事が仕事になるため、ユーザーにとっての成功が必ずしも高いプランへ移行する事ではありません。
BtoB の SaaS という視点で考えると、プロダクトとして重要な役割はユーザーとなる企業の課題を解決できる事になります。そのため、カスタマーサクセスとしての重要な役割はユーザーが躓く事なく課題が解決できるよう、時にはユーザーを育成して操作に慣れてもらい、時には障壁を取り除くような改善を提案・実現して、最終的にはカスタマーサクセスが関わらずともユーザー自身で継続的に課題を解決できる状態を作る事になります。
端的にまとめると下記の3点がカスタマーサクセスとしての重要な役割になります。
順番に説明します。
顧客の課題解決という視点でいうと「顧客のBurning needsを解決する」という記事がとてもわかりやすく書かれていますのでお勧めです。
ユーザー自身がプロダクトを操作して一番小さな成功体験へ導く
ユーザーのリテラシーの左右される部分でもあるため、人がサポートしなければならない機会は絶対に訪れます。継続してプロダクトを利用してもらうために、まずはユーザーにプロダクトを操作してもらい、課題解決を実現するという一番小さな成功体験が必要です。
プロダクトのフェーズによっては人が対応する事も多くなると思いますが、いかに人が作業ではなく考える・分析する方に時間を割けるような業務設計が作れるかはとても重要です。ただし最初から完璧な業務設計を作る事は不可能なので、ある程度人が作業をしながら業務フローの修正を重ねていくイメージです。
また、人が行う作業が多ければ多いほどインシデントの発生率が上がるので、運用でカバーの先に一定レベルの自動化を描けないと厳しいですね。特にカスタマーサクセスは人力に頼る事から抜け出せないとプロダクトはスケールできません。
ユーザーの課題解決までの時間を短縮できる改善を繰り返す
個人的にはこの部分が一番楽しいと思ってます。
ユーザーの行動データを基に仮説を立てて改善を繰り返す事になるんですが、例えばユーザーがよく離脱するページやよく見られている FAQ など GA によるアクセス解析である程度サービス利用中に躓いているであろうポイントのあたりをつけて、LogRocket でより詳細な行動分析をしてユーザーから問い合わせが来る前に躓いているポイントを改善していく、そんな前衛的な取り組みです。このような形でユーザーの行動ベースのデータに指標を設定できると強いですね。
テクノロジーの進化によって上記のような事が可能になった事は、本当に嬉しい限りです。もちろん、全てが仮説からのアクションである必要はなく、実際のユーザーからの問い合わせ内容を分析して改善を繰り返す事も重要です。こうした改善が継続率の向上に繋がります。
最終的には FAQ やドキュメントがなくなり、ユーザーが直感的に全て UI 上で解決できるといいですね。FAQ やドキュメントをゼロにする事は不可能かもしれませんが、ゼロに近づけるよう努力し続ける事は大切だと思います。
ユーザーがより多くの課題が解決できるような新機能を提案する
ユーザーが目の前の課題を解決できると、ユーザーは次の新しい課題に気付いて相談してくれたり、後回しにしていた課題を相談してくれたりなど、新機能のヒントはユーザー起点となる事が多いです。大切な事はユーザーと定期的に対話をすることです。きっかけはインタビューでもアンケートでもなんでも良いです。より多くのヒントを得るためにセールスのメンバーに頼んで、見込み顧客への訪問へ同行しても良いと思います。
経験上、先進的な取り組みを率先して行っている企業との対話からは沢山の新機能のヒントを得る事ができます。一つでも多くの課題を聞き出すためにも、プロダクトに関わる業界・市場のトレンドや事例など先に情報提供をする事で良い信頼関係が築け、結果的にいろいろな話を聞く事ができます。
そのためには日頃からの情報収集がとても大切です。競合の機能リサーチや、自社のプロダクトが関わる市場やマーケティング手法のトレンドなど、ユーザーが知りたいと思うような情報を最低限でも良いので収集しておくと、ユーザーへヒアリングする時に役立ちます。
いろいろな情報を収集して、プロダクトに新しい価値をもらたす機能を考える事はとても刺激的です。最終的にプロダクトマネージャーに却下されてもめげずに提案し続ける事でより深い思考ができるようになるはずです。
一番効いてくる一歩先をいくアプローチ
ここからは少し高度なテクニックの話になります。カスタマーサクセスに限らずプロダクトマネージャーやセールスの人にも参考になるはずです。
上記に挙げた3つのアプローチは割と当たり前のことで、ユーザーの目の前にある課題を解決する事は当然なんですが、一番効いてくるアプローチはユーザーが今は気付いてないが今後ぶつかるであろう中長期的な課題に気付かせ、目先の課題と中長期的な課題を並行して解決できるようなアプローチをする事です。
このアプローチはカスタマーサクセスに限らず、マーケ・セールスも行う事でより大きな効果を生み出します。なぜならユーザーは人なので、中長期的な課題を解決する必要性を感じるタイミングがさまざまだからです。また企業体質やユーザー企業が提供しているサービスのフェーズにも左右されます。
このアプローチは信頼関係を深めるだけではなく、より長い期間プロダクトを使ってもらえるようになる事に加え、より多くの機能を活用してくれるようになるので、結果的にアップセル的な結果をもたらします。
中長期的な課題を解決するためにどのようなアプローチをすべきかは、一番ユーザーと接する機会が多いであろうカスタマーサクセスから発信できるとベストですが、メンバー全員が同じ意識を持ち、チームで議論できる環境があると良いですね。
理想的なカスタマーサクセス
仮説立てと改善を交互に回転させるスピードを上げて、ユーザーが躓くポイントを UI で解決できるような改善を繰り返し、人が対応すべき時間が減ったら分析する時間を増やし、既存機能の改善と共に新機能を生み出して、新機能も改善のサイクルに乗せる事ができれば素晴らしいですね。
また、UIの改善や中長期的な課題を解決するためのアプローチをより前倒しできるようになると、本当の意味で攻めのカスタマーサポートとなり、個人的には理想的なカスタマーサクセスになります。
導入前やトライアルの段階でカスタマーサクセスの支援により一定レベルまで引き上げる事ができれば、お金を払っているのに課題解決が実感できないという最悪のケースは凌げます。この状態から信頼を取り戻すのはハードモードかつ疲弊するので、こうなる手前でしっかりアプローチしておきたいですね。
ただしプロダクトのフェーズによっても注力すべきポイントは異なるので、重要な事は自社のプロダクトとユーザーの課題を理解し、カスタマーサクセスの一般的な役割や指標を一旦忘れて、ユーザーが課題を解決するためにできるアプローチが一体どんなことなのかを考えてみる事だと思います。
後書き
私がカスタマーサクセスからプロダクトマネージャーになった理由としては、単純に開発の優先順位を自分でコントロールしたかったからです。特に職種にはこだわりはなく、とにかくプロダクトをより良いものにしていく事が自分の目標だったので、仕事量が増えるだけでなく責任も大きくなりましたが、エンジニアやセールス視点ではなく、カスタマーサクセス視点でプロダクトをスケールできた事は大きな自信になりました。
フィードフォースでは経営層からのトップダウンがなく、社内政治的な事も考慮せずに伸び伸びとやらせてもらえたので、四六時中プロダクトのことを考えながら、情報収集の幅も広げて、自分自身もチームと共に大きく成長できました。
今カスタマーサクセスをしている人達も将来的にプロダクトマネージャーを見据えて業務に携わると、視野が広がり成長の速度が加速するはずなので、自分が心からお勧めできるようなプロダクトを探して、カスタマーサクセスに留まらず是非大きな挑戦をしてみてください!
▼一緒に「働く」を豊かにする仲間を募集しています▼