Client Onboarding & Kickoff Checklist

When to use this

• You’re about to start a project and want to avoid day-2 stalls.
• You want a repeatable onboarding process that clients trust.

How to use this checklist

Onboarding is where delivery either becomes calm or becomes reactive. Most "project chaos" is actually missing basics: access, decision process, review windows, and a cadence that keeps everyone aligned.

Use this checklist like a script. Your goal is not to create more paperwork. Your goal is to prevent the predictable failure modes that turn a good project into a reactive one: missing access, unclear approvals, stakeholders pulling in different directions, and silence that makes everyone nervous.

This page is designed to work with the tool UI. Fill out the checklist, use the interactive preview to sanity-check the final format, then use Copy as Markdown to paste it into your kickoff doc, email recap, or project hub.

Quick start

If you are short on time, run the checklist in this order:

1. Get a decision-maker, an approval path, and a review window for each milestone.
2. Collect access and inputs before kickoff so work doesn't stall on day 2.
3. Confirm how scope changes will be handled so requests stay procedural instead of personal.
4. End kickoff with a first milestone, an owner for open items, and a concrete next step on the calendar.

Then, immediately send a recap. A recap is not "nice to have." It is the moment you turn a conversation into an execution system.

Use it in three moments

Use this checklist in three moments:

• Before kickoff: collect access and inputs so work doesn't stall on day 2.
• During kickoff: define the operating system (cadence, approvals, escalation).
• After kickoff: send a recap and set the first milestone so the project starts moving immediately.

Treat this like installing guardrails. The checklist is there so you don't have to rely on memory, and so your client can see what "professional onboarding" actually looks like in practice.

Before kickoff: inputs and access

The kickoff meeting is not the place to discover blockers. Before kickoff, your job is to collect the inputs required to begin work and to surface the constraints that will shape the plan.

Keep it simple: one shared doc with answers, links, and owners. If you are using this tool page, draft everything here, use the interactive preview to check formatting, then Copy as Markdown into your shared doc so stakeholders can comment in one place.

1) Stakeholders and decision-making

Many projects start smooth and then slow down for one reason: nobody knows who can say "yes" when tradeoffs appear. Fix that before it becomes a conflict.

• Name the single decision-maker. This is the person who resolves disagreements and approves final direction.
• List other stakeholders. Separate "must approve" from "should be informed."
• Decide where decisions live (doc, ticket, or email). Choose one place so you can reference it later.

2) Outcomes and boundaries

You are trying to eliminate the sentence, "Wait, I thought this included X." The easiest way is to define outcomes and boundaries in plain language.

• What does success look like? Write it as a sentence a non-expert would understand.
• What is in scope right now? Keep it short and concrete.
• What is out of scope (for now)? This protects both sides.
• What constraints matter: deadlines, dependencies, platform limits, compliance needs, brand rules, internal policies?

If you are formalizing the agreement, this section naturally becomes the backbone of a SOW. The Statement of Work template is the simplest way to lock scope and review windows into a baseline everyone can refer back to.

3) Access and assets

Missing access is the most common reason work stalls early. When access is delayed, it does not just slow down the task that needs it; it cascades into the whole schedule.

Ask for what you need explicitly and assign an owner on the client side for each item. Typical categories include:

• Access to systems you need to touch (admin panels, accounts, shared drives, source control, analytics, billing, third parties).
• Existing assets (docs, designs, brand guidelines, content, data exports, research).
• Constraints on access (role-based invites, security policies, client-run actions).

Put "access ready" into your definition of ready-to-start. If access is missing, treat it as a blocker with an owner and a due date.

4) Logistics and expectations

Set the baseline for how you will work together so you do not have to negotiate it mid-project.

• Time zones and working hours (so review windows are realistic).
• Where quick questions go vs where approvals go.
• How urgent issues are escalated and who is the backup decision-maker.

During kickoff: define the operating system

Kickoff is where you install the operating system for delivery. You are aligning the humans, not just the tasks: who decides, who reviews, how the plan changes, and how the team stays oriented week to week.

The mistake to avoid is leaving kickoff with only good vibes and no execution rules. You want the client to feel the difference between a casual chat and a working cadence.

Kickoff agenda (use as your script)

1. Context and outcomes: confirm the goal and the boundaries.
2. Scope and assumptions: restate what is in scope, what is out, and what assumptions the plan depends on.
3. Roles and approvals: name the decision-maker, set review windows, and define what counts as approval.
4. Cadence: choose an update rhythm and where updates live.
5. Risks and dependencies: list blockers and assign owners.
6. First milestone: define the next deliverable, its review window, and the next step immediately after.

Approvals and review windows

Approval is where timelines go to die if it is vague. Solve it once in kickoff.

• What needs approval (requirements, designs, copy, milestone acceptance)?
• Who approves each item (name the person, not the department).
• What is the review window for each approval?
• What happens if feedback arrives late?

If you want a structured way to document scope and review windows, use the SOW template. If you want optional contract clause language, see freelance contracts clauses.

Escalation and blockers

Escalation is the agreed process for removing blockers quickly. Decide it before you need it.

• What counts as blocked (missing access, unanswered questions, dependency delayed)?
• Who gets notified first, and who can make the call if tradeoffs are required?
• How will you record the decision (recap, ticket, email)?

Single source of truth

Pick one home for the current plan and the current decisions. It can be simple. It just needs to be consistent.

• One place for the roadmap (milestones and next steps).
• One place for decisions and approvals.
• One place for links and assets.

After kickoff: recap and first milestone

The recap is where you turn kickoff from a meeting into a delivery system. Without a recap, stakeholders remember different versions of what was agreed, and you spend the first week re-litigating scope.

Send your recap while the meeting is still fresh. Use the interactive preview to check formatting, then Copy as Markdown so the recap can live in email or your project hub without reformatting.

Recap checklist

• Outcome statement (one sentence).
• Scope: in scope and out of scope.
• Milestones: the next milestone and what happens after it.
• Roles: decision-maker, reviewers, and who provides inputs.
• Review windows and what counts as approval.
• Open items: missing access, unanswered questions, and owners.
• Change process for new requests.

Copy-ready recap template (Markdown)

Use this as a starting point. Edit it to match what you agreed.

# Kickoff recap

## Outcomes
- (What success looks like in plain language)

## Scope
In scope:
- (Item)
- (Item)

Out of scope (for now):
- (Item)
- (Item)

## Roles
- Decision-maker: (Name)
- Reviewers: (Name, for what)
- Inputs/assets owner: (Name, for what)

## Milestones
- Next milestone: (What it is)
- Review window: (How approvals work)

## Access and inputs
Needed:
- (Access/input)
- (Access/input)

Owners:
- (Who provides what, by when)

## Open questions / risks
- (Question or risk) - Owner: (Name)

## Change process
- New requests will be reviewed as a scope change and handled procedurally.

If you want a more formal flow for changes, use the Scope Change Checklist and the Change Request Addendum Pack to document what is changing and get explicit approval before you do the work.

Decision rules

These rules are intentionally blunt. They exist because delivery breaks in predictable ways.

• If access is missing, don't "start anyway." Your timeline depends on inputs. Make that explicit.
• If approval is unclear, assume delays and write review windows into the plan.
• If stakeholders multiply, require a single decision-maker or your project becomes group therapy.

If the client wants speed but cannot provide access, cannot commit to review windows, or cannot name a decision-maker, you do not have a delivery problem. You have a governance problem. Use kickoff to solve it once.

Scope control and change requests

Scope control is not about saying "no" all the time. It is about keeping changes procedural so the project stays predictable for both sides.

Start with a clear baseline (often the SOW). Then, when new requests appear, run a consistent change process so nobody feels surprised:

1. Identify the request in plain language.
2. Clarify what "done" means (and what is not included).
3. Estimate impact on schedule and dependencies.
4. Get explicit approval from the decision-maker.
5. Update the plan and the next review window so everyone stays aligned.

Use the scope change checklist to keep the conversation concrete. Use the change request addendum pack when you want the paperwork ready to go.

Reviews, approvals, and acceptance

Reviews and approvals are part of the schedule. If they are not defined, your timeline becomes a guess.

• Define a review window for each milestone and each approval-heavy deliverable.
• Decide what counts as approval (a written message, a doc comment resolved, a checkbox in a ticket).
• Decide what happens when feedback is late (schedule moves, or the next iteration narrows).

If you want a straightforward way to capture this in a baseline agreement, start with the SOW template.

Cadence and communication

Cadence is how you keep the project from going silent. Silence creates anxiety. Anxiety creates reactive decisions.

Keep it lightweight, but consistent:

• Choose an update rhythm (weekly, biweekly, or milestone-based).
• Use a consistent update format: what shipped, what is next, what is blocked, and what the client owes (inputs, approvals, access).
• Decide where updates live so stakeholders do not miss them.

FAQ

What if the client does not have access ready?

Treat access as a dependency. Do not pretend you can start anyway. Make missing access visible in the plan, assign an owner on the client side, and adjust the timeline based on when inputs arrive.

What if the client cannot name a decision-maker?

Expect delays and conflicting feedback. Push for a single decision-maker or a clear approval rule before you commit to a schedule.

How do I set review windows without sounding rigid?

Frame review windows as a schedule requirement. If the client needs more time to review, the plan should reflect that reality. Clarity is kinder than surprise.

What counts as a scope change?

If a request changes what you deliver, how long it takes, or what needs to be reviewed, treat it as a scope change. Make impact explicit and get an approval decision before you do the work.

When should I use a SOW vs a change request?

Use the SOW to define baseline scope and review windows. Use a change request when the client asks for something outside that baseline and you need explicit approval before doing the work.

Do I really need a kickoff recap?

Yes. The recap creates a single reference for scope, milestones, responsibilities, open items, and the next step. It prevents the project from becoming a set of half-remembered conversations.

Want the full delivery system?

Read onboarding, delivery, and retaining clients for the maintained model behind this checklist (cadence, scope control, retention, and offboarding).

How to customize

1. Replace the access/assets line with your standard access request list.
2. Adjust cadence to your delivery style (async updates vs meetings).
3. Add any compliance/security steps required by your clients.

Related Codex pages