There's a question every agency operator using GoHighLevel hits in the first 30 days: should each client get their own sub-account, or should we run all clients out of a single shared instance with tagging or pipelines for separation?
The short version: sub-accounts win on every dimension that matters except cost, and the cost difference shrinks to nothing as you scale. Operators who start on shared instances almost always migrate to sub-accounts within 12-18 months — usually triggered by a compliance event, a client trust issue, or an acquisition conversation that exposes the architectural debt.
Here's the longer version.
The shared-instance shortcut
The shared instance is what new operators reach for. One GHL agency account, all clients living in it as separate contacts/pipelines, separated by tags or by custom field values. The appeal:
- Cheaper at small scale — one location fee instead of N
- Faster to set up — no per-client provisioning
- Easier reporting — pull data across the whole book in one query
For an operator with 1-3 clients in the first 60 days, those advantages are real. The shortcut works.
The problem is the shortcut compounds against you. By client 10, the shared instance has become a tangled mess that's hard to operate, hard to audit, and impossible to detangle without weeks of migration work.
Where shared instances break
Compliance isolation. When client A's domain gets blacklisted, the shared sender reputation tanks for clients B, C, D, and E too. When client A's TCPA opt-in records get subpoenaed, you have to produce records for everyone in the shared instance. The compliance blast radius is the size of the whole book.
Client trust. Clients who understand the shared structure invariably ask whether their leads are visible to other clients. The technical answer is "no, we use tags" — which is an answer that doesn't survive five seconds of customer scrutiny when something goes wrong. A sub-account is a clean, defensible answer.
Provisioning automation. Onboarding a new client in a sub-account architecture is a templatable workflow: import a snapshot, configure the brand, wire up the integrations. Onboarding into a shared instance is a manual exercise in not breaking what's there for everyone else. The automation gap widens as the book grows.
The handover problem. If you ever need to give a client the keys — they end the engagement and want to keep their data, you sell the relationship to another agency, the client takes their marketing in-house — there's no clean handover from a shared instance. You'd have to surgically extract their contacts, pipelines, automations, and SMS history without disrupting the rest of the instance. From a sub-account, you transfer ownership and the work is done in 15 minutes.
The acquisition problem. Agencies get bought. When the buyer does diligence, an architecture of "we run 30 clients out of one instance" is a red flag. An architecture of "every client has an isolated sub-account, we have the agency-level oversight on top" is a green flag and adds material multiple to the deal.
The cost reality
The argument for shared instances usually centers on per-location cost. The math at small scale:
- 5 clients on shared: 1 location fee
- 5 clients on sub-accounts: 5 location fees
That difference is real but smaller than it sounds. Most operators charge $300-1,500/month per client and the per-location cost is $50-100. That's 3-15% of revenue per client. The architectural cleanliness is worth more than that delta.
At scale (20+ clients), most agency-tier GHL plans include sub-accounts at no additional cost or at heavily discounted rates. The per-location math stops being a meaningful argument once you're past 10-15 clients.
When shared instances actually make sense
There are three scenarios where shared works:
1. Demo / sandbox usage. Internal testing, prospect demos, training new team members. Use a shared dev instance freely.
2. White-label resold lite product. If your agency offers a "lite" tier where the client gets access to your version of GHL but doesn't actually own a sub-account, that can be modeled as a single instance with strict data isolation. Used carefully, this works for a productized lower-tier offering.
3. Very early MVP, fewer than 3 clients. The first 90 days of the agency, when speed matters more than architectural rigor. Plan to migrate to sub-accounts by client 5 — and budget the migration time accordingly.
Outside of those three scenarios, sub-accounts win.
The provisioning pattern
The right architecture once you commit to sub-accounts:
- Agency-level GHL account — the operator's master account, with all sub-accounts under it
- Per-niche snapshots — pre-built configurations for HVAC, dental, roofing, etc., that get cloned into each new sub-account at provisioning time
- Templated automations and pipelines — every sub-account gets the same baseline, customized per client
- API-driven provisioning — operator triggers a single workflow that spawns the sub-account, imports the snapshot, configures the brand, and wires the integrations
That pattern is what the platform ships by default. The HVAC, dental, roofing, and plumbing templates each have a snapshot that drops into a fresh sub-account in roughly 8 minutes of automated provisioning. The operator never logs into GHL to manually configure anything.
The brand and white-label angle
Sub-accounts also unlock the white-label experience that clients increasingly expect. A client who logs into "their portal" and sees their own brand colors, their own domain, their own pipelines — without seeing your agency's name anywhere — feels the relationship differently than a client who logs into "AcmeAgency Marketing's GHL" with a generic agency-named instance.
The white-label portals breakdown goes deeper on this. For most niches, the white-label experience is what differentiates a $1,500/month agency from a $4,500/month agency offering the same underlying services. The sub-account architecture is the foundation that white-label sits on.
Migration: the moment you have to do it
Most operators end up doing a shared-to-sub-account migration once. The trigger is usually one of three events:
- A compliance event (a client's domain gets blacklisted, the operator sees the blast-radius problem firsthand)
- A client churn event (the client wants their data, the operator realizes they can't cleanly export)
- A scale event (the operator hits ~10 clients and the shared instance becomes ungovernable)
The migration is painful but bounded. Per client, the work is roughly 2-4 hours of operator time: provision the new sub-account, export and reimport contacts, recreate pipelines, redirect webhooks, update tracking pixels, transition the client to the new portal URL. Multiply that by N clients and you're looking at 2-4 weeks of operator time spread over a quarter.
The operators who delay the migration regret the delay. The operators who do the migration in month 6 (when they have 6 clients) report it took them a long weekend. The operators who delay until month 18 (when they have 14 clients) report it took six weeks and they almost lost a client over data they couldn't extract cleanly.
How AcquireOS handles GHL provisioning
Sub-account provisioning is built into the platform onboarding flow. When an operator deploys a new agent for a client, the workflow:
- Calls the GHL agency API to create a new sub-account
- Imports the niche-specific snapshot
- Configures the brand (logo, colors, domain) per the operator's white-label settings
- Provisions the phone numbers (call tracking + voice AI)
- Wires up the webhooks back to the platform's adapter
- Creates the client portal at the white-label URL
The operator clicks "deploy agent for client" and 8-12 minutes later the entire infrastructure is live. No manual GHL configuration. No copy-paste of webhook URLs. No "did I remember to set that pipeline?" moments.
The principle: shared instances are the architecture you regret. Sub-accounts are the architecture you scale. Pay the small upfront cost in month 1; avoid the large migration cost in month 18.
