Onboarding Ends at Value, Not at Go-Live

Somewhere in most SaaS implementations there is a moment that feels like the finish line. Configuration is done. The integration passes its tests. Training was delivered to fourteen people, nine of whom attended. Someone posts in the channel that the customer is live, and the project moves to the closed column.

Go-live is a real milestone. It just isn't the customer's.

Onboarding, in Customer Success, is the stretch of the relationship between the signature and the first time the product verifiably does the thing the customer bought it for. Not the first login. Not the training certificate. The thing. Almost every onboarding problem I've watched up close traces back to a team that quietly moved that finish line somewhere easier to reach.

The handoff is a document, not a meeting

Onboarding starts with a transfer. Sales knows things about this customer that Customer Success needs and cannot reconstruct later. The handoff is where that knowledge moves, and in most companies it moves badly, because it happens in a thirty-minute call and then lives in one person's memory.

At minimum the transfer should carry the business problem the customer is trying to solve, the use cases that were promised, who the stakeholders are, what measurable outcomes were agreed, the commercial scope, the technical dependencies, the risks that were visible during the sale, and the time horizon the customer has in their head. None of that is interesting to read. All of it is expensive to rediscover in week six, usually in the same meeting where you find out the executive sponsor left.

A handoff that produces "they want to improve efficiency" in a CRM field is not a handoff. It's paperwork.

Exit criteria are the whole argument

Here is the strong opinion of this chapter: the most consequential sentence in a Customer Success operating model is the one that defines when onboarding ends, and most teams have never written it down.

"Implementation complete" is the default, and it is a vendor condition. It can be satisfied in full without the customer having received anything. Stricter exit criteria ask for observable things instead: the target group of users is genuinely active, a key workflow runs end to end, the data that workflow depends on is flowing, someone on the customer side can operate it without you in the room, and an agreed first business outcome has been seen.

That last criterion does the real work, and it is the one that gets negotiated away. It requires naming the outcome early, which means the outcome conversation has to happen before implementation rather than during the first review. Teams that skip it end up with implementations that complete into a void: configured, launched, and quietly unused by week six, with a green status and a closed project.

Time to value, and the temptation to cheat it

Time to value, usually shortened to TTV, is the interval between an agreed start and the first verified value. It earns its place in an onboarding dashboard because it punishes ceremony. You cannot improve it by holding more kickoff calls.

It also has a gaming problem, and the gaming starts with the word value. Gainsight's own guidance on the metric notes that organizations measure TTV from purchase to first login, to onboarding completion, to a first value milestone, or to full implementation. Four conventions, one name. Which is a polite way of saying that comparing TTV across companies is mostly decorative.

The fix is not an industry standard. It is honesty per customer: decide what the first moment of real value looks like for this specific account, write it down before the clock starts, and measure to that. It is the same discipline as writing the denominator down for any other number you plan to report. If TTV improved forty percent because the definition of value moved from "workflow running in production" to "kickoff held," nothing got faster.

There is reason to believe the metric responds to actual work. Gainsight redesigned its own implementation process and reported cutting average time-to-launch from thirteen weeks to four. Drata, in a 2026 Gainsight Pulse session, reported a 55% reduction in time to value using in-app checklists, product walkthroughs and just-in-time education, with more customers reaching value inside the first thirty days. Both are directional rather than conclusive. One is a vendor describing its own process, the other is a customer presenting at that vendor's conference, and neither is a controlled study. What they do suggest is that onboarding friction is an operational problem with operational fixes, not a fact of nature.

The sequence, and where it breaks

Written out, an onboarding sequence that holds up runs roughly like this: outcome alignment, stakeholder map, implementation plan, configuration and integration, enablement, activation, first verified value, adoption plan, onboarding exit. Activation is worth defining because it gets used loosely. In product analytics it means a new user or account reaching a specific behavior that is plausibly connected to value. Reaching a milestone, not opening the app.

Two stages get skipped more than the rest, and they happen to be the first and the last.

Outcome alignment gets skipped because it feels like repetition. Sales already discussed it, the deck had a slide, everybody nodded. But the promise the customer bought is the first link in the chain that every later link depends on, and a handoff document is not the same thing as a shared written objective with an owner and a date. GitLab publishes its success-plan structure for exactly this reason: objectives, owners, timelines, verifiable outcomes.

The onboarding exit gets skipped because by that point everyone is tired and the account looks fine. This is also the stage where health scores mislead most, because during implementation there is no verified value to score yet. A health score weighted for the implementation phase should lean on onboarding milestones and technical readiness, and it should get re-weighted toward verified value the moment onboarding is supposed to be over. If it never gets re-weighted, the account stays green on the strength of work that finished weeks ago.

What a clean onboarding exit actually produces is small and specific: a named value moment that happened, a group of users doing the workflow, a customer admin who can operate the product, and an adoption plan for the next ninety days. That is the point at which the relationship can move from implementation to adoption without pretending.

Onboarding is where the chain gets its first real test. A promise was made during the sale. The capability exists in the product. Adoption has to happen inside the customer's actual work, outcomes have to follow from that adoption, and value has to be visible enough that someone internal would defend the spend. Retention and growth are the consequences, not the plan. Onboarding does not deliver the whole chain. It delivers the first verified link, and if it ends before that link exists, everything downstream is running on hope. Hope does not show up in GRR.