GoHighLevel Sub-Accounts Explained: Structure, Costs, and Common Mistakes

A GoHighLevel sub-account is a self-contained workspace inside an agency’s main GoHighLevel account, with its own contacts, pipelines, phone number, and automations, isolated from every other sub-account. The standard structure for an agency serving multiple clients is one sub-account per client, cloned from a shared snapshot but then run independently. Get the isolation boundary wrong, by sharing an asset that should stay separate, and the mistake tends to surface as a client’s campaign behaving strangely for reasons nobody in the agency can immediately explain.

Each client gets its own sub-account, not a shared workspace

GoHighLevel’s sub-account is the account boundary, not a tag or a folder inside one shared workspace. A client’s contacts, conversations, calendars, pipelines, and automations all live inside their sub-account, and nothing there is visible to another sub-account unless the agency deliberately connects them. This is the structural decision that everything else in this guide sits on top of: one sub-account per client is the default, and departures from that default should be intentional, not accidental.

The practical reason this matters is data separation. A client should never be able to see another client’s contacts, and an automation built for one client’s sales process shouldn’t fire for a different client’s leads. Sub-account isolation is what makes that guarantee hold. Agencies that skip this, usually by trying to run several small clients out of one sub-account with tags to separate them, run into exactly the problem sub-accounts exist to prevent: one client’s data mixed into another’s view. GoHighLevel for Agencies: The Complete Setup Guide covers the full account architecture this sits inside.

New sub-accounts are usually populated from a snapshot rather than built from scratch each time. A snapshot is a template of pipelines, workflows, and settings that gets cloned into the new sub-account as a starting point. That’s efficient, but it’s also where the next mistake tends to creep in: treating the sub-account as still connected to the snapshot, or to other sub-accounts, after the clone is done.

Shared templates and phone numbers are the most common structural mistake

The single most common mistake in a multi-client GoHighLevel setup is sharing an asset, a template, a custom value, or a phone number, across sub-accounts that should each have their own. It happens gradually: an agency clones a snapshot for a new client, reuses a phone number “temporarily” instead of provisioning a new one, or points two sub-accounts at the same custom value because it’s faster than setting it up twice. Each shortcut works fine in isolation, right up until a change made for one client quietly changes behavior for another.

Custom values are a typical example. If a business-name or booking-link custom value gets set at a level that’s shared rather than sub-account-specific, updating it for Client A can silently update the same field showing up in Client B’s automated texts or emails. Nobody notices until a client asks why their outbound message is referencing the wrong business name, and by then the agency is debugging a problem that traces back to a setup decision made months earlier.

The failure mode with shared assets isn’t a crash or an error message, it’s silent behavior drift that only surfaces when a client notices something looks wrong, which means it often goes undetected far longer than a hard failure would.

Phone numbers deserve their own callout because the failure mode is worse than a mislabeled text. A shared number breaks call routing and caller-ID attribution outright: inbound calls land in the wrong sub-account’s conversation thread, and there’s no clean way to tell which client’s campaign generated a given call or reply. Each sub-account should have its own dedicated number, provisioned specifically for that client, full stop. If an existing setup already has a shared number that clients depend on, correcting it isn’t a quick settings toggle. It’s a structural rebuild: provisioning new isolated numbers, migrating each client’s routing and campaigns onto them, and testing that nothing breaks for the client who was relying on the shared version in the meantime.

Usage-based costs run through a separate wallet, and they can surprise you

GoHighLevel’s flat monthly subscription covers the platform itself, but calling, texting, and email sending are billed separately through a usage-based wallet tied to each sub-account. That distinction matters because it’s easy to budget for the subscription and forget the wallet entirely, right up until a client runs a heavy SMS campaign and the wallet drains faster than expected.

This is a real, recurring pattern for agencies running text-heavy campaigns on behalf of clients: a promotional blast, a review-request sequence, or an appointment-reminder workflow can consume wallet funds quickly, especially at volume. Because each sub-account has its own wallet, one client’s high-usage campaign doesn’t affect another client’s balance, which is good for isolation but means the agency needs to monitor usage per sub-account rather than assuming one aggregate number tells the whole story.

The practical fix is straightforward: set a wallet balance alert per sub-account, and have a conversation with any client running SMS-heavy campaigns about what usage costs to expect before the campaign launches, not after the wallet hits zero mid-send. Building that expectation into onboarding avoids the awkward conversation where a client asks why their texts stopped going out in the middle of a campaign.

Multi-location setups need a mix of shared and isolated assets

Multi-location businesses, a franchise with several offices or a healthcare group with multiple clinics, don’t fit neatly into either “one shared account” or “fully separate sub-accounts.” The workable structure is usually one sub-account per location, cloned from a common snapshot so branding and base workflows stay consistent, but with the phone number and usage wallet kept isolated to each location.

The logic mirrors the shared-template problem above, applied at the location level instead of the client level. A shared snapshot template makes sense because most locations run the same core process, and updating the template centrally is efficient. But a shared phone number across locations recreates the exact routing and attribution problem described earlier, and a shared usage wallet means one location’s high call volume can eat into budget meant for another. Keep the number and the wallet local to the location, and share what benefits from consistency — the pipeline structure, the review-request workflow, the base automation logic. GoHighLevel Snapshots Explained covers how to build that shared template so it actually adapts cleanly to each location instead of just being cloned as-is.

One asset that can reasonably live above the individual location is top-level reporting. An owner overseeing five locations usually wants a consolidated view of performance across all of them, not five separate dashboards to check individually, even though each location’s sub-account stays functionally isolated underneath that view.

Central reporting sits on top of isolated sub-accounts

For an agency owner managing multiple client sub-accounts, or a multi-location owner managing several location sub-accounts, GoHighLevel’s agency-level dashboard aggregates key metrics, contact counts, pipeline value, campaign activity, across every sub-account under the account. That gives account-level visibility without requiring anyone to open each sub-account individually just to get a pulse check.

It’s worth being precise about what this reporting layer is and isn’t. It’s a summary view built on top of isolated sub-accounts, not a merge of the underlying data. Detailed reporting, individual conversation history, and granular automation performance still live inside each sub-account. An agency owner checking the aggregate dashboard and noticing a dip in overall pipeline value still needs to drop into the specific sub-account to find out which client’s numbers moved and why. Treat the top-level view as a monitoring tool that tells you where to look, not a substitute for the per-client detail underneath it.

What this costs to set up correctly

Setup cost tracks the shape of the account more than the number of contacts involved. A single-business GoHighLevel setup, one sub-account, one snapshot, standard automations, typically runs $500-$4,000. A white-label SaaS build, where an agency resells GoHighLevel under its own brand to multiple client sub-accounts, runs $4,000-$10,000 given the added work of white-labeling, snapshot standardization, and onboarding flow for new clients. Multi-location setups, with the shared-snapshot-but-isolated-number-and-wallet structure described above, run $4,000-$12,000 depending on location count and how much reporting consolidation the owner wants at the top level. See pricing for how a specific setup gets scoped into one of those tiers.

Where a given build lands in those ranges depends mostly on how many sub-accounts need to be provisioned, how much of the automation can be cloned cleanly from a snapshot versus rebuilt per client, and whether existing sub-accounts already have shared assets that need to be untangled into isolated ones. That last scenario, correcting a setup where phone numbers or templates were shared when they shouldn’t have been, is the one most likely to push toward the higher end of a range, since it’s rebuild work layered on top of the initial build rather than a clean setup from scratch. GoHighLevel implementation services covers what that audit-first engagement looks like.

Getting the sub-account structure right at the start, one sub-account per client or location, isolated phone numbers and wallets, a shared snapshot used deliberately rather than left half-connected, avoids the slower and more expensive path of discovering the shared-asset problem after a client has already noticed something was off.