A client onboarding checklist that shows when work can start
Short answer: onboarding is complete when the team knows what was agreed, who decides, what inputs are available and what happens next. A sent welcome email alone is not completion. Give each step an owner, a required input and an observable done condition.
Open the editable client brief and checklist, or preview the Flori onboarding project template. The download requires no signup. The template creates a private editable project after sign-in; it does not send emails or connect services.
Completed example: Juniper's website refresh
This fictional three-person studio is delivering five pages, two revision rounds and a handover for an illustrative USD 6,000 fee. Rowan approves; Casey supplies content and access; Alex owns delivery. Day 0 is the confirmed start, not necessarily the day a CRM stage was changed. Use the actual agreement and dates in your project.
| Step | Owner | Required input | Done condition | Suggested timing |
|---|---|---|---|---|
| Confirm permission to start | Alex | Actual agreement and any required deposit evidence | Start conditions checked; unknown payment stays unconfirmed | Day 0 |
| Confirm scope and approver | Alex with Rowan | Five pages, exclusions and review rounds | Rowan confirms scope and approval responsibility | Day 1 |
| Send welcome and next steps | Alex | Agreed start and contact details | Message actually sent; kickoff and input requests clear | Day 1 |
| Check content and access | Alex with Casey | Copy, brand files and named CMS invitation | The team opens the files and tests the required access | By day 3 |
| Run kickoff | Alex | Brief, inputs and open questions | Decisions, owners and next review saved | First week |
| Prepare first review | Designer | Confirmed direction and available assets | Named draft version and specific approval request ready | Day 7 |
| Review the relationship | Alex | Delivery progress and client feedback | Next action recorded; unresolved issues have owners | Around day 30 |
These timings are a starting example, not a universal service standard. If your contract, procurement or security process takes longer, adjust the plan before promising a date.
The missing-input branch matters most
If Casey has not granted CMS access, leave the access task Waiting. Write what is missing, who will ask Casey and when the team will reassess. Separate work that can proceed, such as a design review, from work that cannot, such as implementation in the CMS. Do not mark access complete because an invitation was requested.
Ask for a named account with an appropriate role. Never put passwords or recovery codes in a project note or intake form. If the approver is unknown, resolve that before treating a review deadline as agreed. If scope differs from the signed agreement, keep the discrepancy visible rather than silently adding it to the project.
What should be true at the day-7 check?
For Juniper, the expected exercise state is a confirmed brief, tested access and a homepage direction ready for Rowan. Check the actual records against that expectation. A late input is a finding to report, not a reason to mark a task done.
Write a short update with four facts: what is complete, what is ready next, what is blocked and what decision the client owes. If the original target is at risk, say so and name who will confirm a revised plan. Use the three completed weekly-update examples for on-track, delayed and approval-pending cases.
What can an assistant help with?
An assistant can summarize the confirmed brief, suggest tasks and draft the welcome email. Read-only access is enough for a recap or a draft. For changes in Flori, choose a proposal or submitted-work review path when you want to inspect the result first. Other authorized updates can save directly; connecting an assistant does not put every action behind approval.
The Flori MCP connector does not send the welcome email, sign a contract or collect a deposit. A task due date is a reminder to a person, not evidence that an external action ran. The onboarding software page distinguishes manual, assistant-assisted, recurring and configured workflow steps.
Make the second onboarding better
After the first client, compare the plan with the blockers you actually encountered. Add the missing question or done condition to the reusable template. Existing project copies stay independent, so update a live client's plan deliberately when it needs the change. Do not add steps merely to make the checklist longer.
At completion, use the client handover packet so open issues, ownership and access survive the transition to the client.
FAQ
When is client onboarding finished? When start conditions, scope, owners, required access and the next deliverable are confirmed. Use evidence for each step. A welcome email or a completed form alone does not establish readiness.
What if the client has not supplied access? Keep the request open, name the person responsible for following up and show which work is blocked. Continue only work that can proceed without that access, and reassess the delivery date with the client.
Does installing the onboarding template automate the work? No. It creates editable project tasks. Sending messages, obtaining access and approving work still require the relevant people or separately configured tools.
Start your workspace