Why Your CSMs Are Overloaded: The Customer Success Workload Audit

I'm seeing a common pattern over the past two years. Customer Success leaders come to me saying, their team isn't proactive enough, or their team is overloaded. Sometimes it's both, and the first instinct is usually that the team needs enablement, better customer communication skills, more multi-threading, stronger discovery, better prioritization across the book.

Sometimes that's right. Sometimes the answer really is enablement. But more often than not, when we dive deep into what's actually happening on the team, the problem is somewhere else entirely.

It's in how customer success is positioned in the company. It's in what the CSM role has turned into over the years. The team is reactive, because the system around them produces reactive behavior.

And you can put different people into that system, and you're gonna get the same result. In this episode, I'm gonna walk you through an exercise that I do with the CS leaders I work with to map where the hours actually go. What comes out of it feeds some of the biggest decisions you make in this role, your headcount and capacity plan, your CS charter, meaning what your team owns and what it does it.

Let's get into it. Welcome to the Customer Success Leadership Podcast. I'm Angeline Gavino, a former VP of Customer Success turned executive coach to CS leaders.

If you're leading a function and want to build not just a strategy, but also the influence, credibility, and authority that make customer success indispensable to the business, you're in the right place. Let's get into today's episode. When a team is reactive, the easiest explanation is the people.

The CSM doesn't prioritize well, that CSM never gets ahead of the account. My CSMs don't have the right skill set, so you reach for enablement, because you assume it's a skills issue. But then, look at what the CSM job has actually become.

You hire them for onboarding, adoption, value realization, renewals and expansions, maybe depending on whether you own that too. But in practice, every time we dig into a CS organization's capacity, the pattern is the same. Support is an escalation, they reach out to the CSM.

Finance has an overdue invoice, the CSM is asked to chase it. Product needs customer context, looping customer success, product workarounds, that's customer success too. Everything that touches the customer is automatically customer success.

That's the assumption the whole company is running on, and it's wrong. Touching the customer and owning the outcome are two different things. And the thing is, customer success always steps in.

We're team players, we're close to the customer, and we care. Not stepping in means dropping the wall, which means a bad customer experience, which can mean churn. And all the customer success gets penalized for churn.

So your team says yes to all of these, and over time you've set the wrong precedent. That precedent becomes how the company sees customer success. But that work as an owner, supports own technical escalations, product owns product workarounds, finance owns billing, but they just stop acting like it because customer success has been picking it up for so long that it looks like the CS job now.

What you need to do is change the system, because no amount of enablement or playbooks is going to fix a bandwidth problem. You need to provide your team with a role that fits in a week, clear ownership so they know what's theirs, and what they're allowed to hand back and cover from you when they say no to another team. That's your job as the leader.

Your CSMs can't renegotiate what CS owns with support or product, but you can. Now, before you change anything, you need to know what needs to change. This is where what I call a CS Workload Audit comes in.

A Workload Audit is a two week snapshot of how your team actually spends its time. Every CSM logs their day against a handful of categories, and at the end, you have a picture of where the hours go, by type of work, by segment, and by person. The goal of the audit is to understand where your CSMs' time goes, so you can separate the work that's actually theirs from the work that they've picked up along the way and put a number on both.

So here's what you're gonna do. For two weeks, ask your CSMs to write down where their time went at the end of each day. Pick two normal weeks.

Skip renewal season and launch weeks. Time goes into one of the five buckets. One, proactive customer work, like onboarding, success planning, adoption, renewals, expansion, the work that you hired them for, basically.

Two, reactive customer work, inbound requests, escalations, whatever the customer needed that day. Three, prep and admin. So call prep, DAX, follow up emails, CRM notes, updates, chasing internal answers before a meeting, because we all know that a one hour customer call is actually off in three hours once you count all of this.

Four, work that belongs to another team. Building questions, support tickets, reference calls for sales, product feedback, collections. And then five, internal work, team meetings, reporting, trainings, one-on-ones.

If you want a head start, I actually have a CS Workload Audit Template in our free library at csrevspeak.com forward slash templates. It's already built around these five buckets, so your team could just open it and start logging. Now, before you start this exercise, you need to ensure that your team understands the why.

Why are you doing this? So say something like, I know the week feels unmanageable, but before I try to fix it, I wanna see it. I think a lot of your time is going to work that was never yours, and I need the evidence to do something about it. Then tell them that it won't be used to evaluate anyone and actually mean it.

If they think this is about who works hardest, they're gonna log the week that they think you wanna see. And I would recommend that you log your own two weeks too. It's very important to understand where your time goes as a leader, and then share the results with the team.

Don't be surprised if proactive work turns out to be the smallest bucket, the work that you actually hired for getting squeezed out by everything else. Don't be surprised if reactive work is bigger than you expected either. And don't be surprised if prep and admin eats a bigger share than you'd guess.

Call prep, DAX nodes, follow-up emails, chasing internal answers. It's invisible because it hides inside a customer work, but it's real time. The bucket I want you to look at closest is the other teamwork.

Whatever shows up there is the clearest evidence of what CS has absorbed that was never actually CS job. And put a cost on it. Take a loaded CSM salary and the share of the week going to other teamwork, and you can tell your executive team roughly how much of the CS budget is funding work that actually belongs to the other team.

If you're taking this to a budget conversation, the CS budget and capacity planning template in our library walks through building that number from the bottom up. Look at it two more ways. By segment, to see whether your highest touch accounts are actually getting more proactive time than the rest, or whether your segmentation only exists on paper.

Also look by tenure, because it's common for your most senior CSMs to be the ones absorbing the most reactive and maybe other teamwork, simply because they're the one who everyone trusts to handle it. Then comes the skill question. Look at the proactive hours that did happen.

Were the success planning conversations good? Did the expansion conversations go anywhere? Did the CSM reach new stakeholders? If the quality is there and the quantity isn't, you know it's a system problem. If the quality is also off, you have both, and you now know which to fix first. Now you know what you're dealing with.

Let's talk about a fix. And there are two wrong turns to avoid here. The first is assuming that the fix is inside the team.

You reach for better prioritization, better time blocking, better boundaries. That's your CSMs to solve a problem the organization created. The second, going straight to headcount.

De-scope before you hire. Go through the other team bucket and ask three things. What is CSM owning that it shouldn't? What crept in that nobody has signed? What exists only because another team hasn't fixed its process? Hiring on top of borrowed work only hires more people to do it.

So here's how I'd go about it. First, get clear on what CS should own and what belongs somewhere else. That's your mandate, and it starts with writing it down.

Build a one-page charter. What CS owns, what it doesn't, and where the handouts sit. You don't have to build this from scratch.

There's also a customer success charter template in our free library. Again, you can access that at csrevspeak.com forward slash templates is the same one I use with my clients. Why is this important? Writing the charter forces you to get honest with yourself about how you actually want CS to work inside a company and what you think your team can realistically contribute.

That clarity is what you bring into every conversation it follows. Once you've got a draft, take it to your executive team and your cross-functional leaders. Support, sales, product, finance.

Present your findings from the audit. Lead with what you've found. Something like over two weeks your CSM spent, I don't know, let's say 40 hours on support escalations or X number of hours chasing unpaid invoices.

Put a cost on those hours and call out where it's concentrated. It could be a segment that isn't getting what it should or your most senior CSMs picking up the slack. That's what gets a room to lean in.

You wanna present the facts, then your proposal, go over your charter, tie it into what your CSMs should own and not own, make your case and then get the buy-in. If everyone aligns, the next piece is being clear about the handoff itself. Agree on a date, agree who owns what, starting when, give it a short window so nothing falls through the cracks and put it in writing.

Now expect some pushback along the way because the team has been sending you overflow, probably has its own capacity problem. So you wanna be generous in timing, but firm on direction. And then, communicate it to the rest of the team.

The charter tells you what CS owns. You've got buy-in, now make sure everyone knows the way forward. Make sure your CSMs know what's been handed back, killed or automated.

Make sure your cross-functional leaders have had that same conversation with their own teams too. Then optimize, cut the prep and admin tail with templates, use AI to draft call recaps and capture notes, then move your team's time toward the high leverage work and protect it. Do that and the training that you probably have already invested in has somewhere to land.

Oh, and also, I talked about this earlier. Here's how you can use this audit for your headcount and capacity planning. Go back to the proactive bucket and find out how many hours it actually takes to run one account properly in a given segment.

Then, look at how many hours a CSM has free in a real week once meetings and paid time off are out of the picture. Match those two numbers and you've got how many counts one person can actually carry well. Compare that to your total book and the gap between what you need and what you've got is your headcount case, straight from your workload audit.

That's what takes the guesswork out of it. Instead of telling your executive team, the team feels stretched, you're showing them the actual number, how many accounts one person can carry and where it runs out. Let's recap what we just went through.

First, when a team is overloaded or reactive, check the system before you check the skills. Second, run the audit with your team. Third, read the other team bucket.

That's how your company sees CS. Put hours and costs on it. Cut by segment and tenure.

Then, check the quality of the proactive work so you know whether it's a system problem, a skills problem or both. And fourth, de-scope before you hire. Build a charter.

Get buy-in on what CS owns and when you do need more people, use the audit's capacity math. How many accounts one person can carry to make the case. If you run this audit, you'll know where the time goes and what it says about how your company sees customer success.

The bigger job comes after because nobody ever wrote down what CS owns versus what sales, support, product, rebuilding should have rightfully owned to begin with. The audit shows you the symptoms. Fixing the model is the work.

If this is something you wanna get right in your org or something you're already working toward, I'd love to invite you to join Lead to Scale. It's my 12-month CS leadership program where you build your CS operating model with me and a small group of CS leaders. This means for one full year, we get to work together on building your overall CS strategy, your charter, your playbooks, all of it.

You can check out a program details and apply at csrevspeak.com forward slash L2S. The link is also in the show notes. Thanks for joining me in today's episode.

I'll see you in the next one.