Client onboarding workflow

Start client work when it is actually ready.

By Jacob Burke · Working Properly · Updated October 26, 2026

A client onboarding workflow turns a signed scope into a delivery-ready project. Record the scope, name the approver and internal owner, collect required inputs, resolve exceptions, then approve the start. Keep an incomplete intake in onboarding until a person confirms it is ready.

Most onboarding problems are invisible at kickoff. They surface a week later, when the team needs an approval nobody was named to give, access that was never requested, or a decision the agreed scope left open. A good onboarding workflow makes those gaps visible before work begins, and gives each one an owner.

What “ready” should mean

“Ready” is not a feeling or a kickoff date. It is a short set of conditions your team can check:

Agreed scope. The work, its limits and its acceptance criteria are written down and match what was sold.
A named approver. One person on the client side can approve work and settle disagreements.
Inputs and access. The materials and minimum access the work actually depends on are in hand, not promised.
An internal owner. One person on your team is accountable for reaching “ready,” including chasing what is missing.
A confirmed start. The client has confirmed the start date, not merely requested one.

If any condition is open, the project is in onboarding, not delivery. That one distinction does most of the work.

How the workflow runs

Capture. Record the agreed scope as the single reference for onboarding. Requests that arrive by email or call are checked against it, not silently added to it.
Check. Compare what has arrived against the five conditions. Each gap becomes a visible item with an owner and a next step, not a note in someone’s inbox.
Resolve. The internal owner requests the missing approver, inputs and access. Anything outside scope is routed as a scope question, not absorbed.
Approve the start. A named person on your team confirms every condition is met. Only then is the delivery project created or released.
Hand off. The delivery team receives the scope, open assumptions, the approver’s name and the acceptance criteria in one place.

Sales-to-delivery handoff: what moves from your CRM?

A won deal is not automatically a ready project. Carry the agreed facts from the sales record into the delivery brief, keep a link to their source, and have the receiving owner accept the handoff.

This example field map is a template to adapt to your process. One person may hold several roles. Record access status here, never passwords or credentials.

1. Scope and acceptance criteria

Source: Accepted proposal or written scope, with its current version.
Owner: Sales or account lead supplies it; delivery lead checks it.
If missing: Keep the project in onboarding. Do not turn an informal sales note into an agreed deliverable.

2. Client approver

Source: The client’s written confirmation of who can approve the work.
Owner: Account lead.
If missing: Ask for a named decision-maker. Do not treat silence or an unnamed contact as approval to start.

3. Delivery owner and start

Source: Capacity check and the confirmed start agreement.
Owner: Delivery lead.
If missing: Keep requested dates separate from confirmed dates. Work waits for the agreed start conditions.

4. Required payment status

Source: The invoice or payment record, checked against the agreed terms.
Owner: Finance or the responsible business owner.
If missing: Do not release work that requires payment. A “won” sales stage is not evidence of payment.

5. Inputs and access status

Source: Intake checklist and confirmation that required materials and access are available.
Owner: Onboarding owner, confirmed by the delivery lead.
If missing: Assign the gap and next action. A partial start needs explicit approval and a recorded boundary; it is not the default.

6. Exceptions and extra requests

Source: Sales notes checked against the accepted scope.
Owner: Sales lead clarifies; delivery lead accepts the resolved brief.
If missing: Record the unanswered question. New requests stay outside delivery until their scope is agreed.

Test the handoff before automating it. Try a complete record, a missing approver, an unpaid required invoice and an extra request. The workflow should identify the right owner and hold the start when required—not quietly create an approved delivery project.

Keep this information in the tools your team already uses. A native automation can prepare a draft project or review task where supported; a person confirms readiness. See how we help configure CRM and client-management workflows →

Exceptions worth designing for

The normal path is easy. These are the cases that usually come back to the founder:

No approver named. Delivery waits. The owner asks the client for one decision-maker by name.
Partial inputs. Work that does not depend on the missing material starts only if someone explicitly approves a partial start.
New requests during onboarding. An extra page, a review or a video becomes a separate scope question with its own decision.
Access the work may not need. Request access only when the agreed work depends on it. Optional items should not block the start.
Date pressure. A requested kickoff date is recorded as a preference until the conditions are met.

A fictional example

Cedar Lane Creative is a fictional agency, and Harbor House is its fictional client. This illustrates the method; it is not a client result.

The agreed scope is five website-content pages and one consolidated revision round. At intake, three things are open. No client approver is named. Analytics access is absent, and it is needed only if the agreed work depends on it. Kickoff has been requested but not confirmed. Separately, the client mentions SEO and a short video; neither is in scope.

In the workflow, Cedar Lane’s project owner sees three open readiness items and one scope question. The owner asks Harbor House for a named approver, confirms the content pages do not depend on analytics, and records the SEO and video interest as a separate conversation. Once the approver is named and the date confirmed, the start is approved. The delivery team receives a project with no invented owners, dates or commitments.

See this fictional handoff step by step in the interactive workflow example.

Readiness checklist

Use this before any project moves from onboarding to delivery.

Agreed scope is recorded and matches what was sold.
Acceptance criteria are written, not implied.
One client approver is named.
One internal owner is accountable for readiness.
Required inputs are received, not promised.
Minimum required access is granted; optional access is not blocking.
Out-of-scope requests are logged as separate scope questions.
The start date is confirmed by the client.
A named person on your team has approved the start.
The delivery team has scope, assumptions, approver and criteria in one place.

When a scoped implementation helps

The checklist is yours to use. Implementation helps when the checklist is clear but onboarding still runs on memory, inboxes and reminders, so the same gaps reappear with each new client.

The $3,000 Workflow Implementation Sprint installs one agreed onboarding workflow in tools you already use. It covers owners, readiness status, the approval to start and exception handling, with up to two native automations and one accepted AI-assisted step. It includes:

two 45-minute training sessions for up to ten participants
an operating guide and acceptance checks
two bounded revision rounds
fourteen days of accepted-scope defect correction

It is not the right fit if you need custom APIs, a full migration to new software, or several workflows at once; those are scoped separately. Software subscriptions remain yours. Tool support is confirmed before you commit, and timing depends on your inputs and approvals.

Describe where onboarding gets stuck.

Scope and price come before any commitment. No payment or access is needed to ask.

Get my process scoped →