← Back to all posts CS Operations

Your CS Team Isn't Broken, It's Running Without a System

I've been building and fixing Customer Success organizations for 25 years, across high-growth SaaS companies, from early-stage to enterprise. Every one of them different, but here's what I've seen at least two dozen times:

A SaaS company at $10M, $20M ARR. A CS team of 3–5 people grinding hard every day. Renewals are happening. Customers are getting onboarded. Fires are getting put out.

But churn is creeping. The board is asking questions. And when the CEO asks "which accounts are at risk right now?", the room goes quiet.

The team isn't the problem. The system is. Or more accurately, the absence of one.

What "No System" Actually Looks Like

Most SaaS companies build CS the same way: organically. You hire a CSM. Then another. Each one develops their own way of running their book. Some use spreadsheets. Some use Salesforce tasks. Some just rely on relationships and memory.

It works until it doesn't. And when it stops working, the signs are predictable:

Renewals become surprises. You find out an account is churning two weeks before the renewal date, not two quarters before.

Onboarding is different every time. Each CSM runs it differently. Time-to-value is unmeasured and inconsistent.

Health is a gut feeling. "Which accounts are at risk?" depends entirely on who you ask and what day it is.

Expansion is accidental. Upsells happen because a CSM spotted something, not because a system surfaced a signal.

Knowledge walks out the door. When a CSM leaves, everything they know about their accounts goes with them.

This doesn't mean your people aren't good. It means they're operating without infrastructure, and there's a ceiling on what any team can do without it.

The System Your CS Team Actually Needs

If your engineering team had no deployment process, no code reviews, no CI/CD pipeline, you'd call it chaos. But we accept exactly that in Customer Success, the function responsible for protecting your entire revenue base.

Here's what a CS operating system actually looks like. Over 25 years, I've developed and refined this framework across multiple SaaS environments and codified it into a framework I call CSOS, six pillars that form a complete system:

Onboarding Foundation. A repeatable process with defined milestones, time-to-value metrics, and clear handoff from sales. Not a checklist. An architecture.

Engagement Architecture. Segmentation by value and complexity. Defined touch cadences. Escalation triggers. A model that tells your CSMs what to do and when, not just "manage your book."

Health Scoring & Risk Intelligence. Quantified signals, usage, support trends, engagement, stakeholder changes, that produce a real score. Not a red/yellow/green someone updates manually once a month.

Value Expansion Engine. Defined triggers for upsell and cross-sell. CS sees expansion signals before anyone else. That shouldn't be accidental.

Renewal & Retention Strategy. A motion that kicks in 90+ days before renewal. Risk mitigation playbooks. Executive alignment triggers.

AI & Automation Readiness. The infrastructure that lets you actually scale, automated health scoring, risk alerts, engagement sequences. But only after the first five pillars exist.

Why This Matters Right Now

Two things have changed in 2025–2026 that make this urgent.

First, boards and investors have zeroed in on net revenue retention. NRR is the most scrutinized metric in SaaS right now. If your CS team can't report on it confidently and explain the drivers, you have a credibility problem.

Second, AI has made it possible for a CS team of 2–3 to operate like a team of 10. But only if the system exists first. You can't automate what isn't defined. AI amplifies whatever process you have, and if that process is "everyone does it their own way," AI just does that faster.

You Don't Need a VP of CS. You Need the System First.

The instinct is to hire a VP of Customer Success and let them sort it out. That's a $200K+ bet on one person building everything from scratch, hiring, process, tech stack, reporting, while also managing the team day-to-day.

The faster path: install the operating system first, then hire the leader to run it.

When the system exists, your VP walks into defined playbooks, working health scores, engagement models, and reporting. They spend their first 90 days optimizing and leading, not building from zero while simultaneously fighting fires.

One Thing You Can Do This Week

Ask your CS team this question:

"How long would it take you to give me a confident list of every account at risk of churning in the next 90 days?"

If the answer isn't "I can pull that up right now", you're running without a system.

That's not a failure. It's a starting point. And the fix is faster than most people think.

← Back to all posts AI + Customer Success

Why AI Won't Fix Your Customer Success Problems

I design AI-assisted CS workflows with client teams. So when I tell you that AI probably won't fix your Customer Success problems, at least not yet, I'm not being contrarian for the sake of it.

I'm telling you what I see every week when I talk to SaaS founders and CS leaders. They all say some version of the same thing: "We need AI in our CS operation. The team is stretched, churn is up, and everyone says AI can fix it."

They're half right. AI absolutely can transform a CS operation. I've built systems where a team of 3 does the work of 10. But here's the part nobody talks about:

AI doesn't fix broken CS. It scales it.

If your operation is reactive, inconsistent, and flying blind on risk, AI just makes you reactive, inconsistent, and blind faster.

The "Just Add AI" Trap

Here's what actually happens when you bolt AI onto a CS function with no foundation:

AI health scoring with no playbooks. You build an automated health score. It flags 30 accounts as at-risk. Now what? Your team has no defined playbook for at-risk accounts. No escalation criteria. No executive engagement triggers. The AI surfaces the problem. Your team stares at it.

AI-generated QBRs with no value framework. You automate QBR creation. The AI pulls usage data and builds slides. But there's no structure tying product usage to business outcomes, because nobody defined what "value realization" looks like per segment. You get beautifully formatted decks that say nothing useful.

Automated onboarding with no milestones. You set up AI-driven sequences. But there's no definition of "successful onboarding." No time-to-value metric. No handoff criteria. The automation runs, the customer gets emails, and nobody knows if they're actually getting value from the product.

In every one of these scenarios, the AI works perfectly. The system it's plugged into doesn't.

What AI Actually Needs

AI in Customer Success isn't magic. It's an amplifier. And amplifiers need signal.

Here's what has to exist before AI delivers real results:

Defined segments. AI can't decide how to engage a customer if you haven't defined what kind of customer they are. High-touch? Tech-touch? Pooled? Each segment needs a different engagement model.

Measurable health signals. AI-powered scoring requires inputs, usage data, support patterns, engagement frequency, NPS, stakeholder changes. If you're not collecting these in a structured way, there's nothing to score.

Playbooks with triggers. AI can automate the execution of a playbook. It can't write the playbook. When health drops below 60, what happens? When a champion leaves, what's the re-engagement sequence? When usage drops 30% MoM, who gets alerted?

A renewal motion with a timeline. AI can forecast risk, but only against a defined process. When does prep start, 120 days out? 90? Who owns the conversation? What triggers executive involvement?

The Right Sequence

I've been building CS organizations for 25 years and designing AI-assisted CS workflows for the last two. Here's the order that works:

Step 1: Audit. Map your current operation against a structured framework. Where are the gaps? What's documented vs. tribal knowledge? Where are you actually losing customers? This takes 2–3 weeks.

Step 2: Build the foundation. Install playbooks, health scoring, engagement architecture, renewal motion. This is the operating system, the process your team runs on. It doesn't need to be perfect. It needs to be defined.

Step 3: Add AI. Now AI has something to work with. Health scoring gets consistent instead of debated. Risk alerts fire on real signals instead of hunches. Engagement reaches the accounts headcount was never going to cover. Reporting stops eating a day a week.

Step 4: Optimize. AI gets better with data. Refine triggers. Adjust thresholds. Build new workflows. This is where an ongoing CS partner earns their keep.

The Math

A $15M ARR SaaS company at 85% gross retention is losing $2.25M in ARR every year to churn.

If AI-powered risk detection catches even 20% of that 90 days earlier, giving your team time to intervene, that's $450K in protected ARR. Every year.

But only if the system exists to act on what AI surfaces.

A $7,500 audit followed by a $12,000–$18,000 system build pays for itself the first time it saves a single enterprise renewal.

Honest Self-Assessment

Before you invest in AI for CS, answer these:

Can your team tell you which accounts are at risk right now, and why? If the answer requires a meeting or a spreadsheet scramble, you need the system first.

Is your onboarding documented and measurable? If every CSM does it differently, AI just automates the inconsistency.

Do you have playbooks for common scenarios? At-risk accounts, expansion signals, champion departures, executive escalations. If these live in people's heads, AI can't run them.

Can you report on NRR, GRR, and time-to-value with confidence? If not, AI dashboards just surface the fact that your data isn't clean.

If you answered "no" to two or more, you're not ready for AI in CS. But the foundation can be built in 4–6 weeks. Then AI becomes the most powerful tool your CS operation has ever had.

Bottom Line

AI is a force multiplier for Customer Success. But you can't multiply zero.

Build the system. Then let AI make it scale.

← Back to all posts AI + Customer Success

The Five Questions I Ask Before I'll Help Anyone Build an AI Workflow

I've written a fair amount about how AI exposes a weak Customer Success motion rather than fixing one. But the question I keep getting back is the practical one: so what do I actually do Monday morning?

Here's my honest answer. Based on what I've seen, the teams that get something real out of AI can answer five questions before they build anything. The teams that stall can't answer two of them.

These are the five I ask. You can run them on your own team in about twenty minutes on your own - you don't need me for this part.

1. Pick the process that consumes the most time. How consistently is it actually done?

Not the process on the org chart. The real one. Renewal prep, QBR prep, account research before a call, the weekly risk review, whatever your CSMs grumble about on your 1-1s or team calls.

Now peel back the onion one or two layers and ask how that process gets done when you're not watching. If three CSMs do it three different ways, you don't have one process. You have three, and none of them are written down.

Point AI at six different versions of renewal prep and you'll get six different versions faster, formatted beautifully, delivered with total confidence. Remember, formatting is not the same thing as good judgment.

A bad answer sounds like: "Everyone kind of has their own approach."

What it costs you: Eight weeks of build time, adoption dies in month two, and the team concludes AI doesn't work for them. The tool was never the problem here.

2. Can the workflow actually reach your customer context?

I've made the point before that the real CS motion lives in Slack threads, call notes, and CSM memory. What I haven't said is what that means when you sit down to design something.

Three things have to be true. The workflow has to be able to reach the context. The context has to be current enough to act on. And it has to look roughly the same from one account to the next. Miss any one of the three and you get a confident summary of nothing.

Test it on a single account this week. Just go ahead and pick one and see how much of what actually matters is reachable without asking the CSM. The gap between what's in the system and what's in someone's head is your real data readiness score.

A bad answer sounds like: "It's in Salesforce," said quickly, without checking.

What it costs you: You build for the data you wish you had, then discover in testing that half of the reasoning depends on a field nobody fills in.

3. What is your team already doing with AI today?

Ask this with no consequences attached, because the real answer is almost always "more than leadership thinks."

I'll guarantee that at least one person on your team is pasting call notes into a personal ChatGPT account, and somebody else built a prompt for QBR prep and quietly shared it with a couple other teammates. Interestingly enough, that shadow AI usage is the most useful signal you'll get. Your team already told you which task hurts most, and they voted with their own time.

It's also a governance problem sitting in plain sight, which is the next question.

A bad answer sounds like: "Nobody's really using it."

What it costs you: You miss the highest-value use case in your org because it never made it onto a roadmap, while customer data goes somewhere nobody approved.

4. If AI drafts something headed to a customer or into the CRM, who reads it first?

This is the question that is rarely asked, and it's the one that separates a demo from something you can run in production.

Human review must absolutely be part of the design. It can't be left to just a disclaimer you add to the bottom of a slide.

Get real specific here. Who approves it before it goes out? What happens when the model gets an account wrong (because you know it will) and probably on an account that matters? What customer data is allowed anywhere near it, and who decided that? Is there a clear path to go from "the AI suggested this" to "a person decided this"?

The teams that answer these fast are usually the ones who've been through a security review before. The teams that wave it off are the ones who will hit a wall two weeks before launch when your Legal or IT team finally sees it.

A bad answer sounds like: "We'll figure that out when we get there."

What it costs you: One bad summary in front of one customer and the program is finished. Not paused. Finished. You'll spend more political capital recovering from that than designing the review step would ever have cost.

5. Who is accountable for owning it after it's built?

This is where most of these efforts quietly fall into the abyss, and it's the question people skip because the answer is uncomfortable.

A workflow isn't a deliverable you receive and file away in a shoebox. Somebody has to watch it, tune the prompts when the model drifts, update it when your process changes, and answer the new CSM who asks "why is it now doing that weird thing"? Somebody has to be there to herd those cats.

If the answer is "it's me, on top of everything else I'm doing," that isn't an owner. That's a volunteer with a full calendar. Most CS leaders I know are already absorbing whatever nobody else in the org wants to handle. Adding an unfunded AI program to that pile isn't a plan, it's a recipe for failure.

A bad answer sounds like: "We'll sort that out once we see if it works."

What it costs you: It works for six weeks, then it drifts, then people stop trusting the output, then they stop opening it. Nobody announces the death. It just stops showing up in the work.

What to do with your answers

If you can answer four of the five clearly, you're in decent shape and your real risk is picking the wrong first workflow. Most teams reach for the flashiest one - Churn Prediction - when the real money is sitting in the boring one, which is the four hours a CSM burns pulling together context before every renewal discussion.

If you can't answer two of these questions, that's not bad news. That's just the actual work, and it comes before the tooling. Nobody's operating model is ready on the first pass, including my own.

Either way, the sequence is the same. Map how the work really happens. Score the candidates on value, feasibility, data readiness, risk, and whether anyone will adopt it. Design one workflow all the way through, including the review step and the owner. Test it somewhere safe. Then decide whether it earns a second one.

If you want help running that

One of my workflows, the AI Customer Risk Triage Brief, is in Rod Cherkas's CS AI Playbook Vault. You can also run it free on my site. That brief is one workflow built for a single problem. The CS AI Workflow Design Sprint is how we figure out which workflow is yours.

It's a simple process: two to three weeks, $7,500, fixed fee. We map your current process together, score three to five candidates, and I design one of them end to end: the trigger, the prompts, the review checkpoints, the owner, and a 30/60/90 plan your team can run without me. It gets built and tested inside your own environment, and I never need your customer data moved into anything of mine.

If you'd rather start alone, I built a free five-question version of what's above and only takes a minute, but it gives you a straight read on whether AI would survive contact with your operation. CS AI Readiness Assessment

If you'd rather just talk it through, take twenty minutes. Bring the process that's eating your team alive and we'll work out whether AI belongs anywhere near it.