Building CS Before You Have CS Ops: What to Do First

There's a gap that a lot of growing companies fall into. They have a customer success team (two, three, five CSMs) doing genuinely useful work. The founder or CS leader has read the literature, knows what good CS Ops looks like, and understands that the team needs health scoring, structured playbooks, segmentation, and the rest of it.

And then there's the reality: this is a five-person team with one shared CRM login and a spreadsheet for health tracking. There is no CS Ops function. There may not be one for another twelve months. What do you build first?

This is a practical question, and I want to give a practical answer, not a checklist of everything mature CS Ops covers, but an honest prioritisation for the pre-scale stage.

---

What pre-scale CS Ops looks like

Before you have a dedicated CS Ops function, the CS Ops work falls to the CSMs themselves, the CS leader, or, increasingly, a capable generalist who has half their time in CS and half somewhere else. That's fine. The mistake is trying to build everything a mature CS Ops function would own, all at once. The return on effort varies dramatically across CS Ops capabilities, and at pre-scale, sequencing is the thing that makes the difference.

Here's the order that tends to produce the most impact per unit of effort at the 2 to 10 CSM stage.

---

First: know who's at risk

Before you can do anything useful with your customer portfolio, you need a working definition of "at risk", and a way to identify which accounts match it. This does not require a sophisticated health score model. It requires answering one question: what are the three signals that, in your experience, most reliably predict that a customer is going to churn?

For most SaaS businesses, the honest answer is something like: usage decline over the last 30 days, no executive sponsor contact in 90 days, and less than half the contracted team onboarded. Whatever your version is, write it down, apply it to your current portfolio, and produce a list. Review that list weekly.

This is not a health score. It is the thing you build before you have a health score, and it does most of the same work for a small team. A weekly "who's at risk" conversation in the CSM team, structured around a few agreed signals, generates better outcomes than waiting until you have the tooling to do it properly.

---

Second: write down the renewal narrative for every account

This is tedious. It is also extremely high-value. For each customer in your portfolio (or at least the ones above a meaningful ARR threshold), write a three-paragraph summary: why they bought, what they've achieved since, what the plan is for the next twelve months.

This forces a reckoning with the accounts where the narrative doesn't hold together, where the "why they bought" and the "what they've achieved" are disconnected, where the next twelve months don't have a plan. Those disconnects are your at-risk accounts, even if the health score data looks fine.

This exercise also produces the artefact you need for the renewal conversation: a clear business narrative rather than a product usage report. And it tells you, in aggregate, whether your portfolio has a story to tell or a problem to solve.

---

Third: build a basic segmentation

Even at pre-scale, not all accounts deserve the same CSM time. A simple segmentation (high-value accounts that need regular engagement, mid-value accounts that can operate on a structured lighter-touch, low-value accounts that should be primarily digital) is achievable with a spreadsheet and a day of work.

The output: a list of your top accounts by value, flagged with their current risk status, with a defined engagement rhythm for each tier. Not a sophisticated system. A shared document the team reviews weekly. This is the foundation everything else is built on.

---

Fourth: agree on a playbook for the situations that keep coming up

Don't build a comprehensive playbook. Build a decision guide for the three situations that your CSMs encounter most often where the right answer isn't obvious: the customer who has gone quiet, the account where usage is declining but there's no escalation yet, and the customer who says they're happy but the health signals say otherwise.

For each situation: what does the CSM check first, what are the two or three response options, and what does each option signal about the account? This is not a twenty-page document. It is a one-page reference that a new CSM could read in five minutes and a experienced CSM can sanity-check their judgment against.

The value of writing this down is that it makes the team's judgment explicit and discussable. When a CSM makes a call on a difficult account, there's a shared framework to evaluate it against. That makes team conversations more useful and feedback more specific.

---

Fifth: fix the handover

If you're at pre-scale, the sales-to-CS handover is almost certainly not as good as it should be. The most impactful single-page template you can build is a structured handover note: what the customer bought, what they're trying to achieve, what was promised, what the implementation timeline is, and who the key contacts are.

This is not a CS Ops build. It is a one-hour conversation between CS leadership and Sales leadership, followed by a template that goes in the CRM. The payoff is immediate: CSMs stop doing shadow discovery calls to learn what was actually sold. Kickoff calls become more useful. The first-ninety-days experience improves.

---

What to deprioritise until you're ready

Some things are genuinely not worth building at pre-scale:

Sophisticated health scoring. A complex health score model requires clean data, consistent CRM inputs, and regular recalibration. At pre-scale, you don't have the data quality or the operational rhythm to make it work. The weekly risk list built on three agreed signals does most of the same work with a fraction of the overhead.

Formal expansion processes. At pre-scale, expansion is a relationship and a conversation, not a process. Build the relationship depth first. The process for surfacing and managing expansion opportunities can be added when you have the volume to justify it.

Automated nurture sequences. Tech-touch automation is powerful at scale. At pre-scale, you don't have the customer volume to need it, and you have the CSM time to do the work manually. Automated sequences built on insufficient data and without the segmentation to target them well often do more harm than good.

---

The pre-scale CS Ops mindset

The pre-scale stage is not about building everything. It's about building the three or four things that most change the trajectory: the stuff that prevents the accounts you're about to lose, makes the renewal conversation easier, and gives the team a shared framework for making hard calls.

The investment at this stage is mostly time and clarity, not tooling. A weekly risk review with an agreed definition of "at risk." A one-page renewal narrative per high-value account. A basic segmentation with defined engagement rhythms. A decision guide for the hard situations. A handover template.

These things scale. When you eventually hire for CS Ops, the infrastructure they build sits on top of the clarity you've established at this stage, not from scratch.

---

Questions worth sitting with

1. If you asked each of your CSMs today to name the three accounts in their portfolio most likely to churn, would they agree? What would explain any disagreement?
2. Do you have a written renewal narrative for each of your top accounts, not a health score, but a business story?
3. When a CSM makes a difficult call on a hard account, what do they base it on? Is there a shared framework, or is it individual judgment?
4. What does the sales-to-CS handover currently look like? What's the most important piece of information that doesn't reliably make it across?
5. If you prioritised one CS Ops capability to build this quarter, what would produce the most impact on retention?

---

Where Pivotal Path comes in

Pre-scale CS Ops design (working out what to build first, in what order, with what tools and what available time) is one of the most time-compressed and highest-stakes engagements we work through with clients. We help small CS teams build the infrastructure that prevents the most expensive churn, establishes the practices that scale, and makes the case for the next CS Ops hire when the volume justifies it.

If you're trying to work out what to build first, we're happy to have that conversation.

---

The short version

• At the 2 to 10 CSM stage, you cannot build everything a mature CS Ops function would own. Sequencing is what matters.
• Start with: a working definition of "at risk" and a weekly review; a written renewal narrative for high-value accounts; basic segmentation with defined engagement rhythms; a one-page decision guide for the hard situations; a handover template.
• Deprioritise: sophisticated health scoring, formal expansion processes, automated nurture sequences. These are scale capabilities that require clean data and volume you don't yet have.
• The pre-scale stage is about clarity more than tooling. The frameworks you establish here become the foundation CS Ops builds on later.