Agency owners tell me their whole week disappears into "onboarding," so I pulled Mike Pacitto — five-plus years building GoHighLevel snapshots and watching agencies run on them — into a conversation about why.

Ask an agency owner where their week goes and you'll get a shrug and something about "onboarding." Every new client eats hours nobody scheduled. Every onboarding is a little different from the last one. Half of it is improvised live, off memory, on a call. And it never seems to get faster, no matter how many clients you've done — which is the tell. Reps are supposed to make a thing faster. When they don't, it's because there's no thing there to repeat.

Here's the thing that takes most owners too long to see: onboarding isn't broken because onboarding is hard. It's broken because it's where every other broken thing you do finally sends you the invoice.

Onboarding is the collection point. It's the one moment where a new client forces you to actually run your whole system end to end — the snapshot, the customization, the documentation, the support, all of it, under time pressure, in front of someone paying you. Every upstream shortcut you took shows up here at once, wearing a trench coat, calling itself "onboarding friction." Fix onboarding as if it's an onboarding problem and you'll build a nicer checklist on top of the same five fires. So let's name the fires.

The five failures that all arrive at onboarding

None of these are onboarding problems. Every one of them is an upstream problem that happens to become visible — and expensive — the moment a new client lands. There are full guides on most of them; here each gets the tight version and a door to the deep one.

1. You never designed onboarding. It accreted.

Ask yourself honestly: did you ever sit down and design your onboarding process? Or did it grow — one client at a time, each one adding a step you learned you needed, none of it ever written down as a whole?

For almost everyone, it's the second one. Onboarding accreted. It's a pile of things-you've-learned-to-do, held together by your memory of the last time it went wrong. Which means nobody actually knows what it takes to onboard your clients — not even you, not as a complete thing you could hand to another person. You know it the way you know how to drive home: automatically, until someone asks you for directions and you realize you can't actually say the route.

That's failure one, and it's the foundation the other four stand on. You can't systematize a process you never designed. You can only keep performing it.

2. You don't know your own customization points

Here's the tell that you never designed it: every onboarding, you customize on the fly, discovering the customization points live, one client at a time, as if you hadn't done this fifty times already. The fix is a different discipline — Mike's rule, verbatim: "You put the customization into the design. You don't create a design and then customize it." Decide in advance what varies per client and it sorts into tiers, which are the backbone of the system below. Full treatment: every new niche is a second business.

3. "Getting it done in the moment" quietly forks every client onto a different snapshot

This is the most expensive one, and it's invisible while it happens. You onboard client one, spot something better, fix it in place; then you copy that improved account onto client two — and now you have two separate snapshots that no longer talk to each other, because improving-in-place plus copying is forking. Do it across a hundred onboardings and every support ticket opens with "wait, which version is this account on?" The mechanics of the silent fork live in the niche guide; what survives a version push and what silently doesn't is in updating a snapshot without breaking client accounts. Getting-it-done-in-the-moment during onboarding is how the fork gets born.

4. No feedback loop — and, worse, you're not dogfooding

You onboard clients, they struggle, they open tickets. What happens to that signal? For most agencies: nothing structured. The pain gets absorbed, ticket by ticket, and never rolls back into fixing the onboarding that caused it. So the same confusion generates the same tickets forever.

The instinct is to make that pain go away by outsourcing support — and there's a whole trap in doing it too early, laid out in before you hire outsourced GHL support. The core of it: problems are the signal that tells you whether your product works. Pay someone to hide that signal from you and you'll start assuming your onboarding is fine, because the pain became "the vendor's problem." It isn't. It's your onboarding's problem, and you just bought a service to stop yourself from hearing about it.

But there's a failure underneath even that one, and it's the one to actually feel: you're not dogfooding. Mike's warning on this is blunt:

If you don't dogfood your own product and you don't know what it actually takes to go through and actually use your account and why people are struggling, then you're going to be in for a world of issues. — Mike

You designed the front door from inside the house. You've never once walked up to it from the street with a key you've never held, the way every client does on day one. Everything is obvious to the person who built it. Nothing is obvious to the person meeting it for the first time. If you're not regularly being that second person, you have no idea what your onboarding actually feels like — you only know what you meant it to feel like.

5. Nothing to hand off

Add the first four up and you get the fifth for free: when it's time to hand onboarding to a VA, a team member, or an outsourced desk, there's nothing to hand them — no documented process, no training docs, no map of what a client actually touches, just you narrating live forever. That's the wall the VA onboarding guide hits (you can't delegate what you never wrote down) and the rot the SOP guide diagnoses (docs float free of the system, go stale in a month, nobody trusts them). Delegation isn't a people problem here — it's a there's-nothing-to-delegate problem.

What an actual onboarding system looks like

Here's the good news buried in all of that: fix the upstream failures and onboarding fixes itself, because onboarding was never the disease. It was the symptom. So the system isn't an onboarding checklist — it's the four upstream pieces, assembled so that a new client just flows through them.

Built from the customization tiers. This is the backbone. Because you decided your customization points in advance (failure two, solved), they sort into three tiers, and your onboarding is literally built around them:

Simple stuff — captured in an onboarding form. Business name, colors, a handful of field values. No judgment, no hand-touching the account. The client fills a form; the values flow in. This is the bulk of most onboardings and it should require zero improvisation.
Parts that need finessing — bounded, known, budgeted. Not form-fillable, but you knew going in these need a careful hand. You planned time for them instead of discovering them live. No surprises, because you decided they existed before the client showed up.
Deep personalization — captured in a client conversation. The stuff where you sit down with them and capture their voice, their personality, how they want to sound. Real judgment, real conversation — but you knew this specific piece was the piece that needed it. It's a scheduled part of the design, not a thing you stumble into.

The difference between this and improvising isn't the amount of customization. It's that you decided where it lives before the client landed, so onboarding is a known sequence instead of a live investigation.

A snapshot with documented overwrite-safety. Every asset flagged: safe to push, or holds client-specific data and must be updated by hand. This is what kills the silent fork (failure three) — you stop improving-in-place during onboarding because the safe-to-overwrite map tells you exactly which assets are shared logic you can update fleet-wide and which are client-owned and hands-off. The full discipline is in the snapshot update guide, and it's non-negotiable: without it, you can't push an update to your onboarded clients without gambling their data.

Training docs attached to the assets clients actually touch. Not a folder of SOPs floating in a Drive somewhere, going stale. Docs attached to the specific workflow, field, or calendar the client interacts with — so when the asset changes, you can see every doc that just aged, and when a client's confused about an asset, the explanation is right there on it. That's the source-of-truth model from the SOP guide, and it's what makes onboarding handoff-able (failure five): the docs are a live layer on the map, not photographs of a Tuesday that no longer exists.

A feedback loop the owner personally feels — for a while. Before you delegate or outsource any of this, you run onboarding and support long enough to feel the shape of the pain. Every recurring ticket is a defect in the onboarding, and you fix onboarding until the ticket stops generating itself. Only once the system is stable, documented, and tested do you hand it off — and then you hand off the map with it. That's the readiness the outsourced-support guide is built around: delegate a system you've felt, never one you're trying to avoid feeling.

Build it in this order

The pieces above are what the system is made of. This is the order you assemble them in. Skip a step and the later ones have nothing to stand on — you can't sort customization points you haven't listed, and you can't build a form for tiers you haven't sorted. Work it top to bottom.

Inventory your snapshot's customization points, and flag each asset safe or not-safe to overwrite. Go through the snapshot asset by asset — every workflow, field, calendar, template — and write down where a client's version differs from the base. On each asset, mark it: shared logic you can push fleet-wide (safe), or holds client-specific data that a push would destroy (not-safe). This map is the foundation; everything downstream reads from it.
Sort every customization point into the three tiers. Form-fillable (tier 1: business name, colors, field values), needs-finessing (tier 2: renaming pipeline stages to their sales language, setting calendar hours to their real availability), or client-conversation (tier 3: voice, personality, how they want to sound). Every point lands in exactly one tier. If you can't place one, you don't understand it yet — that's the point of doing this before a client shows up.
Build the onboarding form to capture every tier-1 answer in one pass. One form, all the form-fillable values, collected before you touch the account. The client fills it once; the values flow in. No coming back three times because you forgot to ask for their booking-confirmation phone number.
Turn tier-2 into an internal finesse checklist with a named owner. These aren't client-facing — they're the careful-hand items you budgeted for. Write each as a checklist step, assign an owner (a person, not "someone"), so nobody discovers a tier-2 item live on a call.
Script the tier-3 client conversation. Write the actual questions that capture their voice and personality — the ones that can't go on a form because the answers are judgment calls. Scripting them means the conversation is repeatable instead of a different improvised chat every time.
Attach training docs to the assets clients will actually touch. Not a Drive folder — docs pinned to the specific workflow, field, or calendar the client interacts with, so the explanation lives on the thing it explains and ages visibly when the asset changes.
Onboard yourself through the whole thing, cold, before any client sees it. Run steps 3 through 6 on a fresh account as if you knew nothing. This is the acceptance test for everything above, and it gets its own section because it's the step everyone skips.

Dogfooding is the test that proves the system

Everything above is theory until you run the one test that can't be faked: onboard yourself onto your own system, cold, as if you were the client.

Not review it. Not read your own checklist and nod. Actually do it — take a fresh account, run yourself through your onboarding form, your finessing steps, your client conversation, your training docs, in order, as if you'd never seen any of it and knew nothing about the account. Feel where you hesitate. Notice the step where the doc references a button that moved. Catch the form field whose label only makes sense if you already know what it's for.

What confused you — the person who built the entire thing — will bury a client who didn't. That's the whole value of dogfooding: it's the only way to meet your own front door from the street. Do it before every meaningful change, and do it periodically even when nothing changed, because GHL drifts underneath you and your account does too. The agencies whose onboarding quietly gets worse over time are, without exception, the ones who never walk through their own door.

When you don't need any of this

If you've got two or three clients, improvised onboarding is genuinely fine. You can hold the whole thing in your head, you customize live because you remember every client, and there's no fork to fear because you personally touch every account every week. Building a documented tier system and an overwrite-safety map for three clients is inventing a problem to give yourself a system to solve it with. Don't.

This system earns its keep at the exact point where the improv stops scaling — where you can't remember which client got which tweak, where a fix that works on one account breaks another, where the honest answer to "what does it take to onboard a client?" is "well, it depends." That point arrives faster than you'd expect, usually right around the client where onboarding stopped feeling like a favor to your pipeline and started feeling like a tax. If you're already there, you're the audience.

Where PatchyHub fits

Every piece of the system above rests on one thing you can't do from memory: a live, per-asset map of your account — customization points flagged, overwrite-safety marked on each asset, training docs attached to the things clients actually touch, and versions tracked so you know what changed between releases. That map is the infrastructure under the whole onboarding system, and it's exactly what I build. Import your account or snapshot and every workflow, funnel, field, and calendar gets mapped automatically — then you flag the customization points, attach the docs, and mark what's safe to push, all on one living source of truth instead of scattered across your head and a folder nobody trusts.

That's the short pitch, because the real point stands on its own: onboarding isn't a process to polish, it's a system to design — built from customization decided in advance, a snapshot you can safely push, docs attached to the assets they explain, and a feedback loop you personally felt before you handed it off. Get those right and onboarding stops being where your week goes to die. You can build the map in a spreadsheet if you want. Just build it before the next client builds a different one for you.

Building a Client Onboarding System in GoHighLevel That Actually Scales