把「用户库」改造成 CRM：达人运营的公海、私海和个人池

一句话版本：内部工具做不起来，往往不是功能不够，而是「归属」和「指标」没定义清楚。先定义谁对哪个用户负责、怎么算管好了，功能自然就长出来了。

背景

我在 TikTok 负责过一个全球运营团队用的内部达人管理平台。它最早只是一个「用户库」：运营把达人导进来、打上标签，然后看数据。

几年下来功能加了不少，结构却没怎么动。运营用它主要做两件事：批量打标，打完标追踪数据。

问题是，库里挂着运营名字的达人很多，真正活跃的却只是一小部分。 哪个达人断更了、哪个运营手里的人在流失，系统都发现不了。

与此同时，越来越多团队来提需求：

• 一个负责欧洲多国的运营，要在不同地区的用户库之间反复切换，还得逐个国家申请权限。
• 市场团队做名人、新闻类专项，只需要看数据，不需要任何操作权限。
• 音乐团队想用同一套工具管理音乐人，但不想和达人运营的数据混在一起。

问题

表面上看是「用户库不好用」，往下拆其实是三个问题：

1. 归属不清。 一个达人挂在某个运营名下，但没人定义「挂上去」意味着什么，也没有机制把长期不维护的达人收回来。
2. 角色不清。 所有人用同一套权限和视图。看数据的人、做运营的人、带团队的人，需要的完全不同。
3. 指标不可行动。 看板告诉你「活跃达人数下降了」，但不告诉你是谁、为什么。

我的做法

1. 借用销售 CRM 的「线索池」模型

销售团队管客户的方式其实非常适合达人运营：线索在公共池里，谁跟进谁认领，长期不跟进就收回，让别人来。

我把系统拆成四层：

层级	放什么	解决什么
公海池	所有符合门槛、还没人管的达人线索	新达人从哪来
私海池（团队池）	一个团队负责人及其组员正在维护的达人	团队层面的管理与数据
个人池	单个运营正在维护的达人	日常联络、追踪、转移
单个达人	达人详情页	一个人的完整画像与操作记录

关键不在分层本身，而在层与层之间的流动规则：运营可以从公海认领，负责人可以分配；长期不维护的达人可以被规则自动收回，或者由负责人手动收回。

这让「归属」第一次有了生命周期，而不是挂上去就永远挂着。

2. 让用户自己选角色，而不是先卡权限

新用户第一次进入时，页面只问一个问题：你是哪种角色？

• 团队负责人（Lead Operator）：能建组、加组员、设准入规则，看到全部功能。
• 运营（Operator）：管理自己的达人，看不到角色管理。
• 访客（Visitor）：只能看公海池，大部分操作不可用。

角色本身不额外加审批，真正敏感的操作（比如查看达人联系方式、批量导出）仍然走原来的细粒度权限。

这样做的好处是：入口门槛低，敏感操作的门槛不降。 市场团队这类「只想看看」的用户，不再需要为了看数据去申请一堆用不上的权限。

3. 每个指标都要能下钻到「是谁」

看板上的核心指标，比如活跃头部达人数，都展示周同比，点开能看近三个月趋势。

但最有用的设计是 diff case：点开「活跃头部达人数」，直接列出这周相比上周新增了谁、流失了谁，按过去 7 天的有效投稿量排序，还能直接播放他们最近的内容。

指标从「一个数字」变成了「一张待办清单」。运营看到数字下降，下一步就是去联系名单上的人。

4. 批量操作要按「失败了怎么办」来设计

批量添加、打标、发邀请、移除、导出都设了单次数量上限。规则里最花心思的是冲突和失败：

• 添加的达人已经属于别的运营：不直接覆盖，而是向原运营发起审批。审批通过前，归属和标签都保持原样。
• 新标签和旧标签属于互斥类别：弹窗二次确认。
• 批量移除时某些人移除失败：失败的人留在个人池，不清除归属和标签，不允许出现「一半成功」的中间状态。
• 导出量大：不让用户在页面上等，而是完成后用机器人消息推送下载链接。

5. 上线前就定义「怎么算成功」

我在需求文档一开始就把成功标准分成两个视角：

• 用户视角：使用量（双月 PV 比现状提升 xx%）、看板加载时间（< xx 秒）、覆盖的业务团队数（≥ xx 类）、功能认知度（小测验 ≥ xx 分）、满意度（≥ xx 分）。
• 业务视角：线索池到管理池的有效转化率（> xx%）、有运营维护的达人活跃率（从 xx% 提升到 xx%）。

其中「功能认知度用小测验来测」这一条，后来我在很多项目里都在用。内部工具最常见的失败不是功能做错了，而是用户根本不知道有这个功能。

可以直接拿走的经验

1. 做内部工具前，先问「归属」怎么定义。 谁对哪个对象负责、什么时候收回，比加多少功能都重要。
2. 借成熟行业的模型。 销售 CRM 的线索池、分配、回收规则，几十年验证过，直接用比自己发明省事。
3. 角色选择做在前，敏感权限放在后。 降低入口门槛，不降低风险门槛。
4. 每个下降的数字都要能点开看到具体名单。 不能下钻的指标只能用来汇报，不能用来干活。
5. 批量操作先设计失败路径。 冲突走审批，失败就回滚，不留中间状态。
6. 把「用户知不知道这个功能」也当成成功指标。

一个中途改掉的决定

最初的设计是：负责人把某个运营移出团队时，这个运营名下的达人自动转给负责人。

听起来很合理，但会带来两个问题。一是负责人名下会突然多出一大批他不会去维护的达人，等于制造了一批新的「僵尸归属」。二是运营可能只是换组，达人关系其实还在。

最后改成：移出团队只解除运营和负责人的关系，不动运营和达人之间的绑定。 同时在确认弹窗里显示这个运营当前名下的达人数量，让负责人知道自己在动什么。

教训是：自动转移归属看起来省事，但归属一旦转给了不会去管的人，就和没有归属一样。