CS5年。過去の自分に先に伝えておきたいことリスト
本記事は、CS HACK Advent Calendar 2022 の12/19の記事になります🙋
皆さん非常に勉強なる記事が多く、若干プレッシャー感じています…(ﾄﾞｷﾄﾞｷ
今回はCSだった頃の過去の自分に伝えたいことをまとめてみよう思います。
CSを5年弱やって先日ジョブチェンジしたので、この場を借りて、印象に残っているポイントを振り替えたいと思います。
もっと早いタイミングでやっておくべだったこと、反省していること、良かったことなど色々ありまして、その一部を書き出してみます。
読者の方は掻い摘まんで見てもらって「要注意なんだなー。これやった方がいいんだなー。ふむふむ…」くらいにヒントのように感じてもらえたら、本noteの価値はあったかな？と思います。
なお、本記事に書いてあることは、主に前職での経験になりますが、あくまで私個人としての反省や良かった点です。補足入れなくても...と思いますが念のため先にかいておきますっ！
そもそも、君はダレ？
CSのAdvent Calendarを書いていますが、現在、ファンファーレ株式会社という会社で、プロジェクトマネージャー（PjM）をやっている竹谷と申します。
ファンファーレ株式会社は、持続可能な社会の実現に貢献するエッセンシャルテック企業です。廃棄物回収の配車計画を自動作成するSaaS事業「配車頭（ハイシャガシラ）」を運営しています。すげいサービスです。
以前は、不動産会社向けのSaaSを提供しているイタンジ株式会社という会社で、複数ある自社サービスの1つのCSをやっていました。担当サービスは、不動会社向けのCRM兼MAみたいなサービスです(たくさんnote書いているので、分かるのでオープンに)。
CSは未経験だったのですが、立ち上げから5年くらい(ほぼ好きに)やらせてもらって、色々経験させてもらいました。今でも感謝しかないですmm。
CSも絶賛募集しているようなので興味ある方はぜひ！
で、実際にどんなことを経験したことはザックリと下記の通りです。
※もちろん全部一人でなく強力なメンバーと一緒にですし、その後、他のメンバーによりどんどん良い感じにアップデートされていきました。
[OPS的な内容]
- 顧客のステージング設計
- オンボーディングフローの設計や資料整備、
- データ分析基盤の整備（redashいじったり、ハイカスタマー入れたり）
- CSM業務の分業化（チーム分割）
[サポート的な内容]
- サポートサイト構築＆コンテンツ整備＆サポートサイトリニューアル
- 問合せ対応（サポート）
[CSM的な内容]
- オンボーディング
- アダプション＆リニューアル
[マーケ的な内容]
- 事例作成
- セミナー
- 分科会的な小さなユーザー会の企画と運営
[マネジメント]
目標設計等々
読む前の注意事項
カスタマーサクセスに関するノウハウは、ここ数年で、偉大な先輩のおかげで、かなり充実しました。書籍もたくさん出ましたし、ググればほぼ何でもヒットする状況です。
しかし、これは要注意な状況だなと感じています。どういうことかというと、Howが先行しすぎて、早く取り組み過ぎている会社もあるのでは？と思っています。。
進んでいる会社の事例をみていると「めっちゃいいなー。良さそう」みたいなことを思っちゃうんですが、他社事例は参考にしつつも、今の自社に必要なエッセンスを取り出して、自社に最適なことをきちんと考える必要があります。
分業化するにしても、顧客理解が進み、アハポイントが分かり、カスタマージャーニーがある程度固まって…くらいまで至らないと適切な分業化ポイントも分からなかったりします。
業界、提供サービス、組織構成、働くメンバーによって適切な答えは違いますので、良い感じで掻い摘まんで、参考にしていただければと思います。だいぶ偉そうなことを書いてしまって恐縮していますが、重要なことなので、書きました🙏
なお、「これ書籍にあるわ」「これCSに限らないことじゃん？」という内容も含まれていますが、そこは気にせず記載します。
カスタマーサクセス/ OPS / CS業務効率化関係
まずはカスタマージャーニーを模索し、理解し、可視化する
ことが最重要です。冒頭にも触れましたが、howが大量に転がっていますが、最初はスケールしないことを最初はとことんやる。
カスタマージャーニーについては、こちらのページが分かりやすいです。
カスタマーサクセスもジャーニーを作るべき！メリットと方法を解説
カスタマージャーニーが分かってくると、またさらにやるべきことが見えてくると思っています。
分業化、自動化、仕組化等は、オンボーディングからリニューアルまでのカスタマージャーニーがある程度分かってから着手した方が良いと思います。
フェーズ毎のサクセス指標を定義する
カスタマーサクセスは良い意味で無限（笑）であるため、フェーズ毎でのサクセスとなる指標は作った方が良いです。（できれば定量的で、難しければ最初は定性的でもOK）
まずは、the ヘルススコアというほどきっちりとしたものでも無くて良いので、『 ○○○のフェーズでは、○○○になっていればOK』くらいのものからでもあったほうが良いです。
でないと、メンバーは何を目指して良いか分からなくなりますし、どこまでやるべきか？という判断がつきやすくなります。
AとBとCの要素が○○○だからGoodだね！みたいな理想型を最初から作るのはかなり大変であり、サービスによっては定義が難しいと思います。（沼にはまるとヘルススコアを作ることが目的化しそう。）なので、まずは小さいところから初めて、サクセスやチャーンに関係しそうな要素が見えてきたら、どんどん拡充していけばいいと思っています。
プレイブックは最初から作る
プレイブックは、簡易的なものでもいいので、必ず最初から作りましょう。プレイブックを知らない方は、以下のnoteに書かれています。
プレイブックが無いと、ノウハウが属人化しやすく、いつまでたってもチームとして強くならず、結果的にスケールしづらい組織になります。
上記noteの例では、オンボーディング、アダプション、エクスパンションの例がありますが、そのほかにも、チャーン連絡時、○○○のトラブル時など、様々なシーンで作ると良いと思います。
チャーン理由は初期からきちんと記録する
チャーンした顧客の情報は、初期からきちんと記録しておいた方が良いです。顧客名、地域、sales/cs担当、契約内容、契約期間、チャーン理由…などです。
データが蓄積されてくると傾向が見えてくるようになりますし、数年後再度営業する際や再契約至った際にも役に立ちます。
下記に詳細を記載しましたが、このときにもDWHは効果を発揮します。契約データ、利用データをjoinして分析することで、なぜチャーンに至ったか、調べることができます。
DEAR フレームワークは、参考にすべき
DEARフレームワークとは、ゲインサイトがまとめたヘルススコアを設計する際に用いるフレームワークになります。きちんと運用するのはかなり難易度高いのですが、これらの要素を押さえながらカスタマーサクセス活動することは本当に重要です。めっちゃ上から目線ですが、よく出来ているな…と思います。チャーンさせないようにするためには何が必要か？という大枠のヒントになります。
顧客の設定/利活用状況の可視化ダッシュボードは速攻作る
カスタマーサクセス活動をする上で、顧客の利活用データの有無で、顧客対応の質やスピードが大きく変わります。
最初は簡易的なものでもいいので、エンジニアさんにお願いして、非エンジニアでもSQLを叩ける環境は作ってもらうようにしましょう。
無償でサクッとできるものだと、Redashやmetabase等が有名ですね。Redashは、スプレッドシートとデータ連動させることもできるので、かなり強力です。
顧客に割く時間を作るための効率化は、どんどんやっておくべき。
1日20分定常作業をやったら、月で400分。複数のCSが同じ事をやっていたら…怖いくらいのコストです。
DHW(Google BigQuery等)を導入し、横串でのデータ分析ができるようにする
ある程度顧客が増えてきたら、顧客データ、契約データ、プロダクトの利活用データは、DHW(データ ウェアハウス)に導入し、横串で分析できるようにしましょう。
これがあると、あらゆる分析ができるようになり、様々なアクションの質とスピードが劇的に速くなります。
エンジニアさんの協力が必要ですが、エンジニアにとってもいいことばかりのはず。顧客が増えてきたら、お願いしてやってもらいましょう！
社内CRMの運用整備は、絶対に最初からやるべき
小さい規模からCRMは、絶対にきちんと運用・整備すべきです。
「使っていないプロパティあるけど、整理は後でいいか…」みたいな考えだと後で痛い目に遭います….
最初から社内でCRM専任を置くのは難しいかと思いますが、誰かが責任を思って管理し、きれいな状態を維持すべきです。そして、できるだけ早く、CRM整備をOPSやマーケ的な人がやった方が良いと思います。
データの重複登録などをきちんと無くす（クレンジング）
使わないプロパティを放置しない
現状や成約に関する情報に関する情報の管理（アップセルとかの提案するとき超大事）
個人的な感想ですが、CRMの整備は、相当レバレッジが効く施策だと思っています。知りたいデータが出しやすくなりますし、営業活動の精度も上がりますし、アップセルやクロスセルを狙う際にもピンポイントでターゲティングできます。
バックオフィス業務の効率化はマジ重要
サービス初期では、CSはバックオフィス業務をやる場合が多いのでは？と思っています。請求業務や更新業務などですね。
しかし、これらの馬鹿にならないですし、自動化することでミスもなくなります。バックオフィスにこそテクノロジーを入れるべきだと思います。
業務が回っているとついつい先延ばしにしてしまうんですが、顧客数が数十くらいになってきたら徐々に着手した方がよいです。
その作業は一時的な作業か？長期でやるならきちんと設計して運用はシンプルに
これはタイトル通りです。一時的な作業(データをきれいにするとか)なら、あまり考えずに作業をしても良いと思います。
しかし、これから先ずっと行う作業であれば、運用をきちんと考えましょう。
自動化して、余計な工数をかけない
自動化して、ミスを発生させない
人がやる作業なら、作業の少なさよりシンプルさをとる
例えば、毎月やらないといけない作業なら、やり忘れがないように仕組みで解決する
ルールを決めるだけは無意味。どうやったら運用が回るかまで検討しないといけない。
若干、上記とかぶっているのですが、ルールを決めて終わりにしてはだめ。「これルール化しました！皆さまお願いします！」は意味がない。
どうやったらルールが守られるか、実行されるか？、きちんと考えてルールは決めるべきです。みんな忙しいですし、覚えることも沢山あります。ルールが守られないのは、考えた人の責任くらいに思って運用を考えましょう。
スプレッドシートという甘い蜜には、毒がある
スプレッドシートは、手軽使えて、とにかく強力なツールです。
しかし、毒の部分がありますｗ
数人で使ったり、データ量が多いうちはまだいいんです。
しかし、データが増えてきたり、数式を駆使し始めたらもう黄色信号です。
あっと言う間にスプレッドシートが重くなり、計算が終わらず、全く手が付けられなくなります…
集計のための中間データはDHWで作ったり、契約データはスプシの代わりにAirtable使ったり、BIを使うなどを早めに検討することをオススメします。
よく分からない作業で、どんどん時間が持って行かれます。
他部署との連携関係
横のコミュニケーションラインを持つ
組織には、事業（プロダクト）で分けたり、機能（CSやsales等）で分けたり、色々な組織形態があります。
この際に、部署を跨いだ横のコミュニケーションは必ず検討した方が良いです。内容、参加メンバー、頻度、コミュニケーション方法は、その時の状況によると思いますが、横のコミュニケーションラインは絶対に維持すべきだと思います。
横のコミュニケーションラインを作るメリットとデメリットを書き始めるとnote1本分くらいになりそうなので割愛しますが、各部署のアウトプットの質の向上、仕事のしやすさなど、良いことばかりなので、これは意識しておくことを強くオススメします。
全員が仲良くなろう。それぞれの部署で最高の顧客体験を作るためにはとにかく横の連携が肝です。
Salesやマーケへの情報提供を手厚く
上記にも関係しますが、CSから他部署にとにかくたくさんの情報を流しましょう。受注にも大きく影響しますし、全体のモチベーションにも影響すると思っています。これは最初からぜひやりましょう！
- プロダクトのバージョンアップ内容
- チャーン理由
- 成功事例
- etc…
とにかく他部署とコミュニケーションとって仲良くしましょう！
ライトサクセス事例、ディープサクセス事例の蓄積と共有
顧客からの声には、様々な粒度があると思います。
「○○○の機能いいね！○○○の使い勝手いいね！」
「導入したら、売上げ○○○上がったよ！」
みたいな声です。
特にサービスの使い勝手に関するFBは担当者で閉じてしまうことがあると思うのですが、これらの共有も重要です。顧客は、私たちの想定外の意外なところに価値を感じている時があります。
salesの方が現場の方にプレゼンするときに、そのあたりのトークを織り交ぜるとより興味をもっていただけるかもしれません。一方で、その機能を開発したDeveloperの方にとっては、とても嬉しいFBだと思います。
もちろん、CSにとっても有益で、オンボーディングプログラムに入り込むことで、よりサクセスしやすくなります。
蓄積しておくことで事例集にもできますし、後にセミナーをするときにも、そのリスト見て顧客に相談したりすることもできるので、事例の共有と蓄積は、良いことしかありません。
サポートサイト関係
FAQの作りすぎに注意！
サポートサイトの構築初期は、コンテンツが充実していない場合が多いと思います。このときにやってしまうのが、FAQの量産ではないかと思います。
顧客が解決できないものをコンテンツ化することで、別の顧客から類似の質問が来た際に、素早く回答できます。
しかし、この負債はあとでやってきます。FAQが多くなりすぎて、メンテができず古い情報が残り、ただのコンテンツ置き場となります。
なので、FAQを作るのはもちろん重要なのですが、FAQの大本となる機能説明の記事をアップデートしていくことが重要なのではないかと思います。
作る際には、
- 大本の機能説明の記事に入れるべきか？
- ニッチな質問なので別に切り出した方が見やすいか？
を検討してコンテンツは作っていくべきだと思いました。
サポートサイトを一度リニューアルしたのですが、その際にかなりの記事を削除しました。記事数が多いのは、正義か？を改めて考えた方が良いと思います。
マネジメント、チームビルディング関係
チームとしても、Missonやvalueを持つ
会社やプロダクトのVision / Mission / valueは重要です。
しかし、それと同じくらい、チームでmissionやvalue等を持つことは重要と思っています。これが無いと、色々な状況が変わっていく中で、「何のためにカスタマーサクセスやっているんだっけ？」と思う場合に助かったり、行動指針や価値観が明示されているとメンバーが意思決定がしやすくなります。後は意思決定がぶれづらくなりますね。
自分の中のカスタマーサクセス像を持ち、オープンにする
カスタマーサクセスの部署は、様々な価値観やスキルを持った人が集まりやすいと思っています。人それぞれ得意なことがあったり、貢献したい形も違ったりして、考え方も違います。また、顧客に対しての思いは全て正解で、不正解はないと思っています。
一方で、個人の価値観が、会社やチームのmission / vision / valueに含まれていなかったりするときもあります。しかし、多様性は非常に重要な要素であり、個人としてのカスタマーサクセス像（スタンス）は持った方が、それが強みや自信に繋がります。そして、その考えをオープンにした方が個人にとっても、会社にとっても、良い面が多いと感じています。
チームや個人で考える時間を作る
CSMは特に時間が取りづらい職業だと感じています。
社内外の打ち合わせ、電車やメール対応、顧客の状況確認、その他作業等々で、まとまった時間が非常に取りづらいです。また、「今日は時間あるかも！」と思っても、いきなり急ぎの対応が入ったりしますよね。
しかし、日々の顧客対応ばかりやっていると、考えたり、改善したり、新しいことに取り組んだりする時間がなくなります。そうすると、効率化や改善が進まず、いつまで経っても忙しい…みたいな感じになります。また、新しいことにチャレンジすることでモチベーションも上がりますが、その貴重な機会も失われます。
お客様に多少のご迷惑をかけるときもありますが、議論したり、先のことを考えたり、作業の時間等を意識的にとることは将来への投資になり、結果的にとってもメリットがある時間になります。
改善やチャレンジは、別の目標を設定する(月次スプリント)
5年の中で、1番改善が進んだ時期(CSが進化できた時期)はいつだったか？と思うと、オンボーディング社数とかそういうKPIとは別に改善目標を立てていたタイミングでした。
月初のタイミングで、○○○の資料作る、○○○の仕組みを作る、○○○の事例を作るみたいなことを決めて、月次でスプリントを回していました。
CSの立ち上げ時は兼務になりがちです。で、1番の優先事項は？というと顧客対応になると思います。目標をきちんと設定しないとあっという間に時間が過ぎて、顧客対応しかできなかったみたいなことが起きます。
月1目標を設定することで改善にも繋がるし、メンバーは新しいことにも挑戦できるからスキルも上がりますし、半年後に振り返ったら、「頑張ったー！」とモチベも上がります（僕は上がっていましたｗ）
目標設定は、smartでやるといいと思います。
スプシに簡単に記載するレベルで大丈夫です。
◆要素1：Specific（具体的に）
誰が読んでもわかる、明確で具体的な表現や言葉で書き表す
◆要素2：Measurable（測定可能な）
目標の達成度合いが本人にも上司にも判断できるよう、その内容を定量化して表す
◆要素3：Achievable（達成可能な）
希望や願望ではなく、その目標が達成可能な現実的内容かどうかを確認する
◆要素4：Related（経営目標に関連した）
設定した目標が職務記述書に基づくものであるかどうか。と同時に自分が属する部署の目標、さらには会社の目標に関連する内容になっているかどうかを確認する
◆要素5：Time-bound（時間制約がある）
いつまでに目標を達成するか、その期限を設定する
https://globis.jp/article/659
マネージャーは自分でやらない時期を明確に決めて、考える時間を確保する。
CS立ち上げ当初は、マネージャークラスでも実務(CSM)をやることになると思います。しかし、メンバーが増えてきたタイミングやカスタマージャーニーが確立してきたタイミングで、早々に新規の顧客の対応はやめるべきだと思います。
あまりに引っ張りすぎると、下記問題が発生する可能性があります。
- 新しいことができずに事業やチームが停滞する。
- リーダーが忙しいとメンバーも声をかけずらくなる。
- メンバーが新しいことにチャレンジする機会が減っていく。
- 育成にも時間がかけられないので結果的にメンバーの成長も遅くなる
自分でできることなんて小さな事、遠くに行きたければ、みんなでいくしかない。不安でも任せていきましょう。なお、そのためには、後述するプレイブックなどが重要になってきます。
おわりに
これまで手元にとどめてあったメモを書き起こしたら、想定以上に長文になってしまいました。。
書けていない部分は沢山ありますので、もし気になるところがあれば、TwitterのDMにてお気軽にご質問ください。
明日は、山下 俊さんより、記事がアップされる予定です。お楽しみ！
CS HACK Advent Calendar 2022
この記事が気に入ったらサポートをしてみませんか？