成员、角色与团队
邀请团队、每个内置角色能做什么，以及怎么给一个人恰好够用的权限、一点不多。
每个回顾客消息的人都需要自己的账号。共用一个账号是那种"省事"的做法，代价是你从此说不清谁做了什么——这是第一件该修的事。
邀请一个人
团队与角色 → 邀请用户。 你填邮箱、姓名和角色；对方收到链接，自己设密码，然后就进到工作区里了。
关于邀请有两件事要知道：
- 角色在邀请时选定，之后可以改。起点定得比你以为的低一点：事后放宽是点一下鼠标，出事之后再收紧是一场对话。
- 邀请会绑定到持有那个邮箱的人。 发到本人的工作邮箱，不要发到共享邮箱。
三个内置角色
| 角色 | 适合 | 能做 |
|---|---|---|
| Front Desk 前台 | 只负责回消息的人 | 读和回会话（包括用 AI 起草、从 AI 客服手里接手）、看和改联系人、用快捷回复 |
| Agent 客服 | 全职的客服或销售 | Front Desk 的一切，加上分配、备注、标签、在会话里批准或撤销 AI 客服的动作、知识库和自己的报表 |
| Administrator 管理员 | 运营这个工作区的那一两个人 | 全部，包括计费、渠道、角色和审计日志 |
这张矩阵就是定义——它由角色本身生成，所以永远不会和系统实际执行的东西对不上。它也是回答"他为什么看不到那个"最快的方式。
自定义角色
如果三个都不合适，新建角色可以自己勾权限。有用的场景是窄而不是巧：
- 一个市场人员，需要群发和模板，但不该读每一段顾客对话。
- 一个记账的，需要报表和计费，别的都不要。
- 一个外包，需要收件箱两周，之后永远不要。
三个内置角色不能编辑也不能删除——它们是系统依赖的地板。要改就复制最接近的那个成新角色。
团队
团队是一组具名成员——销售、客服、周二班。它存在的目的是路由：一条自动化规则可以把会话分给一个团队，在当前有空的人之间轮转，而不是点名一个可能正在休假的人。
团队不授予权限。一个人的权限来自他的角色；团队决定的是什么会到他面前。
移除一个人
停用成员，而不是删除。他的会话、备注和审计记录会继续挂在一个真实的人身上，而不是变成匿名的，同时账号无法登录。删除是留给"发错了邀请"这种错误的，不是留给离职的。
有人离职当天要做两件事：停用成员，以及在受信任设备里检查有没有他的设备还被放行着。
一套能用的默认
- 管理员：两个人。 一个是单点故障，四个是没人负责。
- 其他人：Agent，除非有理由不是。
- Front Desk 给兼职和顶班的人。
- 在有人入职或离职时复核这份名单，其他时候不用——一个没人做的季度审计，比一个在正确时刻触发的习惯要糟。