Skip to main content
A channel is a two-way line between you and a customer. Requests come in on it; replies go back out on it. Run all of them at once if you like. It makes no difference to your team, because every channel feeds the same inbox. Find them in the dashboard under Channels.

Chat

One script tag on your site. Works on any page.

Contact form

A card you place inside your own contact page.

Email

Forward your existing support address.

Telegram

Connect your own bot. One paste.

Instagram

Direct messages to your Instagram account.

Messenger

Messages to your Facebook Page.
The API is one more way in. It does not appear on that screen because there is nothing to configure. Any ticket created through the REST API arrives with source: "api". Discord is filed with these and is not one of them. No customer is on Discord: it is a place for your team to read and answer the conversations that arrive on the channels above, without opening the dashboard. On the Channels screen it is listed under integrations, apart from the channels, and it never appears as a conversation’s source.

​
One of each kind

A workspace supports at most one chat widget and at most one contact form. Email is one address, Telegram is one bot, Instagram is one account, and Messenger is one Facebook Page. An Instagram account or a Facebook Page can only belong to one workspace at a time. If you need chat on two domains, use a single placement and list both domains on it. Do not create a second placement.

​
Picking one

Email is where most workspaces start. The address already exists, and customers already use it. Chat usually follows once you want to reach people before they leave.

​
What is the same everywhere

No matter which channel a conversation arrives on:
  • It becomes a ticket, carrying a reference and a requester.
  • Triage fills in a priority and a category if the message does not make them obvious.
  • The language is detected, and your team can reply in it.
  • The AI drafts a reply from your reference documents. It either suggests one or sends one, depending on your settings.

​
Requesters, and what “verified” means

The requester is the person on the other end. Whether they are verified comes down to who vouched for them. There are exactly two answers. Verified: an API credential supplied an external_id. Someone holding a key we issued vouched for this person from their own server. Unverified: anything else. An address a visitor typed into chat, or a value a web page asserted. That line is drawn where it is because anything a page can claim without proof, anyone with devtools open can claim too. Our JavaScript runs on your visitor’s machine, which makes it theirs, not ours. Unverified is still useful. An agent who sees “claims to be sam@acme.com” can act on that with judgement. It just never adds up to proof.