Run repeatable client onboarding
Your onboarding checklist describes the snapshot as it was when someone wrote it down. The account has moved since — renamed workflows, added systems, a booking flow that works differently now. So every onboarding is part checklist, part improvisation, and the improvised parts live in your most senior people's heads.
The walkthrough
The steps
- 1
Connect the account your clients run on — one click with the Chrome app. If they all start from the same snapshot, one representative build is enough.
- 2
Read what Patchy wrote, as a team. The account described system by system — lead intake, booking, review requests. Expect surprises in both directions.
The account explained system by system, in plain language. - 3
Build the checklist from what's actually there. What the client configures, what they'll use daily and need shown, what's internal machinery they should know exists but never touch.
- 4
On calls, show the map instead of lecturing — and share the link so the client can look at their own system between calls.
A shareable map — the client sees their system instead of imagining it. - 5
When the snapshot changes, refresh and adjust the small difference — instead of the slow rot of a checklist nobody trusts.
Why this changes onboarding
The checklist gets a source of truth under it: documentation generated from the account itself, current as of the last refresh. Because it's organized by system rather than by individual workflow, it survives small changes — "walk the client through the booking system" stays true when a workflow inside that system gets renamed — and every step traces to something in the docs, so "why is this step here" always has an answer.
Any team member can run it, because the knowledge is in the docs, not in seniority. Clients get the same onboarding regardless of who they drew, plus a map they can actually look at — and clients who can see their system open fewer "what does this thing do" tickets in week two. That's your support load, not a soft benefit.
If the onboarding itself needs designing — what varies per client, where customization lives — that's a deeper problem than a checklist, and there's a full guide on building a client onboarding system that scales. This page is the part where the checklist stops lying about the account.
The takeaway
The checklist stops describing the account as it was the day someone wrote it down. Any team member can run the onboarding — and it's actually true.
FAQ
We onboard every client onto the same snapshot. Do we connect every client account?
You don't have to. Connect one representative account built from the snapshot and build the checklist from that. Connect individual client accounts only when a build diverges enough that the standard checklist stops fitting.