ARR per CSM Is Not a Capacity Model

You know the moment.

You ask for another CSM.

Instead of talking about the work your customers require, the conversation turns to benchmarks.

ARR per CSM.

Accounts per CSM.

How much more capacity AI should have created.

Before long, you're defending your team against numbers built for somebody else's business.

Benchmarks aren't the problem. Treating them like operating models is.

The question behind ARR per CSM

I understand why leaders want benchmarks.

If you're trying to decide whether a Customer Success team is appropriately staffed, you need something to compare against.

• How much ARR should one CSM manage?
• How many accounts should a CSM have?
• When should we hire the next person?

Those are reasonable questions.

The problem starts when the benchmark becomes the answer.

Imagine two SaaS companies that each have $2 million in ARR per CSM.

At one company, customers have a relatively simple product, a lightweight implementation, a small number of stakeholders, and require limited ongoing intervention.

At the other, customers have a complex implementation, multiple stakeholder groups, significant change management, and a series of high-touch activities required to reach the outcome they purchased.

The ratio is identical.

The work isn't remotely the same.

That's why ARR per CSM tells you almost nothing about the effort required to manage that ARR.

Accounts per CSM has the same problem.

Fifty customers requiring five hours of work each are fundamentally different from fifty customers requiring twenty.

A ratio tells you how the work has been distributed. It doesn't tell you how much work exists.

Start with the work customers actually require

There's a better place to start.

What actually has to happen for your customers to progress?

Not how many accounts do we have?

Not what does the benchmark say?

What work does the customer experience actually require?

Product complexity matters.

Implementation depth matters.

Customer maturity matters.

The number of stakeholders involved matters.

The customer's ability to manage change matters.

Most importantly, what actually has to happen for the customer to make progress matters.

Once you understand that, capacity planning starts to become much more concrete.

Define the progression you want the customer to experience.

Then define the plays required to create it.

Maybe a customer needs a structured kickoff.

Maybe the team needs to establish First Value.

Maybe an executive sponsor needs to become involved.

Maybe the customer needs an alignment meeting after achieving that first value.

Maybe there are specific interventions required later in the relationship to maintain adoption, demonstrate outcomes, or prepare for renewal.

Those aren't abstract Customer Success activities.

They're work.

And work can be estimated.

Build CSM capacity from the plays

Once you've defined the plays, you can begin asking better capacity questions.

• How often does each play occur?
• Which customer segments require it?
• How much time does it take to execute well?
• Who owns it?
• Does the work happen once, monthly, quarterly, or only when a specific condition occurs?
• What can be automated?
• What requires human judgment?
• What unplanned work should we expect?

Now you're building capacity from the work required to deliver the customer experience you've designed.

That gives you something a benchmark can't.

A reason.

Instead of saying:

“We need another CSM because our ARR per CSM is too high.”

You can say:

“This segment requires this set of plays to move customers forward. Those plays require this amount of capacity. Based on the customers we're adding and the work we've designed, here's where we run out of capacity.”

That's a very different staffing conversation.

Capacity isn't just customer-facing time

There's another mistake I see in simplistic CSM ratios.

Not every hour in a CSM's week is available for planned customer work.

• There are internal meetings.
• Account preparation.
• Documentation.
• Team coordination.
• Escalations.
• Administrative work.
• Unexpected customer issues.
• And the unplanned work that inevitably appears in any customer-facing organization.

If your capacity model assumes a 40-hour week can be filled with 40 hours of designed customer activity, the model is already broken.

Capacity planning needs to account for the actual availability of the team, not theoretical working hours.

That also makes something else visible.

If too much capacity is disappearing into internal or unplanned work, hiring may not be the first answer.

The operating model itself may need attention.

What happens when AI changes the work?

AI makes this conversation even more important.

We're already hearing some version of:

Shouldn't each CSM be able to manage more customers now?

Maybe.

But “AI should increase capacity” isn't a capacity model either.

Go back to the work.

If AI eliminates a task, reduces the effort required for a play, or allows part of the customer experience to be delivered differently, change the assumptions.

Maybe a play that required 60 minutes now requires 20.

Maybe preparation that required 30 minutes now requires five.

Maybe a segment can move from a one-to-one interaction to a one-to-many experience without sacrificing progression.

Good.

Put that into the model.

Now the productivity gain is visible.

And if AI doesn't materially reduce the work required to move a particular customer forward, don't manufacture a capacity gain because a benchmark says one should exist.

When the work changes, the capacity model should change with it.

Benchmarks still have a place

None of this means ARR per CSM or accounts per CSM are useless.

I want to know them.

They can help you understand how your organization compares with others.

They can raise questions.

• Why are we operating at half the ARR per CSM of another company?
• Why can this segment support more accounts than that one?
• Why has our ratio changed over time?

Those can be useful signals.

But the benchmark should start the conversation, not end it.

Because ultimately the staffing question isn't:

How many customers should a CSM manage?

It's:

How much work is required to create the customer progression we've designed, and how much capacity do we have to execute it?

Answer that, and ARR per CSM becomes what it should have been all along.

Context.

Not the operating model.

Use benchmarks for context. Build capacity from the work.