Customer Onboarding Dependency Clearance Lag

A new customer cannot launch because an integration credential, data import and internal approval are not ready. Customer onboarding dependency clearance lag measures how long a declared prerequisite remains open from recognition to verified removal as a blocker.

Define the dependency: a task is a prerequisite only if a named downstream milestone cannot proceed safely without it, and the specific milestone at risk and its agreed date should be recorded. HubSpot's onboarding checklist describes setup, training and handoff stages, and its customer success plan guidance maps milestones and actions for vendor and customer.

These are planning examples; the actual dependency chain comes from the project and agreement. Set the start, since a blocker may exist before anyone logs it, by choosing discovery or formal record time and labelling the measure, and set the end, because an owner saying done is not enough if the dependent team still cannot proceed.

Define verification by testing the actual integration, import or approval artefact under the authorised process; test any supplied credential with the needed role and a limited sample of actual data, since a successful sign-in is not proof that the integration can complete its launch-critical task. Check correctness too, because a rushed workaround can make a prerequisite appear cleared while creating later data errors.

Check authority as well: a customer may need to approve data transfer or account access, and consent should not be bypassed to clear a metric. Assign an owner, since some actions belong to the customer, others to vendor operations or a third party, and the owner should know the next action and any promised update time.

Distinguish waiting, because an item planned for next week is not necessarily an overdue blocker today, and avoid circular dependencies, as two teams waiting on each other need a joint plan rather than two permanently blocked tickets. Check multiple paths, since an alternative approved workflow may allow a milestone to proceed without the original dependency, and preserve change history so that a new plan can close an old blocker with a reason rather than letting it vanish.

Show open age, because completed-only averages hide the blockers currently delaying launch, and segment reasons, as customer inputs, vendor configuration, security review and outside provider delays have different remedies. Use a clock basis deliberately: calendar time reflects the customer's wait while working time helps assess team capacity, so label both if reported.

Report the critical path, since the oldest blocker is not always the one determining the launch date, and keep related tasks linked so that one missing approval blocking several milestones is not triple counted. Avoid blame, because a customer-supplied credential delay may reflect unclear instructions from the vendor, and keep customer-facing clarity so the customer knows in plain language what is needed from them.

Separate risk, since some prerequisites protect data security or legal compliance and should not be waived for speed, and review aging patterns, so that if many blockers wait for the same security form, the preparation and customer instructions improve rather than reviewers being asked to skip controls. Check handoffs between teams, as a dependency can be cleared in one team's system but remain unknown to implementation, and pair the lag with time-to-value because clearing every prerequisite does not prove the customer has gained value; use this lag to expose and remove real obstacles without skipping required checks.