06
11 月
被炎上後才開會檢討，管理動作應該提前到這裡
摘要
炎上之後才召開檢討會議、成立對策本部、追究責任、修改SOP——這是多數企業面對社群風暴的標準反應。問題在於，這個順序本身就是錯的。檢討會議開得再認真，處理的是已經發生的損害；對策本部成立得再快，也只能縮短滅火時間，無法改變火已經燒過的事實。真正決定一場炎上是「小火」還是「大火」的，不是滅火的速度，而是企業在火苗出現之前、甚至火苗尚未被點燃之前，是否已經把管理動作放在了正確的位置。本文拆解炎上後檢討的結構性病灶，說明管理動作必須提前到「弱訊號階段」「日常營運決策點」與「授權前線」三個位置，並提供可操作的機制設計、KPI框架與常見問答。如何從Google和網路上刪除負面新聞文章
一、炎上後才開會，檢討的是「誰的錯」，不是「為什麼沒看見」
一場炎上爆發，企業的標準動作大致如下：社群小編發現風向不對，通報主管；主管往上呈報；高層指示「先了解狀況」；隔天或數天後召開緊急會議，成立對策小組，發出道歉聲明，承諾檢討改進。會議紀錄寫得詳盡，責任歸屬逐一釐清，SOP修訂版本很快產出。表面上，組織完成了「學習」。
但這場會議有一個根本性的盲點：它預設炎上是一個「突發事件」，因此檢討的重點落在「事件發生時誰做了什麼、誰沒做什麼」。這個預設忽略了絕大多數炎上並非無跡可尋。日本網路炎上研究機構以「批判或非難投稿超過100件」作為炎上的操作型定義，並持續追蹤年間發生件數。累計超過7,000件炎上數據的分析顯示，炎上的「火種」在爆發之前通常已經存在於某個營運環節、某句公關用語、某個未被處理的客訴、某項過度樂觀的行銷宣稱之中，只是組織沒有配置任何機制去捕捉它。