会议纪要与行动事项 AI. 这是一套工作流:读完一场会议,提取其中每一项承诺,分配给一位具名的负责人,再推送到该团队已经在用的工具里,然后持续跟进未完成的事项直到关闭。转录稿只是副产品。重点在于,有人在会上答应要做的事,会以被跟踪任务的形式出现在 Slack、Linear 或 Asana 里,而不是文档里一行没人会再打开的文字。
如果你是一家 120 人服务公司的幕僚长,你一定清楚承诺是在哪里夭折的。周二做出一项决定,纪要被贴进共享文档,到下一个周二,一半的负责人已经忘了,文档上面又多了三页。这篇文章是从运营负责人的角度来解决这个问题。它先讲你能挽回多少被遗漏的承诺,而不是模型如何转录音频。
我们的会议行动事项为什么总是死在文档里?
因为文档只是记录的地方,不是会去追踪的系统。一场 10 人的每周领导层会议,可以产生 12 到 15 项承诺。它们落在一份纪要里,而纪要没有工具强制要求的负责人字段,没有团队会跟踪的截止日期,日期延误时也没有提醒。所以后续跟进全靠碰巧有人重读纪要。漏读一次,承诺就没了。会议开得很有成效的样子,却什么都没交付。
会议纪要与行动事项 AI 究竟做什么?
它读取会议内容,把每项承诺提取为任务,并分配给一位具名的负责人,附上截止日期。由真人确认负责人。随后它在 Slack、Linear 或 Asana 中创建任务,并在截止日期临近或已过时发出提醒。衡量标准是关闭了多少行动事项,而不是转录了多少分钟。
请注意这四个步骤:提取、分配、派发、跟进。转录是第零步,Otter、Fireflies 和 Granola 已经做得很好。运营负责人真正想要的工作,从转录稿生成之后才开始:这件事归谁、放在哪里、谁去提醒。我们的 AI 助力运营业务把这称为跨系统集成的内部运营机器人:行动事项走出会议室,在真实的工具里变成真实的任务,通过你的团队已在使用的接口派发。
这难道不就是又一个转录机器人吗?
We are
我们构建转录之后的那一步:一套工作流,把每项承诺变成 Slack、Linear 或 Asana 里有负责人、有期限的任务,并一路跟进到关闭,让你盯着的那个数字,也就是承诺遗漏率,不断下降。
We aren't
我们不是转录应用:不会把一份整洁的摘要丢进你的云盘,然后把后续跟进留给碰巧重读它的人。
选择衡量什么的时候,这个区别很重要。转录机器人以准确度打分:它多忠实地记录了所说的话。那是录音指标。运营负责人以后续跟进打分:商定的事项到底完成了多少。这是两份不同的工作。一份完美的转录稿,配上只有 40% 完成率的行动事项,依然是一个说到不做到的团队。你要找的结果是关闭,而关闭需要系统里的一项任务,而不是摘要里的一句话。
它怎么知道某项事项该交给谁?过程中还有真人把关吗?
分配是你不会完全交给模型的一步。起草是自动的,签字确认由人来做。工作流会根据谁发了言、谁被点名、谁以前负责过类似工作来提议负责人,然后由真人在任何事项派发之前确认或更正。负责人这一环保留真人参与,是有意为之。把任务分给错的人,比没有任务更糟,因为这样两个人都会以为对方在处理。
- 提取:会议中的每项承诺都成为候选任务,附上建议的负责人和截止日期。
- 确认:在创建任何任务之前,由真人一次性审阅负责人的分配。
- 派发:确认后的任务通过接口在 Slack、Linear 或 Asana 中创建,并附上指向会议纪要的链接。
- 跟进:工作流在日期之前提醒负责人,事项逾期时向你示警,让未完成的承诺浮出水面,而不是悄悄消失。
我们通过AI 实施交付:工作流自动化加上 AI 副驾驶。第一个周期通常把一种会议类型端到端接通,比如你每周的领导层或运营同步会,接入团队已经在用的某个工具。代码归你所有。指派负责人这一步,按设计保持由人来做。这与我们用于其他运营工作流的AI 咨询模式相同,公开构建的文章在 journal 中。
会议的价值,只取决于有多少承诺能在会后留存下来。
如果你的领导团队每次开会都先翻开上周的文档,去弄清有什么被漏掉了,那是工作流的缺口,而不是记笔记的问题。我们梳理一类定期会议,把它的行动项接入你已经在用的工具,并在指派这一步保留一个人。预约一次 30 分钟的调研通话,并带上一场产生的承诺多于关闭的会议。我们会追踪后续跟进在哪里流失,以及其中哪些可以找回。
