Churn doesn’t start when the customer leaves. It starts the day they signed.
AI & Automation

Churn doesn’t start when the customer leaves. It starts the day they signed.


Let’s start with an uncomfortable truth

A sale doesn’t end when the customer signs. It ends when they renew. Or, if they don’t renew, when they disappear.

Everything that happens between those two moments is post-sale. And most SaaS companies manage it as if it were an administrative detail between departments.

Churn doesn’t start when the customer says they’re leaving. It starts much earlier, at the moment a salesperson closes a contract and what they promised doesn’t reach the team that has to deliver it.

That moment—the handover from Sales to Customer Success—is the most critical point in the customer lifecycle. And it’s also the most ignored from an operational design perspective.



What’s lost when the handover fails

Most companies treat the handover as a formality. A deal is moved in the CRM, a quick call is made, or CS directly receives an email with the contract attached.

And with that, supposedly, the customer is already “handed off”.

The problem is that at that moment things get transferred that no CRM captures: the customer’s real expectations, the verbal commitments made during negotiation, the objections that were never resolved but that the customer signed off on anyway, and the internal political context of that company: who holds real power, who will obstruct the implementation, who measures success.

When that context doesn’t arrive, CS starts out blind.

The cost isn’t abstract. A poorly designed handover delays time-to-value by three to eight weeks. In companies with annual contracts, that means the customer reaches the first renewal without having yet achieved what they purchased. And a customer who renews without having seen value isn’t retained: they’re waiting for the right moment to leave.



The five failures that always recur

Before designing the system, you need to name the problem precisely. These are the five failures that consistently appear, regardless of company size or industry.

Failure 1. Sales promised something that doesn’t exist, or not within the agreed timelines.

Not always out of dishonesty. Sometimes out of lack of product knowledge, sometimes due to closing pressure, sometimes because the customer asked something in the demo and the salesperson answered with what they believed to be true. The result is the same: CS inherits an expectation it can’t meet.

And when it comes to light, the customer doesn’t perceive that Sales made a mistake. They perceive that the company failed them.

Failure 2. The customer’s context wasn’t passed on, or arrived incomplete.

There’s information that exists in the salesperson’s head and is never written down anywhere: why the customer really bought, which alternative they ruled out, what internal pressure they have to show results, who in their company is skeptical about this purchase.

When CS doesn’t have that context, it starts the relationship from zero. It asks questions the customer already answered during the sale. And the customer perceives the worst: that the company doesn’t communicate internally.

Think about it from the outside. You call customer service at your phone company. You explain your problem. They transfer you to another department. You tell the same thing again. And again. After 20 minutes repeating your problem four times, how do you feel? Well, the same thing happens with your SaaS customer when the handover fails.

Failure 3. The customer doesn’t know the handover has happened.

Suddenly, the person with whom they had built trust for months stops showing up and someone new appears who knows nothing about them. No one explained that this was going to happen.

This failure may seem minor. It isn’t. Trust in a commercial relationship is fragile in the first months, and an uncommunicated transition generates exactly the opposite sensation to what you need at that moment: that the company is organized and knows what it’s doing.

Failure 4. CS doesn’t know which sales arguments convinced the customer.

A customer may have bought the same product as a hundred other customers, but what convinced them was a specific promise about efficiency, or a comparison with their direct competitor, or a demo of a particular feature.

If CS doesn’t know that, they can’t reinforce it. They can’t connect the initial onboarding milestones with what the customer already valued. They can’t speak their language from day one.

Failure 5. There’s no standard handover format.

Each salesperson does it differently. The quality of the handover depends on who does it, not on how the process is designed. CS can’t predict what they’ll find when they receive a new customer. And the company can’t improve the process because there is no process: there are scattered individual practices.



What these five failures have in common

None of them is a problem of attitude or talent. They’re design problems.

The most visible symptom — which is usually CS’s complaint about Sales or Sales’ complaint about CS — hides the real problem: the absence of a shared system.



What a handover should actually transfer

A mature handover doesn’t transfer an account. It transfers the necessary context so the company can continue the relationship with the customer without breaking the trust built during the sale.

When the handover is understood only as “passing a customer from Sales to CS”, it’s reduced to an administrative task. But the customer doesn’t experience that transition as an internal change of ownership. The customer experiences a single experience with a single company.

That’s why what’s transferred in the handover isn’t just information: it’s continuity.

A well-designed handover should transfer five critical layers.

Churn doesn’t start when the customer leaves. It starts the day they signed.
  • Context. Why the customer bought, what problem they were trying to solve, which alternatives they evaluated. Without context, CS starts the relationship by repeating questions that the customer already answered.
  • Expectations. Everything the customer believes will happen after signing. Some are in the contract. Others were mentioned in a demo, hinted at during negotiation, or assumed by the customer without anyone correcting them. Those are the ones that generate conflict.
  • Risks. The signals that appeared during the sale and that predict adoption, implementation, or renewal problems. For Sales, many of those signals are noise. For CS, they’re critical information.
  • Ownership. When Sales stops being the main contact, when CS assumes ownership, who has the authority to stop the process if critical information is missing. Without this layer, the transition remains ambiguous.
  • Continuity. The result of the four previous layers. When they work, the customer doesn’t feel a break. They feel that the company remembers what was discussed, understands why they bought, and has a clear plan to take them to first value.

Most companies transfer the first layer. Some transfer the first two. Almost nobody transfers all five.



Why almost no one reaches all five

Because a well-designed handover isn’t a document. It’s a system.

And a system requires three things that most SaaS companies don’t have in place:

A standard format that all salespeople fill out in the same way. Without this, nothing can be improved because there’s no baseline.

A validation system where CS has real authority to condition or block a customer’s activation. If CS can’t say “this handover isn’t ready,” the standard format becomes an empty formality.

An integration with the rest of the post-sale system: with onboarding, with product, with support, with renewal. Without that integration, the handover is an isolated improvement instead of a real lever.

These three layers are built in order. You can’t skip them. A company that tries to implement a unified information system before having a documentation culture produces an empty tool.



When the system truly works

The real indicator that the system is working isn’t the metrics. It’s something subtler.

It’s when Sales starts asking better questions of customers during the sales process. When the salesperson asks about the success metric, about absent decision-makers, about the internal context. Not because CS asks for it later, but because they know that information will be relevant.

At that point, the system stops being a control between two teams and becomes a different way of selling.

That’s the real transformation. And it’s what makes the system sustain itself effortlessly after the first six months.



One final thought

The handover isn’t an administrative task between Sales and CS. It’s a test of operational architecture. It shows whether the company knows how to turn what it sells into what it delivers, what it delivers into value, and that value into renewal.

When the handover fails, the customer feels fragmentation.

When it works, the customer feels continuity.

And in B2B SaaS, continuity is one of the most invisible — and most profitable — forms of retention.



If you want to go further

What you’ve just read is the diagnosis and the concept. The full framework includes the minimum viable document that Sales must fill out, the traffic-light validation system, the seven specific types of red flags that predict churn, the maturity model to know where to start, and the implementation plan to roll it out without the team abandoning you along the way.

If you recognize these failures in your company and want to design the system, write to me. I’ve built this system in real companies and I know exactly where the implementation breaks.


In the newsletter I share frameworks, real decisions and how to design client systems that actually work.