ARR tells you the value of the customers. It doesn't tell you the work required to move them forward. Capacity starts with the work.
There is no universal number of customers a CSM should manage. The right number depends on how much work your customers need to progress and how much time your team realistically has to do it.
Industry data shows CSMs averaging about 22 accounts in high-touch models and about 144 in low-touch ones, a sixfold difference that illustrates why a single CSM ratio can't describe every service model. To find your number, start with the work: the plays and service moments your customers need, the full effort each one takes, and when that work happens across the year. Then compare that demand with the capacity your team actually has.
Customer Success capacity is the amount of customer work a team can realistically perform in a given period. It should be planned from the work an organization has intentionally designed to help customers progress, not from a fixed ratio of accounts or ARR per CSM.
If you're looking for a CSM ratio, there's usually a reason. You're building a budget, defending a headcount request, or answering a CFO who wants to know why your team needs another person when a peer company seems to do fine with fewer.
That is a fair question, and benchmarks exist for it. The most widely cited come from Gainsight's analysis of platform data across 17,034 CSMs at US-based customers. It found a median of $1.4 million in ARR per CSM, with the top quartile at $4.2 million. By touch model, CSMs averaged about 22 accounts in high-touch segments (ACV above $100K), 49 in mid-touch ($10K to $100K), and 144 in low-touch (below $10K).1
Those numbers are useful context. They can tell you whether you're far outside the norm and prompt good questions about why. But look at what they show. The top quartile manages three times the ARR of the median. Accounts per CSM changes by a factor of six or more depending on the touch model. The benchmarks themselves are telling you that the number depends on the work. What they can't do is tell you how many people your customers require.
Customer count and ARR describe the customers or revenue being managed. They do not describe the work required to help those customers progress.
ARR tells you the value of the customers. It doesn't tell you the work required to move them forward.
Picture two companies, each running at $2 million in ARR per CSM. At the first, customers buy a simple product, implement it in a few weeks, and involve two or three stakeholders. At the second, customers go through a complex implementation, multiple user groups, integrations, and real organizational change before they reach the outcome they bought. The ratio is identical. The work is not remotely the same.
Accounts per CSM has the same problem. Fifty customers that each need 5 hours of work a year and fifty customers that each need 30 are not the same job, even though the ratio says they are.
A ratio describes how work has been distributed. It doesn't tell you how much work exists. That's why two teams with identical ratios can be comfortably staffed and badly overloaded at the same time.
A better question than "how many customers can a CSM manage?" is this:
How many customers can a CSM move forward?
That question points at the work. And the work starts with customer progression: the meaningful change a customer makes from the reason they purchased toward the outcomes they intended to achieve (see How Do You Know Whether a Customer Is Actually Progressing?).
If you know what progression needs to happen, you can design the plays and service moments intended to help create it: a kickoff that produces clarity on goals and responsibilities, an onboarding motion that gets the customer to first use, a push to First Value, recurring Alignment Meetings, insight sharing, renewal preparation. Those plays require work. That work creates demand for capacity.
The CXology capacity mechanism runs in five steps:
Progression defines what needs to happen for the customer. Capacity determines whether you've funded enough work to help make it happen.
A play is what your team does. Progression is what changes for the customer. Running a play doesn't guarantee progression, but you can't plan for progression without funding the work designed to create it.
Designed effort is the full effort required to deliver a play or service moment well: preparation, execution, and follow-through. The time on the calendar is only part of the workload.
Start with one meeting. A customer meeting is scheduled for 60 minutes. Delivering it well takes more than that:
| Part of the work | What it includes | Time |
|---|---|---|
| Preparation | Review goals and progress, pull usage and outcomes, shape the agenda | 30 min |
| Execution | The meeting itself | 60 min |
| Follow-through | Document decisions, send the recap, confirm owners and next steps, update the plan | 20 min |
| Designed effort | 110 min |
A 60-minute meeting requires 110 minutes of capacity. If your model counts only the 60, it underestimates the work by almost half before you've added a single customer.
Bigger plays carry even more hidden work. A full Alignment Meeting, with insight gathering, executive briefing, stakeholder preparation, the meeting itself, and follow-through, is modeled at 3.5 hours in the CXology Capacity Planner, even though the meeting on the calendar may last an hour.
This is the most common hidden error in CS capacity: counting meetings instead of work. Preparation and follow-through are not overhead. Customers feel the quality of all three. A poorly prepared meeting feels generic, and a meeting without follow-through erodes trust because nothing changes afterward.
Now repeat that thinking across the plays one customer needs in their first year. The figures below are the starting defaults in the CXology Capacity Planner for a high-touch customer, so you can reproduce them there. They are planning assumptions, not benchmarks. Your plays and estimates will differ.
| Play / service moment | When | Designed effort |
|---|---|---|
| Purchase & Welcome, Kickoff, and Onboarding start | Month 1 | 8.5 hrs |
| Onboarding continued | Months 2 and 3 | 2 hrs |
| Quarterly Alignment Meetings (4 at 3.5 hrs) | Months 3, 6, 9, 12 | 14 hrs |
| Value Blocks and insights (0.5 hr a month) | Months between alignments | 3 hrs |
| Designed effort, year one | 27.5 hrs |
Two things show up immediately.
First, the work is not spread evenly. About half of it, 14 of the 27.5 hours, lands in the first three months, when kickoff, onboarding, and the push to First Value require intensity.
Second, year two looks different. Without kickoff and onboarding, the same customer needs about 18 hours, weighted toward alignment, insights, and renewal readiness. The work doesn't disappear after onboarding. It changes form.
Touch model changes it again. The Planner's default low-touch customer needs about 8.5 hours in year one and 4 hours a year after that.
That's why a customer is not a unit of work. A new high-touch customer in month two and a mature low-touch customer in year three both count as "one account" on a ratio, yet one needs several times the capacity of the other.
Designed plays are not the only thing that consumes a CSM's week. Capacity planning separates three kinds of effort:
| Effort type | What it is | Examples |
|---|---|---|
| Direct effort | Work that directly contributes to customer success. Includes designed proactive work and reactive customer work. | Plays and service moments; answering customer questions; resolving issues |
| Indirect effort | Necessary internal work that consumes capacity but doesn't directly serve an individual customer. | Team meetings, enablement, planning, internal coordination, supporting Sales and Product |
| Unplanned effort | Unexpected or avoidable work that consumes productive capacity. | Escalations from broken handoffs, unclear ownership, system gaps, urgent internal asks |
Indirect effort is real work, not a sign of poor discipline. Unplanned effort deserves a harder look. When too much of the week disappears into it, hiring may not be the first answer. The operating model may need attention.
Availability is the percentage of a person's capacity realistically available for direct customer work after indirect and unplanned effort are accounted for.
CXology has historically used 65% availability, about 26 hours of direct customer time in a 40-hour week, as a planning starting point. It is not a universal benchmark or a best-practice requirement. It is an assumption to validate. A team carrying heavy internal responsibilities may run closer to 55%. A team with strong operations support and little cross-functional load may sustain more. What matters is that the number is explicit, tested against how your team actually spends its time, and refined as you learn.
A capacity model that assumes 100% availability is almost certainly overstating the team's usable capacity. A 40-hour workweek does not mean 40 hours are available for designed customer work.
Keep the two ideas separate: designed effort describes the demand (how much work the customers need), and availability describes the supply (how much of your team's time can go to it). Most staffing arguments go sideways because those two get blended into one ratio.
Customer Success capacity planning compares two numbers: the designed effort your customers require and the time your team has available to deliver it.
Required capacity = Σ (designed effort per play × customers needing that play in the period)
Available capacity = Σ (each person's workable hours × availability × share left for designed work)
A first pass with the Planner's default assumptions:
These are illustrations of how the math works, not recommended CSM ratios. Change the plays, effort estimates, reactive workload, availability, or customer lifecycle mix and the answer changes.
Notice the shape. A work-based model lands in the same broad territory as the benchmarks above, with a few dozen accounts in high-touch and hundreds in low-touch. The difference is that you can see why, and you can change the answer by changing the work.
That gives you a defensible answer to "how many customers should a CSM manage?" for your own design. But it's still a static answer. It assumes every customer is at the same point in the lifecycle, needs the same work every month, and that the team never changes. None of that is true, which is why the real model looks across time.
Customer work moves. New customers arrive in uneven waves. Each one brings a heavy first quarter, then settles into a steadier pattern. Existing customers cycle through quarterly alignment and renewal windows. High-touch and low-touch models carry different effort profiles. Year-one customers need more than year-two customers.
The team moves too. Some months have more workable hours than others. New hires don't arrive at full strength: recruiting takes time, and a new CSM may contribute a quarter of a full load in their first month, half in the second, and three-quarters in the third.
So the CXology model looks across 12 months and accounts for:
Here's what that looks like for a simple illustrative team: three CSMs, 100 existing high-touch customers in year two or later, and four new high-touch customers added every month, using the effort and availability assumptions above.
| Month | Designed effort required | Capacity for designed work | Position |
|---|---|---|---|
| 1 | ~185 hrs | ~230 hrs | Comfortable |
| 4 | ~210 hrs | ~240 hrs | Tightening |
| 6 | ~225 hrs | ~205 hrs | First pinch (a short month) |
| 9 | ~240 hrs | ~220 hrs | Over |
| 12 | ~260 hrs | ~230 hrs | Over, and still climbing |
Nothing dramatic happens in any single month. Demand climbs because every new customer adds a heavy first quarter and then stays in the base. A ratio taken in month one would say this team is fine. The forecast shows a first pinch in month six, when fewer workable hours meet growing demand, and a team that stays over capacity from month nine on.
And because a hire who starts in month six won't be fully productive until about month nine, the staffing decision for this team needed to happen around month two or three, when the team still felt comfortable.
That's the more useful operating question. Not "how many CSMs do I need?" but:
When will the customer work we have designed exceed the capacity of the team available to perform it?
The point is not to predict every hour. Estimates will be wrong in places, and that's fine. The value of the forecast is that it makes the work visible, exposes the assumptions so others can challenge them, and shows where demand and capacity diverge early enough to do something about it.
When required work exceeds available capacity, the answer is not automatically "hire." Leadership has real choices:
| Choice | What it means |
|---|---|
| Add capacity | Hire, and start early enough to cover ramp time. |
| Reduce or redesign service moments | Remove plays that don't help customers progress, or make them lighter. |
| Automate work | Move repeatable work, such as onboarding steps or routine insights, to programmatic delivery. |
| Move work to another role | Shift onboarding, renewals, or technical work to specialists or partners. |
| Change the touch model | Serve some segments with a lighter or one-to-many model. |
| Accept the tradeoff explicitly | Fund less than the designed experience, and name what customers will no longer receive. |
All of these are legitimate if they're made deliberately. The one option that isn't legitimate is the default most teams fall into: keep the design, skip the funding, and let the team quietly absorb the gap. That's when plays get skipped or degraded, progression stalls, and the organization depends on heroic effort from a few people.
Capacity planning doesn't just tell you how many people you need. It forces you to decide what customer work you're willing to fund.
That's also what changes the conversation with a CFO. Instead of "our ARR per CSM is too high," a CS leader can say: "This segment needs these plays to move customers forward. Those plays require this much effort. Based on the customers we already have and the ones we expect to add, we run out of capacity in month six. Here are the options, and here's what each one means for customers."
None of this makes ARR per CSM or accounts per CSM useless. They are good context:
The problem starts when the benchmark becomes the model. Use benchmarks to check your thinking. Build capacity from the work.
You don't need a perfect future-state design to begin.
The CXology Capacity Planner is built around this model. It takes planned growth by touch model, your current customers by contract start month, designed effort by lifecycle month for year one and later years, current and future team members with ramp, and target availability. It returns a 12-month view of demand against available capacity, the first month the team goes over, and when hiring needs to start. Use it to test the choices above: add a hire, remove a service moment, change the touch model, or reduce reactive work, and see how the forecast moves.
For the full argument on capacity as the investment decision behind the post-sale operating system, read Chapter 22: Proactive Capacity Planning.
There's no universal number. It depends on the work your customers need to progress and the time your team realistically has for it. Calculate it by estimating the designed effort (preparation, execution, and follow-through) for each play customers need, then comparing total demand with each CSM's available hours. Benchmarks can give context, but they can't account for your product, customers, or service design.
Define the progression customers need to make, list the plays and service moments designed to help create it, and estimate the designed effort for each. Multiply by the customers who need each play in each month, then compare the result with your team's available hours over 12 months, accounting for availability, reactive work, future hires, and new-hire ramp.
ARR describes the value of the customers being managed, not the work required to move them forward. Two companies with the same ARR per CSM can have completely different implementation complexity, stakeholders, and service designs, so the same ratio can mean a comfortable team at one and an overloaded team at the other.
Designed effort is the full effort required to deliver a play or service moment well: preparation, execution, and follow-through. A 60-minute meeting that needs 30 minutes of preparation and 20 minutes of follow-through has a designed effort of 110 minutes.
CXology uses 65% availability, about 26 direct customer hours in a 40-hour week, as a planning starting point. It's an assumption to validate against how your team actually spends its time, not a universal benchmark. The remaining time goes to indirect work, such as internal meetings and enablement, and to unplanned work.
No. Leadership can add capacity, redesign or remove service moments, automate work, move work to another role, change the touch model, or explicitly accept a lighter customer experience. Capacity planning makes the tradeoff visible so it's a decision rather than silent overload.
1. Nick Mehta and Shantan Reddy, "Gainsight Horizon AI Labs: What Is the Right CSM to Customer Ratio?," Gainsight, July 29, 2022. ARR figures cover 17,034 CSMs at US-based Gainsight customers; account figures are from US-based enterprise customers above $100M ARR.