每个组织都面临相同的会议问题。有人做了纪录,纪录被放进共享文件或 Slack 频道,大家可能会读(也可能不会)。行动项目被提及但没有追踪。到了下周,一半的后续工作被遗忘,然后又开一次会重新讨论相同的议题。
问题不在于做纪录——而是纪录与行动之间的落差。将一页会议纪录转换为已分配、可追踪且有截止日期的任务是一项没人想做的手动工作,所以这件事很少能持续执行。
会议到行动的 workflow
营运入门包包含一个名为 Meeting to Action 的 workflow。它接收原始会议纪录——无论格式如何、多么杂乱——然后产出结构化、可执行的输出。
-
会议摘要器 — AI 读取原始纪录并产生结构化摘要:做出的关键决策、讨论的议题、待解决的问题,以及一段执行摘要。这不是重写纪录——而是浓缩精华,让错过会议的人可以在 60 秒内读完并了解发生了什么。
-
行动项目萃取 — 从相同的纪录中,AI 识别出每一个明确或隐含的行动项目。「John 会查询供应商报价」会变成一个结构化项目:负责人(John)、任务(研究供应商报价)、背景(在 Q2 预算讨论中提到),以及建议截止日期(根据会议背景)。隐含的承诺也会被标记——「我们应该更新 SOP」会变成分配给议题负责人的行动项目。
-
Loop: For Each Action Item — workflow 迭代每个萃取出的行动项目。
-
后续追踪分配 — 针对每个项目,AI 生成一则后续追踪讯息:简要说明需要做什么、为何提出,以及建议的截止日期。这些讯息可以透过 webhook 发送到 Slack、Jira 或团队使用的任何任务系统。
这对营运团队的重要性
营运团队仰赖流程的一致性。当一位专案经理认真追踪行动项目而另一位没有时,有追踪的专案会成功,其他的则会漂移。Meeting to Action workflow 让追踪变得自动化——后续执行的品质不再取决于谁主持会议。
另一个好处是组织记忆。当行动项目被萃取并储存为结构化资料时,你可以跨会议搜寻。「我们对供应商报价做了什么决定?」即使在几个月后也有答案,因为决策被记录在结构化摘要中,而不是埋在某人纪录的第三页。
整合到 SOP
营运包还包含一个 Process Documentation workflow,建立在会议输出之上。当会议讨论新流程或现有流程的变更时,Meeting to Action workflow 会捕捉决策。Process Documentation workflow 可以接着采用该决策并生成或更新正式的 SOP。
流程如下:
- 会议举行 → 输入原始纪录
- Meeting to Action workflow → 结构化摘要 + 行动项目
- 如果决定了流程变更 → Process Documentation workflow 运行
- 生成 SOP 草稿 → 经理审核的核准闸道
- 核准的 SOP 发布到 Confluence 或你的 wiki
从「我们同意变更流程」到「SOP 已更新」原本需要三周的时间差,现在变成当天完成。
排程会议处理
大多数营运团队会排程 workflow 在定期会议后自动运行。常见设定:
- 周一全员大会 → workflow 在周一下午 5 点处理纪录
- 到周二早上,每位与会者的收件匣里都有摘要,任务伫列中有行动项目
对于临时会议,workflow 可按需运行。贴上纪录、点击执行,不到两分钟就会产出结果。
完整的营运包
Meeting to Action 是营运入门包中四个 workflow 之一:
- Process Documentation — 将非正式的流程说明转换为正式的 SOP,包含审核和核准
- Project Health Check — 从多个来源收集状态、评估风险,并生成标准化报告
- Vendor Assessment — 评估计分卡、跨供应商比较,以及包含支持性分析的建议
独立 recipe——会议议程建立器、风险登记、周报生成器、流程改进分析器——可以单独运作或作为自订 workflow 的组成部分。