▼ この記事の内容
カスタマーサクセスは、受注後の顧客が期待した成果へ近づけるように導入・活用・更新前の判断を支援する役割です。営業やサポートとの違いは、目的、タイミング、KPI、引き継ぎ情報、社内で見る成果指標で整理します。
弊社が支援したカスタマーサクセス領域の企業では、更新前会話を見直した結果、更新率4pt改善、更新月の急失注件数27%低下が確認されています。
一方で、QBR準備や顧客情報整理の時間は1社あたり28分増えました。
カスタマーサクセスの役割を曖昧にしたまま始めると、顧客から来た問い合わせを順番に返すだけの運用へ寄りやすくなります。
営業との引き継ぎやKPIが決まっていないと、成果を説明できず、追加人員やツール投資の判断も止まります。
営業改善の観点でも、受注理由と導入後の利用状況をつなげる設計が必要です。
この記事では、カスタマーサクセスの役割を営業・サポートとの違い、仕事内容、KPI、立ち上げ時の失敗条件から整理します。読了後には、自社でCSが担う範囲と、最初に固定すべき引き継ぎ情報を説明できるはずです。
営業AIを入れても売上につながらない理由を、8項目のチェックリストで解説！
＞＞無料で『営業AIを成果につなげる導入前チェックガイド』をダウンロードする
カスタマーサクセスの役割とは
カスタマーサクセスは、受注後の顧客が期待した成果へ近づけるように、導入・活用・更新前の判断を能動的に支援する役割です。単なる問い合わせ対応ではなく、顧客の利用状況と社内の引き継ぎ情報をつなぎます。
カスタマーサクセスは成果創出を支援する役割
カスタマーサクセスの役割は、受注後の顧客が契約時に期待した成果を出せるように、導入から活用定着まで支援することです。顧客の状態を見ながら、次に必要な接点を先回りして設計します。
営業が受注前の合意形成を担うのに対し、カスタマーサクセスは受注後の成果実現を担います。たとえばSaaS企業では、初期設定、利用部門の定着、更新前のリスク確認までを一連の業務として扱います。
役割を正しく置くには、顧客がどの機能を使ったかだけでなく、何を成果として合意していたかを確認する必要があります。商談記録、導入時の要望、問い合わせ履歴を同じ文脈で見ます。
解約防止だけでなく導入支援まで担う
カスタマーサクセスは解約防止だけを担当する部門ではありません。契約直後のオンボーディングで初期価値を出し、利用が止まる前に活用の障害を取り除く役割を担います。
解約が見えてから動く運用では、CSは火消しの担当になりやすくなります。弊社が支援したカスタマーサクセス組織では、更新前会話を見直した結果、更新率が4pt改善し、更新月の急失注件数が27%低下しました。
同じ支援先では、この成果に代償もありました。QBR準備と顧客情報整理の時間は1社あたり28分増え、記録入力も1日あたり11分増えましたが、リスクを早く拾う運用に切り替わりました。
役割が曖昧だと問い合わせ対応係になる
カスタマーサクセスの役割が曖昧な組織では、顧客から来た問い合わせに順番に返すだけの運用へ寄りやすくなります。能動支援の範囲を決めないと、CSの成果は対応件数だけで評価されます。
CS責任者は、問い合わせ対応を否定する必要はありません。問題は、問い合わせの裏にある利用停滞、期待値のずれ、更新前の不安を次の支援に変換できるかどうかです。
よくあるケースとして、営業が受注時の約束をCSへ渡さず、CSが顧客から初めて要望を聞く場面があります。この場合、顧客は同じ説明を繰り返すことになり、担当者への信頼が下がります。
関連する設計を整理する際は、セールステックの領域別整理も確認すると、本記事の論点を実務に落とし込みやすくなります。
営業AI・営業DX セールステックカオスマップ｜課題逆引き7分類
営業・サポートとの違い
営業、カスタマーサクセス、カスタマーサポートは、同じ顧客接点でも担う目的が異なります。違いは部署名ではなく、受注前後のタイミング、追うKPI、引き継ぐ情報で判断します。
営業は受注前、CSは受注後を主に担う
営業は受注前の合意形成を担い、カスタマーサクセスは受注後の成果創出を支えます。境界は担当者名ではなく、契約前後とKPIで切り分けます。
営業の主な役割は、顧客課題を把握し、提案内容と契約条件を合意することです。カスタマーサクセスは、その合意内容をもとにオンボーディングや活用促進を進めます。
責任分界が曖昧なままだと、受注時の約束がCSへ伝わらず、初回接点で認識違いが起きます。弊社の支援先で見られるつまずきも、営業の商談記録とCSの初期対応がつながらない場面から始まることが多いです。
サポートは問題解決、CSは予防に重点を置く
カスタマーサポートは発生した問題への対応を担い、カスタマーサクセスは問題が起きる前の予防に重点を置きます。問い合わせ対応だけをCSに集めると、成果創出の役割が薄まります。
サポートは問い合わせ、障害、操作不明点など、顧客から届いた相談に答えます。CSは利用状況やヘルススコアを見ながら、定着しない兆候を先に見つけて打ち手を考えます。
よくあるケースとして、CSがすべての問い合わせを抱えると、更新前のリスク検知や活用提案に時間を割けません。サポートへ任せる業務を決めると、CSは導入支援や利用定着へ集中します。
目的・KPI・引き継ぎ成果物で比較する
営業、CS、サポートの違いは、目的、KPI、入力情報、引き継ぎ成果物を並べると判断しやすくなります。部署名だけで決めると、顧客接点の抜け漏れを見落とします。
比較時は、誰が顧客と話すかではなく、どの成果に責任を持つかを先に置きます。営業責任者とCS責任者の会話では、「受注後に何を渡せば初回支援が進むか」と確認すると整理が進みます。
| 部門 | 主目的 | 主なタイミング | KPI | 入力情報 | 引き継ぎ成果物 |
|---|---|---|---|---|---|
| 営業 | 課題合意と受注 | 契約前 | 商談化率、受注率 | 商談記録、提案条件 | 合意課題、導入目的 |
| カスタマーサクセス | 成果創出と定着 | 契約後 | 更新率、LTV、活用状況 | 商談記録、利用状況 | 活用計画、リスク情報 |
| カスタマーサポート | 問題解決 | 問い合わせ発生後 | 対応件数、解決時間 | 問い合わせ履歴、FAQ | 解決ログ、ナレッジ |
表で見ると、CSは営業とサポートの中間ではなく、受注後の成果に責任を持つ役割だと分かります。次のセクションでは、CSが実際に担う仕事内容を導入支援、活用促進、解約予防、VOC連携へ分けて整理します。
カスタマーサクセスの仕事内容
カスタマーサクセスの仕事内容は、導入支援、活用促進、解約予防、更新支援、VOC連携に分かれます。担当範囲を業務名ではなく、顧客ステージと成果指標で整理すると責任分界が明確になります。
オンボーディングで初期価値まで伴走する
オンボーディングの役割は、顧客が契約直後に最初の価値を得るまで伴走することです。初期設定の完了だけでなく、導入目的に合う使い始め方まで支援します。
初期価値は、顧客が自社内で導入の意味を説明できる状態まで含めて考えます。SaaSなら、管理者設定、利用部門の招待、最初に見る指標の確認までを一連の流れにします。
導入支援でよく抜けるのは、営業が合意した課題とCSの初回説明がずれることです。初回面談では「今回の導入で最初に変えたい業務は何ですか」と聞くと、期待値のずれを早く見つけられます。
初期対応は、次のように分けると業務範囲を決めやすくなります。
- 導入目的と契約時の約束を確認する
- 初期設定と利用開始の条件を決める
- 最初に定着させる機能を絞る
- 利用開始後の確認日を決める
活用状況から定着しない理由を見つける
活用促進の役割は、利用状況を見て定着しない理由を特定し、次の打ち手へつなげることです。ログや利用回数だけでなく、誰がどの業務で止まっているかを見ます。
利用が少ない顧客には、機能理解の不足、業務フローとの不一致、社内責任者の不在など複数の原因があります。CSは数字を見た後に、顧客の運用場面まで戻って確認します。
ある営業チーム向けSaaSでは、管理者だけが使い、現場メンバーが入力しないケースが起きやすくなります。この場合は利用率を責めるより、入力後に誰が確認し、何の判断に使うかを決める必要があります。
解約予防と更新支援の論点を整理する
解約予防と更新支援の役割は、更新月だけでなく、その前からリスクと継続理由を整理することです。CSは顧客の不満、未活用、成果未達を早めに見つけます。
更新直前に初めて課題を聞くと、価格、社内利用率、担当者変更などの問題を短期間で処理することになります。CS責任者は、更新日の数カ月前から継続判断に関わる情報を集めます。
弊社が支援したCS組織では、更新前の会話を火消しではなく、成果確認と次期活用の合意へ変えました。顧客情報の整理時間は増えましたが、更新前にリスクを拾う運用へ切り替わりました。
VOCを営業とプロダクトへ戻す
VOC連携の役割は、顧客の声を問い合わせログで終わらせず、営業とプロダクトの改善材料へ戻すことです。CSは受注後に見えた期待値のずれや要望を社内へ伝えます。
VOCは要望の一覧ではなく、顧客ステージ、契約時の約束、利用状況と結びつけて扱います。営業には次の提案で誤解を減らす材料として渡し、プロダクトには改善優先度の判断材料として渡します。
支援先の一例では、CSが更新前の不満を営業へ戻したことで、次の商談で約束する範囲が見直されました。プロダクト側にも同じ声を渡すと、個別要望ではなく利用継続に関わる論点として扱えます。
役割別に見るKPIと成果指標
CSのKPIは、解約率だけでなく役割別に分けて設計します。導入支援、活用促進、更新・拡張のどこを担うかにより、オンボーディング完了、成果行動、NRR、リスク検知を見る軸が変わります。
導入支援はオンボーディング完了と初期活用で測る
導入支援のKPIは、オンボーディング完了と初期活用で測ります。初期活用の定義は商材で変わるため、設定完了、初回利用、社内説明のどれを追うかを決めます。
たとえば営業支援ツールでは、アカウント発行だけでは初期活用と呼べません。初回商談記録、管理職レビュー、次回アクションの登録まで見て、業務に入ったかを確認します。
導入支援の指標は、初月の行動を顧客と共有できる形にするのが有効です。次の活用促進では、ログイン率より成果行動に近い指標へ重心を移します。
活用促進はログイン率より成果行動に近い指標を見る
活用促進では、ログイン率より成果行動に近い指標を見ます。利用回数が多くても、業務改善につながる入力やレビューがなければ成果説明には使えません。
成果行動の例は、商談メモの記入、担当者の次回行動登録、マネージャーのフィードバックです。営業責任者へ説明するなら、利用率と成果行動を並べて見ます。
ログイン率を完全に捨てる必要はありません。入口指標として使い、活用率、ヘルススコア、更新前の不安までつなげると、更新・拡張の判断材料になります。
更新・拡張は更新率、NRR、リスク早期検知で見る
更新・拡張の成果は、更新率、NRR、リスク早期検知で見ます。数値改善を保証する指標ではなく、顧客が継続判断に必要な価値を説明できるかを測る軸です。
弊社の支援先では、更新前の会話を定例メモと商談記録で整理し、停止条件を早めに確認した例があります。成果の裏側では、入力ルール整備と会議時間の確保が必要でした。
| 役割 | 見るKPI | 確認する行動 |
|---|---|---|
| 導入支援 | オンボーディング完了、初期活用 | 初回利用、責任者設定、社内展開 |
| 活用促進 | 活用率、ヘルススコア | 成果行動、レビュー、改善アクション |
| 更新・拡張 | 更新率、NRR、リスク検知 | 停止条件、意思決定者、追加利用余地 |
上司に説明する前に、更新率、活用率、NRRの見方を整理しておく必要があります。実行可能なCTA IDは未提供のため、成果指標やROI診断テンプレは公開前に作成確認が必要です。
CSの役割を決める手順
CSの役割は、顧客ステージ、営業引き継ぎ、サポート境界、KPI、導入前質問の順で決めます。最初に範囲を固定すると、立ち上げ後の責任分界がぶれにくくなります。
顧客ステージごとに関与範囲を決める
CSの関与範囲は、契約直後、初期設定、活用定着、更新前のどこで価値を出すかで決めます。全期間を一人で抱える前提にすると、支援が浅くなります。
契約直後はオンボーディング、活用期はヘルススコア、更新前は継続理由の整理を担当範囲に置きます。弊社が支援したSaaS企業の一例では、まず初期設定と活用定着に絞ると運用しやすくなります。
顧客ステージを分けると、CSが能動的に動く場面と、顧客からの依頼を待つ場面を区別できます。次に、営業から何を受け取るかを固定すると、支援の出発点がそろいます。
営業からCSへ渡す情報を固定する
営業からCSへ渡す情報は、受注理由、導入目的、決裁者の期待、運用上の懸念、初回支援で確認すべき約束事項に絞ります。商談記録だけを渡しても、CSは優先順位を判断しにくくなります。
よくあるケースとして、営業が値引き条件や期待成果を口頭で伝え、CSが初回面談で初めて認識する場面があります。このずれは、顧客から見ると社内連携不足として受け取られます。
引き継ぎ項目は、営業責任者とCS責任者が同じ表で確認するのが有効です。最初の一言は、今回の受注で顧客が最も達成したいことは何ですか、と聞く形が使いやすいです。
サポートへ任せる業務を切り分ける
CSとカスタマーサポートの境界は、問い合わせ対応か、成果に向けた能動支援かで分けます。操作方法の回答までCSが抱えると、活用促進や更新支援に時間を使いにくくなります。
サポートへ任せる業務は、不具合一次回答、操作質問、既知FAQの案内などです。CSが担う業務は、利用状況の確認、定着しない理由の特定、更新前のリスク整理に置きます。
境界を決める際は、顧客にとって窓口が増えすぎない設計も必要です。サポートで受けた問い合わせ履歴をCSへ戻す運用にすると、解約予防の材料として使えます。
導入前に確認すべき質問を決める
CS導入前の質問は、誰に、どの顧客ステージで、何を成果として支援するかを明らかにするために使います。質問が曖昧なまま採用やツール選定へ進むと、担当者の努力に依存します。
確認すべき質問は、導入目的、営業からの引き継ぎ情報、サポートとの境界、KPI、顧客ナレッジの管理先の5つです。事業責任者は成果指標、現場責任者は運用負荷を中心に確認します。
この質問を先に決めると、CSを置く理由を社内へ説明しやすくなります。役割設計の次は、立ち上げ時に起きやすい失敗を先回りして潰すことが必要になります。
CS立ち上げの失敗パターン表
CS立ち上げの失敗は、担当者の能力不足ではなく、役割境界、引き継ぎ、KPI、運用設計の不足から起きます。先に失敗条件を表にすると、営業、CS、サポート、プロダクトの分担を決めやすくなります。
立ち上げ前に確認したい失敗パターンを整理します。
| 失敗パターン | 起きる原因 | 影響 | 回避策 | 関係部署 |
|---|---|---|---|---|
| 問い合わせ対応係化 | 能動支援の範囲が未定義 | 活用促進と更新支援が後回しになる | オンボーディング、活用確認、更新前面談を業務に入れる | CS、サポート |
| 営業引き継ぎ不足 | 受注理由と約束事項が残らない | 初回支援で顧客期待とずれる | 商談記録、導入目的、懸念事項を固定項目で渡す | 営業、CS |
| KPI不在 | 解約率だけで成果を見ている | 初期価値や活用定着を説明できない | 導入完了、活用率、更新理由、LTVを分ける | CS、事業責任者 |
| ツール先行 | 運用前提を決めずに機能比較へ進む | 入力が増えて現場に定着しない | 入力する情報、見る会議、更新担当を先に決める | CS、情シス、事業責任者 |
表の要点は、CSの失敗がツール選定より前の設計不足から起きる点です。役割を決める順番を守ると、立ち上げ後の手戻りを減らせます。
問い合わせ対応係化を防ぐ
CSを問い合わせ対応係にしないには、受け身の回答業務と、成果に向けた能動支援を分けます。操作質問までCSが抱えると、オンボーディングや更新前の対話が薄くなります。
よくあるケースとして、サポート窓口が未整備のままCSを置くと、顧客からの質問がすべてCSへ流れます。営業責任者から見ると、CSの成果が見えず、追加人員の説明もしにくくなります。
防ぐには、FAQ回答、障害一次対応、操作案内をサポート側へ置き、CSは導入目的と活用状況の確認に時間を使います。一般的な定義を補う場合は、カスタマーサクセスの基本的な役割整理も確認材料になります。
営業引き継ぎ不足を防ぐ
営業引き継ぎ不足は、受注理由、決裁者の期待、導入時の約束事項がCSへ渡らないことで起きます。商談記録が残っていても、CSが初回支援で見るべき要点が整理されていなければ機能しません。
支援先の一例では、営業が口頭で伝えた期待成果をCSが把握できず、初回面談で顧客から説明を受け直す場面がありました。この状態では、顧客は導入直後から社内連携の弱さを感じます。
防ぐには、営業からCSへ渡す項目を受注理由、利用部門、成功条件、懸念事項、次回確認事項に固定します。顧客に最初に聞く一言は、今回の導入で最初に変えたい業務は何ですか、が使いやすいです。
KPI不在とツール先行を防ぐ
KPI不在とツール先行は、CSの成果を説明できないまま運用だけ増やす失敗につながります。ツールを入れる前に、導入完了、活用率、更新理由、LTVを誰が見るかを決めます。
弊社が支援したカスタマーサクセス領域の企業では、更新前会話を見直した結果、更新率4pt改善、更新月の急失注件数27%低下、NRR5pt改善が確認されています。一方で、QBR準備や顧客情報整理の時間は1社あたり28分増えました。
この事例は、入力負荷をなくせば成果が出るという意味ではありません。KPI、会議、記録更新の担当を決めてからツールを使うと、次のセクションで扱う商談記録や顧客ナレッジも判断材料として活用しやすくなります。
AI・商談記録・顧客ナレッジの使い方
AIや商談記録は、カスタマーサクセス業務を丸ごと自動化する道具ではありません。受注理由、問い合わせ履歴、確認済みのナレッジを整理し、人が判断するための材料として使います。
商談記録は受注理由と約束事項を渡す材料になる
商談記録は、営業からカスタマーサクセスへ受注理由と約束事項を渡す材料になります。導入目的、決裁者の期待、懸念点を残すと、初回支援のずれを減らせます。
よくある失敗は、営業が受注時に話した成功条件を、CSが把握しないままオンボーディングを始めることです。SaaS企業なら、商談メモに導入目的、利用部門、初期設定の期限を残すだけで、初回面談の確認漏れを抑えられます。
商談記録を渡す目的は、営業の会話を監視することではなく、顧客との約束を支援計画に変えることです。受注前の情報を整理できると、次は問い合わせ履歴から継続利用の兆候を読み取りやすくなります。
問い合わせ履歴は解約兆候を見つける材料になる
問い合わせ履歴は、顧客がつまずいている機能や業務を見つける材料になります。単発の質問ではなく、同じ顧客や同じ機能で繰り返される相談を見ます。
導入後3か月の顧客で、管理画面の設定変更に関する問い合わせが続く場合、利用意欲の低下ではなく初期設計の不一致が原因かもしれません。CSは問い合わせ件数だけで判断せず、質問内容、発生時期、利用ステージを合わせて確認します。
問い合わせ履歴を読むときは、解約予防の仮説を作ってから顧客接点に移すのが有効です。サポート対応の記録をCSの判断材料へ変えると、顧客ナレッジの整備にもつながります。
確認済みのナレッジで支援方針のぶれを減らす
確認済みのナレッジは、CS担当者ごとの案内や判断のぶれを減らす前提になります。FAQ、導入手順、業種別の注意点を更新し、顧客対応の前提をそろえます。
担当者が増えると、同じ質問に対して回答の粒度が変わりやすくなります。たとえば製造業向けの導入支援では、現場部門と管理部門で見る画面が違うため、部門別の案内手順をナレッジ化しておくと説明が安定します。
ナレッジは作って終わりではなく、商談記録と問い合わせ履歴から更新する運用が必要です。古い回答を放置すると誤案内につながるため、AI活用も人の確認と更新ルールを前提にします。
AI活用は人の確認と更新運用を前提にする
AI活用は、確認済みのナレッジと人の確認を前提にするとCS業務へ組み込みやすくなります。AIの回答をそのまま顧客へ出すのではなく、要約、分類、確認候補の作成に使います。
AIを入れればCS業務が自動化できると期待すると、誤った回答や古いナレッジの再利用が問題になります。営業責任者やCS責任者は、AIが参照する情報、回答を確認する担当者、更新頻度を先に決める必要があります。
CSの役割を広げるほど、商談記録、問い合わせ履歴、顧客ナレッジをつなぐ運用設計が欠かせません。まずは自動化の範囲ではなく、どの判断を人が担い、どの情報をAIが整理するかを分けるのがおすすめです。
よくある質問
カスタマーサクセスの役割を一言でいうと何ですか
カスタマーサクセスの役割は、受注後の顧客が期待した成果を出せるように支援することです。導入支援、活用促進、解約予防、更新支援までを顧客ステージに合わせて担います。
カスタマーサクセスは営業が兼任してもよいですか
立ち上げ初期は営業が兼任する場合もあります。ただし、受注前の提案と受注後の成果支援は目的が違うため、引き継ぎ情報、担当範囲、KPIを分けて管理する必要があります。
カスタマーサクセスのKPIは何を見ればよいですか
CSのKPIは解約率だけでなく、オンボーディング完了、初期活用、活用率、ヘルススコア、更新率、NRR、VOC連携などを役割別に分けて見ます。具体的な進め方は組織の現状に応じて調整します。
まとめ
カスタマーサクセスの役割は、受注後の顧客が成果へ進むために、導入支援、活用促進、解約予防、更新支援、VOC連携を担うことです。営業は受注前の合意形成、サポートは発生した問題解決を主に担うため、CSは目的、KPI、入力情報、引き継ぎ成果物で境界を決めます。
役割と成果指標を決めないまま立ち上げると、CSは問い合わせ対応係になり、営業引き継ぎの不足やKPI不在が後から表面化します。更新前になって受注時の約束、利用停滞の理由、継続判断の材料を探す状態では、担当者の努力だけで顧客対応を支えることになります。
まずは費用やツール比較に進む前に、CSがどの顧客ステージを担い、営業から何を受け取り、何を成果として測るかを整理します。CSの役割と成果指標を1枚で説明できる状態にしておくと、担当者は社内説明と初期設計を同時に進めやすくなります。
※具体的な数値は導入企業の許可を得た範囲で一部加工しています
営業AIを入れても売上につながらない理由を、8項目のチェックリストで解説！
＞＞無料で『営業AIを成果につなげる導入前チェックガイド』をダウンロードする
