01 / PROGRAM VS. ROS
如果流程只能在順利時成立，它還不是現場流程
一份只有「14:00 開場、14:10 致詞、14:30 演出」的表格，無法回答影片何時播放、誰給 Cue、講者未到怎麼調整、延誤十分鐘要刪哪一段。Run of Show 的目的，是把時間、責任、素材與備案放在同一列，讓團隊不必在壓力下重新拼資訊。
每一列都要能回答：何時開始、誰做、在哪裡、需要什麼，以及失敗時立刻改做什麼。
02 / THE SEVEN FIELDS
活動流程表至少要有七個欄位
| 欄位 | 要回答的問題 | 常見錯誤 |
|---|---|---|
| 開始／結束 | 這一段何時開始、何時必須收尾？ | 只寫開始時間，無法判斷延誤。 |
| 環節／台詞 | 觀眾會看見或聽見什麼？ | 名稱過短，工作人員不知道內容。 |
| 主責／支援 | 誰做最後決定，誰協助執行？ | 寫部門不寫人，現場找不到窗口。 |
| 位置 | 人、物與設備應該在哪裡？ | 忽略移動時間與場地死角。 |
| 設備／素材 | 要使用哪一個檔案、麥克風或燈光狀態？ | 只寫「播放影片」，沒有檔名與版本。 |
| Cue | 誰在什麼訊號後啟動下一步？ | 每個人都以為別人會下指令。 |
| 備案 | 觸發什麼條件時，立刻切到哪套流程？ | 只寫「視情況調整」。 |
常見做法會再加入「狀態／備註」與「實際時間」，前者保留彩排修正，後者供結案時判斷哪一段長期低估或高估。
03 / BUFFER AND FALLBACK
緩衝不能只藏在總時長裡
把十分鐘緩衝寫成一個具體環節，並先決定延誤時的刪減順序。否則每一位工作人員都會保護自己負責的段落，最後只能壓縮觀眾移動、技術換場或安全確認。
- 先保留安全、法定與核心承諾。
- 再保留會影響後續設備與人員移動的換場。
- 最後才決定縮短問答、重複介紹或非必要儀式。
每一個高風險環節還要寫觸發條件。例如「開場前五分鐘講者未到」比「講者遲到」更能驅動行動，因為團隊知道何時切換到主持人延長版。
04 / SHOW CALL
活動前簡報，不逐字念完整張表
現場 Briefing 只確認五件事：今日版本、指揮者、前三大風險、關鍵 Cue、緊急中止與對外回應權限。每個人應該知道自己前後相鄰的環節，而不是只看自己的那一列。
延伸定義可參考 Atlassian 的 Run of Show 範本說明；實際欄位仍應依活動規模與風險調整。