How to set up a white label chatbot platform as an admin

Sign in as the dedicated WL administrator and open Account from the header. The account must resolve to role admin inside an organization whose type is whitelabel. The sidebar then shows the organization-scoped Admin section with Users; it must not expose platform-wide Organizations, Costs, Revenue or other superadmin routes.

Record the organization name, account identity and current host without showing a password, session token or SMTP secret. If the expected status, Branding card, SMTP card or Users link is absent, stop. Do not continue under a normal user, team member or platform superadmin.

At the top of Account Settings, read the current plan, chatbot pool, messages per month, training-data characters and domain verification badge. The first number is live organization-wide usage; the second is available capacity. Users later receive personal caps from this pool.

You may open add-on, plan and voice dialogs to explain available choices, but do not accept terms, select Buy now, change a paid quantity, cancel a tier or open the Stripe portal during the reusable capture. A billing preview is not a test purchase.

Open Set up whitelabel and enter only the approved host name, without https://, a path or trailing slash. This tutorial uses northstar-wl-tutorial.test, a reserved local-only value that cannot prove domain ownership, public routing or certificate readiness. Replace it with a dedicated organization-controlled subdomain only in the separate production rollout.

Changing the domain clears its previous verification. Confirm the intended host with the DNS owner, identity owner and support team before saving. Do not reuse a production login domain for a tutorial or point an apex domain without a reviewed DNS and mail-impact plan.

The setup page displays the production workflow: copy the exact record type, name, target and TTL to the organization’s DNS provider. CNAME is the recommended option; use an offered A-record fallback only after the DNS owner reviews the operational trade-off. No DNS record was created or queried during this reusable local run.

The green state in the screenshot was seeded locally to explain the interface. For production, wait for propagation, select Check DNS now, require DNS correct and Verified, then open the HTTPS tenant URL in a clean browser and confirm certificate, host and branded login. None of those external DNS or HTTPS checks is claimed by this tutorial evidence.

In Branding & whitelabel, set the fictional platform name Northstar AI Studio, support@example.com, primary color #029cf5, “Powered by Northstar AI Studio”, https://example.com, a fictional footer and the reserved imprint and privacy paths under example.com. Upload the approved TEST logo and favicon; the real organization must use its own reviewed assets and legal pages.

Save once and allow the application reload. Check that no field is clipped and that image proportions are preserved. The primary color generates the interface color scale, while email footer links are separate from the SMTP sender name and address.

Open Dashboard after saving. Confirm the Northstar logo, the Welcome back, Northstar heading, the real No Chatbots Yet card, the organization name in the browser title and the saved blue theme. This view is deliberately different from Account Settings, so it proves that the persisted branding reaches another product route.

For the production launch, open the verified tenant domain in a separate clean session. Check the favicon, certificate, login page, blue focus and button treatment, account links and customer-facing support contact. Inspect desktop and a narrow viewport without changing to Dark Mode.

Load Email / SMTP before entering anything. Use the organization’s approved non-production host, port, SSL mode, username, password, sender name and sender address. The password must come from a secret store and remain absent from screenshots, narration, logs, source files and manifests. Leaving the password empty keeps an already stored secret.

Save only after the current configuration loaded successfully. Test connection may contact the SMTP server, so run it only against the approved sandbox. For a delivery proof, invite only a controlled inbox after connection passes. The server refuses white-label mail without usable own SMTP to prevent a WebChatAgent sender leak; a failed test blocks the invitation step.

Open Admin → Users. The organization pool cards show live used capacity and the amount already distributed. The customer table then shows account status, actual chatbot count, personal allocations, allowed internal model providers and last activity.

Leave a resource empty when the customer should draw from the shared organization pool. Enter a number only when the contract or risk policy needs a personal cap. Messages, indexed content and storage used by TEST customers still consume package resources even though their bots do not consume paid bot slots.

Choose Create directly, not Invite user. Enter Northstar Demo Client and wl-client-tutorial@example.com, supply the password only from the protected capture environment and enable Test account. Direct creation sends no email, creates a plain user and adds the 14-day auto-delete marker.

Require exactly one new row with the Test badge and expiry text. Record the new user ID outside the public artifact for exact cleanup. Never use a customer, colleague or reachable address, and never read the password aloud or type it while a zoomed crop could expose it.

Edit only the new TEST row. Allocate 1 chatbot, 2,000 messages per month and 500,000 training characters. Restrict internal providers to Google Vertex (EU). Turn on restricted dashboard access and grant Chatbots, Conversations and Analytics. Mark Leads as a locked preview; leave Live Chat, Feedback, Questions, Bookings, Tickets and Calls hidden.

Save and reopen the customer to confirm persistence. A teaser is not access: it shows a blurred feature preview and the organization contact route. Tightening the customer restriction also clamps that customer’s team-member permissions; lifting the restriction later does not automatically restore removed rights.

Use Log in as this user on the active TEST row. The orange impersonation banner must identify wl-client-tutorial@example.com. Create one assistant named Northstar Client Test and verify that Chatbots, Conversations and Analytics open. Confirm the customer can select only Google Vertex (EU).

Open Leads and require the locked preview instead of live data. Try a direct Bookings URL and require a return to Dashboard without protected content. The customer must not see Admin → Users, Account white-label status, Branding, SMTP, plan purchase or another customer’s assistants. Record allowed and denied results separately.

Exit impersonation through the orange banner and require the WL admin to return to /settings/users. Disable the exact TEST user and verify its active session loses authenticated access. Re-enable only long enough to finish a planned check; otherwise continue directly to permanent deletion.

Delete wl-client-tutorial@example.com and confirm the warning that its assistant and data are removed. Query the organization inventory again and require the user, Northstar Client Test bot and dependent records to be absent. Restore the saved branding snapshot, remove uploaded TEST logo files, restore or clear any tutorial domain, leave SMTP untouched unless a dedicated sandbox snapshot was changed, and verify no checkout, invitation or external customer mail occurred.