CSがやるべきことの核はどこにあるのか
今回のテーマは「CSはどこまでやるべきか」。抽象度が高いテーマなので、MCをいつもの城田さんから大脇さんにバトンタッチしてスタートします。
まず大脇さんが投げかけたのは、HRテックのCSにおいて「CSがやるべきことの核」はどこか、という問いでした。最初に答えたのは綾部さんです。
結構フェーズによるという前提がすごい重要になってきます。特に初期のフェーズは、お客様のアウトカム創出に必要なプロセスは全部やる、というのがいいのかなと思ってます。
ただし綾部さんは、「全部やる」にも条件があると釘を刺します。プロダクトの成長につながらないことは、初期フェーズでもやらないほうがいい、という考え方です。
(初期設定の代行を無償で)ずっと引き受けてしまうと、本来お客さん側が設定してプロダクトで完結しないといけないことが、機能として成熟しないんですよね。
無償の初期設定代行を抱え込むと、顧客数が増えるたびにCSも過剰に増やさなければならなくなります。結果として、本来向き合うべきアウトカムに時間が取れなくなるというのが綾部さんの見立てです。
ここで城田さんは論点を広げます。CS内部の話だけでなく、ザ・モデル ── マーケ・インサイドセールス・営業・CSと役割を分業する営業プロセスの型。米セールスフォースの手法をもとに日本のSaaS企業で広く使われていますの中で、セールスとCSの分担をどう考えるかを問いました。
めっちゃ理想は、セールスがアウトカム創出までのプランニングまでできてるみたいなのが理想かなと思ってますね。
綾部さんによると、成果への道筋が固まらないまま受注すると、顧客が違う解釈をしたり「もっと支援が受けられると思っていた」という認識のズレが生まれます。だからこそ、期待する成果とそのプロセスのプランニングまでセールスがやってくれると、引き継ぎがスムーズになるといいます。
オンボーディングは人がやらないのが理想?
続いて瀧田さんが、少しドキッとするような理想像を語ります。8年CSをやってきた立場からの本音でした。
こういうこと言っちゃうと怒られるかもしれないですけど、オンボーディングは人がやらないのが理想だと思うんですよね。
瀧田さんの整理では、戦略はセールスが描けても、それをどう実現するかの「戦術」の部分にこそCSが介在する価値があります。深く顧客の業務を理解して改善しに行くことで、システムをインフラ化していく、という考え方です。
お客様がどれだけ今の状態がいいと思ってても、こうしたらもっと良くなるという例を把握してるのは、ユーザーよりベンダー側だと思うんです。
瀧田さんは、顧客がまだYESと言っていなくても「強制的に振り向かせる」くらいのことができて初めて、真のカスタマーサクセスに近づくと話します。大脇さんは「すごいCSの本質という感じ」と受けました。
ここで話は、HRテックならではの初期設定の重さに移ります。人事労務では過去分のデータ移行が入り、その作業でつまずくと本質にたどり着く前に頓挫してしまう、と城田さんは前職の経験を振り返ります。
難しいのは、その設定作業を誰がやるか。AIというワードが出る前は、CSが持つと工数の問題になるため「お客さんにやってもらうのがベスト」という判断が主流でした。
設定ってほぼ一回、最初の初期設定なんで、やってあげちゃった方が最終ROIは出やすいのかなっていう所感はありますね。
城田さんは、BPO ── 業務プロセスの一部を外部の専門業者に委託すること。Business Process Outsourcingの略で、代行ニーズの強い業務を切り出す手段として使われますやAIなど、CS以外のリソースで初期設定をまかなえないかという方向性にも触れます。
ただし城田さんは、これを無償でやってしまうのはちょっと違うと線を引きます。代行ニーズが強いプロダクトなら、有償のプロフェッショナルサービスとして用意しておくことが重要だ、という結論です。
沼にはまる不具合対応、CSが手放すべきこと
後半のテーマは反転して「CSがやるべきでないこと」。まず綾部さんが挙げたのは、有償化できるサービスを無償で提供してしまうことです。
評価制度の構築などは、サービス設計を前提にした無償対応ならいいけれど、有償サービスとして成立した後に「なんとか無償で」と応じてしまうのはNGだ、と綾部さんは言います。
リターンがある状態で無償で支援するのは全然いいと思うんです。でも、サービスとしてあるのに「実は」みたいな形でやると、属人化するしCS組織も疲弊してしまう。
CSって、最後にこちら側が妥協するときの最後の砦になりやすいんですよね。
大脇さんは、「解約します」と言われると無償でやりがち、と共感します。だからこそ、長い時間軸と持続可能性を見据えて、本当に一回やるべきなのかをメタに見たほうがいい、という整理になりました。
瀧田さんが強く避けたほうがいいと挙げたのが、不具合対応やトラブルシューティングです。工数を取られるだけでなく、対応するメンバーのメンタルにも来ると指摘します。
不具合対応ってプラスの感情は受け取らないので、メンタルに来る。本当はサクセスに時間を使いたいのに、マイナスをゼロにする作業しかできなくなってしまう。
瀧田さんの提案は、CSが一人窓口として抱え込まず、事象が起きたら横に流す仕組みを作ること。そのうえで、この人に頼めば安心という関係を保てば、CSは他のことに時間を使えると話します。
城田さんはこれを、テクニカルサポート ── 製品の技術的な不具合や操作トラブルに専門で対応する部隊。CSがすべて抱え込まず、ここへ動線をつなぐことで対応ログも残りやすくなりますへ窓口を移行する話だと補足します。属人的に一人で対応すると、何が起きたかのログデータも残らない、という点も重要だと指摘しました。
瀧田さんは、ToCなら一次窓口・二次窓口の切り分けが当たり前なのに、ToB同士だとそのズレが起きるのが不思議だと投げかけます。城田さんは、HRのドメイン特性が背景にあるのではと返します。
給与計算ってミスが伴うものだから、自分で解決するのが怖い。ベンダーさんの何々さんも言ってたから大丈夫だ、と安心を買いたい心理があるのかなと。
社労士の独占業務、CSが越えてはいけない線
HRテックならではの論点として、城田さんが挙げたのが法的な線引きです。CSが答えていい範囲を越えると、思わぬリスクを負います。
仕様としては設定できますけど、労務的な部分は社労士の方にご確認ください、というところはちゃんと線引きしないと。
等級制度の設計あたりまではギリギリ許されても、労働時間の改善や給与支払いの制度設計まで踏み込むと、社労士の独占業務 ── 社会保険労務士だけが報酬を得て行える業務。労働・社会保険関係の手続き代行や、労務管理の指導などが該当し、無資格者が行うと法令に抵触するおそれがありますに抵触するおそれがある、というのが城田さんの整理です。
言い切ることのリスクってすごくあるので。我々ってシステムのプロであって、法律のプロではないっていうところを切り分けてお伝えしています。
大脇さんは、何もしないと「どっちのプロでしょ」と期待値が膨れ上がってしまい、お互いにとって良くないと言います。城田さんは、導入時に顧問社労士もプロジェクトにアサインしてもらうと、スムーズに進むケースが多いと補足しました。
綾部さんも評価制度の例で線引きを示します。等級グレードごとの年収レンジや昇給ルールは作るけれど、基本給や手当の細かい設計は社労士や労務に委ねる、という暗黙の了解があるといいます。
城田さんはさらに、バックオフィスの入れ替え時に対応に困った例を挙げます。上場準備やセキュリティ監査に関する質問です。
「このシステム入れてたら上場に適用してるってことですよね?」と言われて。それは監査法人に聞いてください、みたいな。
城田さんは、ISMS ── 情報セキュリティマネジメントシステム。組織が情報を安全に管理する仕組みが一定基準を満たしていることを示す認証で、SOC報告書などと同様に監査の文脈で問われますやSOCへの遵守についても、システムを使っていること自体が監査合格を保証するわけではない、と切り分けて答える必要があったと振り返ります。データを扱うバックオフィス領域ならではの綱渡りでした。
CSの役割を一文で言い切ると
最後のテーマは、4人それぞれがCSの役割を一文で定義することです。まず城田さんから。
既存顧客起点で、顧客満足度と事業価値を創造できること。お客様と自社の価値をいかに創造できるかだと思っています。
城田さんは、カスタマーをサクセスさせることはゴールではなくスタートラインだと言います。顧客の成功は役務提供の最低限であり、そこから事業成長やエキスパンションまでできるのがCSの役割だ、という整理です。
瀧田さんの一文は「事業の生命線」。入り口はセールスが取ってくるけれど、それを維持し伸ばすのはCSだと語ります。
プロダクトの設計もサポートのあり方もセールスの取り方も、全てにフィードバックを言えるのって、後工程に生きる僕らならではの強みだと思うんです。
瀧田さんは、フィードバックを伝えるだけでなく、反映させコミットさせるところまでやらないと意味がない、と付け加えます。ただ使わせるだけのオンボーディングはもうサクセスではない、という強い言い切りでした。
城田さんは「生命線」という言葉から、自身の経験を思い返します。CS組織が疲弊して退職が出始めているときは、事業としても危機的状況だった、という実感です。
提供しているお客様に対峙しているので、クライアントの健康状態をモロに食らうのがCS。お客様の鏡としての状態が表れてるのかなと。
綾部さんの一文は「サービスの価値を伝達する役割」。ターゲットとサービス設計が噛み合っていないと、事業としてもうまくいかなくなる、というのがポイントです。
綾部さんは、ジムの場を提供するサービスに本格的なパーソナルトレーナーがつくと、気軽に来た人が戸惑ってしまう、という例えで説明します。ターゲットのニーズに応えるプロセスを設計するのがCS本来の役割だ、という考えです。
城田さんも、飲食領域のプロダクトに関わる中で学んだサービスプロフィットチェーン ── 従業員満足が顧客満足を生み、それが企業の利益や成長につながるという考え方。価格と提供価値のバランスを重視する視点として紹介されていますの考え方を重ねます。価格と期待値に対して適切なラインでサービスを提供することが、トゥーマッチで悩んだときのヒントになると話しました。
吉野家の牛丼で「この牛肉は」とか説明されたら、とりあえずサクッと10分で昼飯を食べたかったんだよ、みたいな。
最後は大脇さん。「事業やプロダクトのビジョンを現実にしていく役割」という一文です。
大脇さんは、大きなビジョンと小さな現実のプロダクトのあいだの隙間を、お客さんの努力かCSのサービスで埋めるしかない、と整理します。ただし、ビジョンから外れたところをサービスするとプロダクトの成長に効かなくなる、と綾部さんの話を受けました。
その隙間を埋めながらフィードバックを集めてプロダクトを成長させ、カバーできない部分はサポートやコミュニティ、エコシステムで埋めていく。さらに外側の会社のビジョンには新規事業として広げていく発見もCSがしやすい、という広い視野の定義でした。
僕は極端ですけど、カスタマーサクセスの仕事をなくすためにずっとカスタマーサクセスをしてるみたいな。
一方で城田さんは、隙間を埋める工夫が裏目に出た「しくじり」も共有します。集計機能がなかったため、CSVとGoogleワークスペースで代替する運用をハックで生み出した結果、本来のダッシュボード機能の成長が遅れてしまった、という話です。
だからこそ、サービスでギャップを埋めるにしても、ちゃんとプロダクトに実装させるという概念を持って埋めないと、誤った方向に成長させてしまうと城田さんは戒めます。CSはその責任も担っている、という締めでした。
PdM的な視点も必要ですし、PMM的にマーケットを広げていく視点も必要ですし、ほんと面白いポジションですね。
まとめ
HRテックのCSは「どこまでやるか」より「どこで線を引くか」が問われる仕事だと4人が語り合いました。無償代行や不具合対応を抱え込まず、法的な領域は専門家に委ね、顧客を自立へ導くこと。そのうえで、フィードバックを通じてプロダクトと事業を伸ばすところにこそ、CSの本質的な価値があるという着地でした。
- 初期設定の無償代行は、プロダクトの成熟を止めCS組織を疲弊させる。代行ニーズが強いなら有償サービスとして用意する
- 不具合対応やトラブルシューティングは沼になりやすい。CSが抱え込まず、テクニカルサポートへ動線を移してログも残す
- 労務や制度設計は社労士の独占業務に抵触しうる。「仕様は設定できるが判断は専門家へ」と線引きし、導入時に顧問社労士も巻き込む
- CSの役割は「顧客満足と事業価値の創造」「事業の生命線」「サービス価値の伝達」「ビジョンを現実にする役割」と、4人がそれぞれの言葉で定義した
- サービスでギャップを埋めるときも、プロダクトへの実装を前提にしないと、成長を誤った方向に導いてしまう




