Start with the work you need to begin
An onboarding checklist is useful when it removes uncertainty. It should tell the client what to send, why you need it, and how they can tell they have finished. It does not need to contain every question you might eventually ask.
Before writing the request, identify the next meaningful step in your project. For a website, that may be a content review. For a consulting engagement, it may be a discovery session. Build your first checklist around the inputs needed for that step.
Collect five kinds of input
First, establish basic context: the business name, the main contact, the audience, and the problem the project should solve. Ask for enough detail to make the next conversation useful, rather than asking the client to repeat their entire proposal.
Second, request existing assets. Name each item separately: logo, brand guidelines, approved photos, previous reports, or current copy. Explain the preferred format and whether an alternative is acceptable.
Third, ask for references. A URL to an existing website, campaign, or example can be more helpful than a long description. Ask what the client likes about a reference so you do not mistake a content example for a design instruction.
Fourth, clarify access. Request an invitation through the relevant service, with the account and permission level needed. Do not ask the client to place a password in a general onboarding form.
Finally, identify decisions and approvals. Ask who can approve the work, what the approval covers, and which decisions are already settled.
Make every item easy to answer
Replace ‘send branding’ with ‘upload your current logo as a PNG, or a ZIP containing your original files.’ Replace ‘tell us your goals’ with ‘what should a visitor do after reading your homepage?’ A specific prompt reduces the amount of interpretation a client must do.
Choose the response type deliberately. Short text works for names and labels. Long text suits context and feedback. File uploads suit assets. URLs suit live references. Yes/no questions capture a choice, while a checkbox confirms a statement the client can actually verify.
Mark only the true blockers as required
If every possible input is mandatory, a client can become stuck on a minor detail while the useful information remains unsent. Make an item required when its absence prevents the next agreed step. Mark optional examples and background material accordingly.
Give clients a way to explain an unavailable item. A missing historical report and an overlooked request are different problems. Knowing the reason lets you decide whether to proceed, change the scope, or ask another stakeholder.
Send a clear handoff, then review it
Your invitation should name the request, explain the next step it supports, and identify who to contact about questions. If there is a deadline, agree it with the client and state it in the introduction. A software reminder is useful, but it does not create an agreed timeline by itself.
Once the checklist is complete, review the substance. A file can be present but outdated; an answer can be saved but ambiguous. Collection is a handoff point, not quality assurance. Take any necessary follow-up into the project conversation and update your template if the same confusion keeps happening.