For SaaS teams

Three properties. One support team.

Your marketing site, your docs and your app are three different conversations with three different people — a prospect comparing plans, a developer stuck on an endpoint, a customer whose billing failed. They should not all land in the same undifferentiated queue, and they should not cost you three subscriptions either.

1 Workspace for every property you run
1 Snippet — the same token on all of them
Per-domain Routing, greetings and agents

Sound familiar?

These are the four things SaaS teams tell us before they switch. If none of them land, you probably do not need us yet.

A separate workspace per property

Marketing, docs and app each got their own install, their own settings and their own invoice — and now nobody can see the whole picture.

Docs questions in the sales queue

A developer asking about pagination lands in front of whoever is next, and waits while they find someone who knows.

Paying for seats you do not use

Per-agent pricing means the engineer who answers two hard questions a week costs the same as a full-time agent.

The widget slowing your own app

A support script that opens a socket and starts polling on every page load, whether or not anyone wants to chat.

One workspace

Every property, one place to look.

Whitelist each domain and subdomain you run. The same script tag and the same token serve all of them, so shipping chat on a new property is a dashboard action rather than a second install and a second invoice. Every inbox and every report filters by domain, so "how is docs doing" is a dropdown, not an export.

  • Marketing, docs and app under one workspace
  • One snippet and one token across all of them
  • Per-domain filtering on inboxes and reporting
  • Domains are reviewed before they go live — no rogue installs
Routing

The docs question goes to someone who reads docs.

Group your people into departments and assign departments to domains. A question from the docs site reaches whoever owns docs; a billing question reaches billing. When an engineer is only on rotation two afternoons a week, a concurrency cap of one keeps them from being buried.

  • Departments assigned per domain, not per person
  • Per-agent concurrent-chat limits
  • Transfer to a department with the full history attached
  • A visible waiting queue when everyone is at capacity
Your app’s performance

A support widget that costs your dashboard nothing.

You spent real time on your app’s load performance; a chat script should not undo it. Before a visitor clicks the launcher there is no session, no heartbeat, no polling and no socket. The widget also registers no beforeunload handler, which is the thing that quietly disables the back/forward cache for the whole page in Chrome and Firefox.

  • No socket, session or polling before the first click
  • Config arrives inlined with the snippet — no init round-trip
  • No beforeunload, so your bfcache survives
  • The launcher paints on the first frame

The parts that matter most here.

Three of the six feature pages, picked for this audience rather than listed alphabetically.

Questions from teams like yours.

Do I pay per domain?

No. Domains count against your plan’s limits rather than being a separate line item, and one token serves all of them.

Can each property have its own greeting and colour?

Yes. Set a workspace default, then override only the fields that need to differ on a given domain — the rest keeps inheriting, so a brand tweak does not mean editing every site.

Can engineers help out without being full-time agents?

Yes — add them as agents, assign them only the docs domain, and set their concurrent-chat limit to one so they are never buried.

Does the widget slow the app down?

It does essentially nothing until someone clicks it: no session row, no heartbeat, no polling loop and no WebSocket. See Widget & branding for the detail.

More of these on the general FAQ.

See whether it fits. This week.

One line of code, no card to start. If it is not right for you, you will know within an afternoon — and we would rather hear why.