演员陈赫的达人直播管理:飞书多维表格 SOP 落地
一场明星达人直播,台前是三四个小时,台后是三四十号人、上百个环节。演员陈赫的抖音电商直播项目,把这套复杂协作沉淀成了一个飞书多维表格 Base——「禾风一漾-达人直播 SOP」。
25 张表,2 块仪表盘。它同时解决三件事:开播前谁该做什么、开播中怎么盯、开播后怎么复盘。
一、痛点:直播是项目,不是任务
达人直播的组织难度,来自它同时具备三个特征:
- 职能极多。一场直播要动用 PM、商务、商品策划、直播策划、短视频、设计、投放、中控、场控、社群、技术、样品,十来个工种,每个工种的活儿都不一样。
- 强时间约束。开播时间是硬截止,样品没寄到、链接没核对、海报没出图,任何一环卡壳都直接影响当场 GMV,而且没有补救窗口。
- 高度重复。每场直播的流程其实高度一致,但如果每次都靠 PM 拉个群、在群里口头分工,那前一场踩过的坑下一场照样踩。
这三点合起来的结论是:直播应该按「项目」管,而不是按「一堆待办」管。
二、核心设计:48 条任务映射,把 SOP 变成可执行数据
整个 Base 的心脏是「任务映射表」——48 条记录,每条包含三个字段:任务名称、当前阶段、职能。它不是文档里的一段流程说明,而是一张可以被程序读取、自动展开的标准任务清单。
三个阶段的划分是:前期准备 → 中期(现场)→ 后期。
前期准备(占了绝大多数任务)按职能分工如下:
| 职能 | 标准任务(节选) |
|---|---|
| PM | 确定直播排期和目标 / 选品及定品 / 达人确认选品 / 短视频确认(商家 brief、脚本、拍摄)/ 设计海报确认 / 投放确认 / 预测会 / 彩排 |
| 商务 | 提报线索——权益、机制、条件 / 确认机制 & 拉群 / 行业小二对接,获取资源,明确活动玩法 |
| 商品策划 | 沟通商家,收集手卡和资料 / 根据产品策划展示方案和实验,采购相关道具 / 撰写手卡,准备卖点讲解辅助资料、KT 证书贴片 |
| 直播策划 | 设计场景,设计视觉 / 设计玩法,根据玩法采购或制作道具 |
| 短视频 | 明确权益,构思场次选题,开选题会 / 确定发布排期,撰写 & 确认脚本,拍摄规划 / 拍摄 & 剪辑 / 审片发布(组内、达人、品牌商家) |
| 中控 | 直播产品信息收集(商家信息表、SKU、库存…)/ 产品比价(二次确认,写入手卡)/ 核对链接(价格、库存和佣金)/ 开播前检查:产品利益点,二次核对链接 |
| 设计 | 收集产品白底图 / 设计物料(海报、KT 板、主图框、贴片)/ 制作海报 |
| 样品 | 沟通商家寄样 / 收样理样,机制确认 |
| 技术 | 清点设备 / 直播搭建 |
| 投放 | 分配预算,确认人群包,建立投放计划 |
| 社群 | 私域玩法设计 / 海报预热 |
**中期(现场)**是一张实时作战表:PM 负责主播管理(提示)、节奏引导把控现场、直播大屏数据监控;中控负责链接管理、发福袋发红包、监控投放消耗与红包消耗、对接商家确认实时库存;投放负责调计划调预算;商品策划监控主播话术并实时更改;短视频负责直播切片制作与发布、短视频数据监控;商务对接商家实时调整机制。
后期:PM 做直播现场流程复盘、整场成本确认;社群做售后维护。
这张映射表最值得学的地方在于颗粒度选得准。任务名称写的是「核对链接(价格、库存和佣金)」而不是「准备工作」——前者可以打勾,后者只能扯皮。而「开播前检查:产品利益点,二次核对链接」和前期的「核对链接」是两条独立任务,说明这个环节在实践中被坑过,所以特意设计了二次校验。
三、一键立项:从按钮到项目群
「项目表」是每场直播的主记录,字段配置反映了完整的角色矩阵:主播、平台、开始时间、负责人、运营负责人、策略负责人、短视频负责人、编导、中控、场控、跟拍、参与人,以及退后预估 GMV 和实际达成 GMV。
项目名称用 formula 自动拼成 电商直播*主播*平台*日期 的格式(例如 电商直播*陈赫*抖音*20250530),一眼可读、天然可排序,不依赖任何人的命名习惯。
真正的效率点是「立项」按钮和「创建项目任务」字段。触发之后,配套的自动化流程「创建直播任务 & 拉群 & 添加群成员」会做三件事:
- 按任务映射表展开这场直播的标准任务集,写入「项目进度 & 任务表」;
- 建一个项目群,挂到项目记录的「项目群」字段上;
- 把相关成员拉进群。
另一条流程「任务完成后,发送提醒」负责在任务状态变更时推送。
展开后的「项目进度 & 任务表」目前累计 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 兼容网关,模型随需切换,不必为每家单独接一套鉴权。