Structuring a CS team. Cover the whales, gamble on the tail.

The 866 number ringing my cell phone

Our first dedicated CS hire was our first team member, period — the only person before them was a 1099 contractor building the product. The trigger wasn't a revenue threshold or a customer count on a planning slide. It was landing one large customer we needed to support, and the dawning realization that I could not be the support team anymore.

Because that's what I'd been. I was doing the CS job while working at a consulting client, since we couldn't afford to keep me — or anyone — in the business full-time yet. Our 866 number rang straight to my cell phone. It would go off while I was in the car, or onsite at the consulting client, and I'd answer it.

I lead with this because founders ask "what revenue should I be at before I hire CS?" and the honest answer is that the number rarely drives it. The account that's too important to handle off your cell phone drives it. If you're reading your own situation in that sentence, the hire is already overdue.

How many accounts one CSM can carry

Here's the economic reality that shapes every CS org at SMB scale. We had 3,000 accounts and couldn't afford to cover them all. So we didn't pretend to. We covered the tunas, whales, and salmon — the accounts whose revenue justified a named, attentive CSM — and ran a round-robin on the minnows and the smaller accounts. There are only so many hours; that was the math, not a philosophy.

When you load a CSM too heavy, the wheels don't dramatically come off. It's quieter and worse than that. The high-value services — QBRs, training, expansion pitches — simply don't happen at the scale they should for the small and medium accounts.

That unanswered question is the real cost of an over-loaded book. It doesn't show up as a fire. It shows up as a ceiling you can't see, on a segment you decided not to look at.

Where success ends and support begins

Early on, success and support were the same people — there weren't enough of us for them to be anything else. It took us roughly five years to split the function. The dividing line, once we did, was proactive versus reactive: the 866 number was reactive support, fielding what came in; CSMs were proactive service, reaching out before they had to. Customers wanted and needed both, which is exactly why you eventually can't ask one person to be both. (Support deserves its own treatment as a retention engine — that's the next piece in this series.)

Organizing the book — and the experiment we skipped

The structure we landed on is the common one, and it's common because the economics are sound: CSMs own a fixed book of named accounts, and a pooled queue handles the smaller ones. Bigger accounts get a named CSM; the long tail gets light-touch or pooled coverage. For a business with thousands of low-LTV accounts, that's the model that makes the most economic sense, and I'd point most SMB founders straight to it.

But here's the miss, and it's the one I'd most want a founder to avoid repeating. We assumed we couldn't profitably service the small accounts — too many of them, the economics won't work — and we never tested the assumption. I wish we'd run the experiment: put a dedicated CSM on a book of smaller accounts and actually measure whether better service drove adoption, expansion, or retention well enough to pay for itself.

The assumption might well have been right. But "we ran the numbers and a dedicated small-account CSM doesn't pay back" is a conclusion; "everyone knows you can't serve the tail" is a reflex. We acted on the reflex for years. If you're going to write off a whole segment of your base, write it off because you tested it, not because the spreadsheet looked obvious before you tried.

CSMs are not salespeople

What makes a good CSM? For us it was a specific mix: strong communication, real problem-solving, genuine product depth, a measure of persuasion, and the ability to stay calm in a crisis — a botched product launch, system downtime, the moments that test a relationship. The persuasion part is subtle: it's persuading a customer to adopt, and sometimes persuading them they don't need a particular feature — not closing them.

And here's the conviction underneath the whole function. We never trained our CSMs in sales, and I think the assumption that you should is one of the biggest mistakes SaaS businesses make.

This resolves a tension a careful reader of this series will have felt. Elsewhere I've said your best salespeople are your success people — and that dedicated expansion salespeople mostly failed for us. Both are true precisely because CSMs sell by not selling like salespeople. The trust they build is the thing that makes the expansion conversation land. Train that out of them and replace it with quota behavior, and you break the exact mechanism that was producing the revenue.

What I'd do differently

If I were structuring CS again, I'd invest more in two linked things. First, expansion — having more add-ons to sell, so a CSM's hard-won trust has somewhere to go. Second, more CSMs — enough to support a broader slice of the customer base, not just the high-value accounts at the top.

Those two regrets are really one regret seen from two sides: we under-invested in the customers we already had. We didn't build enough to sell them, and we didn't staff enough to serve them past the whales. The structure wasn't wrong — named CSMs on big accounts, a pooled tail, success split from support. We just drew the coverage line conservatively and never pushed on whether it could move. If you take one thing from how we built CS, let it be that: pick the economically sound model, then actually test its boundaries before you accept them as walls.