How Many Accounts per CSM Is Too Many?

Start with the hours a CSM has. Forty hours a week, minus the 30% that goes to internal meetings, CRM updates, Slack and reporting (a conservative share; published CS surveys put admin closer to half), leaves 28 client-facing hours a week, or about 121 a month. That is the whole budget.

Now cost the book. An account that gets a monthly call, prep, follow-up and the occasional fire costs roughly 1.25 hours a month. At that rate 150 accounts need 187 hours from a CSM who has 121, before onboarding a single new customer. The team is at 155% of capacity by arithmetic, which is what "going crazy" means when you write it down.

The same arithmetic is why the obvious fixes did not work. A calendar reminder to check in with 150 accounts is 150 reminders. A shared inbox routes the same hours to a different person. Nothing changes until some accounts cost fewer hours, and that is a tiering decision, not a discipline problem.

The review corpus says how common the situation is. Of 3,628 public reviews of the three most-reviewed customer success platforms, 456 describe the job the tool was bought for as knowing which accounts to focus on this week, and the account counts reviewers mention run from 150 to "1000's". The r/CustomerSuccess threads on the subject describe books of 150, 450, 600 and 900 accounts, and one scaled CSM role advertised at over 2,000.

Three tiers is enough. More than three and the rules for moving between them take longer to explain than the time they save. Each tier is defined by what the customer gets, what it costs in CSM hours, and what moves an account in or out.

The column that matters most is "enters when". ARR alone is the usual rule and it is the reason re-tiered teams stay overloaded. The r/CustomerSuccess thread on dedicated versus pooled coverage puts the objection well.

So tier on three inputs: ARR band, current risk (from whatever health score you have, even a spreadsheet one), and complexity (integrations, number of teams using the product, whether the sponsor who signed is still there). Any one of the three can promote an account. Only time and a green score demote one.

Here is the team from the thread, run through the accounts per CSM calculator with its default assumptions: 40 hours a week, 30% overhead, 3.5 / 1.25 / 0.15 hours per account by tier, six hours per new onboarding, eight new accounts a month.

Two things to notice. The tech-touch tier is 71% of the book and costs 14% of the hours; that ratio is the entire model. And the headline ratio did not change. 150 per CSM was never the problem. 150 at 1.25 hours each was.

You could instead give one CSM the whole tech-touch tier as a program owner and split the 130 named accounts between the other two. The maths is worse (each of the two would carry 20 high and 45 mid, 150 hours against 121) unless you also count the program owner's time building sequences and running webinars as a real job, which it is. Mixed books fit the hours better; a dedicated scaled CSM builds a better tech-touch program. Choose on which problem is bigger this year.

1. 1

   Export the book with ARR, renewal date, start date and named CSM

   From billing, not the CRM, so the list contains only paying accounts. Add columns for risk band and complexity score. If you have no health score yet, use the three-value rules from the spreadsheet template and score usage and relationship only; that is enough to tier.

2. 2

   Set the tier rules in writing before you look at names

   ARR bands first, then the promotion triggers (open escalation, sponsor change, 3+ integrations, usage down 40%). Decide the rules with the team in one meeting and write them at the top of the sheet. Tiering by name, account by account, produces the tiering everyone already had in their head.

3. 3

   Apply the rules and cost the result

   Multiply each tier by its hours, add onboarding, and put the three numbers into the calculator. If the load is over 105%, the tech tier is too small or the hours per tier are too generous. Move accounts down before you move hours down.

4. 4

   Tell the customers moving down, in their terms

   A mid-touch account moving to tech touch gets one message from its former CSM: what they can still reach (office hours, the pooled inbox, a person within a day for anything that matters), and the name on the inbox. Nobody minds losing a quarterly call they were skipping. They mind discovering it by silence.

5. 5

   Build the tech-touch tier's four triggers before day one

   Usage down 40% over 30 days, sponsor or admin change, invoice overdue 14 days, renewal 90 days out. Each trigger sends one specific message from a named person and creates a task. Without triggers, tech touch is a newsletter, and a newsletter is not coverage.

6. 6

   Run the tier review monthly, for 30 minutes

   Promotions and demotions only. Which accounts tripped a trigger and are in their 30 days, which have been green for two quarters and can move down. The tiers drift toward high touch if nobody demotes, because every CSM would rather keep an account than hand it to an inbox.

The leader in the thread had already tried automation. The result is the most useful sentence in the whole discussion.

Tech touch failed there because it was defined by channel (email, automated) rather than by trigger. Coverage is a promise that someone will notice when something changes in the account and say something specific about it. A sequence that fires on a calendar does not notice anything. Four rules make the tier feel like a person:

• Every message is triggered by an event in the customer's data, names the event, and offers one concrete next step. "Your team's weekly active users dropped from 14 to 6 since the 3rd; if two of those are people who left, here is the 10-minute way to reassign the seats" is coverage. "We noticed you haven't logged in" is surveillance.
• Every message is signed by a person who will answer a reply within one working day, from the pooled inbox. The name is real. The reply goes to a human.
• A risk trigger promotes the account to a named CSM for 30 days. Tech touch is where accounts live while they are fine, not where they go to be ignored.
• One recurring live touch a month, open to the whole tier: office hours or a webinar on a feature the usage data says most of them have not adopted. Attendance is a signal in itself.

Done this way, tech touch is how small teams cover books they could not otherwise cover, and the reviews say so in almost those words.

When a team re-tiers and the hours still do not fit, one of four things is usually wrong. Check them in order.

1. The demoted accounts did not get the message. They still book calls with their old CSM, still pull them into tickets, and the CSM still answers, because saying no to a customer feels worse than working late. One senior CSM described 60 accounts outside their focus list that "still book calls, pull me into tickets, and need support". Fix: the handover message in step four, and a calendar link that routes to office hours rather than a person.
2. Nothing ever moves down. Every account that was ever high touch is still high touch, so the tier is 25% of the book instead of 8%. Fix: the monthly review, with demotion as the default for two green quarters.
3. Onboarding was not counted. Eight new accounts a month at six hours each is 48 hours, a third of one CSM. If onboarding sits with the CSMs, put it in the model; if the team is also firefighting renewals, it is the first thing to slip, and the churn shows up nine months later.
4. Overhead is not 30%. If Sales pings CS before every renewal call, Product wants churn summaries and Finance wants account status, the internal share can pass 50%. Measure it for two weeks. If it is over 40%, the fix is an internal source of truth others can read without asking, not a smaller book.

Then the decision rule. If the tech tier holds at least 60% of the book, the four causes are handled, and the calculator still shows more than 105%, the model is right and the headcount is wrong. Take the hours figure, not the account count, into the hiring conversation: "we need 1.4 more people at these assumptions" is an argument; "150 accounts is too many" is a complaint. Alongside it, SaaStr's long-standing rule of thumb of roughly one CSM per $2M of ARR gives leadership a second number to check against.

In one case out of four the answer is that churn will happen because of capacity, and the leader's job is to say so in writing before it does, with the accounts named. That is a different conversation from the one where the CSM is blamed for what slipped through, and it is the one worth having. Which accounts to name is what spotting churn risk early across scattered data is for.

GainTrace watches every account in the book, whatever its tier, and fires the triggers the model depends on from billing, CRM, product usage and support data, so the pooled tier gets the same risk detection as the named one. Churn prediction ranks which of the 320 to promote this week, and rescue playbooks run the 30-day human touch with the tasks and the specific message written from the account's own data, without an admin to build the sequences.