Onboarding is taking too long because nobody is accountable for the date. Not the salesperson, who is measured on the signature. Not the customer success manager, whose job description almost certainly does not mention go-live. Not the customer, who has a day job. The date slips because it belongs to everyone, which is the same as belonging to no one.
That is not a figure of speech. We read 76 live Customer Success Manager postings across 13 software companies. Not one of them mentions go-live or launch. Two mention a milestone. The event the customer is counting down to appears in zero job descriptions for the role closest to them.

The split underneath is worse. 43% of those postings mention onboarding and 37% mention implementation, but only 8% mention both, and 28% mention neither. Each role is described as owning one side of a seam, and almost nobody is described as owning the join. Across the full set of 609 postings at 28 companies, not a single role is titled implementation manager or onboarding manager.
So when the go-live date moves, there is usually no one whose performance review notices.
What this page is for
Most published advice on this topic explains how to run onboarding well. That is useful before you start and useless once you are three weeks behind. The guides ranking highest for this question are written by onboarding software vendors, their figures are mostly unsourced vendor claims, and the leading one offers no recovery steps at all for a date that is already slipping.
This page assumes it is already slipping.
The four ways a date actually moves
Slippage is not one problem. The recovery is different in each case, so the first job is naming which one you have.
The kickoff happened before the prerequisites existed. The contract was signed, somebody booked a kickoff for the following Tuesday, and the data export, the technical contact and the integration scope were not ready. Nothing was ever on schedule. The date was wrong the day it was set.
The customer has tasks and no owner. A task assigned to "the client team" is assigned to nobody. This is the most common cause and the most reliably misdiagnosed, because from the inside it looks like the customer is unresponsive rather than unassigned.
The seam. Implementation finished their part and customer success had not started theirs, or each assumed the other was chasing the outstanding item. Nothing was dropped deliberately. It fell in the gap the job descriptions do not cover. How to close that gap properly is covered in our guide to running an implementation to CSM handoff.
Scope grew quietly. A request in week two that nobody logged as a change. The date never formally moved, so it has no new date, it is simply late.
If you cannot say which of the four you are in, you cannot fix it, and every status call will produce the same answer, which is that it is progressing.
The signals that arrive before the date moves
A missed go-live is the last signal, not the first. By the time the date moves, the delay happened weeks earlier.
Reply latency on the customer side. The single earliest indicator. A sponsor who answered within a day during the sales process and now takes four is already distracted. Nothing has slipped yet, but it will.
A task that has moved its due date twice. Once is a schedule. Twice is a decision nobody has made out loud.
The same person on every call. If the technical contact stopped attending and the project lead now answers for them, you have lost the person who does the work and kept the person who reports on it.
Nobody has logged in since kickoff. Obvious in hindsight, almost never checked at week two, and knowable from your own authentication records without any analytics tooling.
The status is a colour, not a date. When "on track" has survived three weeks without anyone restating the actual go-live date, it has stopped meaning anything.
Attendance is its own signal and has its own causes, which our guide to customers not showing up to onboarding deals with directly.
What the delay is costing them, in their numbers
This is the argument that moves a stalled onboarding, and almost nobody makes it to the customer.
On most contracts the subscription starts at signature, not at go-live. So every week of delay is a week the customer pays for something they cannot use yet. On an annual contract, a ten-week slip spends roughly 19% of year one before the product does anything. A sixteen-week slip spends nearly a third.
That maths is worth putting in front of your sponsor, carefully. Not as pressure, and not as a reason you should be paid less. As the reason their outstanding task matters more than it looks on their list. A sponsor who understands they are burning paid months on a stalled data export will usually find the data export.
It is also the honest reason to re-cut the scope rather than wait. Going live on one workflow stops the clock on the part that is wasting. Waiting for the complete build keeps it running.
What to do when it is already late
This is the part the published guides skip. Five moves, in order.
Stop reporting a date you do not believe. The most expensive thing in a slipping onboarding is a status that stays green. Say the date is at risk the week you first think it, not the week it becomes undeniable. Every week of delay in saying so costs a week of the customer's own planning.
Re-cut the scope to the first outcome, not the full build. Find the smallest version of the thing they bought that would be genuinely useful, and go live with that. One team, one workflow, one real use. A partial go-live resets the relationship from late to live, and the rest becomes a roadmap instead of a debt.
Give every open task a human name and a date. Not a team. A person, on the customer's side, who has agreed out loud. Most stalled onboardings have three or four tasks with no owner, and naming them moves more than any escalation.
Escalate on their side before yours. Your sponsor usually cannot free up their own colleague's time. Their manager can. Ask your sponsor who needs to know, rather than going around them.
Set one new date and protect it. A second slip costs far more than the first, because the first is a problem and the second is a pattern. Only commit to a date whose dependencies you have confirmed this week.
Onboarding risk sitting in a project tool nobody checks?
Who should own the date
The hiring data says nobody does, so you have to decide deliberately rather than inherit it.
One person should own the go-live date end to end, and it should be whoever can change the plan. Ownership without the authority to re-scope is reporting, not ownership.
In practice that usually means implementation owns the date through go-live and customer success owns the outcome after it, with a single named handoff moment rather than a drift. The failure is never the choice of owner. It is having two half-owners who each assume the other is driving, which is precisely the shape the job descriptions produce: one side hired against onboarding, the other against implementation, and 8% of postings mentioning both.
Whatever you choose, write the owner's name on the plan. If a reader of your project plan cannot tell you in one second who owns the date, nobody owns it.
Setting a date that survives
Most of this is won before kickoff.
Do not set the date at signature. Set it after a scoping call that confirms the data, the access and the named people exist. A date set at signature is a sales artefact.
Make the customer's tasks visible to the customer. Their delay is usually invisible to them, because it lives in your project tool and their inbox.
Put a prerequisite gate before kickoff. If the data export and the technical contact are not confirmed, the kickoff moves. Holding a kickoff you cannot build on converts a two-week delay into a six-week one.
Separate go-live from adoption, and measure both. Going live is a switch. Value is a habit. For what to target on the second, see our guide to the time to value target for CSMs.
Log every scope change as a date change. A request accepted in week two without moving the date is how a project becomes late without anyone deciding it should be. The commonest source of those requests is a promise made before signature, which our guide to stopping sales from overpromising addresses at the root.
What to say when you have to tell them
The conversation decides whether a slip costs you credibility or buys you some.
Lead with the new date, not the apology. A sponsor needs something to tell their own manager. An apology without a date leaves them with nothing to pass on.
Name the cause in one sentence, without blame. "The data export took longer than we scoped" is a fact. "We are waiting on your team" is a position, and it ends the useful part of the call.
Bring the re-cut scope with you. Arriving with a smaller go-live they could have in two weeks converts the conversation from a complaint into a decision.
Say what changes so it does not happen again. One specific thing, not a process overhaul. The sponsor is deciding whether the next date is real.
Do not do it by email. A written slip gets forwarded without the context and read as worse than it is.
Why this matters more than it looks
A slipping onboarding is not only a project problem. It is the strongest early churn signal you have, because the customer is forming their judgement of you during exactly this window, and a delayed go-live means they are paying for something they cannot use yet.
Our analysis of why SaaS customers cancel in the first 90 days covers what happens after that judgement forms. This page is about the weeks before it.
Where GainTrace fits
Everything above depends on catching the drift while it is still five weeks of warning signs rather than one moved date.
The structural problem is that an onboarding in trouble lives in a project tool, and the people who would act on it are looking somewhere else. GainTrace reads the signals this article describes from the systems that already hold them, and surfaces a drifting account next to the renewals and the risk list, where someone is actually looking. The first 25 companies are free forever.

That changes where the information appears, not what you do with it. If your go-live dates already have a named owner who restates them weekly, you have solved this without buying anything.
Want drifting onboardings in front of the people who can act? Start GainTrace free.
Free forever on your first 25 companies | No credit card required
Frequently Asked Questions
- Why is customer onboarding taking so long?
- Usually one of four causes, and they need different fixes: the kickoff happened before the data, access and named contacts existed; customer-side tasks were assigned to a team rather than a person; work fell into the seam between implementation and customer success; or scope grew without anyone formally moving the date. The underlying reason it goes unnoticed is that the date typically has no owner. Across 76 live Customer Success Manager postings, none mentions go-live and only two mention a milestone at all.
- What do I do when a customer is stuck in onboarding?
- Name which of the four causes you have, then re-cut the scope to the smallest genuinely useful outcome and go live with that. A partial go-live changes the relationship from late to live. At the same time, give every open task a named person on the customer side rather than a team, since unowned tasks are the most common and most misread cause of a stall.
- Our go-live keeps getting pushed. How do we stop it?
- Stop reporting a date you do not believe, then set one new date whose dependencies you have confirmed this week and protect it. A second slip costs far more than the first, because the first reads as a problem and the second reads as a pattern. If the blocker is on the customer's side, escalate through your sponsor to whoever can free up their colleague's time, rather than around them.
- Who owns onboarding, customer success or implementation?
- Whoever can change the plan. Ownership without authority to re-scope is reporting. The usual working split is implementation owning the date through go-live and customer success owning the outcome afterwards, with one named handoff moment. The hiring data suggests most companies have not decided: 43% of CSM postings mention onboarding, 37% mention implementation, and only 8% mention both.
- What are the early signs that onboarding is slipping?
- Customer reply latency increasing against their own sales-process baseline, any task whose due date has moved twice, the technical contact dropping off calls while the project lead keeps attending, nobody logging in since kickoff, and a status that is a colour rather than a restated date. All five arrive before the date moves.
- How do I know if a customer is not completing setup?
- Check your authentication records rather than your project tool. Logins since kickoff, by distinct person, tells you whether anyone on their side has actually started. A project plan records what people said they would do. Login data records what they did, and the two diverge well before anyone admits it.
- What causes onboarding to stall in SaaS?
- Most often a customer-side task with no named owner, which from the vendor side looks like unresponsiveness. After that: kickoffs held before prerequisites were ready, work falling between implementation and customer success, and unlogged scope creep. Product complexity is blamed far more often than it deserves.
- How long should SaaS onboarding take?
- Long enough to reach one real outcome, and the honest answer depends entirely on what has to be connected first. The more useful question is whether the date was set before or after someone confirmed the data, the access and the named people exist. A date set at signature is a sales artefact and will move. A date set after a scoping call is a commitment and usually holds.
- Should I set the go-live date at contract signature?
- No. Set it after a scoping call that confirms prerequisites, and put a gate before kickoff so that a kickoff without a confirmed data export and technical contact simply moves. Running a kickoff you cannot build on reliably converts a two-week delay into a six-week one, because everyone believes the clock started when it did not.