An MSP onboarding checklist usually means the technical runbook: discovery, agent deployment, documentation, backup verification. This page is about the other half, the client-facing one, which is what actually decides whether the first month is calm or a series of surprises. It is written for the account or operations side of a managed service provider, and it deliberately does not attempt the technical list, which is your engineers'.
Why the client-side half gets skipped
Because the technical half is urgent and visible and the client-side half is neither, until week three when the client's staff are raising tickets to an address that does not exist yet and their finance lead has not been told how to read the invoice. The technical onboarding can be perfect and the engagement still start badly, and the reverse is much rarer.
What belongs on it
Who the client's authorised contacts are and what each may approve. How their staff raise a ticket, and when they will be told. What the service actually covers and what generates a separate charge, agreed in writing. The billing contact and the invoice format. The date the service starts and the date any transition from an incumbent completes. All of it is administrative and all of it produces a complaint when it is missing.
The incumbent handover
When there is an outgoing provider, the handover is the highest-risk part of the whole engagement and it depends on a party who has no incentive to help. Getting the list of what you need from them agreed with the client early, and in writing, is the difference between a transition and a fortnight of archaeology.
Sizing it against your volume
Count the client-side steps and the documents and approvals you need, multiply by the clients you onboard a month, and you have the workload in hours. The free worksheet on this site does that and returns how many onboardings are in flight at once, which for MSPs is usually the number that shows why the same engineer is always behind.
Questions people ask about msp onboarding checklist
Should this be one checklist with the technical one?
One process, two sections with different owners. Merging them fully produces a list nobody owns; separating them entirely produces two that never meet.
What is the most commonly missed item?
Telling the client's staff how to raise a ticket, and when. It is nobody's job and everybody assumes it happened.
Does Kickoffo do technical discovery?
No. It runs the client-facing half: the steps, the documents, the approvals and who is waiting on whom.