Client onboarding checklists that survive contact with reality: what actually goes wrong in week one

Every MSP has an onboarding checklist, and every onboarding checklist reads the same way on paper: deploy agents, inventory devices, collect credentials, document the network. The checklist is not where onboarding goes wrong. Week one is where it goes wrong, in ways the checklist assumed away — because a checklist describes the steps in the order you'd like to take them, and reality doesn't agree to that order.

The specific things that actually go wrong

• The previous provider goes quiet. "Cooperative handoff" is the exception, not the rule — a departing provider often has no incentive to make the transition smooth, and your checklist step that assumes a clean credential handoff needs a fallback for the far more common case where you get nothing.
• A credential doesn't work. The domain admin password in the handoff document is stale, an MFA-enrolled account locks you out, or an account you were told was an admin turns out to be scoped down. Budget time for this specifically — it is not the exception, it is close to the median case.
• The network diagram was wrong, or didn't exist. What you inherit is rarely an accurate topology; it's someone's memory of the topology from eighteen months ago, before the unmanaged switch got added under a desk to solve a one-off problem that was never revisited.
• A key stakeholder is unavailable in week one specifically. The person who actually knows why a legacy server is still running is on vacation the exact week you need to ask them, and nobody else at the client can answer with confidence.
• Licensing surprises. Software the previous provider left half-licensed, a support contract that expired without anyone noticing, or a device count that doesn't match what was quoted during sales — all of it becomes your problem to explain to a thirty-day-old client relationship, at the worst possible time to be delivering bad news.

A checklist that assumes a cooperative handoff, working credentials, an accurate network diagram, and an available stakeholder is a checklist for the onboarding you wish you were doing. Plan for the one you're actually going to get.

What actually helps in week one

• Discovery before documentation trust — run automated network and device discovery in week one regardless of what documentation you were handed, and treat the handoff docs as a hypothesis to verify, not a source of truth.
• A credential-failure path, not just a credential-collection step — know in advance what you do when the admin account doesn't work: who at the client can grant emergency access, and how fast.
• A default assumption of licensing gaps — check license status and support-contract expiration explicitly in week one, rather than discovering it when something breaks and needs a vendor ticket.
• A named backup contact at the client, not just a primary — confirmed before week one starts, specifically so an unavailable stakeholder doesn't stall discovery for days.

None of this means the checklist is worthless — it's still the right skeleton. It means the checklist earns trust by having a documented answer for what happens when a step fails, not just a description of what happens when it succeeds. The version worth building — and the version we're building the onboarding-runbook capability toward inside Nexus — treats "the credential didn't work" and "the diagram was wrong" as expected branches in the process, tracked against the client record, not exceptions that knock the whole onboarding off the rails.