White-label sub-accounts in GoHighLevel: what is actually branded, and what still says HighLevel

White-labelling GoHighLevel means your clients log in to your brand. Your domain in the address bar, your logo in the corner, your name on the notification emails. HighLevel is underneath and, if you do it properly, invisible.

The part worth understanding before you sell it is that white-labelling is configured at agency level and inherited by every sub-account. There is no per-client branding in the standard setup. One brand, every client. That single fact determines a surprising amount of how you should structure your agency.

What gets branded

• The login domain. A subdomain you control — app.youragency.com — pointed at the platform with a CNAME record. This is the piece clients actually notice, because it is what they type.
• The dashboard. Your logo, your colours, your product name throughout the interface.
• Notification emails. The system messages a client receives — password resets, alerts — carry your identity rather than the platform’s.
• The support surface. Your support email and chat name replace the platform’s, which matters because otherwise your clients raise tickets with a company they have never heard of.
• The mobile and desktop apps, on the higher plan tiers. A branded app is a genuinely different sales conversation from “download this other company’s app”.

Setup is short: publish the CNAME, wait for DNS and certificate provisioning, upload the logo and colours in agency settings. Allow an afternoon plus propagation time. The waiting is longer than the work.

What does not get branded

Be straight with clients about these rather than being caught out:

• Deep documentation and some help content still resolves to the platform’s own material unless you replace it with your own knowledge base.
• Certain in-product links and edge screens occasionally surface platform naming. Fewer than they used to, but not zero.
• The underlying telephony and email infrastructure is what it is. A client who inspects an email header will find infrastructure that is not yours.
• Anything a third-party integration renders. Connected services show their own branding, because they are their own products.

None of this undermines the proposition. It undermines the promise if you told the client that nobody could ever tell.

The consequence people miss: one brand, every client

Because branding is agency-level, every sub-account under your agency sees the same brand. If you run two genuinely different offers — a local-services agency and a separate healthcare product, say — they cannot have different logins under one agency account.

The options are a second agency account, or accepting a single shared brand. Both are legitimate; neither is free. Decide before you have thirty clients trained on a URL.

There is a second consequence, which is that white-labelled sub-accounts are excluded from the standard sub-account transfer path. If part of your plan is eventually selling a book of clients or letting a client take their account in-house, read transferring a sub-account to another agency before you commit to a structure.

White label is not SaaS mode

These get conflated constantly and they are separate things.

White label changes what the client sees. Domain, logo, emails, apps.

SaaS mode changes what the client buys. It adds plans, self-serve signup, automatic account provisioning and usage rebilling.

You can white-label without SaaS mode — most done-for-you agencies should, because it makes the client experience coherent without changing the commercial model. You would not normally run SaaS mode without white label, because selling software under someone else’s brand defeats the purpose. The mechanics of the second one are in SaaS mode snapshots.

Where the sub-account work actually is

Branding the platform is an afternoon. Making a sub-account feel like your product is a build, and it lives inside the account rather than in agency settings:

• The custom-value layer. Every message the account sends prints strings from it. If those strings are generic, the account reads like a template regardless of the logo above it. See custom values vs custom fields.
• Naming. A client who opens the workflow list and finds Workflow 4 (copy) has learned something about your product. A client who finds a grouped, prefixed, readable list has learned something else. Our naming convention note is largely a branding argument in disguise.
• Consistency across accounts. Forty accounts built from one blueprint behave identically, so your documentation is true for all of them. Forty bespoke accounts mean forty support experiences under one brand, which is the fastest way to make a white-labelled product feel unreliable.

That last point is the strongest practical argument for a kit. A sub-account kit is not only faster to deploy — it is what makes the branded product the same product for every client you sell it to.

What it costs, and what it lets you charge

White-label branding sits on the middle agency tier; the branded mobile app and SaaS mode sit on the top tier. Published figures at the time of writing are roughly $297 and $497 a month — check HighLevel’s pricing page before quoting, because the tiers move.

The commercial argument is straightforward and does not require inventing numbers. An unbranded CRM is a tool you configured. A branded CRM is a product you sell. The second one is easier to price above cost, harder for a client to shop against, and considerably harder to leave — not because they are locked in technically, but because the thing they trained their staff on has your name on it.

What it does not do is change the underlying cost lines. Telephony, email and per-account credential work are identical whether the login page says your name or not; see what a sub-account costs to run for the full set. Budget the branding as a fixed monthly and the delivery as per-account.

Four questions clients ask, and honest answers

“Is this your own software?” It is our platform, built on infrastructure we licence. Say it plainly. An agency caught claiming to have written a CRM it did not write loses more than the argument.

“Can I keep it if we part ways?” Depends on the structure you chose, and white-labelled sub-accounts have transfer restrictions. Settle this in the contract, not in the exit conversation.

“Why does this email come from a different domain?” Because sending infrastructure is separate from login branding. Configure the client’s own sending domain properly and this question mostly disappears.

“Can we have our own logo inside it?” Not at the login level — that is your brand for every client. Inside the account, their branding appears everywhere their customers see: funnels, emails, booking pages, review requests. Which is the part their customers actually look at.

A sensible setup order

1. Choose and register the subdomain you will use. Never change it later.
2. Publish the CNAME and wait for the certificate.
3. Upload logo, colours and product name.
4. Set the support email and chat identity to addresses you actually monitor.
5. Replace the help links with your own knowledge base, even if it starts as five articles.
6. Configure the branded apps if your plan includes them.
7. Only then invite the first client, so nobody is ever trained on a URL you intend to replace.
8. Write the client-facing “how to log in” page once, and send the same link to everyone.

If the branded product needs building as well as branding

Our sub-account setup service builds and tests the account behind the brand, and bulk provisioning does it for a whole batch so every client under your logo gets the identical product. Anything that needs to reach outside the platform — a custom portal, a two-way integration, middleware between your CRM and theirs — sits in integrations, APIs and custom software, which is scoped and quoted separately rather than pretended to be part of a snapshot.