Defining Success Before the Sale: The CS Conversation That Usually Starts Too Late

Here's a question I find useful to ask CS teams fairly early in an engagement: "For the accounts you're currently managing, can you tell me what success looks like, not for you, but for them? Not renewal, not adoption, but the specific outcome the customer bought the product to achieve?"

The answers, when they come, tend to be one of three things. The first is a product outcome: "They're using the platform for X." The second is a metric that was in the sales deck: "They wanted to reduce Y by Z%." The third, and this one is more common than it should be, is a version of "I think so, but I'd have to check the notes from the initial kick-off."

None of those is quite right. The first conflates using the product with achieving the outcome. The second is often aspirational rather than agreed upon. The third suggests the outcome wasn't captured in a form the CS team can actually work from.

What's usually missing, when you trace back far enough, is a moment in the sales conversation where success was defined jointly: not estimated or pitched, but agreed and documented in a way that carries forward into the CS relationship. That conversation is the foundation of everything that comes after in CS: onboarding milestones, health score design, renewal conversations, expansion. When it doesn't happen, the CS team inherits a customer with ambiguous expectations and no baseline for what "working" looks like.

---

Why success definition gets left to CS, and why that's too late

The conventional view is that defining success is a Customer Success job. CS owns the post-sale relationship; CS runs onboarding; CS does the kick-off call where goals are discussed. The idea that success definition starts in the sales conversation is, in many organisations, a slightly uncomfortable one, partly because it implies that sales needs to think beyond close, and partly because it suggests a level of coordination between sales and CS that most SaaS companies haven't built.

But the timeline of the relationship makes the CS-first framing structurally flawed. By the time the CSM is having the kick-off call, the customer has already formed expectations from the sales process. They've seen the slides. They've been told what the product will do for them. They've agreed in some form to the commercial terms of the relationship. If "what does success look like for you?" is being asked for the first time at kick-off, the CS team is building on a foundation they didn't lay. And any misalignment between sales promises and CS delivery is already baked in.

The better model is to treat success definition as part of the sales process, with CS involved from the final stages. Not to have CSMs close deals, but to have them in the room when the conversation moves from "here's what the product does" to "here's what we'd need to see to know this is working for you." That conversation, done well, produces a documented, agreed-upon set of success criteria that sales can reference and CS can inherit.

---

What a defined success criteria actually looks like

This is worth being concrete about, because "define success" is vague enough to produce outputs that don't solve the problem.

A useful success criterion has three components. A specific outcome (not "improve customer satisfaction" but "reduce average first-response time in the support team from 4 hours to under 90 minutes"). A timeframe (not "within the year" but "by the end of the first quarter"). And a data source that will confirm it (not "the team will feel the difference" but "measured via the support platform dashboard, shared at the 90-day review").

That level of specificity is uncomfortable to achieve in a sales conversation, because it introduces accountability. A sales team that agrees to a specific outcome with a specific timeframe is creating a test that the product and CS will either pass or fail. That's more exposing than promising "significant improvement in your team's efficiency."

But that discomfort is precisely what makes the exercise valuable. A vague success criterion protects everyone from accountability in the short term, and produces the conversation no-one wants to have twelve months later, when the customer says "we haven't really seen the impact we were expecting" and the CS team has no baseline to respond from.

---

The handover as a designed moment

Even in organisations where success definition happens in the sales process, the information often doesn't survive the handover. The AE takes notes in the opportunity record; the CSM inherits a summary that's incomplete or biased toward what closed the deal rather than what the customer actually needs to achieve. The knowledge transfer from sales to CS is, in most SaaS organisations, one of the most consistently leaky parts of the customer journey.

The fix isn't more documentation. It's a designed handover moment. A meeting, not an email; the AE, the CSM, and the customer together; an agenda that explicitly includes "let's align on what we've agreed success looks like and make sure the CS team has everything they need to help you achieve it." That moment does several things simultaneously: it transfers context from the AE to the CSM in front of the customer (which validates the CSM's authority in the relationship), it gives the customer a chance to correct any misalignment before it becomes embedded, and it creates a shared record that both parties have committed to.

CS Ops can structure this: a defined handover template, a set of questions the AE and CSM work through together, a shared document that becomes the reference point for the first 90-day review. The structure is the part that scales; the conversation is the part that builds trust.

---

Why this matters at renewal too

The renewal conversation almost always goes better when there's a clear success baseline to refer back to. "You committed to reducing this by X%; here's what we've achieved, and here's where there's more to do" is a substantively different conversation from "we hope you've been finding value this year."

The first is a business conversation. The second is a relationship conversation. Both have their place, but the first tends to be more convincing to the people in the room who are making the renewal decision, particularly the economic buyer who may not have been in the regular CS conversations and is now being asked to approve the spend.

If success was defined at the start, the renewal case is partially built. If it wasn't, the renewal becomes a conversation about whether the relationship feels good, which is a much more fragile position to defend.

---

Questions worth sitting with

For CS leaders thinking about where success definition lives in their current process:

When was the last time a customer churned and cited "we didn't see the value we expected"? What would need to have happened at the start of that relationship for the CS team to have had a clearer answer?

In your current accounts, could you produce a written, agreed-upon definition of success for the top ten, in the customer's language, not yours? If not, that conversation is overdue.

What would need to change in your sales process for success criteria to be agreed before contract close, rather than negotiated at the first CS kick-off call?

---

The short version

CS teams inherit customers whose success expectations were set in a sales conversation they weren't part of. When success is defined for the first time at kick-off (if it gets defined at all) it's already too late: expectations have formed, promises have been made, and misalignment is embedded. A better model treats success definition as a joint sales-and-CS exercise in the final stages of the commercial conversation, with the criteria specific enough to be tracked (a clear outcome, a timeframe, a data source). That baseline becomes the foundation for onboarding, health score design, the renewal conversation, and any expansion case. The handover from sales to CS should be a designed moment that brings the customer into the conversation, not a document transfer that loses context in transit.

---

Where Pivotal Path comes in

Pivotal Path works with CS and CS Ops teams who are redesigning how success is defined and handed over, from the sales conversation through kick-off to the 90-day review. If you're looking at your current handover process and wondering where the context is getting lost, 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.