Customer Success におけるアカウントのティア分けとは、顧客ベースをバンドに分割し、各バンドに意図的に異なる量の CSM の時間を割り当てる実践です。これは獲得側の ABM ティア分けとは異なります。あちらでは見込み客を購買 intent でティア分けしますが、こちらでは既存顧客を維持する価値と、それにかかる工数でティア分けします。このフレームワークの出力はティアごとのタッチモデルと CSM 比率であり、すべてのアカウントに定義されたサービスレベルが、すべての CSM に定義された book が割り当てられます。
2つの軸でティア分けする：価値と工数
各アカウントを価値の軸と工数の軸でティア分けし、その組み合わせにタッチモデルを決めさせます。
- 価値 とは、アカウントが churn した場合に失うもの、expand した場合に得るものです。ARR をベースに使いますが、重み付けします。高い戦略的価値を持つロゴ（リファレンスアカウント、看板ブランド、親会社への expansion の可能性）は、その素の ARR を上回ります。NRR のポテンシャルもここに含まれます。年 40% 成長している $40K のアカウントは、横ばいの $80K のアカウントを上回ります。
- 工数 とは、アカウントが目標とする outcome に到達するために消費する CSM の時間です。技術的に複雑な deployment、成熟度の低い buyer、複数のステークホルダーを持つ組織、リスクの高い更新を控えた契約は、いずれも工数を高めます。高価値かつ高工数があなたの希少な注意を割く象限であり、高価値かつ低工数はマネージド自動化が最も効果を発揮する領域です。
2つの軸をプロットすればティアは自ずと決まります。ARR だけでティア分けしてはいけません。それは自立した $200K のアカウントを、churn の 3週間前にある $200K のアカウントと同じ bucket に入れることになり、両者は正反対のものを必要としています。
標準の3ティアと、較正された比率
| ティア | タッチモデル | CSM 比率（アカウント : CSM 1名） | Book of business |
|---|---|---|---|
| ティア1 — ハイタッチ | 指名 CSM、定例 QBR、カスタム success plan、エグゼクティブスポンサー | 8〜20 | $1.5M〜$4M ARR |
| ティア2 — ミッド / ロータッチ | 指名 CSM、一部タスクは pooled、四半期チェックイン、テンプレート化された plays | 40〜80 | $2M〜$5M ARR |
| ティア3 — テックタッチ | 指名 CSM なし、pooled キュー、自動ライフサイクル + アプリ内 | 200〜500+ | デジタル、headcount に縛られない |
これらの比率は平均 ACV が $20K 以上の B2B SaaS の標準です。複雑なエンタープライズ製品では圧縮され（ティア1 は CSM 1名あたり 5〜8 アカウントになり得ます）、セルフサーブ寄りの製品では拡大します。book of business の列は sanity check です。ティア1 の比率が CSM 1名あたり $9M の book を意味するなら、その比率は野心的なのではなく間違っています。
タッチモデルをティアにマッピングする
ティアは CSM が実際に行うことを変えるまで意味を持ちません。各ティアを、同じモーションを異なる頻度で行うのではなく、異なるモーションにします。
- ティア1（ハイタッチ）： 人間主導、アカウント固有。mutual success plan、定例 QBR、指名されたエグゼクティブスポンサー、能動的なリスクレビュー。CSM は組織図を把握しています。ここでは book-of-business の計画を手作業で行います。
- ティア2（ロータッチ）： 人間主導ですがテンプレート化され、部分的に pooled。ライフサイクル plays は health score の変化でトリガーされ、CSM はスケジュールではなく例外時に介入します。1対少数のウェビナーが 1対1 の QBR を置き換えます。
- ティア3（テックタッチ）： デジタル主導。自動化された onboarding、アプリ内ガイダンス、メールの nurture、customer health score がフラグを立てたアカウントだけを拾う pooled な CSM キュー。デフォルトではどのアカウントもカレンダー招待を受け取りません。
Gainsight、Vitally、Planhat、Totango のようなプラットフォームは、まさにこれを運用するために存在します。アカウント属性としてのティア、ティアごとの health score、そしてティア3 では自動的に発火しながらティア1 と 2 では優先順位付けされたキューを浮上させる playbooks です。ツールはティアを決めません。それはあなたが決めます。しかしツールはティアを徹底させます。
具体例
600 顧客のベース、$24M ARR、CSM 6名。ティア1 = 価値と工数で上位 60 アカウント（$12M ARR、CSM 1名あたり 10、ハイタッチで CSM 6名分）。これだけでチーム全体を消費するため、ティア2 と 3 はデジタル主導でなければならず、さもなければより多くの headcount が必要です。フレームワークは採用の意思決定をあなたに告げました。ティア2 に指名 CSM を付けるには、およそ 3名の増員が必要です。あるいはティア2 をテックタッチに移し、それが意味するより低い retention を受け入れます。そのトレードオフこそがティア分けの目的そのものです。
よくある落とし穴
- ARR だけでティア分けする。 間違ったサービスレベルを間違ったアカウントに組み合わせます。ガード：常に工数の軸と戦略的価値の重みを含め、ARR ランクとティアが 1バンドを超えて食い違うアカウントはすべてレビューします。
- 静的なティア。 年に 1回のティア分けは、安定したアカウントにハイタッチを浪費し、新たにリスクを抱えたアカウントを飢えさせます。ガード：ティアの適格性を、health score に駆動されたスケジュール（月次）で、明示的な昇格 / 降格ルールとともに再計算します。計画オフサイトではありません。
- ティア1 の膨張。 どの AE も自分のロゴをティア1 に入れたがり、比率は静かに 30:1 まで滑り、ハイタッチは全員にとってミディアムタッチになります。ガード：ティア1 の headcount をベースに対する厳格な割合（一般的に 10〜15%）として上限を設け、昇格 1件ごとに降格を強制します。
- 同じ playbook、異なる頻度。 ティア3 がミーティングを減らしただけのティア1 なら、テックタッチのモーションを構築したのではなく、ティア1 の playbook を提供不足にしただけです。ガード：各ティアは、他のティアが実行しない play を少なくとも 1つ挙げなければなりません。
関連
- Tech touch vs high touch — 各ティアがマッピングされるタッチモデル
- Customer health score — 昇格と降格を駆動するシグナル
- Customer segmentation — ティアが内包される、より広いセグメンテーション
- Book of business — ティアの比率がどのように CSM のポートフォリオになるか
- NRR vs GRR — 各ティアが最適化される retention 指標