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. Regular customer bots use paid bot slots. Only chatbots explicitly created with the admin’s test option stay outside that slot count; their messages, indexed content and storage still consume package resources.

In Admin → Users, choose Create directly, not Invite user. Enter Northstar Demo Client and wl-client-tutorial@example.com, then set a strong password. The recording uses a newly generated random password that stays masked and is never saved in the public material. Direct creation sends no email.

After Create, look for exactly one new row with role user and active status. This is a regular customer account without automatic expiry. Record its internal ID privately so the temporary demo can be removed precisely. For a real customer, share access through your approved secure channel; never expose a password in a screenshot, narration or support chat.

Stay signed in as the white-label admin. Choose Create New in the sidebar, enter Northstar Demo Bot and select Test chatbot (archived after 14 days). Then select Create. For example, an agency can prepare this separate demo for a prospect before allocating a regular customer chatbot.

On the new chatbot page, look for This is a test chatbot and Convert to regular chatbot. The sidebar must show Test beside Northstar Demo Bot. Open the bot from that sidebar entry if you want to check its status again. The name alone does not create a test chatbot: the selected option and the saved status are what matter.

Compare the organization’s paid chatbot usage before and after creation. This bot should add no paid slot, but its messages, indexed content and storage still count against the shared package limits. The bot belongs to the admin who created it. It is separate from Northstar Demo Client and must not appear in that customer’s list.

After 14 days, the bot is archived and stops answering. Its settings and sources remain, but its indexed knowledge is cleared. Convert to regular chatbot keeps an active demo as a regular bot; reactivating an archived bot also makes it regular and requires a free paid bot slot. Reactivation queues its sources for indexing again. Wait for indexing to finish before testing answers; a connected mailbox must be enabled again separately. An archived bot is permanently deleted after 120 days, approximately four months. These later lifecycle transitions are explained from the product rules, not demonstrated by advancing the clock in this tutorial.

Return to Admin → Users and edit only Northstar Demo Client. 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 Northstar Demo Client row. The orange impersonation banner must identify wl-client-tutorial@example.com. Create one regular assistant named Northstar Client Test. Test is only part of its example name, not its status. It uses the customer’s regular bot allocation and has no automatic expiry. Verify that Chatbots, Conversations and Analytics open and that only Google Vertex (EU) is available as an internal provider.

Check the customer’s chatbot list: it should contain Northstar Client Test, not the admin-owned Northstar Demo Bot. The customer’s bot must have neither the temporary-demo notice nor a Test badge. No AI answer is generated in this permissions check, so selecting the provider is not evidence of an actual provider request.

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 Northstar Demo Client and verify that its credentials are rejected. 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. This does not delete the admin’s separate Northstar Demo Bot. The local capture runner removes that prospect bot when it deletes the isolated admin and organization in its final cleanup.

Restore the saved branding snapshot, remove the exact uploaded demo logo files, restore or clear the tutorial domain and verify no checkout, invitation, model-provider call or external customer mail occurred. Final cleanup must report zero tutorial users, organizations, bots, dependent rows and uploads. Customer deletion alone is not enough to establish those five results.