CS・セールス・サポートの違いと連携｜役割分担と効果的な協力体制の作り方

カスタマーサクセス部門を立ち上げたものの、カスタマーサポートとの線引きが曖昧で、気づけば問い合わせ対応に追われている。営業から引き継いだ顧客がうまく定着せず、更新のタイミングで解約が出てしまう。こうした「役割の境界」と「部門間の連携」の未整備は、CSの現場でよく起きる問題です。

カスタマーサポートは問い合わせに応じる受け身の対応、カスタマーサクセス（CS）は顧客が製品で成功するよう先回りで能動的に支援する取り組み、セールスは受注獲得を担います。3者は担当する顧客フェーズと、成果として何を追うかが異なります。違いを理解して分けたうえで連携させて初めて、継続・拡大が回るようになります。この記事では、3者の違いを姿勢・目的・KPI・担当フェーズの観点で整理し、そのうえで役割分担・引き継ぎ・情報一元化という連携設計の具体まで示します。

カスタマーサクセスの体系的な全体像はカスタマーサクセスとは（総論）をあわせて参照してください。

CS・カスタマーサポート・セールスの違い

3者はいずれも顧客に向き合う仕事ですが、区別する軸は明快です。カスタマーサポートは問題が起きてから応じる受け身の対応、カスタマーサクセスは問題が起きる前に働きかける先回りの能動支援、セールスは契約前の商談から受注獲得までを担います。この違いは「姿勢と目的」「KPI」「担当する顧客フェーズ」の観点で捉えると整理しやすくなります。以下の比較表で全体像を一望し、各観点で順に掘り下げます。

はじめに、記事で使う用語を定義します。CS（カスタマーサクセス）は顧客が製品・サービスで成果を出せるよう能動的に支援する取り組み・組織を指します。LTV（顧客生涯価値）は1顧客が取引期間を通じて生み出す利益の総和、チャーンレート（解約率）は一定期間に解約した顧客・契約の割合です。アップセルは上位プランや追加機能への引き上げを指します。

応答時間の目標値やチャーンレートの平均といった数値は業種・事業モデルで大きく変わるため、ここでは相場として断定しません。

姿勢と目的の違い（受け身か先回りか）

最も本質的な違いは、顧客が困ってから動くか、困る前に動くかにあります。カスタマーサポートは、顧客からの問い合わせやトラブル報告を受けて対応します。問題の解決と不満の解消がゴールであり、対応が完了すればその案件は閉じます。

一方でカスタマーサクセスは、顧客が困る前に働きかけるのが仕事です。目的は問題解決の先にある「顧客が製品で成果を出し、使い続けること」に置かれます。

たとえば、契約したのに一部の機能がしばらく使われていない、ログイン頻度が落ちてきた、といった活用が進んでいない兆候をCSが検知し、解約や問い合わせが発生する前に自ら連絡して使い方を提案する。これが先回りの支援です。サポートが「呼ばれてから応える」のに対し、CSは「呼ばれる前に動く」点で姿勢が根本から異なります。

セールスの目的はさらに手前にあります。見込み顧客に価値を提案し、契約を獲得することが成果です。3者はゴールの位置が「受注（セールス）」「解決（サポート）」「成功・継続（CS）」とずれており、この目的の差が次に述べるKPIの違いに直結します。

KPI・成果指標の違い

追う指標が違えば、評価も動機づけも変わります。カスタマーサポートは、問い合わせにどれだけ速く・正確に応えたかが問われ、応答時間・解決率・顧客満足度が代表的な指標になります。カスタマーサクセスが見るのは、顧客が使い続けているか、価値を広げているかです。

チャーンレート（解約率）を下げ、LTV（顧客生涯価値）を高め、アップセル率を伸ばすことに責任を持ちます。セールスは受注数・受注率・売上で評価されます。

ここで実務上の含意が2つあります。1つは、KPIが違うため同じ人・同じチームで無理に兼ねると、どちらかの指標が犠牲になりやすいこと。もう1つは、サポート的な指標（解決速度）だけでCSを評価すると、先回り支援が評価対象から外れて形骸化することです。CSを立ち上げるなら、サポートの指標とは別に継続・拡大の指標を設計する必要があります。

CSのKPI設計を体系的に知りたい場合は、親ピラーのカスタマーサクセスとは（総論）で網羅的に扱っています。本記事では3者を区別する観点に絞ります。

担当する顧客フェーズの違い

3者は、顧客が契約に至り、利用し、更新・拡大していく時間軸の中で担当区間が分かれます。契約前から受注までがセールス、契約後の導入（オンボーディング）から定着、更新・拡大までがカスタマーサクセス、そして利用中に問題が発生したときの対応がカスタマーサポートです。

重要なのは、この区間が完全に分断しているのではなく、境界で重なる点です。セールスが受注してCSへ引き継ぐ受注直後、CSが日常支援するなかでサポートが個別トラブルに対応する場面など、担当が交わるポイントがあります。この重なる区間を誰がリードするかを曖昧にしたままにすると、後述する引き継ぎ漏れや二重対応が起きます。

なぜ3者の混同が起きるのか

3者、とくにCSとサポートが混同されるのは、どちらも契約後の顧客対応に見え、接点が実際に重なるからです。ただし線引きは可能で、「顧客が困ってから動くか、困る前に動くか」「ゴールが問題解決か、顧客の成功か」で判別できます。混同を放置すると、CSが日々の問い合わせ処理に埋もれ、本来担うべき先回りの支援ができなくなります。この節では、混同が実務にもたらす害と、境界を引くための問いを示します。

混同が生む最も典型的な問題が、CSのサポート化です。CSに問い合わせ窓口を兼ねさせると、目の前の問い合わせ対応が優先され、活用状況を見て先回りするという時間のかかる仕事が後回しになります。結果として、チャーンやアップセルといったCS本来の成果が上がらず、「CSを置いたのに解約が減らない」という状態に陥ります。これは人の能力の問題ではなく、役割と指標の設計の問題です。

境界を引くには、対応のたびに次の2つを問うと実務的です。1つは「その対応は、顧客が困ってから始まるものか、困る前に自分から始めるものか」。前者はサポート、後者はCSの領域です。もう1つは「その成果に最終的な責任を持つのは誰か」。問題解決の完了に責任を持つならサポート、顧客が成果を出し使い続けることに責任を持つならCSです。この2問で切り分けると、重なる場面でも主担当を決めやすくなります。

3部門をつなぐ連携・協力体制の作り方

違いを理解して役割を分けるのは出発点にすぎません。3者は顧客ライフサイクルに沿って連携させて初めて、継続・拡大という成果につながります。連携設計の要点は「フェーズ別の役割分担の明確化」「引き継ぎ（ハンドオフ）ルールの整備」「顧客情報の一元化」の3つです。この3点が揃うと、営業が得た顧客情報をCSが引き継いで活かし、サポートが拾った不満やつまずきをCSが先回りのフォローに転換できるようになります。以下で各要点を手順まで掘り下げます。

フェーズ別の役割分担の設計

役割分担は「誰が何を担当するか」を、フェーズと重なる区間の両方で決めることが肝心です。受注・オンボーディング・定着・更新／拡大のどこで誰が主担当かを決め、担当が交わる引き継ぎ区間を誰がリードするかまで明文化します。ここが曖昧だと、双方が「相手がやるはず」と考えて対応が抜けます。

進め方は次の手順が実務的です。

• 顧客ライフサイクルを自社の実態に合わせて分解する（たとえば受注・キックオフ・初期設定・本格活用・更新前フォローなど、自社の顧客がたどる段階に落とす）
• 各フェーズの主担当と支援担当を割り当てる（1フェーズに主担当を1つ置き、必要なら支援担当を明記する）
• フェーズを移行する条件（トリガー）を定義する（受注確定でセールスからCSへ、初期設定完了でオンボーディングから定着へ、など）

トリガーを決めておくと、「いつCSに渡すのか」が人によってぶれず、引き継ぎの抜けを構造的に減らせます。役割の職務内容をさらに詳しく設計したい場合は、カスタマーサクセスの役割を参照してください。

引き継ぎ（ハンドオフ）ルールの整備

連携が最も崩れやすいのは、部門をまたぐ引き継ぎの瞬間です。とくに営業からCSへの引き継ぎでは、受注に至った背景や顧客の期待値といった「営業しか知らない文脈」が抜け落ちがちです。ここを口頭や属人的なメモに頼ると、CSは顧客の期待を把握しないまま支援を始めることになり、初動でつまずきます。

営業からCSへの引き継ぎでは、最低限そろえたい項目をあらかじめ定義しておきます。

• 受注の背景（なぜ導入を決めたか、比較検討で何が決め手だったか）
• 導入目的・解決したい課題（顧客がこの製品で何を達成したいか）
• 顧客が抱いている期待値（成果への期待、活用イメージ、懸念点）
• キーマン・関係者（意思決定者、現場の推進役、利用部門の担当）

サポートからCSへの連携も重要です。問い合わせは、顧客が活用のどこでつまずいているかを映す情報源です。同じ機能への質問が続く、設定でつまずく問い合わせが多い、といった傾向をサポートがCSに共有すれば、CSは個別対応の後追いではなく、同じつまずきを抱える他の顧客への先回り支援に転換できます。問い合わせ内容を一過性の対応で終わらせず、CSの支援計画に還元する動線を作ることが、サポートとCSの連携の要です。

連携を支える顧客情報の一元化

役割分担と引き継ぎルールを機能させる前提が、3部門が同じ顧客情報を見られる状態です。顧客情報が営業・CS・サポートそれぞれのツールやファイルに分断されていると、引き継ぎ項目を定義しても転記漏れが起き、同じ顧客に別々の部門が重複して連絡するといった事故が起きます。情報が一元化されていれば、営業が蓄積した商談の経緯を契約後のCSがそのまま参照でき、サポートの対応履歴もCSが把握できます。

たとえばMazrica SalesのようなSFA/CRM（営業支援システム／顧客関係管理）では、取引先を起点に案件・コンタクト（担当者）・アクション（電話・メール・商談などの活動履歴）を紐づけて一元管理でき、営業が蓄積した顧客情報や商談の経緯を、契約後に参照できます。こうした情報の一元化は、部門をまたいだ引き継ぎの抜けを防ぎ、活用状況を見た先回りの支援を後押しします。どのツールを使うにせよ、3部門が同じ顧客像を共有できる基盤があることが連携の前提になります。

連携でつまずく典型パターンと回避策

連携が機能しない組織には、共通する3つのつまずき方があります。「CSがサポート業務に埋没する」「営業とCSの引き継ぎが口頭・属人的で抜ける」「情報が分断されて先回りできない」の3つです。いずれも根っこは役割分担と情報基盤の未整備にあり、精神論ではなく仕組みで解決できます。この節では各パターンを、なぜ起きるかと回避策までセットで示します。

パターン1は、CSのサポート化です。CSに問い合わせ窓口を兼務させると、締め切りのある問い合わせ対応が常に優先され、先回りの支援が後回しになります。回避策は、問い合わせ対応の一次窓口をサポートに切り分け、CSは活用支援に専念できる線引きを作ることです。問い合わせのなかから活用のつまずきを示すものだけをサポートからCSに渡す動線にすれば、CSは対応量に埋もれずに先回りへ集中できます。

パターン2は、引き継ぎ漏れです。営業からCSへの引き継ぎが口頭や個人のメモに依存していると、担当者の記憶や関心によって渡る情報にばらつきが出ます。回避策は、前述のハンドオフ項目をテンプレート化し、SFA/CRM上の取引先や案件に引き継ぎ記録として残すことです。テンプレートで項目を固定すれば、誰が引き継いでも一定の情報が揃い、記録が残るので後から参照もできます。

パターン3は、情報分断です。営業・CS・サポートが別々のツールで顧客情報を管理していると、引き継ぎ漏れや重複対応が構造的に起きます。回避策は、前の見出しで述べた顧客情報の一元化です。同じ顧客情報を全部門が参照できる状態にすることが、他の回避策を支える土台になります。

どこから着手するかは組織の状況で判断できます。問い合わせ量が多くCSが対応に追われている組織は、まずサポートとCSの窓口分離から始めると効きます。引き継ぎ漏れによる初動の悪さが目立つ組織は、ハンドオフ項目の定義から着手すると改善が早く出ます。

まとめ

3者は、受け身で問題を解決するサポート、先回りで顧客の成功を支援するCS、受注を獲得するセールスというように、姿勢・目的・KPI・担当フェーズで線引きできます。そして違いを理解して役割を分けたうえで、顧客ライフサイクルに沿って連携させて初めて、継続・拡大が回り始めます。分けることと、つなぐことは対立しません。

着手の順序は組織の状況で決めるのが現実的です。CSが問い合わせ対応に埋もれている組織は、まず問い合わせ窓口をサポートに切り分けることから始めてください。営業からCSへの引き継ぎ漏れが多い組織は、受注の背景・導入目的・期待値・キーマンといったハンドオフ項目を1枚のテンプレートに定義するところから始めると、少ない負荷で連携の質が上がります。大がかりな体制設計を最初から目指すより、今いちばん漏れている接点を1つ塞ぐほうが早く効きます。

組織づくりや必要なスキルはカスタマーサクセスの組織体制で扱っています。カスタマーサクセスの体系的な全体像はカスタマーサクセスとは（総論）をあわせて参照してください。

よくある質問

Q カスタマーサクセスとカスタマーサポートは兼任してもよいですか？

A

立ち上げ初期で顧客数が少なければ、兼任もひとつの選択肢です。ただし問い合わせ量が増えると、締め切りのある問い合わせ対応に時間を取られ、先回りの活用支援に手が回らなくなります。兼任を続けるなら、問い合わせ対応と活用支援の時間配分を意識的に区切るか、問い合わせが一定量を超えた段階で窓口の切り分けを検討することをおすすめします。

Q 営業からカスタマーサクセスへの引き継ぎで、最低限そろえるべき情報は何ですか？

A

受注の背景（なぜ導入を決めたか、決め手は何か）、導入目的・解決したい課題、顧客が抱いている期待値、キーマン・関係者の4点は最低限そろえたい項目です。これらが欠けると、CSは顧客の期待を把握しないまま支援を始めることになり、初動でつまずきやすくなります。テンプレート化してSFA/CRM上に記録として残すと、担当による情報のばらつきを防げます。

Q カスタマーサクセスとカスタマーサポート、どちらを先に立ち上げるべきですか？

A

組織の課題で判断します。サブスクリプションや継続課金型のビジネスで解約が課題なら、継続・拡大に責任を持つCSを優先します。すでに問い合わせ処理が逼迫していて顧客の不満が蓄積しているなら、まずサポートの体制を整えるほうが先です。両方が課題なら、まず問い合わせ対応の一次窓口をサポートとして立て、そのうえでCSが先回りに専念できる形を作ると、役割の重複を避けられます。

Q 小規模なチームでも3部門を分ける必要はありますか？

A

分けるべきは人ではなく責任範囲です。人数が少なければ、サポート・CS・セールスの役割（機能）を定義したうえで、担当は兼任で構いません。大切なのは、誰がどのフェーズに責任を持つかを明確にしておくことです。責任範囲さえ整理されていれば、人数が増えたときに役割ごとに担当を分けやすくなります。

Q 3部門の連携がうまくいっているかは何で判断できますか？

A

観察できる兆候で判断できます。引き継ぎ漏れが起きていないか、同じ顧客に複数部門が重複して対応していないか、そして更新・拡大のフェーズでチャーンが増えていないかを見ます。引き継ぎ漏れや重複対応が頻発している場合は、役割分担かハンドオフルールのどちらかが未整備のサインです。チャーンの傾向が悪化しているなら、サポートで拾ったつまずきがCSの先回り支援に還元されていない可能性があります。

Q カスタマーサクセスとアカウント営業（既存営業）はどう違いますか？

A

どちらも既存顧客への拡大提案を担う点が重なりますが、起点となる目的が異なります。アカウント営業は売上・受注を起点に動き、拡大の機会を追います。カスタマーサクセスは顧客の成功を起点に置き、顧客が成果を出し使い続けた結果としてアップセルや更新につながる、という順序で考えます。同じ拡大提案でも、売上が先か顧客の成功が先か、という主目的の違いで区別できます。