Client Onboarding Checklist Template
Download a free client onboarding checklist template with owners, completion criteria, and a worked example for a small service business.
A signed agreement is the start of onboarding, not the finish. This checklist turns the handoff from sales to delivery into a sequence with an owner and a clear completion condition. Use it for a new consulting, agency, or other service engagement.
When to use it
Start after scope and commercial terms are agreed. Assign one onboarding owner who checks the whole sequence, even when different people complete the tasks. Keep the checklist in your existing project tool or shared document.
How to use it
- Confirm the agreed scope, exclusions, first deliverable, and start date with the client. Link the agreement rather than copying sensitive terms into every system.
- Name the delivery owner and the client approver. Agree where routine updates go and how urgent blockers are escalated.
- Request only the access and assets needed for the first milestone. Use invitations with appropriate permissions; do not collect passwords in the checklist.
- Hold a kickoff to confirm the first milestone, dependencies, and what acceptance looks like. Record unresolved questions with an owner and due date.
- Send a written recap and obtain confirmation of the next action. Close onboarding only when the team can begin the agreed work.
The template
Download editable textCLIENT ONBOARDING CHECKLIST
Client / project: [name]
Onboarding owner: [name]
Target ready-to-start date: [date]
[ ] Scope confirmed — Owner: [name] — Due: [date]
Done when: scope, exclusions, and first deliverable are acknowledged.
Evidence: [agreement or confirmation link]
[ ] People and communication agreed — Owner: [name] — Due: [date]
Done when: delivery owner, client approver, update channel, and escalation route are named.
[ ] Required assets and access received — Owner: [name] — Due: [date]
Done when: each required invitation works and the first milestone's assets are available.
Missing dependency / next action: [item, owner, date]
[ ] Kickoff completed — Owner: [name] — Due: [date]
Done when: milestone, acceptance criteria, and open questions are documented.
[ ] Recap acknowledged — Owner: [name] — Due: [date]
Done when: client confirms the first action and delivery can start.
Readiness decision: [ready / blocked]
If blocked: [dependency, owner, next check-in date]Worked example
Illustrative example: a small design studio is onboarding a website client. The account lead owns onboarding; the designer owns the asset request; the client’s marketing lead approves the first wireframe. A missing logo file is recorded as a dependency with a named client owner. The team confirms a revised first milestone before calling the project ready.
Common mistake
A checked box is not proof of readiness. “Access requested” is different from “access works.” If a dependency is still missing, keep the relevant step open and communicate its effect on the start date.
Related templates
Need help putting the workflow into practice? Explore the Operator Sprint.