How Many CSMs Do You Actually Need?

For years, Customer Success leaders have viewed capacity planning as an ‘ARR per CSM’ problem. They’ve answered the question “How many CSMs do we need?” with some version of the same calculation: We have $12m in ARR. The benchmark says a CSM should manage $2–3m. Therefore, we need 4–6 CSMs.

The calculation sounds simple, but finding the right capacity ratio has always been much more complex than a simple division, and it’s only getting more complex with AI and agents being added to the equation. The main issue with the ‘ARR divided by industry benchmark’ method is that $2m of ARR doesn't necessarily equal $2m of work. The amount of CSM capacity required to manage a book will depend heavily on things like:

External factors:

• Market maturity. Do customers already understand the problem you solve and how to use your software category to drive their business? Or are your CSMs also having to educate customers on the value of the category as a whole rather than just your specific product?

• Market competitiveness. Are you in a category where customers have lots of alternatives, meaning that continuously demonstrating the value of your specific product and building lasting relationships requires more proactive intervention?

• Customer characteristics. Does the customer have a dedicated administrator or sophisticated internal team? Or is the CSM effectively filling some of those gaps?

Internal factors:

• Your CS technology. Can your CSMs easily understand what's happening across their book and take action at scale? Or are they manually pulling data, preparing for meetings, identifying risk and writing every customer communication themselves?

• Your risk. How much of the total ARR you’re allocating is at risk? Seeing as saving risky customers requires more time than maintaining healthy ones, are your CSMs having to pull a lot of weight for most of their renewals?

• Your account structure. Are you managing single-entity customers, or global accounts with multiple business units, regions and buying centres, each with its own stakeholders, adoption curve and renewal dynamics?

• Your product’s complexity. Can customers largely figure the product out themselves, or does successful adoption require significant training, configuration and ongoing guidance?

• Your self-service infrastructure. When customers need help, do you have a strong Help Centre, community, academy and support function? Or does everything eventually land with the CSM?

Two companies with exactly the same ARR could therefore require completely different numbers of CSMs. So what’s a better way to calculate your capacity needs? Rather than relying on a single calculation, CS leaders can work through four steps to figure out what the right ARR per CSM ratio looks like for them.

Step 1: Decide where human CS capacity will have the biggest revenue impact

Historically, most CS teams have segmented customers primarily by ARR:

• “Spend over X? High-touch.”

• “Spend between X and Y? Mid-touch.”

• “Below Y? Digital.”

It's understandable. For a long time, ARR was one of the few reliable signals we had. But how much a customer spends with you doesn't necessarily tell you how much CS support they need, or where a CSM can have the biggest impact. A relatively small customer might have enormous expansion potential. A large customer might have a sophisticated internal administrator and require relatively little hands-on support, while a smaller customer might need significantly more help to successfully adopt the product. And two customers paying exactly the same amount could have completely different levels of risk.

Today, CS teams have far richer data available to make these decisions: product usage, engagement, sentiment, customer conversations, support interactions, organisational changes, commercial history, external signals. When you're managing thousands of accounts, no team can manually assess where intervention will have the most impact; it has to be driven by signals surfaced across the whole book. Increasingly, that data can give us much more accurate predictions of where revenue is at risk and where revenue opportunity exists. So rather than tiering customers purely according to what they spend, use those signals to ask: where will CS intervention have the greatest impact on the revenue outcomes we're trying to drive? That might create very different tiers from traditional ARR segmentation, allowing you to align your most expensive and valuable resource (human capacity) with the places it can have the biggest impact.

Step 2: Define what is required to achieve the outcome

Now that you've identified where different levels of intervention are required, ask yourself: What actually needs to happen for customers in each tier to renew and expand? What information do your customers need, and when do they need it, in order to be successful?

That might include:

• Onboarding and implementation

• Success planning

• Product and best practices education

• Evaluating usage and then driving adoption plays

• Tracking and re-engaging stakeholders

• Value and ROI articulation

• Risk identification and mitigation

• Executive alignment

• Expansion discovery

• Renewal preparation and negotiation

Before you can think about allocating ownership to these jobs, you’ll want to prioritise them based on their revenue impact. This will be unique to your organisation but will typically be based on a combination of proximity to revenue, leverage over your book and impact (how much revenue would be lost if no one did this, either instantly or downstream).

This might give you a list from highest to lowest priority like the following:

1. Renewal preparation and negotiation

2. Executive alignment

3. Value and ROI articulation

4. Expansion discovery

5. Risk identification and mitigation

6. Success planning

7. Tracking and re-engaging stakeholders

8. Onboarding and implementation

9. Evaluating usage and driving adoption plays

10. Product and best practices education

Those jobs will vary based on all the factors we started with: your market, your product, its complexity, your customer profile and the maturity of your wider customer experience, and they may vary by tier. The important thing is to stop defining Customer Success as “a CSM owns these accounts” and start defining the actual work required to produce the outcome, and how closely it impacts it. Putting clear boundaries around the jobs to be done by CS is also an important step in protecting your team’s time. It’ll ensure that their days don’t become a dumping ground for other work which doesn’t contribute to the outcomes they are responsible for.

Step 3: Decide what should be done by automation, agents and humans

Now take those jobs and ask: who, or what, should own each one?

There are broadly three options:

Automate it.
For deterministic, repeatable tasks where the workflow can simply happen without requiring judgement (e.g. welcome emails, product updates, best practices).

Give it to an agent.
For jobs where AI can work towards an outcome, make decisions within defined parameters and take action by creating personalised content which is unique to the scenario. Only escalating when it reaches the limits of what it can resolve (e.g. onboarding, communicating value, risk and upsell detection).

Give it to a CSM.
For the moments where human judgement, relationships, creativity, influence or commercial skill genuinely change the outcome (e.g. executive relationship building, success discovery, multi-threading).

Note: this doesn't have to be binary. An agent might own 80% of a job and bring a CSM in at exactly the point where human intervention becomes valuable.

Your model can also change by tier. Perhaps onboarding is almost entirely agent-led for your lower tier, while your highest-potential customers get significant CSM involvement. Perhaps agents monitor adoption across every customer, but a CSM gets involved when particular risk signals appear. The goal isn't just to automate as much as possible, it’s to deploy each type of resource where it is most effective at producing the outcome.

Step 4: Turn the remaining human work into a capacity model

Only now should you calculate how many CSMs you need.

For each customer tier, you should know:

• the jobs that a CSM needs to do for every account (as determined in Step 3)

• how long those take to prep, execute and follow up on (while leveraging AI)

• how frequently they need to do those jobs

This gives you an average amount of time a CSM needs to spend on a customer on a weekly/monthly/quarterly basis. Review this rough time estimate against your CSMs’ average working hours. Perhaps a customer in your highest-touch tier requires an average of four hours of CSM time per month, one in your middle tier requires 90 minutes, and customers in your lowest tier require almost no scheduled human intervention, but you need to allow capacity for escalations from your agents. At volume, those add up quickly: if agents cover 10,000 lower-tier accounts and just 5% escalate in a month, that's 500 cases your team needs to absorb. With these estimates in mind, you can now calculate the realistic number of customers a CSM can support in each tier. And from there, your headcount requirement.

The calculation becomes:

Jobs to be done and how often → human time required → customers per CSM → CSM headcount

Rather than:

ARR → industry benchmark → CSM headcount

One final variable: how aggressive are your revenue goals?

There's another layer that CS leaders should think through before signing off the headcount plan: What is the business actually trying to achieve?

Because capacity planning shouldn't only be about servicing your existing customer base. For example, your model might tell you that X number of CSMs can comfortably deliver the work required to maintain your current renewal performance, but your business has a huge expansion target. Plus, your data shows significant whitespace within a particular group of customers, and you know that more proactive human engagement increases your chances of converting it. In that case, you might deliberately add capacity. You're not adding it because those customers need servicing, you're investing in human capacity because you believe it can create additional revenue. Equally, if the business is prioritising efficiency, you might invest more heavily in agents and automation and reserve human intervention for the customers and moments where it has the greatest impact.

Which means the ultimate question isn't:

“How many CSMs do I need to manage this ARR?”

It's:

“What's the right combination of humans, agents and automation to achieve the revenue outcomes we're trying to produce?”

ARR per CSM should be the result of capacity planning, not the starting point.

The ARR per CSM ratio is expected to increase significantly over the next few years. Hook customers, for example, have more than doubled their ARR per CSM since switching to agentic CS. But this isn’t just because CSMs should simply be given bigger books and asked to work harder. They can manage bigger books because the amount of work that requires a human is fundamentally changing: agents continuously monitor customers, automations remove repetitive execution and AI surfaces risk and opportunity without a CSM having to hunt for it. Agents can now own entire jobs and involve a human only when their judgement, influence or relationship genuinely adds value, which removes a huge amount of the work that has historically consumed CSM capacity. So yes, CSMs will eventually manage $4m, $6m or considerably more in ARR, but that number shouldn't come from a generic industry benchmark. It should come from designing the customer motion required to achieve your revenue goals, deciding which parts should be owned by technology and which genuinely require a human, and then calculating the capacity required to deliver it.

Don't start with ARR per CSM and design your organisation around it. Start with the revenue outcome. Design the work required to achieve it. Then calculate the humans you need.