达人池从20个扩到100个，真正卡住的不是BD人数，是合作记录散在微信和Excel里没人能拼出全貌。关系一旦跟着人走，离职带走、新人重联、重复邀约被拉黑几乎是必然。这篇文章拆解批量管理100个达人时信息沉淀、分组维护、人员分工、数据归档四件事怎么做。
20个达人和100个达人是两件事
20个达人阶段，一个BD靠微信备注加脑记就够用了：谁推过几次、上次佣金多少、最近一条视频什么时候发，全装在脑子里。但到100个量级，这套方法会瞬间崩盘。BD自己都记不清三个月前联系过的达人是不是已经合作过，更别说换人交接。问题出在信息载体——微信对话和Excel表格是"过程文件"，不是"系统数据"，过程文件天然无法被多人共享、无法被检索、无法被复用。结构化系统要解决的就是这件事：把合作状态、佣金、内容产出、复投记录这些字段固定下来，每一次沟通都更新到同一个池子里，BD换人池子不换。达秘在合作记录沉淀这件事上把字段固定死了，BD不需要思考要记什么，按字段填就行。具体字段设计有几个原则：能用下拉选项的不要开放填写，能从达人主页自动抓取的不要手工录入，能从订单系统拉的GMV不要让BD手动填。这些原则看起来是工具问题，实际决定的是数据能不能长期维护下去——开放填写的字段三个月后一定乱成废字段。另外一个容易被忽视的点是合作状态字段的颗粒度。"已合作"是不够的，要拆成"已合作-待上线""已合作-已上线""已合作-已复盘""已合作-待复投""已合作-终止"这几种，BD看到状态就知道下一步要做什么，不需要再去翻聊天记录回忆细节。
批量建联的流程拆开做才不浪费达人
批量建联最容易翻车的环节是"一次性群发"。一次发50条一模一样的邀约，达人要么不回，要么回完没人接，要么隔两周又收到同样的信息。把流程拆成六步走才能看出问题在哪：筛选 → 分组 → 话术 → 发送 → 追踪 → 跟进。筛选先按品类、粉丝量、近期内容方向把达人分成几类，分组是为了后面话术能针对性下钻。话术不是写一段通用模板，是按组写三版：头部达人讲合作历史和资源置换，腰部达人讲品类匹配和佣金空间，尾部达人讲首次合作的低门槛。发送要分批，一天发出去的不要超过20条，否则回复速度跟不上会显得不专业。追踪是记录每一条发出后的回复状态——已读未回、明确拒绝、待跟进、已合作。跟进才是真正出结果的地方，三天没回的可以二次触达，明确拒绝的归类不再打扰，已合作的进入下一阶段的维护流程。整个流程里最容易跳过的是追踪这一步，BD觉得"我发了就记在心里了"，但一周后真的会忘。所以追踪字段必须强制填写，发了邀约没填追踪状态的系统会标红提示，这比事后补救有效得多。达秘在追踪字段上做了强制填写设计，BD发完邀约必须回填状态才能关闭这条任务，避免追踪环节成为漏点。达人合作brief怎么写也有讲究，感兴趣可以看TikTok达人brief这篇拆解。
BD、内容、数据三个角色各管什么
团队扩到一定规模必须有分工，否则每个人都"全栈"覆盖所有达人，重复劳动严重。BD负责建联和维护关系，关心的是达人在不在线、回不回复、合作意向强不强。内容负责选题对接和脚本沟通，关心的是达人这周拍什么、脚本过不过、上线时间定没定。数据负责复盘和分层，关心的是每条视频带货GMV多少、互动率什么水平、佣金ROI正不正。三个角色的信息必须落到同一个池子里，而不是BD记在自己的微信、内容记在自己的飞书、数据记在自己的Excel。最常见的坑是BD"占住"自己开发的达人不让别人碰，理由是"我和她关系好"——这是团队管理问题不是工具问题，规则上必须明确达人池是公司资产不是个人资产，BD离职前所有沟通记录要导出归档。每周开一次三方对齐会，BD讲这周新增了哪些达人、内容讲这周有哪些视频上线、数据讲这周复盘出了什么结论，三个角色的信息在会上交叉验证，不一致的当场核对。这种节奏比任何工具都更能保证数据准确。达人合作管理最大的坑不是找不到人，是合作过程中数据没沉淀，用达秘把合作记录佣金产出都串起来。
头部腰部尾部分层维护频率不同
100个达人一视同仁地维护，要么是头部被冷落流失，要么是尾部占用大量精力没产出。分层标准不是看粉丝量，是看历史合作GMV和近期内容质量两个维度。头部是过去半年带过货、单条GMV稳定过线的达人，维护频率是每周触达一次、每月一次深度沟通、内容上线前后都盯一遍。腰部是有合作历史但产出波动大的达人，维护频率是每两周触达一次、新内容上线时主动转发点评。尾部是首次合作或还在试合作的达人，维护频率是每月一次轻量互动，重点是看她的内容质量有没有变化、粉丝画像是否还匹配你的品类。头部流失是最大损失，因为关系和信任建立成本最高；尾部不活跃反而是正常的，没必要硬留。分层不是固定不变的，每季度根据数据重新分层一次，尾部有起色的可以升到腰部，腰部持续不产出的可以降级或终止。还有一类容易被忽略的是"潜力尾部"——粉丝量不大但近期内容质量明显在上升的达人，这类值得单独标注，提前加深互动频率，等她起来时你就是最早的合作方。小达人和大达人的合作方式本身就不同，可以参考这篇TikTok小达人合作看看具体差异。
踩过的坑：5个BD各管各的达人池
有一个真实情况值得拿出来说。团队把5个BD分成5个达人池各自开发各自维护，前期看起来效率很高，每个人对自己池子里的达人很熟。问题是第6个月一位BD离职，她的池子里有30多个达人，关系全在她个人微信里。新人接手时只有一个Excel表，上面只有达人昵称和粉丝量，没有沟通历史、没有合作细节、没有达人偏好。新人重新建联时，有3个达人被重复邀约直接拉黑，有1个达人本来已经在洽谈独家合作，新人的"重新联系"让达人觉得不专业直接退出。这件事的直接损失是2个月的时间和1位本来能签独家的头部达人。后来改了规则：所有达人沟通必须走系统留痕，微信只做日常维护不做正式邀约，BD离职前必须完成达人池和沟通记录的完整导出。这件事之后团队才真正理解，达人池是公司资产这句话不是口号，是规则。达秘在离职交接这个场景上的价值就是让"导出"这件事不需要刻意做，所有数据本来就在系统里，新人接手直接看就行。还有一个延伸教训：BD之间的达人池不要完全隔离，应该有一个共享池的概念，每位BD都能看到全量达人列表，只是维护责任分到具体的人，这样可以避免重复开发，也能让BD知道某个达人是不是同事已经在跟进。达人合作记录散在微信和Excel里？利用达秘把合作历史和带货数据自动归档，换人交接也不会丢。
数据沉淀是批量管理的根
100个达人量级，没有数据沉淀就没有判断依据。每一轮合作结束要回答几个问题：哪个达人值得复投、哪个品类在哪类达人身上效果更好、佣金区间定多少合理、内容方向需不需要调整。这些问题靠记忆和印象答不出来，必须有结构化的合作记录：达人ID、合作时间、内容主题、视频数据、带货GMV、佣金成本、互动情况、复投次数。沉淀下来的数据还有两个延伸用途：一是新人入职可以快速学习历史合作经验，不用从零摸索；二是季度复盘时有真实数据做依据，而不是凭"感觉头部达人效果更好"这种模糊判断做下一轮预算分配。数据沉淀最大的敌人不是工具不够，是团队不愿意填——BD觉得每合作一次就要回填一堆字段是负担，所以要尽量把字段做成下拉选项和自动抓取，能系统取的不要人填。这也是达秘设计字段时的核心思路：减少人工录入，能用数据接口拉的就让系统拉。另外，达人合作失败复盘如果只看一两次合作很难得出结论，达人合作失败复盘里讲的逻辑也适用于批量管理这个场景。还有一个判断标准可以参考：如果一条合作记录三个月后回头看还是看不懂当时为什么这么决策，说明数据沉淀不到位——好的沉淀应该让任何人在任何时候都能看懂当时的合作背景和结果。
常见认知误区：BD团队越大管理越好
"人多力量大"在BD管理这件事上是错的。BD团队扩到一定规模后，没有系统支持反而更乱：5个BD各自有各自的池子，重复开发同一批达人；每个人备注方式不同，信息没办法汇总；离职交接时数据断层，新人从零开始。管理工具和流程才是关键，BD人数是次要变量。真正决定能不能管好100个达人的，是有没有一个共享的达人池、有没有清晰的分工边界、有没有数据沉淀的机制。这三个条件满足后，3个BD也能管好100个达人；这三个条件不满足，10个BD只会更乱。所以扩团队之前先问自己：现在的流程和工具能不能支撑更多人协作？如果不能，扩人等于扩乱。这一点也是达秘在和很多卖家沟通后反复验证过的结论，扩团队前先把工具和流程搭好，比单纯加人管用得多。
常见问题
100个达人要不要全部签独家
不需要，也做不到。独家合作适合头部少数几位产出稳定的达人，腰部和尾部用灵活合作方式更合适。独家意味着义务和成本，对达人也是对卖家，签太多反而绑死自己，把合作灵活度降到最低，后续调整空间也很小。
BD离职带走的达人关系怎么办
规则上明确达人池是公司资产，BD在职期间所有沟通记录必须留存在公司系统里。离职前完成数据导出和交接，新接手的人至少能看到历史合作细节，不用从零联系。这一条要写进BD的入职合同和离职流程里，不能靠口头约定，口头约定在人员变动时几乎没有约束力。
100个达人一个月维护够不够
够，前提是分层维护。头部每周一次、腰部每两周一次、尾部每月一次，按这个频率算下来100个达人每月触达总量在200次左右，3个BD分担完全做得到。一视同仁地维护100个达人会超载，结果就是每个人都忙但每个达人都没维护好。
结语
批量管理100个TikTok达人的核心是信息沉淀和分工协作，不是堆BD人数。流程拆开做、达人分层维护、数据归档到位，3个BD也能稳住100个达人。把达人关系绑在个人微信和记忆里，团队早晚会被一次离职打回原形。扩团队之前先把工具和流程搭好，比单纯加人管用得多，这也是大量卖家在100个达人这个量级反复踩坑后得出的共识。达秘
