見出し画像

【イベントレポート】#CS駆け込み寺 Vol.2「ハイタッチCSの品質を平準化したい!CS Opsの取組み討論会」

イベント概要


CS KOMMONSには、気軽に質問したり意見を求めたりできるコミュニティ、CS駆け込み寺があります。今回はオンライン交流会形式で熱く議論を交わしました!
第2回目は、「ハイタッチカスタマーサクセスのサービス品質を平準化するために各社のCS Opsがどのような取り組みをしているのか知りたい!」という質問をきっかけに開催しました。
サービスや組織の状況によって、取り組みや考え方が異なっていることが分かる会となりましたので、読者のみなさんは、ご自身の所属する組織の状況や平準化できる度合いが似ている方を見つけて、ぜひ日々の業務の参考にしてみてください。
本記事では、以下の言葉が頻繁に出てきますが、この記事内容の理解の参考とされてください※。会の後半ではどちらのチームが平準化に取り組むべきかという興味深い話にもなったので、カスタマーサクセスに関わる方は奮ってお読みください。

  • ハイタッチカスタマーサクセス (ハイタッチCS):お客様が困っているポイントやニーズなどを理解するために直接関わりながら、よりよいお客様体験に導く。多くの場合、選任担当がお客様ごとにアサインされ、複雑な対応を含むお客様支援を行う。

  • Customer Success Operations (CS Ops) :ハイタッチCSがより成果を出せるように、定量データや担当者の定性情報をもとに適切な業務フローの設計や資料の作成・改善を行う。

※企業によって業務範囲は異なるため、厳密な定義ではありません。
▼参考:過去の実施記録
第1回目:「目指せ!セルフオンボーディング -テックタッチ施策の始め方-」


参加者ご紹介



今回のテーマと背景


今回は、この2つのテーマを主軸に議論しました。

  • ハイタッチ業務の平準化をどこまでするべきか

  • カスタマーサクセスチーム内や社内への教育の仕組み

まずは、質問者である植原さんに、今回の質問の背景についてお伺いしました。
植原さん:最近Opsチームを立ち上げたばかりで、どこまで何をすべきなのかを迷っています。プロダクトの特性上ハイタッチ業務が中心になっており、特にオンボーディングについてどこまで平準化して良いものなのか知りたいです。お客様とのコミュニケーションのスタイルやファシリテーションの進め方は、個々人のカラーがあっても良いと思う一方で、担当者のバラツキにつながっているとも感じています。
もう一つは、社内の教育の仕組みをどのように作っているかも知りたいです。
カスタマーサクセスメンバーの育成では、標準化で埋めきれないことをどの程度教育で埋めていく必要があるのかという点です。
また、カスタマーサクセス以外の部署に新しく入ってきたメンバーを含む全社に向けて、プロダクトの内容やお客様が感じる価値をしっかりインプットするためにどのようにカスタマーサクセスが絡んでいくべきなのかを悩んでいます。
ぜひみなさんの取り組みや経験などを教えていただけると嬉しいです!


1. ハイタッチ業務の平準化とカスタマーサクセスチーム内教育


加藤:ハイタッチの標準化という意味では、7〜8割決まっていて、オンボーディングや状況に応じた支援内容はスライド (ドキュメント) ベースで標準化して、チーム内に共有しています。

高木:コンテンツ内容や提案内容は基本的に標準化しています。一方で、ハイタッチ部分になってくるとお客様の課題に応じて自由にやっており標準化はしていないです。標準化していない代わりに、チーム内の教育をしっかりやっています。具体的に言うと、ロールプレイや勉強会を頻繁に実施し、課題設定やファシリテーションの進め方といった一般的なスキルや要望のもらい方についてはチーム内で実施しています。

活用事例などはお客様にも見えるかたちで公開したり、成功事例は定期的に担当者からチーム内に紹介したり、事例共有も実施しています。また日々の業務では、お客様に案内する資料を事前にレビューしたりミーティング後の振り返りをリーダー以上がレビューしたりとチームメンバーが気づきを得られるような体制を整えています。標準化が難しいプロダクトであると認識したタイミングで、ケースを言語化して共有することに力を入れてここ1年頑張っています。

植原:とても参考になります!
お客様によって状況がバラバラなので、担当者個人のスキルに依存していました。そのためメンバーを教育することに注力しようと考えていたところなので、聞けてよかったです。

高木:これらの取り組みを1年続けてきた中で、読んだ書籍の内容をまとめて講師として勉強会を開くメンバーも出てきたりして、個々人がインプットして業務やメンバーに落とすというサイクルが回っている体感があります。

白塚:それはリーダーの方がやると決めてやっているのか、KPIに合わせてメンバーがやっているのでしょうか?

高木:基本的にはリーダー以上が指揮をとっています。明確なKPIはないのですが、半期ごとに行う行動目標設定では、個人のスキルアップと組織貢献の項目があるため個々人でも取り組んでいますね。このような個々人がスキルアップできる体制や文化があるため、定型化するようなOpsチームをあえて作っていないです。

白塚:ありがとうございます。ハイタッチ業務の標準化について、小岡さんはいかがでしょうか?

小岡:エンタープライズのお客様の場合は、かなりハイタッチなコミュニケーションをして、営業段階から関わりながら、継続定着支援、利用促進も含め手厚くケアします。各フェーズごとにすることは決まってはいるものの、かなり時間を使ってはいますね。パッケージプロダクトなのでコンサル対応は現実的ではないため、うまく使えるような運用提案をするなど、フェーズごとに決まったアクションを定義して状態を確かめたりします。
プロダクトの特徴として、利用開始までの設定に時間がかかる (チャーンの観点からも全ての中で一番時間をかける) ため、この作業については設定代行パートナーと契約をし、お任せするという形態も併用しています。つまり機械的にできることは外部にお願いをして、それ以降の支援に力を入れられる仕組みを構築しており日々改善するサイクルを回しています。すみません、抽象度高めの話でしかお伝えできないのがもどかしいのですが、、

白塚:エンタープライズ向けであれば、客単価が高い為、属人的に対応することも可能かと思うのですが、いかがですか?

小岡:属人化は、要不要のポイントを整理し、できるだけ排除するようにしています。理由は、お客様が悪い意味で担当に頼り過ぎてしまうことや、その人でないと顧客が困る状態はお互いに良い状態とは言えないため、そういった意味でなるべく属人化は避けるようにしています。言語化できないことはやらない、逆に言語化できることは再現性も期待できるのでどんどんやりましょうという方針でやっています。

白塚:ありがとうございます。

ここまでのまとめ

  • 平準化を進めて良い場合

お客様に関わらず内容が固定化されていることや言語化できることは平準化をできる限り進める。

  • 平準化が難しい場合

チーム内教育でカバーして、組織としての平準化を保つ。また、平準化するためのOpsチームを作らないことも一つのやり方としてある。

  • チーム内教育

ロールプレイや振り返りの機会を設け、個人のスキルを高める。また、メンバー個人だけの知見に留めず、チームにも共有する。


2. 社内への教育の仕組み


白塚:それでは二つ目のテーマに社内の教育の仕組みを作っていく件について、高木さんいかがでしょうか?

高木:チーム内での他の事業部とのやりとりはありますが、それをまた別部署や全社レベルで共有することはないです。一方で、サクセスシェアという取り組みがあって、お客様の数値改善や業務が短縮できたとかの情報はこまめにslackに流しています。そのslack内でやり取りや機能についての議論は生まれているため、改まって共有会は現状は不要と考えています。

魚住:サクセスシェアの内容の粒度について、伺いたいです。

高木:slack専用チャネルに投稿していて、フォーマットはなく、粒度なども決めてないです。例えば、こんな取り組みでCVRがこのくらい上がりました、という具体的な結果から「この機能が使いやすくなりました」というお客様のコメントまで、週に10~20個ほどが投稿されていると思います。カスタマーサクセスとしては、プロダクトリリース時に改善された機能についての内容や今後拡大していきたい領域については、意識して投稿するようにしています。また、投稿内容に対して、セールスやエンジニアのマネージャが他のメンバーを巻き込んで議論することもあります。これは目標というよりは意識的にやっている感じです。

魚住:シェアされる量が多そうなので、流れてしまう印象がありますが、メンバーが気にかけている要因はありますか?

高木:全部逐一見ている人はいないと思うのですが、例えばエンジニアであれば、自分が作った機能については気になると思うので見ているとは思います。

白塚:以前同じような仕組みで運用しているカスタマーサクセスの方とお話しした際に、CXOの方々が毎日みており、良いフィードバックがあれば直ぐにプロダクトロードマップに追加することになっているため皆さん力を入れて投稿していることがあるようでした。また、フォームを作ると投稿数が半分になって止めたという話もあって、フリーフォーマットのほうが投稿しやすいということがあるようでした。

高木:我々も最初ワークフローを作ったのですが、全てのケースに対応できるフォーマットを上手く作れなかったので、フリーフォーマットにしました。

白塚:HERPさんは、VOC (Voice Of Customer:お客様の声) の取り組みを積極的に実施されていたと思いますがどうでしょうか?

加藤:VOCをためるだけではなく、社内の知見としてVOCを精査する中で機能・運用の顧客のお困りごとに対して、どのように説明や代替案の提案を行ったかなど個々人の知見やお客様対応のノウハウを共有しています。改めて振り返ってみると、HERPでは決まったトレーニング機会はあまりないものの、これが一種の育成機会になっていることに今、気づきました。あと、ストックセールス、おもてなし幻想といった書籍など、カスタマーサクセスによくある考え方は共通認識として持っていた方が良いと考えており、トレーニングというよりは、相互で理解した上で日々仕事しています。このおかげで、組織として強いと感じています。

ここまでのまとめ

  • 社内向け教育

社内の誰でもお客様に関する情報に自由且つ気軽にアクセスできる仕組みを作る


おまけ:ハイタッチとOpsのバランス


白塚:追加で聞きたいことしたいことがある方はいますか?
今井:もともとハイタッチが先にあって、後からOpsができたという背景があるのですが、Opsが戦略を立てる部門と言われつつハイタッチも戦略を立てているため、どのようにバランスとっているのかみなさんに聞きたいです。

小岡:いわゆるヘルススコアや利用ログに関連する定量的な分析から見えるリスト化や判断はOpsでやっています。また、その定義もOpsが決める。その内容を元に、動くのかどうかの判断、動く場合の戦術はハイタッチチームで決めるべきなのでそうしています。戦術を決める上で必要な情報があれば、Opsチームに依頼するような仕組みで運用を回しています。

白塚:植原さんは、最近Ops立ち上げをしていたと思いますが役割分担はどうされていますか?

植原:Opsを作った背景として、ハイタッチチームでオペレーション作りをしようと思っていたが手が回らず標準化ができなかったため、明確にオペレーションのみを行うチームを作りました。

今井:私たちがOpsチームを立ち上げた背景も植原さんと同じでした。

加藤:前職では、逆に標準化はハイタッチチームがやっていて、個々人がOKRとして持ってましたね。組織毎にOpsチームとハイタッチチームが業務標準化の取り組みをどう役割分担しているのかは気になりますね。

今井:業務を標準化するためにはトライして改善が必要だと思いますが、OpsがやるとPDCAの回転サイクルが回りにくいなとも最近感じますね。

白塚:現場業務を理解しないと実態と乖離することがあって、データ分析とお客様対応はスキル要件が異なるのでバランスが難しそうで、この辺りも別の機会でお話を聞いてみたいですね。
時間になりましたので、本日はここまでとしたいと思います!お疲れ様でした、ありがとうございました!


さいごに


KOMMONSは、国内最大級のカスタマーサクセスコミュニティを基盤とし、おもに以下の方々向けに支援をしています。

  • 未経験からのスタートを含むカスタマーサクセスキャリアを築きたい個人の方向けのコミュニティ運営

  • カスタマーサクセスの立ち上げフェーズで業務設計や採用に課題を感じているカスタマーサクセス責任者・事業責任者の方

カスタマーサクセスに関わっているもしくは興味がある方は、各リンクから確認してもらえると嬉しいです!
KOMMONSについて、詳しく知りたい
コミュニティに参加したい
KOMMONSをどうぞこれからもよろしくお願いします。

この記事が気に入ったらサポートをしてみませんか?