Two people sharing a login is the most common access-control failure on any SaaS product, and it is almost always a symptom of a permission model nobody understood. Chat.co's is genuinely simple once you see the split: admins get account-wide toggles, team members get per-bot, per-action grants.
1. The roles
Everything is managed from Team in the main sidebar — one page covering both admins and staff.
| Role | Scope | Typical person |
|---|---|---|
| Business Owner | Everything, including billing and account deletion. There is one. | The person whose card is on file |
| Admin | Account-wide, limited by a set of permission toggles the owner sets | An operations lead or second-in-command |
| Team member | Per bot, per feature, per action — nothing by default | Support agents, content editors, contractors |
2. Admin permissions
Each admin carries an independent set of account-wide toggles:
| Permission | Grants |
|---|---|
| Chatbot creation | Create new bots |
| Chat logs | Read conversations across bots |
| Knowledge base | Manage documents, links, text and Q&A |
| Configuration | Change bot settings and behaviour |
| Team management | Invite and manage other admins and team members |
| Billing | See and change the subscription |
| Delete chatbots | Raise a deletion request — the owner still has to approve it |
| Voice line | Edit phone line settings, voices, numbers and recordings. Without it, view-only. |
Deletion is handled as a two-step on purpose. An admin with the delete permission can request removal of a chatbot; the owner approves it. Destroying a trained knowledge base is not something anyone should be able to do alone in a single click.
3. Staff permissions
Team member access is granted per bot, and within each bot per feature and per action.
Features
| Feature | Covers |
|---|---|
| Chat logs | Conversation history, and the Handoff queue |
| Knowledge base | Documents, links, text and the Knowledge Gaps screen |
| Manage leads | The Leads screen and lead exports |
| Q&A | Q&A pairs (kept in step with knowledge base in the UI) |
| Tune bot | Model, system prompt, creativity, and bot settings |
| Appearance | Widget look and feel, and deployment settings |
Actions
Each feature carries four independent flags — view, add, edit and delete. That granularity is what makes the useful configurations possible:
Support agent
Chat logs: view. Leads: view. Nothing else. Can read and act on conversations, cannot change how the bot behaves.
Content editor
Knowledge base and Q&A: view, add, edit. No delete, no tune bot. Can improve answers, cannot remove your corpus or change the model.
Read-only stakeholder
View on everything, add/edit/delete on nothing. Perfect for the person who wants visibility without the ability to break something.
4. Seats
Admins and team members draw from a single shared seat pool. There is no separate admin allowance — adding an admin consumes a seat exactly as adding a team member does.
| Plan | Team seats |
|---|---|
| Starter | 1 |
| Pro | 1 |
| Business | 10 |
| Enterprise | Unlimited |
Need more without changing plan? Seats are available as an add-on — the Team page offers the purchase flow directly when you hit the limit, so you are not sent hunting through billing.
5. Inviting someone
- 1
Open Team
From the main sidebar. Admins and team members are both managed here — the sections are separate but the page is one.
- 2
Decide which role they need
Account-wide responsibility is an admin. Work on specific bots is a team member. When it is genuinely ambiguous, team member is the safer starting point — it is easier to add access later than to explain why someone had it.
- 3
Invite by email
They receive an invitation and set up their own credentials.
- 4
Set permissions before they accept, not after
For a team member, choose the bots and the per-feature actions. Doing this up front avoids the window where someone is logged in and nobody has decided what they should see.
6. Getting the model right
Grant the narrowest thing that works
Start from nothing and add what the person is actually blocked on. The opposite approach — grant broadly and trim later — never gets trimmed.
Review when people change roles
The permissions someone needed in their last role follow them into the next one unless somebody looks. A quarterly pass over the Team page takes ten minutes.
Separate audiences with bots, not permissions
Permissions control who can administer a bot. They do not filter what a bot knows. If a document must not reach a particular audience, it belongs in a different bot — see managing multiple bots.
Use SSO once you are past a handful of people
With OIDC single sign-on, access follows your identity provider — so offboarding someone there offboards them here, with no manual step to forget.