> ## Documentation Index
> Fetch the complete documentation index at: https://docs.vorel.ai/llms.txt
> Use this file to discover all available pages before exploring further.

# Team assistants

> Work your workspace from Telegram, WhatsApp or any MCP client, without opening the dashboard.

Most of your team does not want another dashboard. Team assistants put the workspace where they
already are: a chat app, or the AI client they already use.

<Note>
  These surfaces are for your staff, not your customers. They are separate from the
  [customer channels](/channels/overview) with the same names, and a staff message is never treated
  as a customer conversation.
</Note>

## The three surfaces

<CardGroup cols={3}>
  <Card title="Telegram" icon="telegram" href="/assistants/telegram">
    Alerts, replies, commands and approvals, in a DM or a team group.
  </Card>

  <Card title="WhatsApp" icon="whatsapp" href="/assistants/whatsapp">
    The same, one to one, for teams already living in WhatsApp.
  </Card>

  <Card title="MCP" icon="plug" href="/assistants/mcp">
    Connect an AI client directly to your workspace data.
  </Card>
</CardGroup>

## What an assistant can do

**Answer questions about your workspace.** "How many escalations are open?", "What did the customer
on +971 50 123 4567 last ask about?", "How did we do on response times this week?" The assistant
runs real queries against your data rather than guessing.

**Deliver alerts.** Escalations, SLA breaches, mentions and the daily digest.

**Act.** Acknowledge an escalation, reply to a customer, pause or resume the agent. Write actions
are off unless you enable them, and can require approval. See [Governance](/assistants/governance).

## Linking a person

A chat platform hands us an opaque account id and no proof of who is behind it. So the proof comes
from the side we already authenticate: an owner or admin mints a one-time code in the console, and
the staff member carries that code into the chat app.

<Steps>
  <Step title="Mint a code">
    In **Settings, then Channels**, generate a link code for the person.
  </Step>

  <Step title="Redeem it in the chat app">
    They send the code to the bot, or open the deep link the console gives you.
  </Step>

  <Step title="Linked">
    Their chat account is now bound to their user in your workspace, with their role.
  </Step>
</Steps>

A code is single-use and expires. At most one live binding exists per chat account, so a chat cannot
be connected to two workspaces at once.

Sending `STOP` from a linked account unlinks it.

## Permissions follow the person

An assistant does not have its own permissions. When someone acts through it, their role is read
from your workspace at the moment of the action, not taken from anything the chat platform said.

This has a consequence worth stating plainly: **being in the group is not permission**. In a shared
team group, the assistant answers whoever asked, checks that person's role before doing anything,
and refuses if they are not allowed. A colleague cannot press a button in a group and have it act
with someone else's authority.

## Privacy in groups

Answers to an individual's question render for that person alone where the platform supports it, so
a group does not become a broadcast of everything anyone asked.

Internal notes written through an assistant are internal notes. Customer replies sent through an
assistant are customer replies. The distinction is explicit in the syntax, and the safe option is
the default.

## Getting started

Connecting an assistant needs a step from us and a step from you. Talk to your operator about which
surfaces you want, then link your team under **Settings, then Channels**.