カスタマーサクセス担当者に伝えたい5つの約束
この記事は「ウィルゲート Advent Calendar 2023」の 5日目の記事です。
はじめに
初めまして！
ウィルゲートでSEOツール『TACT SEO』のカスタマーサクセスチームリーダーを担当している信宗碧（のぶそうあおい）と申します。
今回は私自身がカスタマーサクセスとしてちょうど1年ほどの経験を経て感じた、
カスタマーサクセスの担当者に必要な要素を5つの約束としてご紹介します。
本記事はこれからカスタマーサクセスを目指していく、ないしはこれから取り組んでいく方にぜひ読んでいただきたいです。
先に結論
私がカスタマーサクセスの担当者として大事にしている約束が5つあります。
約束1:誰よりもプロダクトの理解者であれ。
約束2:プロダクト起点で考えるな。
約束3:線引きを明確に。ただし柔軟に。
約束4:顧客の状況理解は当たり前。大事なのはどこまでイメージできるか。
約束5:前後のつながりがカスタマーサクセスの成果に繋がる
上記を守ることで、
対顧客はもちろん、対組織として成果を出すことに繋がると感じています。
それぞれの約束についてこれから解説します。
約束1:誰よりもプロダクトの理解者であれ。
カスタマーサクセスは顧客にとってプロダクトの導入や定着をサポートしてくれる存在です。
例えばこの存在が質問に対してちゃんと答えられなかったり、間違った回答をしていたらどうでしょうか？ おそらくカスタマーサクセス担当を信頼をすることが出来ませんし、結果的にプロダクトを使いこなすことも出来ません。
カスタマーサクセスに求められるプロダクトの理解というのは、ただ使いこなせるというだけでは不十分です。
自分たちのプロダクトを使うユーザーの数だけ、プロダクトを理解する必要があります。
例えば、
リテラシー
これまでの対策状況
現時点での課題
同様の条件の顧客がぶつかる障害
上記は一部ですが、記載のようにユーザーと一括りしてもその中には様々な条件で分けることが出来ます。
カスタマーサクセス担当者自分たちのプロダクトを使うユーザーを区分して、
目の前のユーザーが現時点で感じている課題感はもちろん、これからぶつかる障害を事前に察知して、先回して潰すようなプロダクトの理解が必要と考えます。
私がカスタマーサクセスになりはじめの頃は、プロダクトの決まった使い方を決まった流れに従って説明をしていました。
しかし、それでは動画やテキストのマニュアルの範疇を越えず、当時私が担当していたユーザーたちは使いこなすまでの時間やサポートの工数もだいぶかかっていました。
そこで先述したように誰にでも共通する説明ではなく、目の前のユーザーにカスタマイズした説明を心がけることで顧客側の理解しやすくなり、私自身も顧客との関係構築や業務の理解度の向上に繋がりました。
約束2:プロダクト起点で考えるな。
一つ前の約束と反対のことを言っているように感じるかもしれませんが、そうではありません。
ここで言いたいのは、プロダクトを理解しているのは最低限必要なマナーであるが、実際にユーザーとコミュニケーションを取る際に、自分たちのプロダクトを中心に考えないようにするということです。
なぜなら、ユーザーが求めているのはそのプロダクトの使い方ではなく、自分たちの感じている課題や理想を実現するためにプロダクトは何ができるのか、どう使えば良いのかということだからです。
多くのカスタマーサクセス担当者に共通することかもしれませんが、
自分たちのプロダクトの理解が深まると一定愛着だったり、知識の偏りが生まれたりします。
すると、プロダクトを主語に話し始めてしまいます。
具体例を上げましょう。
例えば、弊社のプロダクトであれば、SEO対策に活用するプロダクトです。
簡単にSEO対策でやるべきことを説明すると、キーワードの選定⇨記事の企画⇨記事の執筆⇨効果測定⇨リライト、です。
※厳密にはコンテンツマーケティングの領域ですがご容赦ください。
例えば上記の流れを踏まえて、ユーザーにキーワード選定の説明をする場面を想像していただきたいです。
悪い例
「弊社のツールでキーワード選定をやる時は～～の機能を使って、こんな操作をします！」
良い例
「キーワード選定をする時は具体的に〇〇と△△と□□のようなステップがあります。
それぞれやる目的はーーーです。
〇〇の工程は弊社のツールの機能だと～～に該当します。
ちなみに〇〇の工程って今までどのようにやられていましたか？」
悪い例に上げた伝え方だと、いきなり自分たちのプロダクトを主語に話しています。
ツールができることはユーザーにもイメージがつきますが、その工程が全体の作業のうちのでの部分か分からず全体感が掴めません。
このような説明をした時によくユーザー陥るのが『話を聞いていた時はなんとなくわかった気がしたけど実際に使ってみるとわからない』です。
そのために良い例では下記のポイントを注意しています。
細かい作業から入らず、全体像の話をする
それぞれの工程の繋がりを話してフローをイメージしてもらう
それぞれの工程とプロダクトの機能を紐付ける
先方の今までの作業に置き換える ⇦ここが大事
私は元々上から3つは意識して進めていたのですが、最近4つ目のポイントの重要性を感じています。
なぜならどれだけわかりやすくプロダクトの説明をしても、先方の今の業務に落とし込めないと説明が終わった後実践できなくなるからです。
新しいプロダクトの説明を受けた時下記のようなフローが先方の頭の中に生まれると考えています。
やりたいことを実現するためのステップを理解する
プロダクトができることを理解する
それぞれの操作を理解する
その操作を今までやってきたことのどこに該当するかを当てはめる
実際に置き換えて作業をしてみる
この4のステップで躓くケースが多いです。
なぜなら、このステップは業務の解像度×プロダクトの解像度があるからこそできることだからです。
使い始めのユーザーに後者を求めるのは難しいので、カスタマーサクセスが顧客の業務を理解して、それをプロダクトの使い方に紐づけながら説明すること、それが重要だと考えます。
約束3:線引きを明確に。ただし柔軟に。
カスタマーサクセスはほとんどの場合、解約率（チャーンレート）を目標として課されることが多いと思います。
契約初期のオンボーディングでユーザーが100％理解してくれるのが理想ですが、現実的にはなかなか定着しなかったり、使っても成果が出なかったりと様々な課題が発生します。
その際についユーザーの作業を代行したり、プロダクトの範囲外のサポートをしてしまうカスタマーサクセスの担当者もいるのではないでしょうか？
結論、今回の約束ではそのこと自体を否定するわけではありません。
ただ自分たちの通常の役務ではどこまでを対象範囲としているかは適切に理解すべきと考えています。
例えば、弊社のプロダクトを使ってなかなか成果のでないユーザーがいます。
このユーザーに対して下記のようなアクションがとれます。
A:プロダクトの使い方を見直し、改善点を指摘して定着まで補助する
B:カスタマーサクセスがユーザーの課題を分析して、成果が出るための施策を提案する
C:マニュアルを送る
Aが最適です。なぜならあくまでプロダクトでできる範囲を越えずに提案をして、その定着まではしっかり責任を持っているからです。
Bはやり過ぎです。もちろんカスタマーサクセスが責任を持つべき解約率の抑制には貢献できるかもしれません。ただこれが当たり前になると、①本来別の商材（役務の範囲や費用も大きいコンサルティングなど）が提供できなくなる、②必要以上の稼働がかかり想定より案件が担当できなくなる（MRRが伸びない）可能性があります。
Cは惜しいです。状況にもよるので一概には言えませんが、この対応で問題ないのは機能の一部だけ間違った使い方をしているような惜しいユーザーです。
カスタマーサクセスはアクションを起こしたことで満足して、実際にはユーザーに響いていなかった、ということも発生しがちです。
Aが最適とお伝えしましたが、大事なのは自分たちのプロダクトが想定してる範囲を正しく理解するというわけであってBを絶対やってはいけないというわけではありません。
例えば、役務の範囲にこだわって1件解約が生まれるくらいであれば、すこし負荷を増やしても解約を防いだほうが全体の利益に繋がります。
だからこそ、線引を明確する必要はあるが、最終的な目標である解約防止のために柔軟に対応することを忘れないでいただきたいです。
約束4:顧客の状況理解は当たり前。大事なのはどこまでイメージできるか。
SaaSの魅力はたくさんありますが、その一つにユーザーの利用状況が常に把握できるということがあると思います。
従来の買い切りモデルや現物の商品の場合、購入後のユーザーの動向や利用状況を測ることは難しく、ユーザーが何を不満に思っているのか、どこに課題を感じているのかを測るのは困難とされていました。
しかし、Saasであればどのユーザーがいつログインして、どの機能をどれくらい使っているか、実際にユーザーのアカウントを見ればどんな使い方をしているかまで把握できます。
取れる情報が多いからこそ、カスタマーサクセスは情報を持たないままユーザーとやり取りするのは失礼に値するとも思います。
悪い例：「なにかお困りごとはないですか？」
惜しい例：「〇〇の機能を途中まで使っているようでしたが、なにかお困りごとはありましたか？」
良い例：「〇〇の機能の利用状況をみるに、△△あたりで作業に詰まってしまったようですね。その場合、～～がわからないような状況と想定しているのですが、いかがでしょうか？」
悪い例はカスタマーサクセスとしては残念な例だと思います。
利用状況から何に困っているかを仮説立てることはできるのにそれをやっていないパターンです。
もちろん風呂敷を広げてこちらが想定していなかった課題が出てくる可能性は否めませんが、
それはある程度コミュニケーションが続いた後の話です。
最初からユーザーに丸投げするのは得策ではありません。
惜しい例はデータを見たがそのまま事実を伝えて終わってしまっているのが惜しい点です。
これだけでもちゃんと見てくれている感はユーザーに伝わると思いますが、
約束1で伝えたようなプロダクトの理解者としては物足りないです。
良い例で紹介しているように、同じ課題を持っていた過去のユーザーがどんな経緯や原因でそこに至ったかを理解し、先に当てにいくのが正しいデータの活用だと考えます。
カスタマーサクセスを初めたばかりの頃はユーザーのパターンなどイメージつかないかもしれませんが、ある程度顧客対応の経験を詰んだり先輩に聞いたりすることで解消できる点は多いです。
自分のユーザーへのコミュニケーションがどの段階にいるかはぜひ一度見直していただきたいです。
約束5:前後のつながりがカスタマーサクセスの成果に繋がる
前後のつながりというのは具体的に言えば、セールスと開発です。
なぜこの2つの領域とのつながりが大事かというと、カスタマーサクセスが担っている目標である解約率を改善するためにこれらの領域との連携・改善が必要だからです。
解約には大きく3つのパターンがあると考えてます。
セールス要因：売るべきではない顧客に売ってしまった
カスタマーサクセス要因：適切なオンボーディング・サポートが出来なかった
プロダクト要因：ユーザーの満足いく成果やわかりやすいUIを提供できなかった
解約と一言で言っても要因が異なるため、カスタマーサクセスだけで頑張れば解約率が改善されるというのは正直多くないと考えています。
例えばウィルゲートのカスタマーサクセスの場合、
セールスとの連携はTACT SEOで成果を出すための要件を整理したり、提案段階でカスタマーサクセスが受注後の成果を出せる余地があるかをチェックしたりしています。
開発との連携はユーザーからあがってきた顧客からの改善要望をフィードバックすることやユーザーが求める機能をスプレッドシートで作成して現場検証を進めたりしています。
上記を進めることで、弊社のプロダクトで成果を出しにくいような顧客は事前に検知ができますし、プロダクト自体が変わることでこれまで定着しにくかったり成果を出しにくかったりしたユーザーが減ってきました。
このようにカスタマーサクセスはただ解約の要因を集めていくだけでなく、
それをセールスや開発といった関連部署にしっかり共有して改善を進めていくことが重要な役割です。
カスタマーサクセス担当者に伝えたいこと
カスタマーサクセスという職種は比較的新しく、実際やることは会社によって違うと思います。また、体系化された正解があるわけでもないので、何が最適解かを模索し続ける苦しみもあります。
一方で、自分のキャリアを広げるという観点では魅力的な職種であると感じています。
私自身カスタマーサクセスに配属してからもセールスに同席して受注率改善に貢献したり、開発メンバーと連携して新機能開発やUI改善に関わらせてもらっています。
この記事をきっかけにカスタマーサクセスに関心を持ってくれた方がもしいればぜひご連絡ください！！
「ウィルゲート Advent Calendar 2023」、翌日は内藤さんによる「 Amazon RDSのBlue/Green Deploymentsを使ってMySQLのアップグレードをやってみる～実践編～」です。 お楽しみに！
この記事が気に入ったらサポートをしてみませんか？