演员陈赫的达人直播管理:飞书多维表格 SOP 落地

一场明星达人直播,台前是三四个小时,台后是三四十号人、上百个环节。演员陈赫的抖音电商直播项目,把这套复杂协作沉淀成了一个飞书多维表格 Base——「禾风一漾-达人直播 SOP」。

25 张表,2 块仪表盘。它同时解决三件事:开播前谁该做什么、开播中怎么盯、开播后怎么复盘。

一、痛点:直播是项目,不是任务

达人直播的组织难度,来自它同时具备三个特征:

  1. 职能极多。一场直播要动用 PM、商务、商品策划、直播策划、短视频、设计、投放、中控、场控、社群、技术、样品,十来个工种,每个工种的活儿都不一样。
  2. 强时间约束。开播时间是硬截止,样品没寄到、链接没核对、海报没出图,任何一环卡壳都直接影响当场 GMV,而且没有补救窗口。
  3. 高度重复。每场直播的流程其实高度一致,但如果每次都靠 PM 拉个群、在群里口头分工,那前一场踩过的坑下一场照样踩。

这三点合起来的结论是:直播应该按「项目」管,而不是按「一堆待办」管。

二、核心设计:48 条任务映射,把 SOP 变成可执行数据

整个 Base 的心脏是「任务映射表」——48 条记录,每条包含三个字段:任务名称、当前阶段、职能。它不是文档里的一段流程说明,而是一张可以被程序读取、自动展开的标准任务清单。

三个阶段的划分是:前期准备 → 中期(现场)→ 后期。

前期准备(占了绝大多数任务)按职能分工如下:

职能标准任务(节选)
PM确定直播排期和目标 / 选品及定品 / 达人确认选品 / 短视频确认(商家 brief、脚本、拍摄)/ 设计海报确认 / 投放确认 / 预测会 / 彩排
商务提报线索——权益、机制、条件 / 确认机制 & 拉群 / 行业小二对接,获取资源,明确活动玩法
商品策划沟通商家,收集手卡和资料 / 根据产品策划展示方案和实验,采购相关道具 / 撰写手卡,准备卖点讲解辅助资料、KT 证书贴片
直播策划设计场景,设计视觉 / 设计玩法,根据玩法采购或制作道具
短视频明确权益,构思场次选题,开选题会 / 确定发布排期,撰写 & 确认脚本,拍摄规划 / 拍摄 & 剪辑 / 审片发布(组内、达人、品牌商家)
中控直播产品信息收集(商家信息表、SKU、库存…)/ 产品比价(二次确认,写入手卡)/ 核对链接(价格、库存和佣金)/ 开播前检查:产品利益点,二次核对链接
设计收集产品白底图 / 设计物料(海报、KT 板、主图框、贴片)/ 制作海报
样品沟通商家寄样 / 收样理样,机制确认
技术清点设备 / 直播搭建
投放分配预算,确认人群包,建立投放计划
社群私域玩法设计 / 海报预热

**中期(现场)**是一张实时作战表:PM 负责主播管理(提示)、节奏引导把控现场、直播大屏数据监控;中控负责链接管理、发福袋发红包、监控投放消耗与红包消耗、对接商家确认实时库存;投放负责调计划调预算;商品策划监控主播话术并实时更改;短视频负责直播切片制作与发布、短视频数据监控;商务对接商家实时调整机制。

后期:PM 做直播现场流程复盘、整场成本确认;社群做售后维护。

这张映射表最值得学的地方在于颗粒度选得准。任务名称写的是「核对链接(价格、库存和佣金)」而不是「准备工作」——前者可以打勾,后者只能扯皮。而「开播前检查:产品利益点,二次核对链接」和前期的「核对链接」是两条独立任务,说明这个环节在实践中被坑过,所以特意设计了二次校验。

三、一键立项:从按钮到项目群

「项目表」是每场直播的主记录,字段配置反映了完整的角色矩阵:主播、平台、开始时间、负责人、运营负责人、策略负责人、短视频负责人、编导、中控、场控、跟拍、参与人,以及退后预估 GMV 和实际达成 GMV。

项目名称用 formula 自动拼成 电商直播*主播*平台*日期 的格式(例如 电商直播*陈赫*抖音*20250530),一眼可读、天然可排序,不依赖任何人的命名习惯。

真正的效率点是「立项」按钮和「创建项目任务」字段。触发之后,配套的自动化流程「创建直播任务 & 拉群 & 添加群成员」会做三件事:

  1. 按任务映射表展开这场直播的标准任务集,写入「项目进度 & 任务表」;
  2. 建一个项目群,挂到项目记录的「项目群」字段上;
  3. 把相关成员拉进群。

另一条流程「任务完成后,发送提醒」负责在任务状态变更时推送。

展开后的「项目进度 & 任务表」目前累计 228 条任务记录,每条带任务名称、职能、当前阶段、项目负责人、开始 / 结束日期、项目状态、产物,并通过 link 回指项目。项目表侧再用两个 lookup(任务总数、已完成任务书)加一个 formula 算出「项目完成进度」——进度不用任何人汇报,勾一个任务自己就动。

从记录看,不同场次的任务总数分别是 36、48、72 条,说明这套映射并非死板套用,可以按场次规模裁剪或叠加。

四、执行层:一场直播需要填的那些表

围绕主流程,Base 里还有一圈支撑表单,基本对应着 SOP 里那些「容易出事」的环节:

  • 选品池:产品名称、尺寸、配色、产品图片、维护人员,作为选品的候选库。
  • 策略表:定价与机制的核心。品牌、商品名称(link 关联)、单价、券或红包、红包后价格、满减档位、机制、坑位、预估单量、预估坑产、佣金 / 单佣金 / 佣金收入,加上一串开关型 checkbox——是否新品、是否打款、是否需要预约链接、短视频是否露出,以及商务、脚本两个负责人字段。一场直播的商业条款全部结构化在这一行里。
  • 信息表:商家侧要交的完整资料清单,字段名后带 * 的就是必填项——品牌名称*、商品 ID*、商品原价*、主播专享价*、商品规格*(颜色 / 克重 / 容积 / 数量 / 型号)、库存数量*、商品类目*、是否包邮*(注明限购区域)、是否七天无理由退换*、发货快递公司*、赠品是否一起发货*、系统设置发货时间*、利益点*、小店店铺名称*、直播间上架链接*。还有一条要求写得极具体:卖点(必须包含以下内容!200 字<总字数<500 字)。另配「核对 / 核对人 / 核对备注」三个字段,以及淘宝比价、参考链接(天猫 / 京东)、禁忌人群、店铺评分等风控项。
  • 物流进度表:品类、商品、物流单号、物流状态、佣金、确认 checkbox——盯样品和货是否到位。
  • Run down:现场流程单。时间、坑位、产品名称、价格、机制/补贴价、预估单量、预估坑产、佣金、彩排。
  • 手卡 / 违规词检测 / 设计需求申请表 / 直播效果数据复盘:分别承接话术卡、合规校验、设计提需和复盘记录。
  • 人员分工:人员、部门、编号,作为派单的基础数据。

这套表单的设计哲学很一致:把「记得要做」变成「表上有个空要填」。必填星号、核对人、二次确认 checkbox,全是为了让疏漏在开播前暴露,而不是在开播时暴露。

五、复盘层:四个维度拆解一场直播

直播结束后,数据按四层结构入库,最终汇进「🚀 达人直播数据驾驶舱」和「达人数据监测」两块仪表盘。所有表都以 SourceID + 场次时间 + 导入日期 三个字段对齐,保证跨表能拼到同一场直播上:

第一层|基本信息:直播间名称、封面、开播平台、场次时间、直播时长、直播间成交金额、千次观看成交金额、退款金额、违规次数。注意「违规次数」被当成一级指标——对达人直播来说,合规风险和 GMV 同等重要。

第二层|流量与转化:

  • 流量分析(按渠道,20 条):渠道名称、观看人数 / 观看次数、人均观看时长、成交订单数、成交金额、笔单价,以及互动率、观看-成交率等 formula。
  • 转化漏斗:直播间曝光人数 / 曝光次数 → 观看人数 → 商品曝光人数 → 商品点击人数 → 成交人数,配套曝光-观看率、观看-商品曝光率、商品曝光-点击率、点击-成交转化率、曝光-成交转化率,外加自然流量观看人数与付费流量观看人数的拆分、最高在线与平均在线。每一级都有绝对值和转化率两个口径,掉在哪一环一目了然。
  • 短视频引流(184 条):短视频名称、投稿时间、直播入口曝光次数、直播入口点击率、引流直播间次数——把内容侧的贡献单独量化。

第三层|互动 / 人群 / 售后:观看-互动率、观看-关注率、新增粉丝数、人均观看时长、首购率,以及退款人数、退款订单数。把「涨粉」和「退款」放在同一张表里,是很清醒的设计——一场直播的真实成绩要扣掉退款才算数。

第四层|商品与 SKU:商品表(96 条)到 SKU 表(232 条),逐品逐规格记录曝光、点击、成交人数 / 件数 / 金额、预售订单与金额、退款、商品支付 GPM。下次选品就有依据了。

此外还有一张「🎬 TikTok 博主数据」表,已沉淀 9,135 条视频记录(作者、文案、封面、点赞、评论、转发、收藏、发布时间),用于海外达人侧的选人与内容监测;以及一张「群聊记录同步」表,把飞书群里的沟通按客户名称、需求场景标签、商机阶段、下一步待办结构化落库,让散在群聊里的商务线索不至于蒸发。

六、这套系统真正解决了什么

对照 SOP 表看很清楚:这个 Base 不是「把 Excel 搬上线」,而是把一家 MCN 反复吃过亏才总结出来的执行标准,编码成了每次开播都会自动展开一遍的任务流。

  • 立项按钮一按,48 条标准任务 + 项目群 + 成员,全部自动就位;
  • 每个环节都有明确职能归属,不需要 PM 在群里问「这个谁负责」;
  • 必填字段和二次核对把风险前置到开播前;
  • 四层复盘数据回流,让「这场为什么好 / 为什么差」有据可查。

如果要在这条链路上再叠 AI,几个位置很自然:违规词检测可以做话术自动扫描,手卡可以按信息表的卖点自动生成初稿,直播复盘可以让模型读四层数据直接出诊断报告。这类调用可以在飞书自动化的 HTTP 请求节点里接波波 API(apibobo.com)这样的 OpenAI 兼容网关,模型随需切换,不必为每家单独接一套鉴权。