Concepts
Support app
One of your apps that embeds support: how the SDK looks in it, where it may run (web origins), and its publishable keys. The keys go in the app; revoking one cuts the app off.
Conversation
Every message a user sends becomes a conversation they can follow in the app, and your team sees it in the Support inbox, with the app version and device attached. A user’s reply reopens a closed conversation. An in-app message can carry a screenshot of the screen the user was on: the user saw it, and hid what they chose, before sending.
Channel
Where a conversation comes from: the in-app SDK, the web widget, email, WhatsApp, Telegram or a call-back request. In-app and web need no setup; connect the others in Channels. Their tokens go in the vault, on Settings → Keys. Replies go back the way the conversation came.
Help article and the assistant
Help articles are what each app’s assistant answers from. It answers only from them, names the ones it used, says so when it can’t answer, and moves the user to a person, with the conversation attached, whenever they ask. “Talk to a person” is always there.
Proactive rule
When an error hits a user your app has identified, a rule opens a conversation with them before they write in, in their language. One message per user per error, none while they already have an open conversation, and only with their consent. An unanswered conversation closes on its own.
Identified user and profile
When your app tells the SDK who the user is (your own opaque id), their messages and call-backs carry it, and your team can reach them in the app. Each user’s conversations, errors, events and orders sit in one profile. Email and phone are hashed on the way in, consent is recorded, and deletion requests are honoured.
Call-back
From the form, a user can leave a number, what the call is about and a time that suits. It lands in the inbox as a call-back request.
Flows
The assistant can start a chatbot flow when a question maps to one the app lists, and run it in the support sheet.