7 October 2026James Hayward-Zhu6 min read

Building customer success in a company that doesn't think it needs it yet

A paper collage on green. A vintage halftone figure in overalls kneels and plants a small green sprout in cracked ground, while other cut-outs look away. Torn scraps, a coffee stain, a modern photograph and an engraved shrugging man surround the scene with biro arrows and ticks.

There's a type of client engagement that starts with an unusual brief. A CS leader has joined a SaaS business (Series A, maybe Series B) where the product team is strong, the sales team is growing, and customer success as a distinct function has never formally existed. Account managers handle renewals. Founders handle the top accounts. Support handles everything else. And the prevailing view (unspoken but pervasive) is that what CS does is basically what everyone already does, just with a different job title.

Starting a CS function in that environment is a different problem from scaling one that already exists. The operational challenges are real: no process, no CRM hygiene, no defined onboarding path. But the harder challenge, the one that determines whether the function survives the first twelve months, is the political one: proving that CS is worth building at all.

What you're actually up against

In a company where CS doesn't formally exist, its absence is usually justified by one of three narratives:

"Our product sells itself. Customers either get value or they don't." This is the product-first company that has confused the quality of what they've built with the work required to help customers realise that quality. Good products still need adoption work. Good products still have customers who use them poorly and then blame the product.

"Our salespeople handle the relationship." In smaller companies, this is often literally true: account executives manage renewals and expansion and are incentivised to keep customers happy. What this misses is that the work required to keep customers successful is different from the work required to close new business, and the skills and time demands don't overlap as cleanly as the narrative suggests.

"We can't afford a dedicated function yet." Sometimes this is financially accurate. More often, it's a prioritisation argument dressed as a resource argument. The real question is what the cost of not having CS is: in churn, in expansion foregone, in CSM-sized workloads distributed across a team not built for it.

The internal selling problem

Before you build the function, you have to make the case for it. That's not a CS challenge. It's a business development challenge, directed inward.

The case has to be commercial. CS teams that position themselves as "the voice of the customer" or "the relationship function" are making an argument that resonates with people who already believe in CS and nobody else. The argument that lands with a CFO or a CEO who isn't yet convinced is a revenue argument: how much recurring revenue is at risk because customers aren't adopting the product properly? What's the churn rate in the first twelve months, and what portion of that is preventable with structured onboarding? What's the expansion opportunity that's being missed because there's no motion for identifying and acting on upsell signals?

Getting the data to make that argument requires some detective work before the CS function formally exists. Pull the churn data that does exist. Look at which customers churn early and what they have in common. Talk to the sales team about the accounts they're worried about. Map the current onboarding journey (who does what, how long it takes, where customers get confused), even if it's done informally.

The goal is to show that the function is solving a defined problem, not creating infrastructure for its own sake.

Building in sequence when the case is made

If the internal case lands and the function gets approval, sequencing matters. The first thing to build isn't usually the thing that feels most urgent.

The most urgent thing is usually the at-risk account list: the customers who are close to churning and need attention now. But the most important thing to build first is the foundation that makes CS sustainable past the first CSM: the definition of what success looks like, the onboarding path, the signal for when a customer needs intervention.

Without that foundation, the first CS hire spends all of their time reacting. They'll handle the current crises competently. But they won't build anything that scales, because everything they do is bespoke: each account managed from instinct rather than from a defined process.

The sequence that works: spend the first thirty days on the definition work (what does customer success mean here, what does good look like at ninety days, what are the three signals we'd use to identify an at-risk account?), and use that to structure both the at-risk triage and the new customer onboarding. Even imperfect answers to those questions are more valuable than excellent improvisation.

The credibility problem

New CS functions get measured on what they produce, which means the first six months matter more than they should. The team is under scrutiny from stakeholders who weren't convinced in the first place, and a handful of early failures (an account that churns despite CS's involvement, a QBR that doesn't land, a tool that gets bought and not used) can undermine the case for the function entirely.

Managing that credibility risk isn't about performing confidence. It's about picking the right early wins. Don't take on the three most complex accounts in the portfolio as the first three. Find the accounts where you have the best information, the most engaged contacts, and the most straightforward value story, and build the process there, where success is most achievable and most visible.

The accounts where you can demonstrate "here's what we did, here's what changed, here's the renewal that happened as a direct result" are the internal case studies that sustain the function through the messier middle period.

What CS Ops looks like at this stage

In a company that's just starting to build CS, "CS Ops" is less a function and more a hat the CS leader or first CS hire wears. It's the documentation discipline: writing down the process you just did so you can do it again. The CRM hygiene: building the fields and views that make the portfolio manageable. The reporting structure: figuring out what metrics tell you whether the function is working and making sure those are visible to the right people.

None of this needs to be elaborate at first. A shared doc, a CRM view, a monthly summary email to the stakeholders who approved the function. The investment required is low; the credibility payoff is real.

Questions worth sitting with

If you had to quantify the current cost of not having a formal CS function (in churn, in expansion foregone, in time spent by non-CS people on CS work), what would that number be?
Who in the business needs to be convinced before CS gets real investment, and what does the argument look like to them specifically?
What are the two or three early wins that would shift the internal narrative from "this might be useful" to "this is clearly working"?

The short version. Building CS in a company that doesn't yet think it needs one requires two parallel workstreams: the internal commercial case (which has to be a revenue argument, not a culture argument) and the sequenced operational build (foundation first, crisis response second). The first six months are a credibility play as much as a delivery play. CS Ops discipline from day one (documenting process, building CRM visibility, reporting clearly to stakeholders) is what converts early sceptics into supporters.