结论先行：协作平台上线之后，管理员很快会碰到两个没有标准答案的问题：容量按部门分还是按人分；员工离职后他名下那部分空间归谁。这两件事如果在开通时不定清楚，后面会变成两种麻烦——反复的例外审批，或者一批没人认领的文件。可行的做法是把空间分成三级、把人走了之后的三样东西一起定进离职流程。
为什么这两个问题总是拖到最后
开通那天要处理的是账号、权限、初始资料，容量和归属看着都不着急。加上这两件事的判断依据通常不在 IT 手里——谁需要多少容量是业务问题，文件归谁是企业内部的管理问题。于是它们被推后，直到撞上真实矛盾：某个重用户的个人空间满了，或者一个离职员工的空间里躺着上百份没人知道内容的文件。
容量：三种分法各有代价
- 按人头平均分。规则简单、争议少，但需求差异大：重用户很快撞顶并申请扩容，轻用户的空间长期闲置。结果是例外审批变成常态。
- 按部门池化。贴合组织结构，部门内可以互相调剂；代价是部门内部谁多用不好管，而且部门一调整就要重分。
- 按项目或场景单独开空间。最贴合业务，项目结束可以整体归档；代价是空间数量会膨胀，如果没有清理机制，几年后会留下一片没人认领的地方。
现实里通常是三者并存：个人空间给基础额度，部门空间管日常共享，项目空间按需申请并设定回收条件。关键是把三级的边界和上限写下来，而不是靠管理员临时判断。
人走了之后，三样东西要一起定
- 他个人空间里的文件。是继承给指定人员、转入部门空间，还是按类型拆分？保留多久？这套规则要在离职流程里写清楚，并由交接人确认。
- 他建过的群与共享空间。管理员能不能接管、由谁接管。如果不处理，这些空间会继续存在但没有人负责，权限还挂在已停用的账号上。
- 已经发出去的对外链接。账号停用之后，之前发出去的分享链接是失效还是继续可访问，需要在平台上确认过，而不是默认。
这三件事在成熟平台上已经被做成了标准能力——容量分配、空间管理、离职继承，同时支持对外分享与文件流转可追踪。也就是说，技术侧通常不是障碍，真正决定效果的是制度侧有没有把它们接进流程。
一套可以直接落地的口径
- 空间分三级：个人、部门、项目。每一级的上限与例外申请方式写在制度里。
- 离职流程固定增加一步「空间交接」：由交接人确认范围，管理员执行，结果留痕。
- 每个季度清理一次无主空间：定位那些创建人已停用、没有对应项目的空间，要么归档，要么关闭。
- 对外分享的默认状态按内容敏感度分档，不要一刀切全开或全关。
边界与前提
两点需要说明。其一，容量不是安全边界，权限才是：给足容量不等于给足访问范围，两件事要分开管。其二，不同平台支持的继承范围不同——有的只处理个人文件，有的连群与共享空间一起处理，选型时要确认到具体动作。深圳市奇摩计算机有限公司在企业办公平台落地与交付中，会把容量口径与离职交接动作写进交付清单，避免上线之后再补规则。
需要把这套口径做成可执行的流程，欢迎 预约咨询。