Why Most SaaS Companies Are Losing Customers in the First 90 Days — and Blaming the Wrong Thing

There's a conversation that happens after a wave of early churn that I've heard in different forms across more SaaS organisations than I can count. It usually starts with someone in a post-mortem saying: "We think there was a product-market fit issue with this segment." Or: "Sales overpromised." Or, if things are particularly uncomfortable: "The customers were actually a bad fit from the start."

I understand why those explanations get reached for. They're plausible. They're partially true often enough to feel credible. And — crucially — they point responsibility somewhere other than the team that currently owns the problem.

But in most cases, when I get close enough to the actual customer journey, the real story is simpler and more uncomfortable: the customers weren't set up to succeed. Not because the product was wrong and not because the sale was dishonest, but because no one had ever designed what the first 90 days were actually supposed to achieve — or who was responsible for getting customers there.

This is the onboarding failure that nobody wants to name directly. And it costs SaaS companies more revenue than almost anything else.

How onboarding became a feature instead of a journey

In the early years of B2B software, "implementation" was a formal project. The vendor's implementation team came in, configured the product, trained the relevant people, and handed over to the customer's internal team. It was resource-intensive and slow, but it had a defined outcome: the customer was running the product.

As software moved to the cloud and products became faster to configure, the implementation model started to compress. Implementation became onboarding. Onboarding became a wizard, a few training videos, and a "getting started" email sequence. The resource savings were real. So was the loss in structure.

At the same time, Customer Success emerged as the function responsible for customer health — which meant CS inherited onboarding almost by default. Not because CS was designed for it, but because CS was the team that owned the post-sale relationship, and onboarding happens post-sale.

The result, in a lot of organisations, is that onboarding lives in a strange middle ground. It's not the rigorous implementation project of the old model. It's not quite the customer journey experience you'd design from scratch. It's a checklist, built by whoever had time to build it, that the CSM works through with the customer in the early weeks — and which is declared complete when the boxes are ticked, regardless of whether the customer has actually achieved anything.

The three failure modes I see most often

These aren't universal. But they appear often enough to name.

Onboarding ends when the product is configured, not when the customer is successful. This is the most common failure, and it's partly a definitional problem. "Onboarding complete" in most systems means: configuration done, training delivered, go-live confirmed. What it doesn't mean — and rarely measures — is: the customer has achieved their first meaningful outcome with the product. These are completely different gates. The first tells you the vendor's work is done. The second tells you the customer is on the path to value. If you're closing onboarding at configuration, you're not measuring the thing that determines whether the customer stays.

Onboarding is designed for the average customer, not the actual one. Templates are efficient. They're also a fiction. The median customer in your CRM is a construct — a blend of different company sizes, tech stacks, internal politics, and readiness levels. Your actual customers are substantially more varied than that median. The ones who fail to realise value in the first 90 days are almost always the ones whose context diverged from the template in a way nobody flagged and adapted to. A CS Ops function worth its place builds onboarding infrastructure that's adaptable — not by building infinite variants, but by making it structurally easy for the CSM to adjust the plan to what a given customer actually needs.

The CSM handover happens too late. In many organisations, the account executive owns the relationship through close, then hands to a CSM at signature. That handover happens at the moment when customer expectations are highest, familiarity with the new team is lowest, and the work of getting the customer to their first outcome is just starting. The CSM walks into a relationship where the customer already has half the context from a conversation they weren't part of — and the first weeks are partly spent re-establishing trust and re-understanding the purchase context. This isn't inevitable. It's a handover design problem.

What good looks like

I want to be careful here not to imply there's a universal fix. But there are design principles that hold across a lot of contexts.

Define success in the customer's terms before onboarding starts. Not in yours. If the customer bought the product to reduce manual reporting time, onboarding isn't complete until they've actually run a report and noticed the difference. That's a more demanding gate — and a much more meaningful one.

Build the handover into the sales process, not after it. The best handover experiences I've seen involve the CSM in the final stages of the commercial conversation — not just getting briefed by the AE after close, but having a face in the room before the ink dries. It costs something in terms of CSM time. It pays back substantially in terms of continuity.

Track outcomes, not activities. This is where the CS Ops infrastructure matters most. Most activity data — calls logged, training sessions completed, configuration steps done — is easy to capture and weak as a signal. What you want to know is: did the customer achieve what they said they needed to achieve, and by when? Building the data model that captures that, rather than the activity that surrounds it, is the lever that actually improves early retention.

Questions worth sitting with

If you're looking at early churn rates and reaching for the product-market fit explanation, these might be worth pausing on first:

When does your current onboarding officially end, and what does "end" actually mean? Is it a date, a set of completed steps, or a customer outcome? If it's a date or a step-list, you're measuring the wrong thing.

In the last three customers who churned before their first renewal, when did the risk actually originate — and was it visible in the first 90 days? Most early churn is visible earlier than it's acted on. The question is whether the infrastructure exists to surface it.

What would your CSMs say about the onboarding process if you asked them in private? The gap between the official process and what actually happens on the ground is usually instructive — and usually known by the CS team well before it surfaces in the data.

The short version

Early churn in SaaS is often attributed to product fit or sales misalignment — but in most cases the more significant factor is onboarding. Specifically: onboarding that ends at product configuration rather than customer success, that's designed for an average customer rather than an actual one, and where the handover from sales to CS happens too late and without enough shared context. Fixing early churn requires redefining what onboarding completion actually means, building the CS Ops infrastructure to track outcomes rather than activities, and designing the sales-to-CS transition as a deliberate moment rather than an afterthought.

Where Pivotal Path comes in

Pivotal Path works with CS and CS Ops teams who are rebuilding their onboarding programmes — not from scratch, but from a close look at where the current process is losing customers and what would change if it measured the right things. If early churn is a pattern you're trying to break, get in touch

James Hayward-Zhu is the founder of Pivotal Path, a Customer Success and CS Ops consultancy working with SaaS businesses at the growth stage.