CS Segmentation and Leveling: The Framework for Aligning Account Complexity With Career Growth

At one company I worked with, an IC4 CSM managed 40 accounts. An IC2 CSM managed 12. Nobody could tell me why the tiers existed, or what separated an IC4 from an IC2 besides tenure. Promotions turned into a popularity contest, and the leveling guide sat in a shared drive nobody opened.

At another company I joined, there was no leveling guide at all. Not even an archived Notion doc. Which meant new CSMs who had been in seat for 6 months were asking me when they'd get promoted. And let me tell you, those conversations were fun.

Ambiguity like that doesn't stay contained to promotions, either. It shows up as portfolio assignments that ignore account complexity, and it shows up as surprise performance reviews. Outside of a surprise birthday party when you're a kid, nobody past the age of 8 likes surprises, especially not when it's their own performance review.

Both companies had the same root problem: they built one half of the org design and skipped the other. A segmentation model with no leveling framework on top, or a leveling framework with no segmentation logic underneath it. Almost nobody builds both, on purpose, at the same time.

We polled the room on this exact question during last week's webinar with Vitally. 49.1% of CS and revenue leaders said they have a segmentation model with no leveling framework tied to it. Another 29.1% have levels that aren't tied to segmentation at all. Only 10.9% said their team actively uses both together for promotions. Half a framework is the norm, not the exception.

Here's the model we built at Apollo to do exactly that, including the parts most teams skip.

Customer Segmentation: The Foundation Most Teams Get Wrong

Most companies segment accounts on ARR alone. ARR is still the primary driver of tier, but it's a snapshot number, not a workload number. It tells you what an account pays. It doesn't tell you what it costs you in CSM time and skill.

We use 3 inputs, and they should run continuously off live data in your CS platform, not get reset once a year in a spreadsheet:

ARR. Still the anchor, but only 1 of 3 inputs.

Seats and users. Catches complexity ARR alone misses. A low-ARR account with 200 seats behaves like a bigger account.

Product footprint. How many parts of the product are actually live. More footprint means more surface area for a CSM to support.

Run those 3 through a set of thresholds, and you get a coverage tier that maps directly to a CSM level:

Coverage Tier

Illustrative ARR Band

Engagement Type

Typical CSM Level

SMB / Emerging

Up to ~$20K ARR

Digital / Tech Touch

IC1 - IC2

Mid-Market

~$20K - $75K ARR

Mid-Touch / Hybrid

IC2 - IC3

Enterprise

$75K+ ARR

High-Touch

IC3 - IC4

Strategic / Top Accounts

$75K+ ARR (flagged)

White Glove

IC4+

Borrow someone else's ARR thresholds and you'll misallocate CSM time before you've even started. Building your own gives Sales, Finance, and CS a shared language for the accounts, and it protects your best logos from blending into a generic Enterprise bucket where they get the same playbook as every other account over the threshold.

Enterprise and SMB are the easy ends of this. Enterprise justifies throwing people and time at it, the ARR covers the cost. SMB automates heavily with triggered comms and self-serve resources. Mid-market is the segment most teams get wrong, because neither extreme works cleanly, and it's usually where the override logic below earns its keep.

When Tier and Engagement Type Disagree

Thresholds break down at the edges, and that's fine as long as you've built the override into the workflow instead of into someone's memory. Watch for accounts that behave bigger than their ARR (heavy integration footprint, a named strategic logo, flagged for expansion in the next 2 quarters) and accounts that behave smaller (high ARR from a simple self-serve use case, minimal integration depth, flat usage despite the revenue size). Flag it, document why, and revisit at the next re-segmentation cycle.

Account Handoffs: Build the Trigger Before You Need It

The other place segmentation quietly breaks is the handoff. An account grows past its tier with no trigger defined, the CSM finds out from a Slack message after the fact, and quota and comp questions surface mid-quarter while the customer notices the transition before the team has planned it.

The fix isn't more communication. It's deciding the triggers in advance: growth or shrink thresholds set ahead of time, not judgment calls; a short overlap period where outgoing and incoming CSM co-own the account; comp and quota implications resolved before the handoff, not during it. Re-segmentation is a process. Treat it like one.

Most teams aren't there yet. We asked the room how re-segmentation actually happens at their org, and 40.8% said it comes down to manager discretion with no defined process. Another 32.7% said it's ad hoc, triggered only once an account has clearly outgrown its tier. That's 73.5% running on judgment calls after the fact. Only 10.2% have a formal review on a set cadence.

One guardrail worth building in from day 1: lock books on the quarter, not in real time. Track live where an account should sit, but don't move a CSM mid-quarter over it. At the next book cut, keep the CSM if the relationship justifies it, move the account if it doesn't. Aim for at least 80% of a CSM's book sitting inside their assigned tier. Up to 20% variance is fine when it's earned expansion, not drift.

Segmentation done well isn't just a label on a dashboard, either. It's what assigns the next task, automatically, as an account moves through onboarding, adoption, renewal, and nurture. The tier tag should route the account into the right cadence without a human sorting it by hand.

The IC1 to IC6 Leveling Framework

Once segmentation is real, leveling has something to attach to. I use a 6-tier IC framework, split into 2 bands:

Entry to Career (IC1 - IC3): focus on execution. Mastering the customer call, building domain knowledge, managing a defined portfolio reliably.

Advanced to Principal (IC4 - IC6): focus on influence. Strategic, cross-functional impact, company-wide influence beyond your own book, thought leadership inside and outside the team.

The jump from IC3 to IC4 isn't more of the same job. It's a different job. What scales across every tier is span of influence: self, peers, team, function, company. Owner mindset at IC1 means your own accounts. At IC6, it means the business.

Developing and Proficient: The Two-Stage Model Inside Every Tier

Here's the detail most leveling guides skip entirely, and it's the one that matters most for how promotion actually feels: every tier has 2 stages of proficiency, not 1.

Developing (D): actively learning the behavior. Newly promoted ICs start here, on purpose.

Proficient (P): competent and skilled. Could teach this to someone else. This is where most external hires start, and where an IC lands once they've grown out of Developing.

And here's the kicker: getting promoted to IC3 resets you to Developing in IC3, not Proficient. Promotion is the entry point, not the finish line. I've found naming this explicitly, before someone gets promoted, prevents most of the "why don't I feel ready yet" conversations that follow a promotion.

The Developing/Proficient split does double duty as a half-step promotion tool, too. It gives a strong CSM a faster, real career step without a full-tier jump, and it buys a manager more time before they have to make a full-level budget ask.

Time in Seat Is a Floor, Not a Target

Time-in-seat minimums exist to stop premature promotion asks, not to gatekeep. The ranges I use:

Transition

Minimum Time in Seat

What It's Really Testing

IC1 → IC2

6-12 months

Prove the fundamentals before asking what's next

IC2 → IC3

1-1.5 years

A full portfolio cycle, not just one good quarter

IC3 → IC4

2-3 years

Cross-functional evidence, not just tenure

IC4 → IC6

3-5+ years

Scarce by design, not by gatekeeping

How Leaders Evaluate Readiness Objectively

"Readiness" isn't a feeling. It's a file a manager can point to. That file has 3 inputs: self-evaluation (ICs rate themselves against the competency matrix first, before the manager conversation starts), evidence collection (call recordings, project artifacts, and EBR decks, not just a manager's memory of a good quarter), and cross-functional input (feedback from product, sales, or ops partners the IC actually works with day to day). Quantifiable data makes it easier for both a manager and a CSM to understand the realities of their performance, instead of making the call on vibes.

When we polled the room live on this during the webinar, 64% said demonstrated competency evidence should carry more weight than time in seat. Only 24% called it roughly equal, and 12% admitted it's still an informal gut call at their org. That's competency beating tenure 5 to 1. Tenure is the easy default. It's rarely what leaders actually want to reward once you ask them directly.

Career Mobility: Why the Ladder Isn't the Only Path

Not every senior CSM should manage people, and building 2 real tracks (not 1 ladder with a management detour) is how you keep your best ICs instead of losing them to a title they didn't actually want.

The Management Track: owns people, hiring, and team performance. Success is measured through the team's output. Right path for CSMs who want to lead other CSMs.

The IC Principal Track: owns strategic accounts, frameworks, or company-wide initiatives. Success is measured through direct, individual impact at scale. Right path for CSMs who want to go deeper, not manage.

A Principal track isn't a consolation prize. It's how you keep your best ICs from becoming mediocre managers.

The other mobility path worth building on purpose is lateral. CS to CS Operations (systems thinking and process optimization translate directly), CS to Account Management or Sales (commercial acumen and relationship depth are already there), CS to Product or Enablement (deep customer workflow knowledge becomes someone else's shortcut). Off-ramps aren't attrition. A CSM who moves internally is retained revenue for the company, just not for your team.

I've watched this play out with a real CSM on my own team, not just in theory. Noah moved into product, and it turned out to be one of the best moves the team made. He brought a live customer lens into engineering decisions that no PM could replicate secondhand. Even though in the short term, losing a great CSM is painful, in the long run, having them shift to product can return more value than keeping them in the CSM seat both for you as a business and for them in their career.

Comp should follow all of this, not lead it. Each tier maps to a defined band, not a negotiated number, and the bands should reflect market data for the role and level, not just internal history. Segmentation matters here too: an IC4 on strategic accounts and an IC4 on mid-market should sit in the same band and the same tier, with a different portfolio. And get the equity right across tiers before you launch this. Teams talk about salaries, and inheriting a team where a lower-tier CSM earns more than a higher-tier one is a painful fix to make after the fact.

Building It in Your Org

If you don't have a segmentation model yet, start there before you touch leveling. Get ARR, seats, and product footprint into 1 view, draw your thresholds, and build the override workflow for the accounts that disagree with their own tier. Only once that exists does a leveling framework have something real to measure against.

If you have levels but no segmentation, audit whether your tiers actually predict CSM workload, or whether they're just measuring tenure. If you have neither, don't try to build both perfectly before you launch either. Start with the Customer Success Leveling Guide as your baseline, not a blank page, and revise it once you have a quarter of real data.

Two more things I'd add before you start. Give whatever model you build roughly 2 quarters before you evaluate whether it's working. And talk to your CSMs while you're building it, not after. They're one of the best inputs you have for what segmentation actually feels like on the ground, and if your company already segments pre-sales territory, that split can seed your CS model instead of starting from a blank page.

Segmentation tells you how to structure the work. Leveling tells you how people grow inside it. Neither works well alone, and you don't need a perfect version of either to start.

If you're working through what this looks like for your team's size, stage, or account mix, we're happy to walk through it together. Book a time here.