Segmentation without strategy: where CS capacity disappears.

Ask most CS leaders how their accounts are segmented and you'll hear something like: Enterprise above $100k ARR, Mid-Market $20–100k, SMB below that. Ask them what the commercial thesis is for each segment — and the answer gets much more complicated.

ARR-based segmentation isn't a strategy. It's a sorting mechanism. And when capacity allocation follows a sorting mechanism rather than a commercial thesis, time flows to the loudest accounts, not the most strategically valuable ones.

Where the capacity actually goes.

I've seen CS teams of twenty people with 60% of their hours concentrated in five accounts that have no realistic expansion potential and a contractual ceiling that's already been hit. The revenue impact of winning those accounts back is marginal. The revenue impact of losing a high-potential mid-market cohort through neglect is catastrophic.

Segmentation earns its name when it answers two questions: where is the revenue potential, and what does the right engagement model look like to capture it?

Everything else is just labelling.

A real segmentation model carries a thesis: what success looks like in each segment, what the engagement model is, where the expansion pathway sits, and what the warning signs are when a customer slips between tiers.

What a segment thesis actually contains

What success looks like here. Not a health score — the specific outcome a customer in this segment is trying to buy. It differs by segment more than people expect. An enterprise customer is usually buying standardisation or risk reduction across business units. A mid-market customer is usually buying a capability they don't currently have. If success is defined identically across both, you're measuring one of them against the wrong thing.

What the engagement model is. Named coverage or pooled. Scheduled or triggered. Proactive outreach or responsive. This should be written down and specific enough that two CSMs would treat the same account the same way. Most models stop at a tier name, which leaves the actual decisions to individual judgement — and individual judgement, aggregated across a team, is what produces capacity flowing to whoever asks loudest.

Where the expansion pathway sits. Each segment should have a plausible route to growing — more seats, more business units, a higher tier, an adjacent module. If a segment has no expansion pathway, that's not a failure, but it should be explicit, because it changes what the segment is for. A segment you're retaining is managed differently from a segment you're growing, and conflating the two wastes effort at both ends.

What the warning signs are. Segment-specific, because risk looks different at different sizes. In enterprise, a sponsor change or a stalled business unit rollout. In mid-market, usage concentration in a single team or a quiet renewal approaching. Generic health scores flatten these into one number and lose the signal that mattered.

The other half of the decision: cost to serve

Segmentation is usually discussed as a revenue question — where is the potential. It is equally a margin question, and that's the half most CS leaders don't argue.

Every account has a cost to serve: CSM hours, support load, onboarding effort, the executive time a demanding customer absorbs. Segmentation is the only real lever you have on it. Without deliberate differentiation, cost to serve grows in step with revenue, and you never get operating leverage — which is the point at which the board starts asking why CS headcount rises in lockstep with ARR, and the honest answer is that nothing was ever designed to stop it.

This reframes the uncomfortable part. Deciding what a segment doesn't get sounds like neglect when you describe it as capacity. Described as margin, it's an ordinary commercial choice with a number attached: this cohort generates this much revenue, warrants this much cost to serve, and here is the service model that fits inside it. That's a conversation a CFO recognises, and it's considerably easier to defend than an argument about CSM workload.

It also makes the reverse case possible. If a segment justifies more investment — more coverage, a dedicated onboarding resource, an expansion-focused motion — you can show the return rather than assert it. Segmentation that carries cost as well as revenue gives you the evidence for both directions.

What happens when you don't differentiate

The failure mode isn't an absence of segmentation. It's convergence.

Without a deliberate model, teams settle into a single average service level applied to everyone. Quarterly check-ins for accounts that need monthly attention and accounts that need none. The same onboarding for a twelve-user team and a twelve-hundred-user rollout. It is too much service for the tail and not enough for the top, and it satisfies nobody — the small accounts get contact they didn't want, the large ones get coverage that doesn't match their complexity, and the team is fully occupied without anything being well served.

That convergence is what most organisations actually have when they say they're segmented. The tiers exist on the slide. The behaviour underneath them is uniform.

Accounts move. Models usually don't.

Most segmentation is set once at the start of the year, and then the business changes underneath it.

An account that has doubled its footprint is still receiving the coverage that fitted it eighteen months ago. Another that has quietly consolidated to a single team still absorbs high-touch attention it no longer warrants. Neither is visible, because nothing is designed to surface movement — the segment was assigned once and nobody's job is to question it.

The fix is unglamorous: review quarterly, with defined triggers for movement in both directions, and an owner. Growth in users or business units, a change in expansion potential, a shift in support load. What matters is that moving an account between segments is a normal operational event rather than an annual re-planning exercise, because that's the difference between a model that describes your customer base and one that describes it as it was.

This is also where capacity leaks most quietly. Not in the accounts you're consciously over-serving, but in the ones that stopped warranting the service level they're still receiving.

The defensible answer

Without that thesis, segments are tidy on a slide and meaningless in execution. With it, capacity has direction, cost to serve becomes a designed number rather than an emergent one, and the CS leader has a defensible answer to the only question that matters: where is your team spending its time, and why.