顺序别颠倒，颠倒就要重来
名称建议用对外能看懂的全称，简称另设。管理员至少两人，其中一个留作备用账号，避免唯一管理员离职后进不去后台。
部门是权限与可见范围的基础。按实际管理关系建，别按办公室座位或者项目临时建，不然后面发通知只能一个个挑人。
先想清楚谁能看见全部通讯录、谁只能看本部门。这一步定下来，后面加人几乎不用再调。
先邀请几位管理员试用一轮，确认消息、文件、打卡这类日常动作都正常，再全量导入。
三种常见建法，后果不一样
| 建法 | 好处 | 后面会碰到的麻烦 |
|---|---|---|
| 按职能分部门 | 权限清晰，通知好发 | 跨职能协作需要另建协作群 |
| 按项目分部门 | 项目内沟通直接 | 项目结束部门就闲置，需要定期清理 |
| 按地区分部门 | 区域管理方便 | 同一职能被拆散，总部发通知要选多次 |
| 单层扁平结构 | 建起来最快 | 人数上去后通讯录很长，找人靠搜索 |
按人数规模选
未认证的组织可以正常使用日常沟通功能，但可邀请的成员规模、对外展示的名称形式以及部分面向客户的能力会受限。人数不多、只做内部沟通的团队，未认证也够用。
需要对外服务客户、或者成员规模较大的组织，建议尽早完成认证。认证材料一般包括主体证件与管理员信息，准备齐了一次就能过，材料缺项会被退回重来。
都出现在注册后的头两周
同一账号可以参与多个组织。切换时注意当前处于哪个组织，发错消息多半是切换没确认。
一般不能。部门归属由管理员在后台调整，成员端只能看到自己被放在哪里。
可以换。换绑之前确认新号码能收到验证码，并且至少还有另一个管理员能进后台。
先停用账号而不是直接删除。停用后聊天记录与文件仍在，交接完成再决定是否彻底移除。
外部协作走外部联系人机制，不要直接把人加进部门。直接加进部门会让对方看到内部通讯录。