每個組織都面臨相同的會議問題。有人做了紀錄,紀錄被放進共享文件或 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 的組成部分。