Why does customer onboarding slip?

Last updated 19 August 2026

Onboarding rarely slips because a task was forgotten. It slips because it is waiting — on a customer decision, an integration, a security review, or a person who has other work. Task trackers record what you owe; they are silent about what you are waiting for, which is where the time actually goes.

Where does the time actually go?

Take a completed onboarding that ran late and mark each day as either someone was working or everyone was waiting. The waiting column is almost always the larger one, and it is the column no tool shows you.

This is why adding more task tracking so rarely helps. The tasks were not the problem: they were done, and often done quickly, separated by stretches where the project sat still. A plan that lists twenty tasks and no dependencies will look healthy through every one of those stretches, right up to the point the date is missed.

What are the usual sources of waiting?

Source	Why it is invisible in most plans
Security or procurement review	It is a permission, not a task, so nobody assigns it a duration
Data access or export	Owned by a team outside the project with its own queue
A decision nobody owns	Sits between two people who each think the other has it
Customer-side competing work	Real, unmentioned, and the most common reason a week disappears
Your own review or approval steps	Counted as instant because they are “quick” individually

Why does the slip only become visible late?

Because most status reporting measures completion rather than movement. A plan that is 60% complete and has not moved in eleven days reports the same number as one that is 60% complete and moving daily. The first is in trouble and the second is fine, and no percentage will tell them apart.

The useful signal is time since last movement, per item. It requires no new process and it surfaces the stall while there is still room to react — usually a fortnight before the date itself is obviously at risk.

What actually shortens onboarding?

Three things, in rough order of effect. Start long-lead items immediately, regardless of logical sequence — anything gated on a third party should be requested in the first week. Name an owner on the customer’s side for every dependency, by person rather than by team, because a team is not something you can chase. Make the wait visible to both sides, so the customer sees which single item is holding the date.

None of those is a tooling change. They survive being written on a whiteboard. What tooling adds is that the stall shows up without anyone remembering to look.

Does a shared plan with the customer help?

Materially, and mostly for a reason that has nothing to do with project management: it changes who is doing the chasing. When the customer can see that the date depends on one outstanding approval on their side, the person who wants that date will usually go and get it — and they can apply pressure inside their own organisation that you cannot.

It also removes the awkward status email, which is the thing most likely to be skipped in a busy week and most likely to be the week the project stalls.

Common questions

Is onboarding delay usually the customer’s fault?

Most of the elapsed time sits on the customer’s side, but "fault" is the wrong frame and an expensive one. Their delay is predictable and largely manageable if you plan for it; treating it as their problem means you stop planning for it, and the timeline slips anyway.

Will a project management tool fix it?

It will make your own work visible, which is worth something, but delay usually lives between the tasks rather than in them. Unless the tool distinguishes "not started" from "blocked on someone else", it will show a tidy plan and a slipping date at the same time.

What is the single biggest source of delay?

In most B2B onboarding, it is waiting for a person who does not report to either project lead — a security reviewer, a data owner, an IT team with its own queue. They are rarely in the plan because they are not doing a task, they are granting a permission.

How do you shorten a timeline you do not control?

Start the long-lead items on day one even if they are not the logical next step. A security review or a data export that takes three weeks should be requested in week one, not week four — sequencing by dependency length beats sequencing by logic.

Should you tell the customer when they are the blocker?

Yes, and earlier than feels comfortable — but as a shared timeline rather than an accusation. A customer who can see that one outstanding item is holding the date will usually escalate it internally, because the deadline is theirs too.