はじめに
「カスタマーサポート」と「カスタマーサクセス」。
この二つは、しばしば役割の違いとして語られます。
サポートは問い合わせ対応、
サクセスは継続利用や成果の支援。
※この整理自体は、表面的には間違っていません。
ただ、この説明だけでは、現場で起きてきた違和感は説明しきれません。
なぜなら、カスタマーサクセスという言葉は、理想論から生まれた概念ではないからです。
もともとは、従来のカスタマーサポートでは扱えないCSが増えていったことが、その出発点でした。
私はガラケー時代から、ユーザー対応とサービス設計の両方に関わってきました。
問い合わせを解決するだけでは足りない。
しかし、継続や成果だけを追っても、ユーザーの迷いは消えない。
その中で見えてきたのは、
サポートでも、サクセスでも拾いきれない体験の断層でした。
サポートとサクセスはなぜ分けられたのか
一般的には、次のように整理されます。
- サポート：発生した課題への対応
- サクセス：継続や成果への支援
この整理自体は間違っていません。
しかし、分離の理由を「役割の違い」だけで説明すると、本質を見誤ります。
現場で起きていたのは、もっと単純なことでした。
- 問い合わせは来ないが、ユーザーは機能や仕組みを正しく理解しないまま利用している
- 問い合わせ対応は完了しているが、その後の使い方や次に取るべき行動が伝わっていない
- 不満は表に出ないまま、静かに離脱していく
これらは、従来のカスタマーサポートの評価指標では扱えません。
「問題が起きていない」ように見えるからです。
その結果、
CSの中にある“できない領域”を説明するための言葉として、
カスタマーサクセスが生まれました。
現場で見えてきたこと
私が現場で担ってきた業務は、
一般に定義される「問い合わせ対応としてのカスタマーサポート」には収まりません。
FAQやVOCをもとに課題を構造化し、
企画・開発・運営と連携して、仕組みそのものを見直す。
これらはすべて、カスタマーサポートという名称のもとで実行されていました。
FAQの構造化、VOCの分析、部門連携による改善は、
問い合わせに対応する業務ではなく、
体験全体をどう成立させるかという設計行為です。
ただし、これらの業務は
組織上「カスタマーサクセス」として切り出されていたわけでもありません。
一方で、多くのカスタマーサポートの現場では、
「問い合わせを受け、回答する」という役割にとどまり、
FAQの構造化やVOCの分析、部門連携による改善は
サポートの業務範囲として扱われてきませんでした。
その結果、
同じCSでありながら、同じCSでは扱えなかった仕事が現場に生まれ、
それを説明するための言葉として、
後から「カスタマーサクセス」という名称が必要になったのです。
サポートとサクセスの関係
サポートとサクセスは、対立する概念ではありません。
- サポート：課題発生後の「反応」
- サクセス：課題発生前・利用過程での「促進」
この二つは、ユーザー体験の中で担う役割の位置が異なるだけです。
サポートで得られるVOCは、サクセス改善の材料になります。
サクセスで得られる行動データは、サポート改善に還元されます。
本来は、循環してはじめて意味を持つ関係です。
問題は、組織構造が体験の流れを分断してしまったことでした。
サポートとサクセスをつなぐ“設計責任者”──SVの役割
この分断を現場でつなぐ役割を担うのが、SV（スーパーバイザー）です。
SVは、対応の監督者ではありません。
サポート体験全体を、構造として設計・制御する責任者です。
- 問い合わせ対応の質
- FAQの構造と更新
- 行動データとVOC
- 継続施策との接続
これらを横断的に理解し、
ユーザーの「迷い」を減らす構造を整える。
SVが設計視点を持たない現場では、
サポートは「対応の品質管理」で止まります。
一方で、データと構造をもとに判断できるSVがいれば、
サポートとサクセスは、ひとつの体験設計として機能します。
おわりに
カスタマーサポートとカスタマーサクセスは、対立する概念ではありません。
どちらも、ユーザー体験の一部を担う機能です。
サポートという役割定義の中では扱えないCSがあり、
それを区別して語るために、
カスタマーサクセスという名称が必要になったのです。
重要なのは、名前ではありません。
ユーザーの体験を、どこまで構造として捉えられているか。
CSを「対応の仕事」で終わらせず、
「迷わせない体験を設計する仕事」として扱えるかどうか。
そこに、これからのCSの分かれ道があります。
コメント