# How to create a client onboarding checklist that sets a project up well

https://techy.eus/en/resources/create-a-client-onboarding-checklist
Updated: 2026-09-20

A strong kickoff is not a long welcome email. It is a short sequence that gives both sides a shared picture of what will happen, who owns what and what is still missing.

Techy · Editable offline copy. Examples are illustrative, not customer results. Review the guide's limitations before applying it.

## Collect only information that changes the work

Ask for the goal, primary contact, existing materials, access requirements and decision process. A large intake form creates delay when half the answers never affect delivery.

Use plain language and explain why each requested item matters. Clients respond faster when the request has an obvious purpose.

- Main outcome and audience.
- Decision-maker and day-to-day contact.
- Access, files and brand materials.
- Target date and known constraints.

## Turn unknowns into named actions

Do not leave missing information as a vague note. Assign the next action, an owner and a due date. That makes an incomplete brief a manageable checklist rather than a source of repeated messages.

## Confirm the first milestone

Close onboarding by confirming what happens next and when the client will see it. A defined first milestone gives everyone a useful checkpoint before assumptions become expensive to change.

## Worked example: make access a dependency, not a checkbox

For a fictional website project, separate ‘access requested’ from ‘access verified’. A client can send an invitation that expires or grants the wrong role. Verification means the assigned person can reach the required project and perform an agreed harmless check. Use an invitation or approved access workflow, never a shared plaintext password in the checklist.

Track owner, required date, status and evidence for each input: scope approval, content, access and billing contact. If access is blocked, the next action should name who will resolve it rather than leaving the project apparently ready. Onboarding is complete only when the first planned task can actually begin. Review whether every collected field supports that task; requesting information ‘just in case’ creates work and unnecessary data to manage.

## Use readiness gates instead of counting completed fields

Fictional website project: the client has sent brand assets and named an approver. Hosting access has been requested but not verified. A checklist that counts ‘access requested’ as complete may incorrectly suggest that implementation can start.

Separate work that can proceed from work that is genuinely blocked. Drafting may start using approved assets while an authorized team member verifies the minimum required hosting permissions. Assign an owner and checkpoint to the unresolved access item. Do not call onboarding complete merely because three of four rows have activity.

Worked example · fictional inputs

| Item | Current evidence | Blocks what? |
| --- | --- | --- |
| Brand assets | Approved files available | Does not block drafting |
| Decision owner | Named contact confirmed | Does not block review |
| Hosting access | Invitation sent, login untested | Blocks deployment work |
| Launch date | Proposed only | Blocks a confirmed launch commitment |

## Test the result and handle the exception

A person able to log in may still lack the permission needed to deploy. Test the specific operation safely. If the client changes the approver, reconfirm pending decisions rather than treating a prior contact’s silence as approval.

- Verified means the authorized person actually performed the required access test.
- Credentials stay in an approved access-management channel, never in the checklist.
- The first milestone names both its output and its prerequisites.

## Your working sheet — fill in locally

Situation and date: ____________________

Inputs and where they came from: ____________________

Decision / calculation: ____________________

Expected result: ____________________

Actual check and evidence reference: ____________________

Exception and next action: ____________________

Owner and review date: ____________________

Do not put passwords, patient details or other sensitive data in a shared worksheet. Downloading or checking a box does not verify real-world compliance.