CSの業務フローと主要活動｜オンボーディングから更新までの一連のプロセス

オンボーディングは手厚くやっているのに、半年後に解約が出る。担当者ごとに支援の中身がバラバラで、何をもって「立ち上げ完了」とするのかも決まっていない。カスタマーサクセス（以下、CS）を立ち上げたばかりの組織で、こうした悩みは珍しくありません。

この記事では、CS業務が「導入→定着→更新→拡大」というどの順序でつながり、各フェーズで具体的に何をやり、何を見て次へ進めるのかを、実務の流れに沿って解説します。フェーズごとの主要活動だけでなく、次に進めるための判断基準（完了判定）と、つまずきやすいポイントの回避策まで掘り下げます。

CSの定義・営業やサポートとの違い・KPIといった体系的な全体像は、カスタマーサクセスとはで整理しています。本記事は、そのうち「業務フロー」だけを深く扱います。

カスタマーサクセス業務の全体の流れ（一連のプロセス）

CS業務は、「営業からの引き継ぎ→オンボーディング→アダプション（活用定着）→リニューアル（更新）→エクスパンション（拡大）」という時系列でつながる一連のプロセスです。個別の問い合わせに都度対応する受け身の業務ではなく、各フェーズの完了判定をクリアしながら顧客を次の状態へ導いていく、能動的な設計が土台になります。契約直後の顧客と、成果が定着して更新が近い顧客とでは、CSがやるべきことがまったく違うためです。

このフローの下段には、常に「ヘルススコアによる状態監視」が帯のように通ります。ヘルススコア（顧客が製品を健全に活用できているかを数値化した指標）で顧客の状態を見ながら、健全なら更新・拡大の会話へ、悪化していればフォローや緊急介入へと動きを切り替えます。以降のH2で、各フェーズの実務内容と、次へ進める判断基準を順に掘り下げます。

フェーズは「顧客の状態」で移り変わる

このフローで最初に押さえておきたいのは、フェーズが「契約からの経過時間」ではなく「顧客の状態」で移り変わる点です。契約から3か月経ったからアダプションに移る、というカレンダー基準ではありません。オンボーディングで合意した初期ゴールに顧客が到達し、主要機能を自力で使えるようになって初めて、活用定着のフェーズへ進みます。

状態基準で進めると、立ち上げが遅れている顧客を「時間が経ったから」という理由で放置せずに済みます。逆に、想定より早く自走した顧客には、更新・拡大の会話を前倒しで始められます。各フェーズに「完了判定」を設けるのは、この状態基準を運用に落とすためです。

営業からCSへの引き継ぎ

一連のフローの起点は、営業からCSへの引き継ぎです。受注時に営業が把握している情報、つまり顧客が何を課題として製品を選んだのか、どんな成果を期待しているのか、決裁者や現場のキーパーソンは誰か、といった商談情報を、CSが引き継いだ状態でオンボーディングを始める必要があります。

ここが抜けると、CSが顧客に一から状況をヒアリングし直すことになり、立ち上げの初動が遅れます。顧客からすれば「営業には話したのに、また同じことを説明させられる」という体験になり、初期の信頼を損ねます。受注時の期待値と成功定義を漏らさず引き継ぐことが、その後のフェーズすべての精度を左右します。

オンボーディング｜導入初期の立ち上げ支援

オンボーディングは、顧客が製品で最初の成果に到達し、自走できる状態になるまでを設計する期間です。CS業務のなかで解約率を最も左右するフェーズであり、ここで「製品を使いこなせる感覚」をつかめなかった顧客は、その後どれだけフォローしても定着しにくくなります。初期の立ち上げを、担当者の勘ではなく再現性のあるプロセスとして設計できるかが問われます。

具体的には、キックオフでの成功定義のすり合わせ、初期設定・データ移行の支援、主要機能の利用開始、という流れで進みます。以下で各ステップと、オンボーディングを「完了した」と判定するための観点を掘り下げます。

キックオフと成功定義のすり合わせ

オンボーディングの最初の山場は、キックオフでの成功定義のすり合わせです。顧客が「この製品で何を達成したいのか」を、できるだけ数値で合意します。「業務を効率化したい」ではなく「月末の集計作業を月10時間削減する」「問い合わせ対応の一次返信を24時間以内にする」といった水準まで具体化します。

このゴールが曖昧なままだと、後のフェーズで「成果が出たのかどうか」を誰も判断できません。更新時に継続の根拠を示せなくなり、拡大提案のきっかけもつかめません。成功定義は、オンボーディングだけでなくリニューアルやエクスパンションまで貫く物差しになります。

初期設定・データ移行・利用開始の支援

成功定義を合意したら、それを実現するための初期設定・データ移行・利用開始を支援します。既存ツールからのデータ移行、権限やアカウントの設定、現場メンバーへの操作レクチャーなどを、顧客が自力で運用できる状態まで伴走します。

この段階でつまずくと、顧客は製品にログインすらしなくなります。最初の成果に到達する前に離脱させないよう、主要機能の初回利用まで確実に到達させることが目標です。設定の複雑さや現場の抵抗といった障害を早めに検知し、優先順位をつけて片付けていきます。

次のフェーズへ進める判断基準

オンボーディングをどこで「完了」とするかは、担当者の感覚ではなく判定基準で決めます。時間で区切るのではなく、次のような状態に到達したかを確認します。

• キックオフを実施し、成功定義を数値で合意できている
• 初期設定・データ移行が完了し、実運用が始まっている
• 顧客が主要機能を自力で初回利用できている
• キックオフで合意した初期ゴールに到達している

これらを満たして初めて、アダプション（活用定着）のフェーズへ進みます。逆に、いずれかが欠けたままアダプションに移すと、定着施策を打っても土台がないため空回りします。完了判定を1枚のチェックリストにしておくと、担当者が違っても立ち上げの質が安定します。

アダプション｜活用定着を支援する業務

アダプション（活用定着）は、導入した機能が日常業務に根づき、顧客が継続的に成果を出し続ける状態を維持する業務です。中心作業は「ヘルススコアによる状態監視と、予兆に応じた先回りの働きかけ」です。オンボーディングで走り出した顧客も、放っておけば利用が細り、やがて解約に向かいます。悪化のサインを検知して、顧客が困る前に動くことが求められます。

たとえば主要機能の利用率が下がってきたら、その原因（担当者の異動・使い方の壁・成果が実感できていない等）を突き止めてフォローします。次の更新・拡大の会話につなげられるかどうかも、このフェーズで顧客を健全に保てるかにかかっています。

ヘルススコアの設計と運用

アダプションの起点は、ヘルススコアの設計と運用です。利用状況（ログイン頻度・主要機能の利用率）、NPS（顧客が製品を他者に薦めたいと思う度合いを測る指標）、サポートへの問い合わせ内容や頻度などを指標化し、顧客の健全度を数値で可視化します。スコアが下がった顧客を、解約の予兆として早期に拾えるようにします。

どの指標をどう重み付けするかは一例であり、自社の製品特性と成功定義に合わせて設計します。使う頻度が成果に直結する製品なら利用率を重く、成果が出るまで時間がかかる製品なら初期のマイルストーン到達を重く見る、といった調整が要ります。指標を作らずに感覚で運用すると、解約の予兆を見逃します。

タッチモデルによる支援の使い分け

顧客が増えると、全員に同じ手厚さで対応するのは不可能になります。そこでタッチモデルを使い、支援の手厚さを顧客ごとに割り当てます。担当者が一社ずつ密に伴走するハイタッチ、複数社をまとめてまとめて支援するロータッチ、メールやコンテンツで人手をかけずに支援するテックタッチの3つが基本です。

割り当ての軸は、顧客の規模やLTV（顧客生涯価値：一顧客が契約期間全体でもたらす利益）です。売上比率が高くリスクも大きい顧客にはハイタッチを、契約単価の小さい顧客層にはテックタッチを、というように配分します。全顧客を均等に見ようとすると、重要顧客への手厚い支援が薄まり、かえって取りこぼしが増えます。

定着を促す施策

ヘルススコアとタッチモデルで支援の優先度を決めたら、実際に定着を促す施策を打ちます。使い方の勉強会、同業種の活用事例の共有、利用状況をまとめたレポートの提示などです。顧客が「この製品で成果が出ている」と自ら実感できる材料を届けることが狙いです。

施策は打ちっぱなしにせず、施策後にヘルススコアや利用率が改善したかを確認します。効果が薄ければ、届け方やタイミングを変えます。定着施策は、顧客が成果を実感し、更新・拡大の会話に自然につながる土台を作る作業です。

次のフェーズへ進める／リスクを検知する判断基準

アダプションでは、更新・拡大へ進める判断と、リスクを検知して介入する判断の両方をヘルススコアで下します。スコアが健全で成果が出ている顧客には、リニューアルやエクスパンションの会話を始めます。逆に、スコア低下や利用停滞が一定の閾値を超えた顧客には、即座にフォローを入れます。

判断を担当者の主観に委ねず、「利用率が2か月連続で下がったら介入」「主要機能の利用が止まったらアラート」といった閾値をルール化しておくと、対応の抜け漏れが減ります。健全な顧客を更新・拡大へ、危険な顧客を早期フォローへと振り分けるこの仕分けが、アダプションの成果を決めます。

リニューアル｜契約更新に向けた業務

リニューアル（契約更新）は、更新月に慌てて動くのではなく、更新の数か月前から「顧客が得た成果を可視化し、継続の意思決定を後押しする」準備業務です。更新は当日に判断が下るのではなく、それまでの成果の積み上げで決まります。更新間際になって初めて顧客と向き合うようでは、すでに手遅れになっているケースが少なくありません。

一般的には更新の60〜90日前からレビューを始める組織が多いものの、この期間は製品や契約規模によって異なります。成果が出るまで時間がかかる製品なら、さらに前倒しで動く必要があります。以下で、更新に向けた具体的な業務を掘り下げます。

成果レビュー

リニューアルの中心は成果レビューです。オンボーディングで合意した成功定義に対して、顧客が実際にどれだけの成果を達成したかを数値で示します。「月10時間の削減目標に対して、実績8時間を達成」といった形で、継続の根拠を顧客と共有します。

この成果が可視化されていないと、更新の判断は「なんとなく使っているから」という曖昧な理由に委ねられ、コスト見直しの対象になりやすくなります。オンボーディング時に成功定義を数値で合意しておくことが、ここで効いてきます。成果レビューは、更新をCS側から能動的に後押しする材料です。

更新前のリスク検知と対処

更新前には、ヘルススコアが低下している顧客を洗い出し、早期にフォローします。スコアの悪い顧客をそのまま更新月に迎えると、解約や減額のリスクが高まります。更新の数か月前に危険顧客を特定し、原因に応じた対処（再オンボーディング・活用支援の強化・キーパーソンとの再合意など）を打ちます。

このリスク検知は、アダプションで運用してきたヘルススコアがそのまま使えます。日頃からスコアで状態を監視していれば、更新前に慌てて全顧客を点検する必要はなく、危険な顧客に絞って手を打てます。ヘルススコアの運用が、更新業務の効率と精度を支えます。

解約意向への対応

フォローの甲斐なく解約意向が出た場合は、その理由を丁寧に分析します。価格・機能不足・社内の体制変更・成果を実感できなかった、など理由はさまざまです。解約を止められるものであれば代替案を提示し、止められないものであれば理由を記録します。

解約理由は、プロダクトへのフィードバックとして製品開発に反映します。同じ理由での解約が続くなら、それはオンボーディングの設計や製品そのものの課題を示すシグナルです。個別の解約対応で終わらせず、CS全体・製品全体の改善につなげるところまでがこの業務です。

エクスパンション｜アップセル・クロスセルの提案

エクスパンション（契約拡大）は、単なる営業行為ではなく、「顧客の次の課題を起点に、成果を伸ばす選択肢としてアップセル・クロスセルを提案する」定着の延長線上の業務です。まだ成果が出ていない顧客に上位プランを売り込んでも、信頼を損ねるだけです。利用が定着し、成果を実感している顧客だからこそ、次の一手として拡大提案が響きます。

順序が重要で、アダプションでヘルススコアが健全になった顧客が対象です。以下で、提案するタイミング、アップセルとクロスセルの使い分け、営業との分担を掘り下げます。

拡大提案のタイミング

拡大提案は、成果が出てヘルススコアが健全な顧客に絞ります。オンボーディングで合意したゴールを達成し、製品が日常業務に根づいている顧客であれば、「次はこういう課題も解決できる」という会話が自然に成立します。

逆に、まだ立ち上げに苦労している顧客への拡大提案は逆効果です。既存の契約すら使いこなせていない相手に追加を勧めれば、信頼を失います。タイミングの見極めにも、アダプションで運用してきたヘルススコアが判断材料になります。

アップセル（上位プラン）とクロスセル（別製品）の使い分け

拡大には、上位プランへの引き上げ（アップセル）と、別製品の追加提案（クロスセル）があります。使い分けの軸は、顧客が次に解決したい課題です。既存製品をさらに深く活用したいならアップセル、既存製品では届かない別領域の課題があるならクロスセルが向きます。

いずれも起点は顧客の課題であり、CS側の売上目標ではありません。顧客が達成した成果と、まだ残っている課題を整理したうえで、その延長線上に無理のない提案を置きます。課題を起点にすることで、拡大提案が「押し売り」ではなく「次の成果への支援」として受け止められます。

営業への引き渡し／CS単独での対応

拡大提案を誰が担うかは、組織体制によって分かれます。CSが提案からクロージングまで単独で担う場合もあれば、CSが機会を見つけて営業に引き渡す場合もあります。どちらが適しているかは、契約規模や社内の役割分担によります。

この分担は、CS・営業・インサイドセールスの役割設計の問題でもあります。役割分担や連携の詳細は、カスタマーサクセスの役割で整理しています。自社の体制に合わせて、機会を取りこぼさない分担を決めておくことが重要です。

業務を回すための情報の一元化とツール活用

一連のフローを回すには、営業・CS・サポートに散在する顧客情報を一元化し、フェーズと状態をチーム全員が同じ画面で把握できる状態が前提になります。情報が部門ごとに分断されていると、CSは受注時の背景を知らないまま立ち上げに入り、サポートは顧客の活用状況を知らずに対応することになります。結果として先回りができず、支援は担当者の記憶と勘に依存します。

顧客情報を一元化すると、営業が把握した期待値・成功定義、CSが積み上げた活用状況やヘルススコア、サポートに寄せられた問い合わせが、一つの顧客像として全員に見えるようになります。以下で、特にフローの起点で効く「引き継ぎ」と、フェーズ運用の土台になる「共有」を掘り下げます。

受注時の商談情報をCSに引き継ぐ

営業⇔CSのデータ連携は、フローの起点である引き継ぎの質を決めます。受注時の商談情報が個人のメモやメールに埋もれていると、CSはそれを掘り起こすところから始めなければならず、立ち上げの初動が遅れます。商談情報が構造化されて残っていれば、CSは背景を把握した状態でキックオフに臨めます。

よく使われる仕組みとして、SFA/CRM（営業支援・顧客関係管理のシステム）があります。たとえばMazrica SalesのようなSFA/CRMでは、取引先・案件・コンタクト・アクションといった単位で商談情報が蓄積されるため、受注時の期待値や顧客の担当者情報をそのままCSに引き継げます。こうした仕組みがあると、営業とCSが同じ顧客データを見ながら連携でき、立ち上げの初動が速くなります。他のツールでも同種の連携はできるため、自社の営業プロセスに合うものを選ぶ観点で検討します。

ヘルススコア・活用状況をチームで共有する

引き継ぎだけでなく、フェーズの状態そのものもチームで共有します。各顧客が今どのフェーズにいて、ヘルススコアはどうか、直近でどんな支援をしたのかを、担当者以外も見られる状態にします。共有されていれば、担当者が不在でも別のメンバーがフォローでき、支援が属人化しません。

顧客情報とフェーズの状態が一元化されていることは、次章で述べる「つまずきやすいポイント」の多くを未然に防ぐ土台にもなります。情報が見える状態を作ってから、フローの運用ルールを整えていくのが現実的な順序です。

業務フローでつまずきやすいポイントと回避策

CS業務が回らなくなる典型は、「オンボーディングの型がなく担当者依存」「全顧客を均等対応してハイタッチが破綻」「ヘルススコアを設計せず解約の予兆を見逃す」の3つです。いずれも、フェーズ設計と優先度づけで回避できます。逆に言えば、この3つを放置したまま人を増やしても、支援の質はばらつき、手は回らず、解約は減りません。以下で、各つまずきと回避策をセットで掘り下げます。

オンボーディングが属人化する

最も起きやすいのが、オンボーディングの進め方が担当者ごとに異なり、立ち上げの質にばらつきが出るケースです。ベテランが担当した顧客は順調に定着し、経験の浅い担当者の顧客は初期でつまずく、という状態になります。担当者が退職すると、その人のやり方ごとノウハウが失われます。

回避策は、オンボーディングを標準プロセスとチェックリストで型化することです。キックオフでの成功定義の合意、初期設定の完了、主要機能の初回利用、初期ゴール到達といった完了判定を1枚のリストにまとめ、誰が担当しても同じステップを踏むようにします。型があれば、支援の質を担当者に依存させずに済みます。

全顧客に均等対応して手が回らない

顧客が増えたときに起きるのが、全顧客を同じ手厚さで見ようとして手が回らなくなるケースです。全員にハイタッチで対応しようとすれば、CSの工数は顧客数に比例して膨らみ、やがて破綻します。結果として、本来手厚く支援すべき重要顧客への対応まで薄まります。

回避策は、タッチモデルで支援を配分することです。顧客の規模やLTVに応じてハイタッチ・ロータッチ・テックタッチを割り当て、限られた工数を成果の大きい顧客に集中させます。テックタッチで支援できる層はコンテンツや自動化に任せ、人手は本当に必要な顧客に向けます。均等ではなく、めりはりのある配分が回すコツです。

解約の予兆を見逃す

3つ目は、解約の予兆を捉える仕組みがなく、顧客が離れる直前まで気づけないケースです。ヘルススコアを設計していないと、利用が細っている顧客も、満足している顧客も、CSからは同じように見えてしまいます。気づいたときには更新見送りの連絡が来ている、という後手に回ります。

回避策は、ヘルススコアと閾値での介入ルールを整えることです。利用状況・NPS・サポート状況などを指標化し、「利用率が一定以上下がったら介入」といった閾値をあらかじめ決めておきます。予兆をスコアで拾えれば、顧客が困る前に先回りでき、解約の芽を早い段階で摘めます。

まとめ

CS業務は、営業からの引き継ぎを起点に、オンボーディング→アダプション→リニューアル→エクスパンションへと、顧客の状態に応じてつながっていく一連のプロセスです。各フェーズに完了判定を設け、ヘルススコアで状態を監視しながら次へ進める設計が、支援の再現性と解約の抑制を支えます。

すべてを一度に整えようとする必要はありません。解約が続いているなら、まずオンボーディングの完了判定（成功定義の合意・主要機能の初回利用）を1枚のチェックリストにするところから始めるのが、負荷が低く効果の出やすい第一歩です。顧客数が増えて手が回らなくなっている組織なら、タッチモデルの割り当てから着手します。どちらも、フェーズ設計と優先度づけという同じ考え方の延長にあります。

CSの体系的な全体像はカスタマーサクセスとはで、組織の立ち上げやスモールスタートの考え方はカスタマーサクセスの組織体制・必要スキルで整理しています。自社のフェーズに合わせて、必要な部分から手をつけてみてください。

よくある質問

Q カスタマーサクセスの業務は1日どのように進みますか？

A

日次の動きは、担当している顧客のフェーズ構成によって変わります。多くの場合、朝にヘルススコアや通知を確認して優先度の高い顧客を洗い出し、日中はオンボーディング中の顧客のキックオフや定例、アダプション顧客の活用支援、更新が近い顧客のレビュー準備などに時間を配分します。本記事のフェーズ軸に対して、1日は「複数フェーズの顧客を並行して見る」時間軸になる点が特徴です。

Q オンボーディング期間はどのくらいが目安ですか？

A

製品の複雑さや契約規模によって異なり、一律の目安はありません。シンプルな製品なら数週間で自走に至る一方、業務への組み込みが必要な製品では数か月かかることもあります。重要なのは期間の長さではなく、成功定義への到達や主要機能の利用開始といった完了判定を満たしたかどうかです。時間で区切らず、状態で判断します。

Q カスタマーサクセスとカスタマーサポートで業務フローはどう違いますか？

A

サポートは顧客からの問い合わせを起点に、発生した問題を解決する受け身のフローが中心です。対してCSは、オンボーディングから拡大まで、顧客の状態を先回りで見ながら能動的に働きかけるフローで動きます。起点が「顧客からの連絡」か「CS側の状態監視」かが大きな違いです。詳細はカスタマーサクセスとカスタマーサポートの違いで整理しています。

Q カスタマーサクセスの業務は何人から始めればよいですか？

A

一人からでも始められます。立ち上げ初期は、まず解約に直結しやすいオンボーディングを型化し、重要顧客に絞ってハイタッチで支援するところから始める組織が多く見られます。顧客数の増加に合わせてタッチモデルで支援を配分し、体制を広げていきます。スモールスタートの考え方や必要スキルはカスタマーサクセスの組織体制・必要スキルで扱っています。

Q ヘルススコアはどの指標で作ればよいですか？

A

一般的には、利用状況（ログイン頻度・主要機能の利用率）、NPS、サポートへの問い合わせ状況などを組み合わせて構成します。ただし、どの指標を重く見るかは自社の製品特性と成功定義によって変わります。使う頻度が成果に直結する製品なら利用率を、成果が出るまで時間がかかる製品なら初期マイルストーンの到達を重く見る、といった調整が必要です。まず数個の指標から始め、運用しながら精度を上げていきます。

Q カスタマーサクセスの業務にツールは必須ですか？

A

顧客数が少ないうちは表計算ソフトでも回せますが、顧客が増えるほど情報の一元化と状態監視の自動化が必要になります。営業・CS・サポートに情報が分断されていると先回りができず、担当者依存に陥るためです。SFA/CRMなどで顧客情報を一元化し、ヘルススコアをチームで共有できる状態を作ると、フローが回りやすくなります。まずは既存ツールで運用し、手作業の限界が見えた段階で導入を検討するのが現実的です。