Why most CS frameworks break the moment they meet Tier 1 enterprise.

The Customer Success literature is large and growing. There are books, frameworks, certifications, podcasts, summits, slack communities, an entire conference circuit. Almost all of it, including the parts I have personally learned from, was written by people whose deepest experience is in software-as-a-service companies with hundreds or thousands of accounts and a fast, self-serve sales motion.

None of that is bad. The SaaS Customer Success community has been one of the most generous bodies of practitioner knowledge of any function in business in the past fifteen years. The challenge is that almost none of it survives contact with a Tier 1 enterprise customer in a complicated, regulated industry like payments. The framework looks fine on the whiteboard. It works for the second account you try it on. By the third, it has begun to deform. By the time you are running it on a household name with nine-figure processed volume, only the cosmetic features of the original framework are still recognisable.

I have watched this happen at three companies now. The patterns rhyme. Here is what actually breaks, and why, and what to do instead.

01. The health score collapses into noise

The health score is the totemic artefact of modern Customer Success. Red, amber, green. Engagement times utilisation times sentiment times advocacy. You build the formula, you wire it to a dashboard, the executive team is satisfied, you move on.

At the enterprise end, the health score becomes meaningless within about a quarter. Not because the formula is wrong, but because every single account has its own definition of what healthy looks like, and averaging across them produces a number that is technically accurate and operationally useless.

Customer A is processing record volumes and their CFO loves you, but they have an unresolved escalation about settlement timing in one corridor. Are they green or red? Customer B is quiet, slow, rarely engages with you, but their renewal is locked in for three years and they have just signed for an additional product. Are they green or red? Customer C just had a major incident, your team resolved it in twenty minutes, and the customer's CTO sent you a thank-you note. Are they green or red?

The honest answer in all three cases is: it depends on what you are trying to predict. If you are trying to predict churn risk, Customer A is a problem and B and C are not. If you are trying to predict expansion potential, B is a problem and A and C are not. If you are trying to predict referrals, C is the only one that matters. A single health score cannot do all three jobs, but in the SaaS framework it is asked to.

What works instead, in my experience, is not a score at all. It is a one-paragraph qualitative summary of each account written by the CSM who owns it, updated monthly, that explicitly addresses the three questions separately: where are they on renewal, where are they on expansion, where are they on advocacy. Three paragraphs across the book is more useful than three traffic lights, because it forces you to actually think about what is happening rather than tick a box.

02. Playbooks become straitjackets

The other heavily-promoted artefact in CS literature is the playbook. A documented sequence of steps to follow when X happens. At-risk playbook. Onboarding playbook. Renewal playbook. Expansion playbook. Re-engagement playbook. The promise is that playbooks let you scale a team, because newer CSMs can follow the documented sequence rather than improvising.

At Tier 1 they break because no two situations are similar enough for the same sequence to apply. The customer whose renewal looks shaky might need a price concession, or might need an executive sponsor to escalate, or might need a product change, or might need a different account team, or might just need to be left alone for two weeks while they finish a major migration. Running them through a five-step at-risk playbook produces a worse outcome than just thinking carefully about that specific customer for twenty minutes.

This does not mean playbooks are wrong. It means they have to be much smaller and looser than the literature suggests. A renewal playbook for enterprise should not be a five-step sequence. It should be a list of seven or eight questions to make sure you have asked yourself before you walk into the renewal conversation. The questions are stable; the answers, and therefore the approach, change every time.

The job at Tier 1 is not to apply the right playbook. It is to be the kind of person whose first move is to think, not to look up the playbook.

03. The QBR cadence does not survive contact with the customer

Quarterly business reviews are gospel in CS literature. Once a quarter, you present to the customer, you walk through the data, you align on the next quarter. Every CS leader has built a deck template. Every CS team runs them.

At Tier 1, the QBR has a few specific failure modes. The first is that the customer's own schedule rarely lines up with your quarter. Their product launches, board meetings, regulatory filings and reorgs do not respect Q1 / Q2 boundaries, and trying to force a 90-minute strategic review into a week when the customer is heads-down on something else gets you a polite QBR that the customer disengages from halfway through.

The second failure mode is that quarterly is the wrong cadence for most genuinely strategic conversations. Either you need to talk more often than that (during a programme launch, during a migration, during a renewal cycle), or you need to talk less often than that (a steady-state customer in year three may not benefit from being dragged into a 90-minute review every twelve weeks just because the calendar says so).

The third failure mode is that the QBR deck almost always looks inward. It is about your performance, your activity, your recommendations. The customer, very politely, finds this less useful than the literature claims. What they actually want is thirty minutes of curated insight about their own programme and their own market that they could not have got from their own internal dashboards.

The version that works, again, is less prescriptive and more responsive. A quarterly default with the willingness to move it forward, back, or skip entirely depending on what is actually happening for the customer. A deck structure that puts the customer's own data first and your activity last, not the other way around. And the discipline to cancel a QBR you cannot make useful, rather than running it because the schedule said so.

04. NRR becomes the wrong thing to chase

Net revenue retention is the headline metric in SaaS CS for perfectly good reasons. Retain plus expand minus contract minus churn, normalised to the prior period. It is a clean number that predicts company valuation.

At Tier 1 in payments, the calculation works mathematically but hides what actually matters. Expansion in payments is rarely linear. A customer might be flat on processed volume for two years, then triple it in a quarter when their new product launches. Another customer might shrink on you for two quarters because they were temporarily routing more volume through a different acquirer, then return. A third might launch a major new card programme that takes nine months to ramp.

Forcing the CS team to optimise quarterly NRR can produce some genuinely bad behaviour. CSMs start pushing for upsell conversations the customer is not ready for, because the number needs to move this quarter. They start chasing the wrong expansion opportunities because the easier ones close faster. They start firefighting the contracting customers more aggressively than is healthy, including ones who are simply going through a normal seasonal trough.

The metric that actually predicts long-term value in enterprise payments CS is something closer to a rolling twelve-month look at customer trajectory. Are they materially larger as a payments programme than they were a year ago? Are they materially more embedded? Are they materially more advocate? You cannot fit that on a single chart in a board pack, which is exactly why most CS organisations end up reporting NRR instead.

05. Segmentation creates customers nobody owns

The SaaS model of tiered customer segmentation, with high-touch for the top, low-touch for the middle, tech-touch for the long tail, simply does not map to most enterprise payments books. The book is too small for tech-touch to be a meaningful category, and the customers in it are too different from each other for tiered playbooks to make sense.

What tends to happen instead is that you segment formally on paper, then ignore the segmentation in practice. The official high-touch customer who is actually self-sufficient gets less of your time than they "should." The official low-touch customer who is quietly compounding problems gets more. You end up running by gut, then awkwardly explaining the divergence at the next ops review.

A model that holds up better, in my experience, is to abandon the static segmentation and replace it with dynamic priority. At the start of every month, every CSM names their three to five most important customer outcomes for that month, regardless of which official tier the customers are in. The leadership review is about whether those priorities make sense, not about whether every Tier 1 got their mandated number of touchpoints.

06. The honest version

None of the above means SaaS Customer Success literature is useless. The vocabulary, the concepts, the discipline of thinking about customer outcomes systematically, all of that carries across. What does not carry across is the assumption that the operating model can be standardised across the book. At Tier 1, the model has to be smaller, more flexible, and far more reliant on the judgement of the individual CSM than most frameworks admit.

If you are building a CS function for enterprise customers in payments, or any other complicated regulated industry, the practical move is to be deeply suspicious of any framework that claims to be turnkey. The good ones give you vocabulary. The bad ones give you templates. The vocabulary helps. The templates almost always have to be torn up and rewritten by the third or fourth customer.

Customer Success at this end of the market is less a discipline than a craft. Two CSMs with the same job title at the same company will run their accounts in noticeably different ways, and the best of them will be right to. The framework's job is to give them shared language to talk to each other. It is not to tell them what to do.