A client who hires you to add an AI chatbot or assistant to their site is very rarely also hiring you to put your own agency’s name on it in front of their customers. The feature needs to look and feel like it belongs to the client’s brand, end to end. This is white-labeling: the standard agency and SaaS practice of delivering a feature so that the end customer sees the client’s brand throughout and has no reason to know which vendor or agency actually built the underlying technology. This lesson covers the practical layers that actually need addressing, not just the visible UI.
Lesson 1’s productized-service framing. This lesson assumes the AI feature itself (chatbot widget, assistant, MCP-backed integration) is already built and working, using this track’s earlier ability and MCP patterns.
Step 1: The layers of white-labeling, not just the widget’s colors
| Layer | What leaks if ignored | What to do instead |
|---|---|---|
| Visible UI | Your product name, logo, or default color scheme in the widget | Rebrand name, avatar, and colors to the client’s own brand, treated as a required delivery item, not a nice-to-have |
| Domain and URLs | API calls or embedded assets served from your-agency.com in the browser’s network tab | Serve client-facing endpoints from a client-owned subdomain, even if it proxies back to shared infrastructure |
| Technical fingerprints | Response headers, error message text, or file paths naming your product or agency | Audit outgoing responses and error copy for anything that names your tooling by name |
| Support contact | An email address or support link pointing at your agency instead of the client | Route end-customer-facing support through the client’s own channel, keep your support relationship with the client, not their customers |
| Legal and licensing footer text | ”Powered by [your product]” badges some off-the-shelf chat widgets add by default | Confirm the underlying widget or library’s license actually permits removing attribution, don’t assume it does |
Step 2: Rebranding the widget itself
The visible layer is the one most agencies get right by default, since it’s the most obvious. A chatbot or assistant widget’s name, avatar, greeting message, and color scheme should match the client’s brand, not whatever the widget shipped with by default. This is genuinely just design and configuration work, most chat widget implementations expose these as configurable properties precisely because white- labeling is such a common requirement. The part worth calling out deliberately is tone: a widget’s default response style (formal, casual, terse) should match how the client’s own brand actually talks to its customers, which is a conversation with the client, not a default you leave unexamined.
Step 3: Domains and URLs, the layer that’s easy to skip
Even when the visible widget is fully rebranded, a technically curious end customer
can open their browser’s network tab and see exactly which domain the chatbot’s API
calls are actually going to. If that domain is your-agency.com or a shared multi-
tenant hostname, the white-label illusion breaks the moment anyone looks. The standard
fix is a custom domain: point a subdomain the client owns (chat.clientdomain.com, or
similar) at your shared infrastructure via a CNAME record, so every request an end
customer’s browser makes appears to go to the client’s own domain even though it’s
served by infrastructure you operate on their behalf.
This is standard practice in white-labeled SaaS generally, not an AI-specific technique, applied here to a WordPress client’s chatbot or assistant endpoint specifically.
Step 4: What “the underlying stack stays invisible” actually requires
Beyond the domain, a handful of smaller technical details are worth an explicit audit
rather than an assumption that they’re fine. Response headers (X-Powered-By or a
custom header naming your product), error messages returned to the browser
(“MyAgencyAI encountered an error”), and even file paths visible in a widget’s loaded
assets (/wp-content/plugins/my-agency-chatbot/) can all quietly reveal who actually
built the feature, none of which matters to you until the specific client relationship
requires it to be invisible, at which point it matters a great deal.
Some clients are genuinely fine being known to use a named third-party AI vendor or agency, particularly smaller businesses without a strong brand-consistency requirement. Ask rather than assume: full white-labeling is real, billable delivery work, and building it for a client who doesn’t need it is effort spent on the wrong thing.
Recap
White-labeling an AI feature for a client goes well beyond the widget’s visible colors and name. A custom, client-owned subdomain (via a standard CNAME setup) keeps the underlying request domain from revealing your involvement, and a deliberate audit of response headers, error messages, and third-party attribution badges catches the technical fingerprints that are easy to overlook until a technically curious end customer notices them. Not every client needs the full treatment, but where a client does, treat it as a defined, billable part of the delivery scope from Lesson 1’s productized package, not an afterthought bolted on at the end.
Resources & further reading
- Packaging AI/MCP Work Into Productized Services, this course, Lesson 1, where white-labeling scope belongs in a package definition
- Advanced WordPress MCP Architecture & Enterprise AI, this track, the multi-server and routing patterns behind serving multiple clients from shared infrastructure