White labelling, sub-accounts and what clients see

The support documentation names the client-facing surfaces:

“Upload your agency logo to display in key client-facing areas such as the login screen, app header, and system-generated emails.” Appears in: “Login screen, App header, Notification emails, Some widgets and form footers”. On favicons: “There isn’t a separate agency-wide favicon upload in Company → Whitelabel at this time.”

The login screen and the app header carry most of the perceived ownership, because they are what a client sees every day. Notification emails matter more than they look: they arrive in the client’s inbox alongside everything else, and an unbranded one is usually where the impression breaks first.

Two separate domains are involved and they do different jobs. The whitelabel domain controls the login portal; the API domain controls tracking links inside SMS and email. Configuring one and not the other produces a branded login that then sends messages containing somebody else’s domain — the exact detail a client notices and you do not, because you never receive your own campaigns.

A limit worth knowing before you promise itThe same documentation states there is no agency-wide favicon upload under Company → Whitelabel, and points to asset-specific settings instead. It is a small thing that is highly visible: the favicon sits in the browser tab of every client who keeps the app open all day.

A sub-account is one client’s workspace: their contacts, their pipelines, their calendars, their settings. You work across all of them from the agency view and log into any one of them without a separate account. That is the whole structure, and almost everything agency-specific follows from it.

The consequence that matters commercially is repeatability. If every client needs roughly the same setup, building it once and copying it is the difference between onboarding as a project and onboarding as a task. The supplier’s term for that copy is a snapshot.

The documentation defines what a snapshot is, and — more usefully — what it leaves behind:

“Snapshots are reusable templates that capture selected configuration assets from a HighLevel sub-account so they can be copied into new or existing sub-accounts.” They carry workflows, triggers, calendars, custom fields, pipelines, tags, forms, funnels and dashboards. They are “designed to transfer configuration and selected reusable assets, not live account activity or customer records”: contacts, appointments, conversations and message history, reputation data, Stripe connections, integrations and assigned phone numbers do not transfer.

That second list is the one to plan around. Configuration travels; the client’s actual history does not. Contacts, conversations, appointments and phone numbers have to arrive by another route, which means a client migration is always two jobs rather than one — apply the template, then move the data — and the second is the one that takes the time.

The pricing page describes the white label scope and names the plan carrying SaaS Mode:

“white label the desktop web app, meaning your clients see your logo and branding”. Agency Pro includes SaaS Mode, which “transforms HighLevel into your own sellable software product”.

That distinction decides your plan more often than any feature list does. Rebranding a delivery tool for clients you already bill is one thing. Selling software as your own product — your pricing, your sign-up, your subscriber relationship — is another, and the supplier places it on the top plan.

1. Decide which of the two you are actually doingBranding a delivery tool, or running a software business. The second changes what you owe your customers: support, uptime expectations and a billing relationship that did not exist when you sold services.
2. Check what your clients receive, not what your dashboard showsSend yourself a real notification from a sub-account and read it as the client would. The header is easy to get right; the email footer is where unbranded text survives longest.
3. Write down what you are willing to promiseIf you tell a client the platform is yours, you inherit questions about it. Decide before the first sale what you say when something breaks upstream and you did not build it.

These are structural patterns, not case studies. No agency is named and no result is claimed, because this site has neither.

• Retainer agency, branded client login

  NeedsClients want visibility on their own leads without a weekly email thread, and the agency wants that visibility to look like part of the service.

  In practiceOne sub-account per client, agency logo on the login screen and app header, whitelabel domain configured so the URL is the agency’s. The client sees their pipeline; they do not see the supplier.

• Productised service, repeated setup

  NeedsEvery new client gets essentially the same funnel, forms, calendar and follow-up sequence, rebuilt each time by whoever is free.

  In practiceBuild it once in a reference sub-account, create a snapshot, apply it to each new client. Configuration lands ready; contacts and history still have to be imported separately.

• Agency selling access as its own product

  NeedsThe agency wants recurring revenue from software rather than only from hours, and wants to set its own price.

  In practiceSaaS Mode on the top plan, which the supplier describes as turning the platform into a sellable product of your own. This is a business model change, with support obligations attached.