Customize widget appearance

Open the Appearance view#

Open Websites, select the intended website and choose Appearance. Review the selected hostname before changing settings, especially in a workspace with several domains. The form applies to that website rather than all installations.

Use Save appearance, then reload a public page. The widget retrieves settings during its installation check; a page already open can keep its earlier settings until reload. The installation code stays the same. An appearance save does not need a new crawl, plugin reinstall or credential replacement.

Available controls#

The service enforces the effective plan when returning settings. A customization outside the current entitlement falls back to its allowed default. These controls change presentation; they do not change underlying intelligence, capacity, verification or Action confirmation.

Choose an appropriate assistant identity#

Use a recognizable assistant name and an avatar that stays clear at chat-header size. Host the image at a stable public HTTPS URL you control or are entitled to use. A URL requiring your administrator login or an expiring private session is unsuitable for visitor display.

The image loads in the visitor's browser. If your site restricts image origins through CSP, review that origin with your developer. Keep tokens and unnecessary personal information out of the URL. The website name below the agent identity comes from website configuration; renaming the agent does not create a human operator or remove the visible AI disclaimer.

Styling boundaries#

The official widget renders in a closed Shadow DOM, not an iframe. Ordinary page selectors cannot provide a supported restyle of its internal typography, controls or message bubbles. There is no documented arbitrary-CSS or custom theme-token interface. Use Appearance rather than private selectors or injected markup.

Keep your own fixed controls clear of the launcher area and test an actual narrow phone with its keyboard open. If browser policy blocks the widget's inline styles, changing its theme cannot repair that directive. Have the developer inspect the actual violation and the loader's supported behavior.

Feedback and conversation controls#

When feedback is enabled, helpful and not-helpful controls can appear under an answer that the service marks as resolving the conversation. Their absence under every reply is not necessarily a failed save. Review a qualifying answer and its retained workspace conversation.

Conversation-start and latest-message controls are normal navigation features. Talk to the team depends on support policy and configuration, not the avatar or theme. Test these interactions separately from branding so you can identify whether a problem concerns appearance, answer feedback or the support process.

Choose an identity customers can recognize#

A useful support identity answers a practical question: which business is speaking, and how can the customer continue? Use a short, recognizable assistant name when your plan permits it, and an avatar that remains clear at a small size. A complex promotional image may look good in a large file and become unreadable in the chat header. Check the actual visitor widget at its displayed size, including on a narrow phone.

Keep the business details in Knowledge consistent with the identity shown in the widget. Changing the assistant’s name does not change its approved policies, Action permissions or support destination. If your business has several websites, review each website’s Appearance view instead of assuming a setting saved on one site applies everywhere. Before saving a branded identity, confirm that the selected website and workspace are the intended ones.

Review the saved appearance on the public website#

Save the Appearance form, reload the public website and open the chat. Check the name, avatar, theme and attribution in the visitor experience. The portal confirms a saved configuration, but an already loaded widget may continue to display the settings fetched earlier in that page session. Reloading obtains the current settings through the installation check.

Use desktop and mobile, a page with a light background and a page with darker content, and a browser with increased text size. Verify that the launcher remains understandable, the composer and close control are usable, and any avatar loads without a broken-image indicator. Keep the same installation code. If appearance did not change, review the saved website and page cache before generating replacement installation credentials. If a plan changes, repeat this check because service-enforced plan limits can affect which saved customizations are visible.

Roll out an appearance change without breaking installation#

First record the current visible identity, theme and attribution for the website you are changing. Prepare an avatar that remains useful when scaled down and a name that does not promise a service your business cannot deliver. Save the available settings in Appearance and reload a public page. Keep the generated installation snippet exactly as it was.

If the change looks wrong, restore the previous supported setting and save again. This reversal does not require a new website record or token. Replacing installation code is a different operation with a wider effect; it invalidates existing copies and can interrupt support until each deployed template is updated. A visual adjustment should stay a visual adjustment.

For multiple websites, repeat the rollout deliberately. Check each public hostname and the saved identity associated with it. A screenshot from the portal is a configuration record; a screenshot of the public chat after a fresh load is evidence of what visitors actually received. Use both when handing the change to a colleague.

When the appearance is not what you expected#

If the standard name remains visible, check the plan and whether the change was saved on the correct website. If an avatar fails, open its URL in an ordinary browser without your administrator session. A login-protected image, an expired link or an image-origin policy can prevent it from appearing. If the entire widget has incorrect styling, inspect browser policy errors and script optimization before trying to compensate with page CSS.

If a colour selection is unavailable, review the plan’s supported controls. If a saved Scale customization stops appearing after a plan change, do not assume the installation was lost. The service applies the effective plan when returning widget settings. Installation and appearance are separate checks.

Report the website, plan, setting, fresh reload time and device when you need help. An image of the intended result and the actual public widget is useful. Redact account identifiers and raw installation credentials. Changing the visual identity does not authorize changes to customer-data access or turn on analytics on the customer’s own website.