book of business とは、1人の CSM が所有し責任を負う顧客アカウントのポートフォリオであり、総 ARR のうちその CSM の取り分を、アカウント数、ドル、またはその両方で測ったものです。この用語は営業から借りたもので、営業では rep の「book」とはquota を持つアカウントの集合を指します。Customer Success では、リテンション、アダプション、エクスパンションが1人の CSM の机の上に乗っているアカウントの集合を指します。
これはテリトリーやセグメントとは異なります。セグメント（「Enterprise」「SMB」）はアカウントを分類する方法であり、book of business はそれを人に割り当てる方法です。2人の CSM が同じセグメントを、まったく異なる book で担当することもあります。quota や target とも異なります。book は資産であり、NRR、GRR、gross リテンションはそれに対して測る結果です。
book のサイズ設定
普遍的な数字はありません。なぜなら適切なサイズはアカウントあたりのドル、タッチモデル、motion の複雑さの関数であり、アカウント数だけの関数ではないからです。まず CSM あたりの ARR でサイズを設定し、その後アカウント数で妥当性を確認します。
| Motion | CSM あたりの典型的な ARR | 典型的なアカウント数 |
|---|---|---|
| Enterprise high-touch | $2-5M | 8-20 |
| Mid-market / ハイブリッド | $2-4M | 30-80 |
| Tech-touch / SMB pooled | $3-6M+ | 150-500+（多くの場合 pooled で 1:1 ではない） |
CSM あたりの ARR のバンドはアカウント数よりも安定して維持されるため、まずドルでサイズを設定します。QBR、エグゼクティブとの連携、カスタム success plan を回す Enterprise high-touch の CSM は、カバレッジが劣化する前におそらく 10-15 ロゴを担えます。pooled book に対してデジタル playbook を回す tech-touch の CSM は、作業が自動化されトリガーで起動しカレンダー管理ではないため、名目上 400 を「所有」できます。
実際に制約となるのはアカウントあたり四半期あたりのタッチ数です。セグメントが要求するケイデンスを決め（Enterprise：月次チェックイン + 四半期 QBR + ad-hoc、SMB：トリガー起動のデジタル + 更新サイクルごとに1回の人的タッチ）、アカウント数で掛け、現実的な週 20-25 時間の生産的時間と比較します。アカウント数が時間を超えるなら、ARR の表が何と言おうと book は大きすぎます。
book のバランス調整
バランスは難しい部分であり、ほとんどの割り当てモデルが静かに失敗するところです。ARR でバランスが取れた book でも、ワークロードでは大きく不均衡なことがあります。少なくとも4つの軸でバランスを取ります。
- ARR — 見出しの数字ですが、決して唯一の数字ではありません。
- アカウント数 — 同じ ARR でも 12 件と 60 件の2つの book は同じ仕事ではありません。
- 更新日の分布 — 更新の 70% が Q4 に落ちる book は、CSM がどれだけ優秀でも Q4 に破綻します。更新の集中を分散させます。
- リスク / health のミックス — red-health で at-risk なアカウントをすべて1人に積み上げないでください。既知のリスクを分散させ、どの book も churn が確定したイベントにならないようにします。
新規で onboarding 未完了のアカウントに完全に偏った book は、成熟しアダプション済みのアカウントの book とは異なる（そしてより重い）仕事です。onboarding の負荷が大きいなら、ライフサイクルステージでも重み付けします。
割り当ての方法
一般的な3つのモデルを、overhead の小さい順に挙げます。
- セグメント別 round-robin — 最もシンプルで、数では最も公平、関係の継続性では最悪です。SMB pooled book には十分です。
- Named-account / pod — CSM が特定のロゴを所有し、しばしば pod 内で AE とペアになります。Enterprise に最適で、更新サイクルを通じて関係の深さを保ちます。
- vertical / ユースケース特化 — CSM が業界または製品ラインでアカウントを所有します。製品がドメイン知識の蓄積が効くほど複雑な場合に報われます。overhead は ~$30M ARR 未満では正当化しにくいです。
どのモデルであれ、割り当てのルールを書き出し、固定のケイデンス（四半期が典型的）で再計算します。誰かが不満を言うたびの ad-hoc な reshuffle ではいけません。
よくある落とし穴
- アカウント数だけでサイズ設定する。 $20K ロゴ 50 件の book と $400K ロゴ 50 件の book は別の惑星です。ARR とタッチ負荷でサイズを設定し、その後で数を確認します。guard：book ごとに両方の数字を必ず公開します。
- 更新の崖。 更新日の分布が不均衡だと、リスクが1つの四半期に集中します。guard：book ごとに更新の集中を報告し、再割り当てが許す範囲でどの四半期も book の ARR の ~35-40% に上限を設けます。
- 静かなオーバーロード。 book は rebalance の間にアカウントが追加されるにつれ上方にドリフトし、CSM は何かが churn するまでそれを吸収します。guard：ARR だけでなくタッチ数-四半期-あたりの厳格な上限を設け、book がそれを超えたら rebalance を起動します。
- 再割り当てによる churn。 CSM 間でアカウントを移すと関係がリセットされ、それ自体が churn のリスクです。guard：まず新規アカウントと at-risk だがまだエンゲージしていないアカウントを再割り当てして rebalance し、確立された関係は最後の手段としてのみ移します。
関連
- Customer segmentation — book が割り当てられる前にどう分類されるか
- Capacity planning — 総 ARR に対する CSM の headcount のサイズ設定
- Customer health score — book をバランスさせるリスク軸
- NRR vs GRR — book が測られる結果