Floating launcher

The floating launcher is a small button pinned to a corner of your site. Click it and a short menu opens — find answers, suggest an improvement, and whatever links you add.

It is a different embed from the Support Hub, with its own script, its own settings and its own behaviour. They are easy to confuse because they look similar on the page and accept some of the same attributes.

Which one do you want

If you want visitors to talk to you, you want the Support Hub. If you want a tidy entry point to your help content and a way to collect suggestions, without staffing a conversation, the launcher is the lighter option.

They can both be on the same page. They do not talk to each other — see using both.

Install

<script
  src="https://clientsphere.io/embed/support-launcher.js"
  data-company-id="your-workspace-id">
</script>

The launcher needs to know which workspace it belongs to. Either attribute works:

• data-company-id — your workspace id
• data-widget-id — a Support Hub widget id, which the server resolves back to the workspace

The second exists so you can reuse the id you already have in a Support Hub tag rather than finding another one. The same value in the two different script tags does two entirely different things, which is the single easiest mistake to make here.

Provide neither and the script logs an error naming both attributes, and stops.

What the menu contains

Four items are configured by default:

Set the label, colour, corner and the items themselves under Customer Support → Floating Launcher. Each item does one of:

Two of the defaults are link items with an empty url, so they do nothing until you fill them in.

Configuration is cached for a minute at the edge, so a change can take up to that long to reach a visitor already on your site.

Identifying the submitter

You can pass who the visitor is:

<script
  src="https://clientsphere.io/embed/support-launcher.js"
  data-company-id="your-workspace-id"
  data-user-email="jane@acme.com"
  data-user-name="Jane Doe"
  data-customer-name="Acme Corp">
</script>

They are recorded on any feature request the visitor submits, and they create CRM records — exactly as the Support Hub does with the same details.

What identification creates

When the launcher loads with an email address:

• finds the matching contact, or creates one with a source of support_launcher
• finds or creates an account when a company was given, and links the two
• saves the suggestion as a feature request pointing at that contact

The address is matched case-insensitively, so Ada@Example.com and ada@example.com are one person rather than two contacts.

Submitting a suggestion resolves the same person again, which by then is a lookup rather than a new record, and is what attaches the suggestion to their contact. Without an email address the suggestion is still saved — it simply has no contact attached.

Using both

Nothing stops you running the launcher and the Support Hub on the same page, and it is a reasonable setup: the launcher for self-service, the widget for conversations.

They are independent, though, and one gap follows from that. A launcher item with the chat action cannot open the Support Hub. It falls back to opening the item's url in a new tab, and does nothing at all when that is blank. To send someone from the launcher into a conversation, point a link item at a page where the Support Hub is embedded.

Appearance

data-theme on the script tag takes auto, light or dark and overrides the workspace theme, the same way it does for the Support Hub.

When the launcher does not appear

• Neither id attribute is set. The script logs an error naming both and stops.
• The workspace id is wrong. The configuration request returns 404 and nothing renders.

Both fail quietly on the page and report themselves in the browser console.