Design Your CS Team Structure and Capacity Model

Why This Matters

By the walk stage, the team has usually grown by adding CSMs reactively, so books of business are uneven and the coverage an account gets depends more on who was hired when than on what the account is worth. A capacity model ties headcount and coverage to segments and real workload, so high-value accounts are not under-served and CSMs are not quietly underwater. It also turns hiring from a panic into a planned decision.

Action Plan

1. 01 Define the coverage model per segment: high-touch, mid-touch, and tech-touch, and what each segment actually gets
2. 02 Estimate the workload of an account by segment (onboarding load, touch cadence, complexity), not just its ARR
3. 03 Set a target capacity per CSM by segment (accounts or ARR per CSM) based on that workload, and write down the assumptions
4. 04 Compare current books of business against the target and find the over-loaded and under-loaded CSMs
5. 05 Rebalance assignments so coverage matches account value, and define how new accounts get routed
6. 06 Define the roles you need beyond the CSM: onboarding specialists, CS Ops, renewals, and scaled or digital coverage, and when each is justified
7. 07 Build a hiring trigger: the leading signals (segment growth, capacity utilization, pipeline) that say it is time to add a CSM
8. 08 Review capacity each quarter as the book grows, and adjust the ratios with evidence rather than gut feel

Metrics to Watch

Related Principles

Common Pitfalls

• Sizing books by account count alone. A CSM with 30 complex accounts can be busier than one with 80 simple ones
• Setting one CSM ratio for the whole base. Enterprise and tech-touch coverage need very different ratios
• Hiring only once CSMs are already underwater. By then retention has usually slipped, which is the expensive way to learn you were short-staffed
• Treating the model as fixed. As segments and product complexity change, the ratios that worked last year quietly stop working