BlogSeptember 14, 2026

Why Customer Success Needs an Operating System

Why Customer Success Needs an Operating System

There's a frustration I think a lot of post-sale leaders have experienced.

A QBR where you realize there isn't much new to talk about.

A health score that says the account is healthy, even though something doesn't feel quite right.

A customer that stalls, and when you look backward, it's hard to pinpoint exactly when progress stopped.

I've experienced all three.

The one that stuck with me was a health score sitting at green for months on an account that had gone quiet.

No red flags anywhere in the system.

But nobody on the team could tell you what the customer had accomplished lately, or what was supposed to happen next.

For a long time, I thought these were separate problems.

Eventually, I started to see them as symptoms of the same one.

Before the sale, progression is designed. After the sale, we mostly hope for it.

Think about the structure most companies put around acquiring a customer.

We define stages. We establish criteria for moving from one stage to another. We identify the next action. We track opportunities that aren't moving. We inspect the pipeline.

And when an important deal stalls, somebody wants to know why.

None of this guarantees the deal will close. But it gives the organization a shared way to understand where the opportunity stands, what needs to happen next, and where intervention may be required.

Then the contract gets signed.

Much of that structure disappears.

When activity replaces progression

It's not that post-sale teams don't have processes.

They do.

Onboarding plans. Success plans. QBRs. Health scores. Adoption metrics. Playbooks. Renewal processes.

There's usually plenty happening.

But activity and progression aren't the same thing.

A QBR can happen without anything meaningful changing for the customer.

An onboarding checklist can be completed without the customer experiencing value.

Product usage can increase without the customer connecting that usage to the outcome they bought the product to achieve.

And a health score can stay green while the relationship quietly stalls.

That's what bothered me about that account.

The deeper problem wasn't that the health score was wrong.

The problem was that we hadn't defined what the customer should be progressing toward.

If you don't know what should happen next, it's difficult to recognize when it doesn't happen.

So you wait.

Eventually usage falls. Engagement drops. A stakeholder stops responding. The health score changes. The renewal gets closer.

Now you know there's a problem.

But the problem may have started months ago.

What if we managed customer progression instead?

That led me to a different question.

Instead of only asking whether a customer is healthy, what if we could also ask:

Is the customer progressing?

To answer that, we have to define what progression actually means.

Once those things are defined, we have something earlier to manage against.

If an important stakeholder never becomes engaged, we can see it.

If First Value should have happened and hasn't, we can see it.

If the customer hasn't connected what they're doing with the outcome they purchased the product to achieve, we can see it.

We don't have to wait for a lagging metric to tell us the relationship has stalled.

We can see that the thing required for progression never happened.

That's a very different way to think about being proactive.

From Customer Success process to operating system

This is where I eventually started thinking beyond individual Customer Success practices.

A journey map can define the progression we want the customer to experience.

Specific plays can define what the team should do to help create that progression.

Health scoring can tell us whether the conditions associated with healthy customers are actually present.

Capacity planning can tell us whether we have enough people and time to execute the work we've designed.

And a post-sale pipeline can make that progression visible across the customer base and connect it to the revenue we're trying to retain.

These aren't separate tools anymore.

They're parts of the same system.

That matters because the alternative is asking every CSM to assemble the system for themselves.

Your best CSMs often can.

They know their customers. They recognize subtle changes. They know when to push, when to wait, who needs to be involved, and what needs to happen next.

The problem comes when you try to make that repeatable across ten CSMs, fifty CSMs, or thousands of customers.

Experience and judgment still matter.

But they shouldn't be the operating model.

Post sale deserves the same discipline

I don't think post sale should copy Sales.

Customers aren't opportunities, and customer relationships shouldn't be reduced to deal stages.

But I do think we can borrow something important from the discipline we've built before the sale.

For years, I looked at QBRs with nothing new to discuss, health scores I didn't completely trust, stalled customers, and surprise churn as different problems.

I don't anymore.

I see them as different symptoms of the same structural gap.

Before the contract is signed, we're deliberate about stages, progression, next steps, and what needs to happen to move a deal forward.

Afterward, much more depends on the experience, judgment, and instincts of the people managing the customer.

Not because they're doing anything wrong.

Because we haven't given post sale the same underlying structure we give the deal that got them there.

Once I saw that gap, I couldn't unsee it.

What would it look like if post sale had the same discipline?

Post-sale is a system, not a hope.

These ideas are the foundation of The Post-Sale Operating System.

Read the book →
← All posts