A client onboarding checklist with clear owners

1. Decide when onboarding can actually start

Choose a definite trigger. This might be written acceptance of the agreed scope and confirmation that the business is ready to begin. Use the conditions that apply to your own arrangement. An encouraging conversation, an unapproved proposal or a provisional date should not quietly become permission to start delivery.

Write the trigger at the top of the checklist, along with the client name, scope reference, main contact and intended first milestone. If a condition is outstanding, record the condition and its owner. This makes it possible to prepare appropriate next steps while keeping a proposed start separate from a confirmed one.

2. Give each step one accountable owner

Several people may contribute to a step, but one person should check that it happens. “Client” or “operations” is often too vague. Use a named contact or a clearly assigned role, and identify who can act if that person is away. Ownership of a checklist item does not automatically give someone authority to change the scope.

Separate the person doing the work from anyone who must approve it. For example, a support person might prepare the welcome message, while the business owner approves a delivery date. Keep those two actions visible if the approval is a genuine dependency.

3. Send a welcome message that answers the next questions

The welcome message should help the client act. Confirm what is starting, who their contact is, which communication channel to use and what you need from them next. Summarise the immediate milestone rather than repeating the entire proposal. Refer to the agreed scope so the client can find the fuller detail.

Bundle related requests into one organised message where practical. Distinguish essential inputs from information that can wait. If you need several documents, explain the intended purpose and the agreed way to provide them. Do not encourage a new client to email passwords or send a whole archive simply because it might become useful later.

• What we are beginning: a short description matching the accepted scope.
• What we need next: a finite list of essential inputs and the agreed route for sharing them.
• What happens afterwards: who checks the information and when the next update will be agreed.

4. Check whether received information is usable

An attachment arriving is not the same as a usable input. Check whether it is the right document, whether it is current, whether it opens through the agreed access and whether anything needed for the first task is missing. Record a specific gap rather than leaving the whole onboarding item marked “in progress”.

In a fictional example, a small design business needs approved product descriptions before preparing a brochure. The client sends a folder containing three drafts. The useful next action is to ask the named contact which version is approved. Passing every draft to the designer would move the uncertainty downstream rather than resolve it.

1. Record receipt

   Note the item, date and agreed storage location so another person can find it.

2. Check suitability

   Confirm version, completeness and access against the immediate task requirements.

3. Resolve the gap

   Name the missing detail, who will supply it and what depends on the answer.

5. Make waiting and changed requests visible

Add a waiting status with a next review date. A checklist otherwise gives the misleading impression that everything moves in a straight line. If an input is delayed, explain which next step is affected and ask the authorised person to confirm any revised dates. Do not promise the original delivery date while a required input remains unresolved.

Capture new requests separately from the agreed onboarding steps. A request for an additional report might be reasonable, but it still needs a scope decision. Record the request, the person who can decide and the impact on existing work. Keep the original checklist readable so the team can distinguish completion work from a potential extension.

6. Close onboarding with a short readiness check

Before moving into routine delivery, check that the client and the people doing the work share the same immediate plan. Confirm the first output, its owner, any approval needed and the next communication point. A remaining issue can be carried into the live project tracker with an owner; it should not disappear when the onboarding checklist is archived.

After the first piece of work, review one practical question: where did someone have to ask for information that the checklist should already have covered? Add a better instruction, remove an unnecessary request or clarify an ownership gap. Keep a reusable master checklist and a separate completed copy for each client, so improvements do not overwrite the record of what happened.