Skip to content

Putting your brand in front of clients

Setting your brand name, logo, colour and support email for the surfaces clients see, and an exact account of which surfaces carry your branding and which do not.

Updated

White-labelling presents your brand rather than the product's on the surfaces your clients reach. Setting it up takes a minute; knowing where it actually appears matters more.

Your branding reaches guest approval pages and the client portal in full: name, logo, colour and support email. It reaches reports partly: the report a client downloads from their portal carries your brand and no product attribution, while the report screen inside the app does not. It does not reach email at all, because there is no mail layer in this product and nothing is sent under anybody's brand.

The page states this itself, surface by surface, rather than making a general claim.

BEFORE YOU START

  • The "administer" permission to change anything. Any member can read the settings.
  • Your logo as a PNG, JPEG or WebP no larger than 512 kilobytes.
  • Your brand colour and a support email address you are happy for clients to use.

STEPS

  1. Open White label, or go to /app/white-label.
  2. Set the brand name clients should see.
  3. Upload the logo. It is served from Social Studio's own address rather than fetched from elsewhere.
  4. Set the primary colour and the support email.
  5. Turn white-labelling on. While it is off, clients see the product's branding everywhere, and the page says so.
  6. Read the coverage table to see exactly which client-facing surfaces carry it.

WHAT YOU SHOULD SEE

A preview of what a client would see, and the coverage table marking each surface as carrying your branding, carrying it partly, or carrying the product's.

WHAT THIS WILL NOT DO

  • It will not brand email. Notification email is not sent by this product at all.
  • It will not brand the report screen inside the app. Only the downloadable report a client takes from their portal is branded.
  • It will not serve a custom domain. A domain you save is stored and never used: a domain is only served to clients once it is verified to point at Social Studio, and the verification flow arrives with the DNS setup. Saving does not activate it.
  • It will not remove required product attribution unless your plan permits it.

WORTH KNOWING

The legacy logo address field is kept for accounts that used it, and it is cleared the moment you upload a logo. Client-facing pages render only the uploaded one.

IF IT DOES NOT WORK

  • "The logo could not be uploaded (PNG, JPEG or WebP, max 512 KB)." names both constraints.
  • "Could not save branding." is the fallback; the server's own message about an invalid colour or an unsafe logo address is shown when it gives one.
  • "administer permission required." means your role can read but not change.
  • "That portal link could not be created." and "That access could not be revoked - it may still be active." relate to the client portal grants panel on the same page.

COMMON QUESTIONS

When will my custom domain work?

There is no date to give. What can be stated is what happens now: the domain is saved, it is not verified, and nothing is served on it.

Does the terminology setting do anything?

It is stored and used where the product reads it, and there is no field for it on this page. It is set through the API.

  • Giving a client a portal

    Creating a read-only portal link for a client, choosing which of the four sections they can see, and why approving is not one of the things they can do there.

  • Organisations, workspaces and brands

    What each level of the hierarchy actually holds, when workspace isolation applies and when it does not, and how a client subaccount differs from a workspace.

  • Reading your reporting

    What the workspace report totals, why a figure can say "Not reported" instead of zero, and the two ways a figure reaches it.