「カスタマーサクセス実行戦略」
アドカレ11日目〜
10月に完全版がでいたらしいのですが、読んでいた当時は増補改訂版だったので悪しからず。
著者の方は元エンジニアということでエンジニア畑でも読みやすい作りになっています。なので青本や赤本を読むよりもエンジニアの人はここから読み始めるのがいいかもしれません。特に青本は翻訳の癖が強くインド人の同僚曰く「英語版の方が読みやすい」という感じなので
お気に入り箇所
サービスに対する進化要件を提供者に訴えなくても勝手にそのサービスが進化してくれる
SaaSをユーザーから見たときの特性。買い切りやSI型と違って、勝手に成長していくのは魅力的。SlackやGithubなどはまさしくその恩恵を感じる。
一方で、Twitter(X)など、期待していない方に進化することもあるので顧客がどの方向に進化して欲しいかと感じ取れるかが重要になってくる。
カスタマーサクセスの本質は、問題が発生してからそれに対処する「守り」の姿勢ではなく、そもそも問題を発生させない「攻め」の姿勢
ここは昨日の「おもてなし幻想」に通ずるところの努力させない体験の重要さになってくる。また、自力での解決だけでなく問題を発生させないというプロダクト自体の可用性に関する部分も含まれており、カスタマーサクセスとプロダクト・エンジニアのつながりが重要になってくる。
カスタマーサクセス組織の成熟度とサブスクリプションモデルの利益には明確な相関関係があり、「その利益追求をカスタマーサクセス組織のKPIとすべき」
よくエンジニアの活動はKPIで測りづらいとされている。というのも、エンジニアの作った機能が利益になるのは大概機能を作ってから少し先になったり、そもそも可用性や負荷の軽減などUXの改善と直接的な利益につながらないからだ。
カスタマーサクセス組織のKPIもかなり近い特色がある。単純にカスタマーサービスの質や自己解決できる環境が向上しても、競合のプロダクトが勢力を伸ばし顧客がそちらに流れればKPIが未達になってしまうからだ。
そう考えると、この「カスタマーサクセス組織」というものが単純にカスタマーサクセスだけでなく、プロダクト開発やエンジニアも含めて考えていくべきだろう。
「オンボーディング対象者をいかに効率的に捌くか」がカスタマーサクセス組織を次のステップに進める試金石になる
オンボードの失敗がチャーンにつながることが多いため、オンボードの改善・効率化がカスタマーサクセスとして重要視されることが多い。「オンボードこそがカスタマーサクセスである」という人もいるが、あっていると思う。
自然に使うことのできるUI・自己解決できる環境・いかに早く「出来た」という体験を与えるかという体験設計などオンボーディングにはさまざまな要素があり、もっとも改善ができるところだろう。
SaaSが売れている以上、何かしらの費用対効果が生まれている。それらを明確に認識し、アプローチできるようにしておく。
要するにはプロダクトの価値の明確化と、それを数値化する方法を見つけることである。これができると、企業ごとに点数がつけやすくなり改善のアポも取りやすくなってくる。
逆に点数が高い人はどのように使っているのか、どのくらいの頻度で使っているのかを分析することにも役立ってくる。
プロダクトフィードバックの機構の1つに、四半期に一度、社内のビジネスサイドのメンバーに「リリースしてよかった機能」のアンケートとを取るという施策があります。
これはやってみるととても面白いです。というのも「要望の声が大きい機能」と「小声だがざわついている機能」があり、前者のリリースが重視される傾向があります。一方で、ビジネスメンバーにヒアリングをすると後者の方が「問い合わせが減った」「この機能のおかげで契約が取れた」という声が聞けます。
もちろん、声が大きい機能も重要ですが小声に耳を傾ける必要もあります。なんにしろ、こういった企画は社内でのコミュニケーションにもつながるのでやって損はありません。
使用方法が固定化した利用歴の長い顧客ほど最新情報に鈍感になり、「プロダクト・サービスは進化しているのに多くの顧客はそのことをしらない」という状態が発生します。
これあるんですよね。「こんな機能ありますか？」「最近できました」というユーザーとCSのログを見たことがあります。
鈍感になる原因も色々考えるところがあるでしょう。例えば、作業が完全にテンプレート化されておりパートに任せている場合は、テックタッチで教えてもよっぽどモチベーションのあるパートでない限りテンプレートが改善されることはないでしょう。
一方で、逆に正社員が手癖で作業をしている場合です。これもちょくちょくあり、こちらは手ぐせのミスの防止のために気づくと使ってくれるでしょう。
鈍感から一歩先に進み、何故この人はこの機能を使わないのだろう・誰が使っているのだろうと考えてみるのも面白いところだと思います。
PLGにおけるパーソナライズの必要性
PLGとは、プロダクトレッドグロースの略で顧客がプロダクトの価値を感じて自発的に有償化・クロス、アップセルをしてくれるような状態です。
そのためにUIのパーソナライズが重要とされ、機能の表示のON/OFFやSlackのハドルなど有料ではないと使えない表示などの契約ごとの動きが重要になります。
これらを外部SaaSで行うのも良いですが、できればSwitting Toggleなど自社で開発できると柔軟にできていいですねー
カスタマーサクセスの最終目的はカスタマーサクセスをなくすことだ
カスタマーサクセスのあり方も複数あり、これはカスタマーサクセスがプロダクトに近い場合の理想と書かれています。 カスタマーサクセスがプロダクト近い場合、その役割は顧客からのFBや改善を素早く提案することになります。即ち情報のパイプラインとしての動きになります。
もし、カスタマーサクセスの文化がプロダクトやエンジニアにも広がれば、情報のパイプラインを自分たちが担うようになり生の声を元に改善が行われるようになります。
もちろん、カスタマーサクセスがカスタマーサポートに近い型・カスタマーサクセスが中心にある型もあり何を使うかは会社のフェースによって異なるとされていますが「カスタマーサクセス」という文化はもっと広まれと思っています。
