カスタマーサクセスの現場が疲弊する原因は、人員の不足ではありません。顧客を分ける軸が決まっていないため、契約金額に関係なく同じ工数が配られていることが原因です。

支援の量は顧客ごとに違って構いません。問題は、その違いが担当者の判断や顧客の要求の強さで決まっていることです。誰にどれだけの時間を使うかを組織として先に決めていれば、現場は断る理由を持てます。本記事では、分類の軸の決め方、担当社数の逆算、そして最も抜けやすいティアの移行基準までを整理します。

疲弊の原因は人員不足ではなく、分類軸が無いこと

継続課金型のサービスでは、顧客数は積み上がっていきます。総務省「令和7年通信利用動向調査報告書（企業編）」（2026年5月公表）によれば、2025年時点でクラウドサービスを「全社的に利用している」企業は59.9%、「一部の事業所または部門で利用している」を合わせた利用企業の割合は83.4%にのぼります。サービスの提供側から見れば、解約されない限り顧客は減らず、支援対象だけが増え続ける構造です。

この構造の中で全顧客に同じ対応を続けると、次のようになります。

項目一律対応階層別対応
支援量の決め方顧客の要求の強さと担当者の裁量契約時に決めた層ごとの規定
顧客が増えたとき1社あたりの時間が薄まる層ごとの上限に達した時点で増員を判断できる
断る根拠担当者の個人的な事情提供条件に書かれた支援範囲
現場の負荷声の大きい顧客に偏る事前に配分され、偏りが可視化される

一律対応が破綻するのは、顧客数が増えたときではなく、顧客ごとの収益とコストを並べて見られなくなったときです。低単価の顧客に人的対応を割り当てていても、それが何社あり、合計で何時間使っているかを数えていなければ、問題は「現場が忙しい」という形でしか現れません。

分類はコスト削減のために行うのではなく、支援の量を組織の決定事項にするために行います。カスタマーサクセスの役割そのものの整理はカスタマーサクセスとは何かを扱った記事にまとめています。

分類軸は「現在の契約額」だけで決めない

セグメンテーションを現在の契約額だけで行うと、伸びる前の顧客が最低層に落ちます。導入部門が1つしかない大企業は、契約額だけを見れば小口ですが、全社展開すれば最大の顧客になり得ます。

実務では、次の3つの軸を組み合わせます。

軸何を見るか数字での定義の例注意点
現在の契約額直近12か月の取引額年間契約額過去の実績なので判断がぶれない
伸びしろ追加で導入され得る範囲未導入の部門数、対象になり得る従業員数数えられる形にしないと願望になる
戦略的価値参照先としての価値、業界での位置づけ事例公開の可否、同業への影響該当する顧客を少数に限定する

3つ目の軸は便利な一方、根拠を書かずに使うと「担当役員が気にしている顧客」を上位に入れるための口実になります。戦略的価値でティアを上げる場合は、理由と有効期限を残してください。期限を切らないと、上位層は増える一方になります。

伸びしろの軸は、必ず数えられる項目に置き換えます。「成長性が高い」という形容ではなく、「未導入の部門が3つ以上ある」「利用者数の上限に対して現在の利用が半分以下である」といった判定可能な条件にします。

タッチモデルの3層と、担当社数の逆算

顧客を分けたあとは、層ごとに支援の手段を割り当てます。一般にハイタッチ・ロータッチ・テックタッチと呼ばれる区分です。

層対象主な手段接触の起点
ハイタッチ契約額が大きい、または伸びしろが明確な顧客専任担当による個別面談、導入計画の共同作成自社が決めた議題での定期面談
ロータッチ標準的な規模の顧客複数社向けの活用セミナー、定型の節目連絡利用状況が基準を下回ったときの個別連絡
テックタッチ小口・セルフサービス前提の顧客製品内の案内、ヘルプ、自動配信利用状況に応じた自動通知

ここで多くの組織が飛ばす工程が、担当社数の上限を逆算することです。層を定義しても、1人が何社まで持てるのかを決めていなければ、上位層は際限なく増えます。

逆算は次の順で行います。

  1. 担当者1人が顧客対応に使える月間の時間を出す（会議や社内業務を差し引いた実働）
  2. ハイタッチ1社あたりに必要な月間時間を出す（面談の準備、面談、記録、社内連携）
  3. 1を2で割り、1人あたりの上限社数を出す
  4. 上限を超える分は、ロータッチの手段で代替できるかを検討する

この計算をすると、ハイタッチの定義が厳しくなります。厳しくなること自体が目的です。上限を決めずに「重要な顧客は手厚く」と運用すると、重要でない顧客がいなくなり、全社がハイタッチになります。

ティアの移行基準を先に決める

セグメンテーションで最も抜けやすいのが、層を移すときの基準です。分類の初期設計だけを行い、その後の移動を決めていない組織では、一度ハイタッチに入った顧客が下がりません。結果として上位層が増え続け、分類が無かった状態に戻ります。

昇格と降格の両方を、判定のタイミングごとに決めておきます。

項目昇格降格
判定のタイミング契約更新時、および四半期ごとの定期判定四半期ごとの定期判定のみ
主な基準契約額が上位層の下限を超えた、伸びしろの条件を満たした契約額が下限を下回った、伸びしろの条件が2期連続で満たされない
移行時にやること担当の割り当て、支援計画の作り直し支援手段の切り替えと、顧客への事前連絡
記録すること判定日と根拠判定日、根拠、代替手段

降格を四半期ごとの定期判定に限っているのは、都度の判断にすると実行されないからです。降格は誰にとっても気が進まない作業なので、実行日を先に決めておかないと先送りされます。

実行時の落とし穴

分類の設計よりも、運用に入ってからの扱いのほうが失敗しやすい領域です。

落とし穴1：降格が「顧客への裏切り」と受け取られる。 これは契約時の説明不足から起きます。提供している支援が契約プランに紐づくものだと最初に伝えていなければ、支援の縮小は一方的な条件変更に見えます。プランごとの支援内容を提供条件に書き、変更の可能性も併記してください。

落とし穴2：テックタッチ層が放置される。 テックタッチは「何もしない」ことではなく、人を介さずに自動で接触する設計です。自動配信も製品内の案内も無い状態は、単なる放置です。放置された層は解約率で跳ね返り、その原因が分類の設計にあると気づくまでに時間がかかります。

落とし穴3：分類の根拠が記録されていない。 誰がいつ、どの基準でその顧客を上位層に入れたのかが残っていないと、次の見直しで判断のしようがありません。判定日と根拠を顧客管理の項目として持ってください。

落とし穴4：層ごとの成果を分けて見ていない。 解約率も継続率も、全社平均で見ている限り分類の妥当性は評価できません。層ごとに分けて初めて、ハイタッチに投じた工数が回収できているかが分かります。指標の置き方は顧客満足度と売上のKPIを扱った記事、コストと収益の両立はカスタマーサクセスの目標設計の記事で扱っています。

まとめ

  • 疲弊の原因は人員不足ではなく、支援の量が組織の決定事項になっていないことです
  • 分類軸は現在の契約額だけに寄せず、伸びしろと戦略的価値を数えられる形で加えます
  • 層を定義したら、1人あたりの担当社数を逆算し、上位層の上限を決めます
  • 昇格と降格の基準、判定のタイミング、記録する項目を先に決めます。降格の設計が無い分類は必ず崩れます
  • テックタッチは無対応ではありません。人を介さない接触を設計しない限り、その層は放置されます