Picture a CSM’s book with thirty accounts in it. Every one of them gets the same onboarding email, the same thirty minute kick-off call, and the same quarterly check in, whether they are a solo developer testing the free tier or a six figure enterprise account that migrated over after three years on Pro. One coverage model. One CSM experience, regardless of what the account actually needs.
That was the setup Paul Staelin inherited when he became CCO at Vercel. Enterprise gross dollar retention was sitting below eighty percent, and the reason wasn’t a bad product. It was that CS had one motion, a light guided tour built for solo developers kicking the tires, and it was being applied to companies that had just signed real contracts with real stakes attached.
This is the trap almost every PLG company eventually walks into. The relationship based playbook that CS teams have run for fifteen years assumes a CSM knows the buyer, the champion, and the business case before day one. In a PLG motion, half of that context doesn’t exist. The account showed up, put in a card number, and started shipping. Usage is the only story anyone has, and most CS teams are still reading it with tools built for a world where the relationship came first and the product came second.
The Old Playbook Assumes You Already Know the Buyer
Traditional CS runs on a handoff. Sales talks to the champion, learns the business case, and passes a file to a CSM who picks up the relationship where sales left off. The whole system, from kickoff calls to quarterly business reviews, assumes there was a conversation before the contract was signed.
PLG accounts frequently skip that conversation entirely. Someone on an engineering team found the product, tried it, and expanded usage on their own schedule, in their own order, for reasons nobody on your team ever heard out loud. There is no champion mapped, no discovery call transcript, no sense of what business outcome this account is even chasing. The only real signal is what the product logs show them doing.
Teams that try to force the relationship playbook onto these accounts end up with CSMs doing the same generic welcome tour for a two person startup and a company that just wired six figures. Both get equally little, because equal coverage is the only rule anyone has agreed on.
One Coverage Model Breaks the Moment You Go Upmarket
The fix isn’t more empathy. It’s structure. Once PLG accounts start migrating into enterprise contracts, a single coverage tier stops making sense, because the accounts stop being similar to each other.
Paul Staelin, now Chief Customer Officer at Relevance AI, spent two years rebuilding exactly this at Vercel. He described it on the Across the Funnel Podcast:
“We had at the time, CSMs all had equal books. There was one coverage model. If you bought Enterprise, you got the one CSM experience, which was again, very light and very technical.”
His team split coverage by tier instead of treating every logo the same way. High touch accounts got real one to one attention. Mid touch accounts got a lighter but still human cadence. Everyone else went into a digital motion driven by usage data and health scores rather than scheduled calls. Enterprise GDR moved from the low seventies into the high eighties within eighteen months, and eventually settled near ninety.
The lesson isn’t that PLG accounts need less care. It’s that the care has to match the account, and the only reliable way to sort accounts at that scale is usage data, not a CSM’s gut feeling about who seems important.
Retire the Relationship Playbook, Not the Relationship
None of this means relationships stop mattering. It means the relationship gets built differently and at a different point in the account’s life. In a sales led motion, trust gets built before the contract, in discovery calls and negotiations. In a PLG motion, trust gets built after, once the product has already proven itself and the account is deciding whether to expand.
That changes what a CSM is actually for. Staelin uses a soccer analogy for this that lands better than most frameworks do: the account executive is the striker, brought in to close an expansion opportunity once one exists, while the CSM spends most of the game in midfield, setting up chances the striker only gets to take a few times a match.
That midfield work is where usage data actually earns its keep. A CSM covering 100 digital tier accounts cannot personally track who is ramping and who is stalling. A health score built on deployment, engagement, adoption, ROI, and sentiment can watch all of them at once, and tell the CSM exactly which ten accounts in their book are worth a real conversation this week.
The Signals That Actually Predict Expansion
Not all usage data is equally useful, and this is where a lot of PLG playbooks fall apart. Login frequency and seat counts feel like signals, but they mostly tell you an account exists, not that it is about to expand or about to leave.
Lincoln Murphy, co-founder of Extensible Agents, ran customer success at ListKit through this exact transition and laid out why usage gets harder to interpret the longer an account stays. He said this on the Across the Funnel Podcast:
“The problem is, from a business standpoint, that’s usually where our customers start doing things that are unique to the customer. Their usage patterns are very unique to them, versus onboarding, which is very normalized.”
His framing splits adoption into stages. Breadth adoption is everybody on the platform doing the basic things in roughly the same order, which is exactly why onboarding can be systematized. Depth adoption is where accounts start diverging, using different features for different reasons, and that’s the stage where a generic playbook stops telling you anything useful. The signal worth building triggers around isn’t whether an account is active. It’s whether an account is moving from breadth into depth, and which specific features are pulling them there.
This is also the stage where customer health scores built on raw activity counts tend to fail. An account can be logging in every day and still be at real risk, because daily logins measure habit, not whether the account is getting closer to the outcome that justifies renewal.
Building the Trigger System
Once you know which signals matter, the next problem is operational. Someone has to actually watch for them and act, and no CSM covering a hundred accounts can do that by memory.
Emily Maxie, Chief Growth Officer at Firm360, runs into the other side of this tension. Firm360 sells to accounting firms, a segment that needs a genuinely complex product, and she put the tradeoff plainly on the Across the Funnel Podcast:
“The more robust a software is, the less self-serve it becomes.”
That’s worth sitting with before building a trigger system. Not every product can or should push toward pure self-serve, and forcing usage-only coverage onto a genuinely complex product just moves the relationship failure earlier in the lifecycle instead of removing it. What she described building instead was a hybrid: platform usage data feeding expansion conversations, with a CS team trained to notice which plan an account is on and flag upsell candidates directly, because the data alone doesn’t know what a customer’s plan entitles them to.
The practical version of this is a set of playbook triggers built on top of a shared data layer that combines product usage with CRM and support context. A usage drop of a defined size fires a retention play. A feature adoption milestone fires an expansion play. An account crossing from breadth into depth adoption gets flagged for a real conversation instead of an automated nudge. None of this requires more headcount. It requires the signals to be defined once and wired to run automatically, which is the actual job a platform like Hyperengage is built to do, sitting underneath the CS team rather than replacing it.
Segment by Use Case, Not Just Contract Size
Most coverage models still tier accounts by ARR, and ARR is a weak proxy once usage data is available. Two accounts paying the same amount can be doing completely different things with a product, which means they need completely different plays.
Staelin’s team at Vercel found that use case, not company size or industry, was the strongest predictor of what an account needed from CS. A marketing site, a production application, and an e-commerce storefront all generate different usage patterns even at identical contract values, and lumping them into one segment just averages away the signal that actually matters. Segmenting by what an account is actually building, rather than what it pays, is what makes a usage-based health score predictive instead of decorative.
What to Build First
Teams reading this and trying to figure out where to start don’t need all of it at once. The sequence that worked at Vercel, and shows up in some form at most companies making this transition, starts with tiering. Split accounts into at least two coverage levels before building anything else, because a single model applied at scale is the actual root problem, not a missing feature.
From there, build a health score around the handful of signals that predict expansion or churn for your specific product, not a generic template borrowed from a vendor’s default dashboard. Then wire the triggers: usage drops, adoption milestones, and use case shifts should all fire a defined play, not just an alert nobody reads. Retention work that depends on a CSM remembering to check a dashboard doesn’t scale past the first hundred accounts.
Conclusion
PLG doesn’t eliminate the need for relationships. It moves the moment they matter most, from the start of the account to the point where usage shows real commitment, and it makes usage data the only reliable way to know when that point has arrived. The CS teams getting this right aren’t the ones automating people out of the job. They’re the ones building the coverage tiers, the health scores, and the triggers that tell a CSM exactly where to spend the ten conversations they have time for this week, instead of spreading the same thirty minutes across every account regardless of what it actually needs.
