PLG戦略で成長してきたプロダクトのCSチーム立ち上げと今後の挑戦
この記事はCS HACKアドベントカレンダーの12月8日分として公開しています🎄
自己紹介
こんにちは！株式会社ヌーラボでCSを担当している原と申します。
ヌーラボには2019年に入社しました。Backlogというプロジェクト・タスク管理ツールのCSチームの立ち上げに従事しています。
この記事では、CS未経験の私が紆余曲折ありつつもチームを立ち上げ、10名規模の組織になるまでに実践した内容を備忘録を兼ねて記録したいと思います。
これからCSのの組織を立ち上げようとしている方や、今まさに取り組んでいる方にとってお役に立てたら嬉しいです。
Backlogの生い立ち
はじめに、Backlogについて少し説明させてください。
Backlogは2005年に自分たちが使うためのプロジェクト管理ツールとして生まれました。生い立ちの経緯は「Backlogが15年にわたり愛されてきた理由を、ビジョン・ミッションと共にふりかえる」をご覧ください。
特筆すべきはBacklogはサービスリリースから14年間セールス組織がない状態で、コミュニティ(JBUGというユーザグループがあります！）のつながりやリファラルでユーザが増えていったプロダクトである、という点です。
「PLG戦略」は愚か「SaaS」という単語すら聞くことがなかった時期から、BacklogはPLGの成長ルートをたどっていました。
CSチームの立ち上げ
そんな稀有なプロダクトであるBacklogですが、2019年に初めてインサイドセールス（以後IS）の募集がオープンとなりました。ご縁をいただき、私はISというジョブでヌーラボに入社したのですが、当時はプロダクトトライアル前の所謂【リード情報】を取得していなかったこともあり、ISのコンタクト対象を【無料トライアル中のユーザさま】に絞ることにしたため、メインの業務は「カスタマーサクセス」そのものでした。
「顧客理解」の方法
「カスタマーサクセス」ですから、兎にも角にも「顧客（カスタマー)理解」が最優先だよね、ということで顧客を知ることに専念しました。
幸いにもBacklogはプロダクトリリースから14年経過していたので、チャットやメール経由の問い合わせ履歴が数万件溜まっていたため、入社直後はひたらすら過去のお問い合わせやNPSアンケート回答に目を通しました。
お問い合わせやNPSの傾向から、リリース当初の2005年はBacklogのメインダーゲットユーザはプロジェクト管理を行なっているエンジニアやディレクターの方々でしたが、2019年前後からはリモートワークの普及や「DX」の波もあり、人事や総務といったバックオフィスの方や、営業等のフロント業務を担当している方からもお引き合いが増えていることがわかりました。（今後前者をまとめて「エンジニアセグメント」、後者をまとめて「バックオフィスセグメント」と呼びます）
エンジニアセグメントの場合、導入前から「プロジェクトマネジメント」に関する一定の知識や、ご自身の業務をシステムに落とし込む際の手順をご存知のケースがほとんどです。そのため、CSが導入支援をする必要はなく、ヘルプサイト上で各機能の設定方法などを検索できる状態にしておくことで導入時のお困りごとを自己解決していただく流れが一般的でした。
※ヘルプサイトのサンプル:[課題を受け取って作業を進めよう]
弊社のヘルプサイトは約300記事あり、カスタマーサポートチームが主体となり各記事の満足度を計測しています。(ヘルプコンテンツの改善施策についてもいつかnoteでご紹介したいと思います）
一方、バックオフィスセグメントの方々は「プロジェクト管理」自体に馴染みがないケースも多く、ご自身の業務をどのようにBacklogに落とし込んだら良いのか悩んで導入の足踏みをしているケースがとても多いことがわかりました。
足踏み中のお客様に対して適切なご支援をするにはチャットサポートやヘルプページといったリアクティブな対応では足りなかったため、プロアクティブにこちらから働きかける支援コンテンツを企画することに決めました。
定期的なオンラインセミナーの開催
ご支援すべき顧客セグメントがある程度明確になったので、次に支援手段を検討しました。
ユーザ様のお困りごとの解像度を上げるために数ヶ月間カスタマーサポートチームにまざってお問い合わせの窓口業務を担当させてもらうことに。バックオフィスセグメントのユーザさまからお問い合わせをいただいたタイミングでオンラインMTGを打診し、80社ほどハイタッチサポートを実施しました。
ハイタッチでサポートした80社のお客様のうち、大多数のお客様が導入初期の設定や活用イメージがうまくできない点について課題を感じていらっしゃったことから、まずはプロジェクトの初期設定と複数社の活用事例を共有するセミナーを実施することに決めました。
毎週定期的にセミナーを実施することで、「導入/活用イメージがわかない、デモ画面などを用いて説明して欲しい」というお問い合わせについては個別商談ではなくセミナー受講に案内できるようになりました。
セミナー施策の改善
お客様の期待値に沿った内容をお届けできているか不安だったので、毎回アンケートをとって大小さまざまな改善を続けています。
改善の一例：
・トライアル前、トライアル中それぞれで説明ボリュームを変更する
・Backlogの習熟度に合わせて初級編/中級編とセミナーを分割
・管理者向けのセミナーだけでなく、一般ユーザ向けのセミナーを追加
・事前に投影資料をメールで配布する（「印刷して書き込みをしながらセミナーをみたい！」という声が多かったので）
・セミナー開催後に、アーカイブ動画を共有する（復習に使いたい、参加できなかったメンバーにも共有したい、というありがたいコメントも多数！）
このような地道な改善の甲斐あって、2023年のアンケートの平均点は10点満点中7.9点と高評価をいただけています。
スケーラブルなCS組織を目指して
2019年に1名で取り組み始めたプロアクティブなCS施策でしたがメンバーも1人2人と増え、2022年には6名に！
今まで遊軍のような存在だったCSチームは晴れて「CS課」として独立した課になりました。（2023年はさらに増えて10名体制です）
増員したことでできることも増えますが、組織として動くには新しい課題もチラホラ出てきます。
課長職を担うことになり、この頃から「スケーラブルなCS組織」について考えるようになりました。
とはいえ、経験も知見もないため、とにかく本や記事を読み漁りました。
CS関連の書籍が増えてきましたが、私のおすすめは以下の3冊です。
赤青黄色、信号カラー🚥
これ以外にも数冊読みましたが、何冊か本を読むとどの本にも出てくる共通項が見えてきます。まずはその共通項を頭に叩き込んで、それから自社のプロダクトや組織構造に一番フィットしていそうな具体例を深堀して、真似できそうな部分から実務に落とし込んでいきました。
弊社の場合
・Backlogの単価が低価格である（月額3,000円-8万円、ユーザ数無制限)
・有料契約数13,000件以上（登録ユーザ数は120万人以上）
・CS担当者は当時6名
という点が特徴的だったので「カスタマーサクセス経営（黄色）」に載っていた「PLG戦略で成長している海外SaaSの事例」を参考にすることが多いです。
カスタマージャーニーマップ作り
どの本にも必ず出てくるCSの基本、「カスタマージャーニーマップ」については、CSが組織化したタイミングで改めてワークショップ形式で作成しなおしました。
基本中の基本ですが、これはめちゃくちゃやってよかったです。
メンバー間の目線もそい、共通言語で今後のCS施策について話せるようになったのも収穫でした。
SuccessGAKOの「スケールCS」を受講
スケーラブルなCSについてもっと体系的に学びたいと思い、コミュニティや学びの場を探していたころ、ドンピシャな講座を発見しました。その名も「スケールCS」！
スケールするカスタマーサクセス、略して「スケールCS」は、
"人" 依存を卒業し、データを頼りに全カスタマーをケアする業務レベルへ進化させたい
そんなカスタマーサクセスリーダー向けのオンライン集中特訓プログラム
サクセスラボの弘子さん、Ciscoの小泉さん、リンクアンドモチベーションの杉山さんという豪華な講師陣による「スケールするCS」のための実践的な講座です。
全8回の講義と熱量の高い参加者との討議会を通して、体系的な学びはもちろん、毎回の宿題が結構ボリューミーなのでアウトプットの機会も自然と確保できますし、受講生同士で悩みを相談し合うこともできたり、本当に有意義な機会でした。
「【顧客の成功】を突き詰めて考えていくつかのパターンを設定し、成功までのステップと一つ一つのステップのクリア条件までしっかり定義した上でサクセスプログラムを実施する。」
文字にすると当たり前ではあるのですが、これをやり切るには想像以上に悩むポイントが多いので、先人の教えや仲間からのフィードバックに大変助けられました。
日常業務や家事育児と並行して講座を受講することに迷いや不安もありましたが、本講座は毎回アーカイブ動画を共有していただけるので、都合がつかず参加できなかった講義も後からキャッチアップできて助かりました。
スケールCSの第2期がちょうど募集開始しているので、ビビッと来た方はぜひ参加してみてくださいね。
今後の挑戦
書籍や講座、そして先を走っているCSの皆様のブログなどからたくさんの刺激を受け、CS施策についての知識を身につけることはできますが「知ること」と「実践すること」の間には大きな大きな溝があることを身をもって体感しているところです。
例えば、前段で記載した通り私たちはセミナー施策を3年間ブラッシュアップしてきましたが、効果測定は「正式登録へのコンバージョン」までにどとまっており、セミナー受講前後のユーザ様の具体的な行動変容（例：初期設定をどこまで行ったか、など）まではウォッチできていません。
PLGの成長戦略をとっているサービスならば、行動変容の確認は必須であり、全ての施策はプロダクト利用ログが起点になるべきであることはわかっているのに、仕組みを構築するとなると一筋縄には行きません。
セミナー受講データとプロダクト利用ログの紐付け方法や、データ照会の基盤ツールはどれにするか、そのデータの保管期間はどうするべきか、などなど細かい検討事項が次から次へと出てきます。
リソースの問題、利用規約の問題、課金モデルの問題、いろいろと制約はありますが、今後もCS界隈の皆様の発信から学びつつ、ひとつひとつ自社流にアレンジして仕組みへの落とし込みを進めたいと思います。
最後に
ここまで読んでくださってありがとうございました。
ひとまとめに「カスタマーサクセス」といっても、対象のプロダクトやユーザ様の属性によって実践手段が様々あるため、自社のユーザ様にあったサクセスプランをどう設定し、それをどのように実践/改善をしていくかがCSの組織作りには重要なのだと思います。
弊社の場合はセールス組織がない状態でのCS立ち上げでしたので、ちょっと特殊な事例だったかもしれませんが、BacklogのようなPLGモデルを採用しているプロダクトのCSの方や、PLG/SLGに関わらずCS組織の立ち上げにまさに今取り組んでいる方の参考になれば嬉しいです。
この記事が気に入ったらサポートをしてみませんか？