The first time I built a Customer Success department from scratch, I learned a lesson I couldn’t put a name to back then, and that now sits at the heart of almost everything I do. Stick around, because I’m going to tell you not just what it is, but how you can start to solve it yourself.
We had good people on the team. Colleagues who gave their all to every account, who loved what they did, and yet, almost every Friday, when you asked how the week had gone, the answer was the same: exhausted, a few strained accounts and, worst of all, unable to fully explain where our time had gone. It wasn’t a lack of effort, but that effort wasn’t translating into results, and the gap was frustrating week after week.
That feeling of running on a hamster wheel is familiar to many of us in this industry. It took me a while to understand why it happened, yes, but once I understood it, I saw it everywhere. Now, working with SaaS companies from the outside, I recognize it in the first conversation, and it’s far more common than it seems.
We make Customer Success accountable for the outcome. The question is whether we’ve ever given it the tools to achieve it.
It’s the team that answers for renewals, adoption, revenue across its portfolio, customer health, open issues, usage… But many of the levers that move those metrics are in other hands. For example:
-
The roadmap that would make the customer stay is decided by Product.
-
The expectations the customer arrived with were set by Sales during the sale.
-
Account prioritization is decided by your leadership committee.
The CSM answers for an outcome they don’t fully control. And when the outcome falls short, they sit across from someone who asks, in that tone we all know: what happened here? As though the whole answer were on their side of the table.
It isn’t. It never was, no matter how much talent or juggling was involved. It’s not a people problem, but a design problem: a process that puts responsibility in one place and control in another.
The 3-bucket test: where the week really goes
When I want to help a client see this today, and help both the CSM and the company at the same time, I use the exercise I’m sharing here. It separates what your CS team truly controls from the extra burden it’s simply putting up with.
The steps are simple. Take everything your team does in a real week, not the neat, clearly defined version in the job description, but the actual one, with its interruptions, unproductive meetings, and exceptions. Now divide it among these three buckets: Conversation, Burden, and Compensation.
What you discover at the end is usually the same: why your team is overwhelmed. And that it’s not for the reason you thought.
Bucket 1. Conversation.
This is where the irreplaceable work goes: the human work that sustains the relationship, whoever on your team does it. Examples:
-
The discovery process that uncovers what this customer really needs.
-
The conversation about expectations that prevents a misunderstanding before it starts.
-
The renewal that hinges on a conversation, not an email.
-
The conversation that prevents churn instead of managing it when there’s no turning back.
-
The meeting to understand the customer’s business well enough to connect your product with what keeps them up at night.
This is where a good CS team shines. The territory where they thrive, and where they should spend most of their day.
Reality: they rarely do. Because the other two buckets eat it up.
Bucket 2. Burden.
The work that exists, that someone has to do, but that doesn’t require a CSM’s judgment. Examples:
-
Updating the spreadsheet manually.
-
Reconstructing the customer’s context before every call because the information lives in five different places.
-
Preparing internal reports that get half a minute of attention in a committee meeting.
-
The coordination meetings that eat up half the morning.
This bucket should be absorbed by your system, not your people. And I’m not talking about a two-year project. I’m talking about two decisions almost nobody makes: where the source of truth about the customer lives and who maintains it, and what repetitive work automation can handle so nobody has to touch it manually again. Because ask yourself this: right now, does your team have a complete, up-to-date picture of the customer in one or two places? I’ve come across companies where nobody is even responsible for making sure that single picture exists.
As long as that bucket stays on the CSM’s desk, you’re paying them a strategist’s salary to do administrative work. And if you then wonder why they aren’t more proactive with their accounts, here’s your answer.
Bucket 3. Compensation.
This is the bucket that changes everything, and the one that almost never comes up when we analyze where our day goes.
It’s the work the CSM does solely to patch up something that broke before it reached them. Examples:
-
Chasing Sales or the AM to find out what was promised or discussed in the last meeting.
-
Explaining again to the customer what Implementation left unresolved and what has kept them from seeing the value.
-
Discovering, in the middle of a renewal, a support ticket that’s been open for months and that nobody flagged.
-
Piecing together the customer’s history week after week, rebuilding information that should have flowed between teams on its own.
Look closely, because this bucket is an impostor. It disguises itself as CS work, but it isn’t. It’s a broken handover turned into a recurring task. It’s the price post-sales pays for a gap that opened much earlier, in the handoff between Sales, Implementation, CS, and Support.
And here’s the uncomfortable part, the one I struggled to see while I was caught up in daily firefighting.
Most CS teams aren’t overwhelmed because they have too many customers.
They’re overwhelmed by the size of their third bucket. And until you fix it, you’re wasting your investment in post-sales: you hire more CS people to endure the chaos instead of redesigning the process, and the revenue you wanted to retain keeps slipping away all the same.
How to solve the third-bucket problem, whether you’re a CSM or a leader.
When I understood what was happening, I looked for a method, an article, anything that would tell me how to fix it. And this is where almost everyone leaves you stranded: they show you the problem and walk away. So let’s get to what matters. There’s no single formula, every company and every product is different, but there is a path forward.
The first step, and it sounds obvious but almost nobody does it, is to measure it. You can’t redesign what you haven’t seen or change what you haven’t audited. The three-bucket test isn’t a pretty metaphor; it’s the first real move. Until you can see how many of your team’s hours live in bucket three, the conversation is about impressions and exceptions. Once you’ve mapped the work, it’s about data. And data beats a narrative.
The second step is to accept that bucket three can’t be fixed within CS, no matter how hard you try. This was the hardest part for me. I was trying to solve a problem within my team that hadn’t started in my team. I organized, prioritized, motivated, and even tried to get other teams moving, but bucket three filled up again every week. Trying to change the course of something that doesn’t originate on your side rarely ends well. What starts outside has to be fixed outside.
The third step is to redesign the handoff, which is where the real levers are. And it’s not as big as it sounds. Start by answering these questions in writing:
-
What gets transferred in each handover. Not “whatever is needed,” but an agreed minimum list: what Sales knew about the customer, what was promised, what Implementation completed, and what it didn’t. If that information doesn’t travel with every handoff, the CSM reconstructs it manually from scratch, and you already know which bucket that falls into.
-
Who owns each piece of data, and the handoff itself. Not the task, the data. When nobody is responsible for a piece of information or for making sure the handoff happens, both end up falling to the last team in the chain, which is almost always CS.
-
What version of the customer each team sees. If Sales, Implementation, CS, and Support are working with four different versions, the customer ends up asking the AM about a support ticket or writing to CS about an invoice. A single shared version empties half of bucket three without hiring anyone and frees up other teams too.
And one condition underpins everything: someone with cross-functional authority must own that redesign. A CSM can’t reorganize how Sales hands things over, or redesign issue prioritization in Support or Product, because they don’t have authority over those teams. That’s why bucket three isn’t delegated downward; it’s resolved across teams and upward, or it isn’t resolved at all.
Notice that none of these four things involves hiring. When a team is drowning, the instinct is to ask for another person. But bucket two is fixed with systems, and bucket three with design. A new hire who joins without any of this changing inherits the same chaos, and six months later you’re in the same place, with a bigger payroll and more burnout.
Run the test before deciding anything
If any of this resonates with you, do the exercise this week. Have each person record their actual responsibilities over five days, including the percentage of time and the hours they spend on them, and assign each one to the three buckets. No dressing it up or saying “this doesn’t count because it was an exception”, because exceptions that happen every week aren’t exceptions; they’re your pattern, your way of operating.
Two rules to make it useful.
-
Validate every line with the person, don’t estimate it yourself from the outside, because what you think fills their week and what actually fills it almost never match.
-
Do it without making it sound like an audit. It’s not “justify your time to me.” It’s “I’m trying to understand how you work; tell me what a normal week looks like for you.”
Then look at the sizes. If the Conversation bucket is the smallest of the three, you have your answer, and what you do next depends on which seat you’re sitting in.
If you lead the team
The third bucket you uncover is your design debt, not a performance problem with your people. You can’t motivate it away, and hiring to tackle it just puts one more person into the same broken loop.
Your next move is a redesign, and it happens across teams and upward, not downward. Take your measured third bucket and sit down with your counterparts, Sales, Implementation, and Support, with those three questions on the table. And take responsibility for that redesign, because if nobody with cross-functional authority owns it, the task falls right back to the last person in the chain: your CSM.
The underlying decision is simple, and it’s yours: either give the person accountable for the outcome the tools to achieve it, or stop holding them accountable for it.
If you’re the CSM
You probably can’t redesign the handoff. You don’t have authority over Sales, Implementation, or Support, and you don’t choose the tools, but there’s something you can control that changes your week and your next renewal: stop absorbing bucket three in silence.
Every time you manually reconstruct what someone else failed to transfer, that work disappears. Nobody sees it, and it remains your invisible effort. Then, at renewal time, when the account gets tense, it looks as though you fell short. Meanwhile, your burnout keeps growing.
Make it visible.
Measure how many hours of your week live in bucket three and present it as data, not a complaint. It’s not “Sales never passes anything on to me”; that makes you part of the problem. It’s “six hours of my week go into piecing together information that should arrive in the handoff; here’s the breakdown.”
With data, your problem stops being yours and becomes the company’s, which is where it belongs. And along the way, you start building something that actually works. Heard of CS Ops? This is part of it. Your work has more impact than you think.
And for both of you
For a long time, I thought my team and I were stuck on a hamster wheel. Running as hard as we could every week, only to end up in exactly the same place.
It wasn’t a wheel.
It was a badly designed racetrack.
And no matter how good the runner is, the layout decides the race before the first turn.
That’s the whole difference between blaming people and looking at the system. When the outcome falls short, it’s comfortable to ask who didn’t run hard enough. It’s more uncomfortable, and far more useful, to ask who designed the track, and why they put responsibility in one lane and the tools in another.
The good news, which would have saved me years and a lot of headaches, is that it can be redrawn. And redesigning it ultimately comes down to a single decision: giving the tools and responsibilities back to the person accountable for the outcome.
Run the test this week.
Look at the size of your third bucket.
And decide which side of that decision you want to be on.
Which of the three buckets is eating up your CS team’s day right now? What strategy have you used to solve it?
I’d love to read your recommendations and hear about your experience.
