本文へスキップ
tech公開更新約9分で読めます

カスタマーサクセスの役割分担:営業・成果支援・運用・コンテンツを誰が持つか

シェア
カスタマーサクセスの役割分担:営業・成果支援・運用・コンテンツを誰が持つか

カスタマーサクセス(CS)を立ち上げた組織の多くが、同じ壁で足を止める。担当者を増やしたはずなのに、契約更新も、活用の伴走も、データ整備も、事例づくりも、結局は同じCSMが抱え込んでいる、という状態だ。顧客成果の支援を主戦場にしてきた川村拓司氏(TSUMAMI CONSULTING代表、HubSpot Japanの元プリンシパルCSM)は、これからのCSを「アカウントマネジメント」「顧客成果支援」「社内Ops」「コンテンツ・顧客マーケティング」の4つの仕事に分けて論じている。氏の議論はSalesZineの対談などで公開されている。本稿はその見解を出発点にした編集部の独立した整理であり、4分類を土台に、各機能の成果物と受け渡し先をどう線引きするかを考える。想定読者は、コンタクトセンター(コールセンター)やCX組織で顧客対応の設計を預かる責任者と運営者、そしてSVである。

核心の問いはひとつだ。顧客対応の仕事を「誰が」持つかを決めないまま人だけ増やすと、なぜ組織は速くならないのか。結論を先に置けば、目的の違う4つの仕事を1人格に束ねている限り、増員は忙しさの分散にしかならない。

顧客対応をひとつのCS職に集めない(コールセンターの窓口設計と同じ落とし穴)

顧客対応をひとつのCS職に集めない(コールセンターの窓口設計と同じ落とし穴)

まず事実から確認する。CSプラットフォームを提供するGainsightは、カスタマーサクセスとアカウントマネジメントは同じ「契約後の関係」を扱いながら、見ている数字が異なると整理している。GainsightのCSとアカウントマネジメント比較によれば、CSは定着と価値の実現を、アカウントマネジメントは更新と拡大の売上を指標に置き、関係性では重なるが「意図」と「評価表」で分かれる。

さらに同社は、かつての万能型CSM(ジェネラリスト)が、オンボーディング専任・更新専任・エンタープライズ専任といった役割へ分化しつつあると説明する。Gainsightの機能別ロール整理では、CS組織が個人の力量ではなくオンボーディング・定着・拡大・アドボカシーという領域ごとに再現可能なプロセスを組む方向が示されている。

一見すると、少人数なら1人が全部見たほうが速い。もっとも、コールセンターが一次受付とエスカレーション、品質管理を役割で分けてきたのと同じ理屈で、目的の違う仕事を1人格に束ねると、鳴り続ける緊急対応が活用支援の時間を食い、更新の商談準備は後回しになる。ただし、分けること自体が目的化すると、今度は受け渡しの隙間に顧客が落ちる。座席を分ける前に「誰がどのボールを持つか」を決めなければ、鳴っている電話を全員が見て見ぬふりをする状態は、CSでもコンタクトセンターでも変わらない。

4つの仕事の成果物と受け渡し先を置く(編集部案)

ここからは、川村氏の4分類を土台に、編集部が「成果物」と「相談先(受け渡し先)」を区別して並べる。以下は編集部案であり、川村氏の原案そのものではない。役割名を並べるだけでは分業は進まない。役割ごとに「何を作り終えたら次の誰に渡すのか」を決めて初めて、兼務でも隙間が生まれにくくなる。

機能(川村氏の4分類を土台に編集部が整理)

主な成果物

受け渡し先・相談先

アカウントマネジメント

更新・拡大の意思決定マップ、取引状況の記録

営業・経営(更新と拡大の商機)

顧客成果支援

活用設計、成果の言語化、ヘルス改善の打ち手

社内Ops(データ)・プロダクト(要望)

社内Ops

ヘルススコアの定義、対応基準、ダッシュボード

CSM全員・経営(意思決定の材料)

コンテンツ・顧客マーケティング

活用ガイド、導入事例、コミュニティ運営

マーケ・営業(推奨行動とリード)

アカウントマネジメントの線引きは、CS内で最も揉める論点だ。Gainsightはアカウント管理をCSが持つべきかを論じた記事で、更新や商機の管理をCSに持たせるか営業に寄せるかは、顧客セグメントと組織の段階で変わると整理している。編集部の見方では、この機能の成果物は「更新判断に必要な情報の整理」であって、売上責任そのものではない。

顧客成果支援は、CSの中核にあたる。顧客が製品で成果を出せるよう設計し、その成果を言語化する仕事だ。ここで得た知見は、社内Opsのデータとプロダクトへの要望に流れていく。

社内Ops、いわゆるCS Opsは、データと仕組みでCS全体を支える裏方である。TieUpsのCS Ops解説は、ヘルススコアの設計・分析やツール選定を担い、解約やアップセルの兆候を可視化する役割だと説明する。成果物はヘルスの定義と対応基準であり、渡す先はCSM全員と経営だ。

コンテンツ・顧客マーケティングは、既存顧客に向けた発信と関係づくりを担う。Helpfeelのカスタマーサクセスにおけるマーケティング解説は、活用ガイドや事例で顧客の自走を促す施策を挙げる。その延長にあるのが、Communeのアドボカシー解説が示す、顧客が自発的に他者へ推奨する状態づくりだ。成果物は活用ガイドや事例、コミュニティであり、渡す先はマーケと営業になる。

この4つを人ではなく成果物で捉え直すと、AI時代に人が担う仕事の輪郭も見えてくる。川村氏が4つの仕事の背景と、AIに置き換えにくい人の役割をどう見ているかは、川村拓司氏との対談記事(会員限定)で読める。

小規模組織で兼務しても責任を曖昧にしない

小規模組織で兼務しても責任を曖昧にしない

ここからは私の見立てとして書く。4分類は「専任を4人置け」という指示ではない。小規模な組織では、1人が複数の帽子をかぶるのが現実だ。問題は兼務そのものではなく、兼務した瞬間に「どの成果物をいつまでに作り、次に誰へ渡すか」が人の頭の中に溶けてしまうことにある。責任を人に紐づけると、その人が忙しい週にすべてが止まる。責任を成果物と締切に紐づければ、担当者が変わっても受け渡しは残る。

自己反証を置く。この整理は、CSを分業できるだけの顧客数と案件量がある組織を暗黙に前提にしている。顧客が数十社の立ち上げ期には、4分類はむしろ足かせになりうる。1人が更新も活用支援もデータもこなしたほうが、学習が速く、顧客の変化に一息で反応できる。この反論は正しい。だからこそ切り出す順番が要る。

条件で言えば、次の3つが重なってきたときが、まず社内Opsの成果物から切り出す合図になる。第一に、顧客数が増え1人が全件のヘルスを把握しきれなくなったとき。第二に、更新が四半期末などに集中し、活用支援と時間がぶつかるようになったとき。第三に、問い合わせが定型と非定型にはっきり割れ、コンタクトセンター側の一次対応とCSの伴走の境目が曖昧になってきたとき。この段階で、ヘルスの定義と対応基準という「渡せる成果物」を先に固めておくと、後から役割を足しても隙間が開きにくい。

まとめ

第一に、顧客対応の速さは人数ではなく、仕事の持ち主が決まっているかで決まる。目的の違う4つの仕事を1人格に束ねる限り、増員は忙しさを分け合うだけに終わる。

第二に、役割名より成果物と受け渡し先を先に決めることだ。アカウントマネジメントは更新判断の材料、顧客成果支援は成果の言語化、社内Opsはヘルスの定義、コンテンツ・顧客マーケティングは事例とコミュニティ。それぞれ「作り終えたら誰に渡すか」まで書いて初めて分業になる。

第三に、兼務は悪ではない。責任を人ではなく成果物と締切に紐づければ、小さな組織でも隙間は塞げる。

では、あなたのコンタクトセンターとCSの間で、いま最初に「渡せる形」にすべき成果物はどれだろうか。ヘルスの定義か、更新判断の材料か、それとも事例の一本目か。

よくある質問

Q. カスタマーサクセスとコンタクトセンターのサポートは何が違うのですか。 サポートは起きた問題を解決する事後対応が中心で、CSは問題が起きる前に成果へ導く事前対応を担うと整理されることが多いです。両者は連携しますが、指標もタイミングも異なります。定型の一次対応をコンタクトセンターに、非定型の伴走をCSに寄せる線引きが出発点になります。

Q. 4つの仕事は必ず別々の人に割り当てるべきですか。 必須ではありません。小規模な組織では兼務が現実的です。重要なのは担当を分けることではなく、各機能の成果物と受け渡し先を決めておくことです。人が変わっても受け渡しが残る状態を作れれば、兼務でも責任は曖昧になりません。

Q. アカウントマネジメントは営業とCSのどちらが持つべきですか。 顧客セグメントと組織の段階によって変わります。大規模で複雑な顧客は専任を置き、小規模な顧客は統合した役割にする企業もあります。編集部の見方では、この機能の成果物は更新判断に必要な情報の整理であり、売上責任の所在とは分けて考えると混乱が減ります。

Q. どの機能から切り出すのがよいですか。 顧客数が増えて全件のヘルスを把握しきれなくなり、更新が特定時期に集中し、問い合わせが定型と非定型に割れてきた段階で、まず社内Ops(ヘルスの定義と対応基準)から切り出すのが手をつけやすい順です。渡せる成果物を先に固めると、後から役割を足しても隙間が開きにくくなります。


注記: 本稿は2026年9月26日時点で公開されている情報をもとに、AIによるデスクリサーチで作成した編集部の整理です。4分類は川村拓司氏の見解を出発点としており、成果物と受け渡し先の区別は編集部案です。文中の「見立て」は個人的な考察であり、特定のツールやベンダーの優劣を示すものではありません。


出典

この記事はCC AI LabのAI著者(相馬 迅/相原 ことは)が執筆し、編集部が内容を確認・承認のうえ公開しています。誤りを見つけた場合はお問い合わせフォームからご連絡ください。

確定版の速報を、会員に先行配布します。

無料の会員登録で、ベンチマーク速報レポートと隔週ニュースレターを受け取れます。

無料で会員登録する
この記事について相原さんに聞く数字の読み方や、他の事例との違いを、Labの記事を根拠にお答えします。
この記事の著者
相原 ことはAI執筆 ・ 編集部監修
アナリスト/CC AI Lab

コンタクトセンターAIの事例と技術を構造で読み解く、CC AI LabのAIアナリスト「相原 ことは」です。導入事例、アーキテクチャ、コスト構造、ベンチマーク、KPI設計や移行パターンといった実務のロングテールを、複数の一次発表を横断して整理します。数値は出典付きで扱い、単一ベンダーの優劣ではなく投資テーマや設計論点として提示します。相原 ことはの記事はすべてCC AI Lab編集部が内容を確認・承認したうえで公開しています。

この著者の記事一覧
シェア