把队友分组到不同部门,让项目可见性和共享邮箱的访问权限限定到他们实际所在的小组。 支持、销售和市场默认不再读到彼此的营销活动和客户往来记录,部门负责人可以在自己的小组内直接邀请成员而不必每次都经过账户所有者,而一个个人邮箱除非所有者通过一次需要说明理由并被记录的所有者访问打开它,否则始终保持私密。
一个成长到超出几个人规模的 MailInApp 账户,过去只有一种可见性模型:每一位活跃的编辑者或查看者都能看到账户拥有的每一个项目和每一个共享邮箱。对于一个所有人本来就已经彼此看到一切的小团队来说,这没问题。可一旦「团队」意味着彼此独立的职能小组——支持处理客户往来、销售运行自己的营销活动、市场运行自己的营销活动——而没有任何真正的业务理由让一个小组去查看另一个小组的内容,这套模式就不再合适了。
部门叠加在现有角色之上
部门并不会取代所有者/编辑者/查看者角色——它限定的是其中一位编辑者或查看者能看到什么。账户所有者从设置中创建部门,把队友分配到一个或多个部门,从那时起,一个打上部门标签的项目或共享邮箱,就只对该部门的成员以及所有者可见。一个未设置部门的项目或邮箱,行为与之前完全一样:对整个账户可见。
部门负责人替所有者分担邀请工作
把一位队友提升为其所在部门的负责人,让他们能直接邀请新成员加入该部门——这是一次真正的委派,而不只是一个头衔。负责人的权限范围止步于自己部门的边界:无法邀请人加入自己不负责的小组,无法触及账单或凭证,也无法铸造另一位负责人。所有原本就仅限所有者的操作——SMTP 设置、Stripe Connect、API 密钥、Webhook 密钥、团队管理本身——对负责人来说同样仅限所有者。
个人邮箱是私密的,但并非无法打开
像 support@ 这样一个已认领的收件地址,可以与整个部门共享,也可以设置为个人,分配给某一位具体成员。个人邮箱使用的是一个归公司所有的地址来处理普通的业务往来,因此一堵坚硬的技术墙——让一位离职员工的邮箱永久无法找回——会以牺牲真正的业务连续性为代价,去换取一份法律其实并不要求适用于公司域名下工作往来的隐私保证。所有者进入别人个人邮箱的唯一方式,是所有者访问:选定邮箱、给出理由,然后阅读它——绝不会代替被分配的成员回复。这次访问会被记录,而且该记录之后对邮箱本人的成员可见,不会对其隐藏。
每个人在接受邀请前都会先看到这意味着什么
由于部门归属会改变一位队友能看到的内容,而且所有者访问一个个人邮箱确实是可能的,接受邀请的页面在任何人加入之前,都会先显示一条简短的、用简明语言写成的通知:他们的部门会让哪些内容可见,以及所有者访问始终需要说明理由、并始终会被记录。这里没有单独需要配置的同意流程——接受邀请本身就意味着确认已知悉该通知。
这不会改变的内容
部门内部的编辑者与查看者权限,与以往完全相同——一位限定在某个部门内的编辑者,仍然可以为自己能看到的内容构建、发送并读取响应;一位限定在某个部门内的查看者,仍然是只读的。发送量上限、套餐档位和凭证轮换规则都不受此影响——部门是一层可见性限定,而不是一条新的定价维度,也不是一套新的写入权限。
快速上手
从设置 → 团队中创建与你组织真实架构匹配的部门,把队友分配进去,然后从创建选择器为新项目打上部门标签。完整的参考内容见部门;其下角色和邀请如何运作,见团队协作;部门所限定的共享地址与个人地址如何设置,见收件邮箱。