產品發布計畫(Go-to-Market 上線協調)範本
追蹤發布準備與必過關卡,自動點名未動員部門與無人回報
- 資料表
- 5 張
- 欄位總數
- 70 個
- 難度
- 進階
- 版本
- 1.0
- 更新
- 2026-08-31
這個範本解決什麼問題
上線當天客服說我們沒有這個功能,是最貴的那種事故。範例裡的 REL-2026-02 距上線十天,客服部一項準備事項都沒有,卻沒有人發現,因為每個部門都以為別人通知過了;REL-2026-04 更安靜,已上線 16 天沒有任何部門回報過結果,發完就散了。這些洞平常都看不見,要到上線那天才一次爆開。
這個範本用五張表把發布拆開管:各部門的工作掛在「🏢 部門準備事項」,必過關卡放在「✅ 上線前檢查關卡」,都關聯回「🚀 發布版本」。「未動員部門」會自動點名一項準備都沒有的部門,「上線回報筆數」抓出上線後無人回報的發布,「回退條件」與「回退決策人」也逼你在出事前先寫清楚誰能拍板。
範本內容
以下欄位結構直接讀自範本本身,永遠與實際內容一致。
| 欄位名稱 | 型別 | 說明 |
|---|---|---|
| 行銷企劃部準備數 | 公式 | |
| 發布負責人 | 單行文字 | |
| 📣 本案上線回報 | 其他 | |
| 版本代號 | 單行文字 | |
| 時段選擇理由 | 單行文字 | |
| 回退決策人 | 單行文字 | |
| 必過關卡數 | 公式 | |
| 延期次數 | 數字 | |
| 未動員部門 | 公式 | |
| 未完成準備數 | 公式 | |
| 主辦部門 | 單選 | 選項:產品部/資訊部/業務部/行銷企劃部/客服部/營運部/品保部 |
| 上線回報筆數 | 公式 | |
| 營運部準備數 | 公式 | |
| 🏢 本案準備事項 | 其他 | |
| 延期原因 | 單行文字 | |
| 影響通路 | 單選 | 選項:官網/蝦皮/momo/LINE 官方帳號/實體門市/經銷商/App/客服專線 |
| 回退準備判定 | 公式 | |
| 本次不含 | 單行文字 | |
| 資訊部準備數 | 公式 | |
| 業務部準備數 | 公式 | |
| 距上線天數 | 公式 | |
| 回退條件 | 單行文字 | |
| ✅ 本案關卡 | 其他 | |
| 發布風險判定 | 公式 | |
| 發布範圍摘要 | 單行文字 | |
| 目前狀態 | 單選 | 選項:規劃中/準備中/待關卡放行/已上線/已回退 |
| 客服部準備數 | 公式 | |
| 預定上線時段 | 單選 | 選項:平日上班前(08:00 前)/平日離峰(14:00–16:00)/平日下班後(19:00 後)/平日深夜(23:00 後)/週末離峰 |
| 發布類型 | 單選 | 選項:新功能上線/改版更新/方案或價格調整/條款與政策異動/緊急修補 |
| 必過關卡未通過數 | 公式 | |
| 實際上線日 | 其他 | |
| 發布名稱 | 單行文字 | |
| 準備事項總數 | 公式 | |
| 預定上線日 | 其他 |
| 欄位名稱 | 型別 | 說明 |
|---|---|---|
| 🚀 所屬發布 | 其他 | |
| 完成日期 | 其他 | |
| 需要誰配合 | 單行文字 | |
| 負責人 | 單行文字 | |
| 完成狀態 | 單選 | 選項:未開始/進行中/已完成/卡住/不適用 |
| 產出位置 | 單行文字 | |
| 準備類型 | 單選 | 選項:業務話術與報價/客服 FAQ 與應答/教育訓練/行銷素材/官網與通路文案/技術部署/通路平台上架/內部公告 …共 9 個 |
| 完成期限 | 其他 | |
| 負責部門 | 單選 | 選項:產品部/資訊部/業務部/行銷企劃部/客服部/營運部/品保部 |
| 備註 | 單行文字 | |
| 準備事項 | 單行文字 | |
| 外部前置天數(自填) | 數字 |
| 欄位名稱 | 型別 | 說明 |
|---|---|---|
| 放行人 | 單行文字 | |
| 檢查人 | 單行文字 | |
| 關卡狀態 | 單選 | 選項:未檢查/檢查中/通過/未通過/豁免 |
| 未通過說明 | 單行文字 | |
| 🚀 所屬發布 | 其他 | |
| 必過關卡 | 核取方塊 | |
| 檢查日期 | 其他 | |
| 通過條件 | 單行文字 | |
| 關卡類別 | 單選 | 選項:技術驗證/內容就緒/通路就緒/客服就緒/法遵與條款/營運準備/回退演練 |
| 關卡名稱 | 單行文字 |
| 欄位名稱 | 型別 | 說明 |
|---|---|---|
| 是否觸發回退條件 | 單選 | 選項:否/疑似/是 |
| 回報標題 | 單行文字 | |
| 後續處理 | 單行文字 | |
| 回報部門 | 單選 | 選項:產品部/資訊部/業務部/行銷企劃部/客服部/營運部/品保部 |
| 回報日期 | 其他 | |
| 🚀 所屬發布 | 其他 | |
| 問題嚴重度 | 單選 | 選項:無問題/輕微/影響作業/影響交易/需回退 |
| 處理狀態 | 單選 | 選項:待處理/處理中/已解決/轉為後續待辦 |
| 回報人 | 單行文字 | |
| 現場狀況 | 單行文字 | |
| 回報類型 | 單選 | 選項:上線確認/客戶反應/通路狀況/問題回報/成效觀察 |
| 欄位名稱 | 型別 | 說明 |
|---|---|---|
| 順序 | 數字 | |
| 內容 | 單行文字 | |
| 章節 | 單行文字 |
三步驟開始使用
- 建立發布版本
複製範本後,先在「🚀 發布版本」建一筆發布,填「版本代號」、「預定上線日」與「主辦部門」;代號要唯一,別讓一個代號成為另一個的開頭,公式靠它比對。
- 掛上準備事項
在「🏢 部門準備事項」與「✅ 上線前檢查關卡」新增資料時,務必把「🚀 所屬發布」關聯回發布版本。沒掛上的事項不會被計入,明明在做事的部門會被誤判成沒動員。
- 每天看紅燈
上線前盯「未動員部門」與「必過關卡未通過數」,點名到的部門當天就去問;上線後請各部門到「📣 發布後回報」回報現場狀況,讓每次發布都有結果可查。
這個範本適合誰
一次上線要同時動到客服、門市、業務、行銷的公司——電商、連鎖零售、訂閱制服務的產品與專案負責人最適合。純內部系統、上線只需要工程部知道的團隊用不上,五張表的維護成本會超過價值。
從 Excel 搬過來
這個範本用到的欄位型別中,以下幾種從 Excel 搬過來時最常出錯。
| 欄位型別 | 搬移時要注意 |
|---|---|
| 單選 | 原本用儲存格顏色標記的狀態要改成單選欄位。顏色無法篩選也無法統計。 |
進階技巧
常延期的團隊可以善用「延期次數」與「延期原因」:每次改期都照實記錄,累積幾次發布後回頭看,就知道哪種「發布類型」最容易出狀況、該提早多久開始準備。
常見問題
- 部門明明在做事,為什麼還是被列為未動員?
- 最常見的原因是新增準備事項時沒把「🚀 所屬發布」關聯回發布版本,該部門的準備數就會是 0。假紅燈一多,大家就不看紅燈了,所以每筆事項掛上發布,是這個範本第一件要做對的事。
- 它會不會跟 CI/CD 或部署工具重複?
- 不會。這個範本不管部署與程式版本,那是 CI/CD 的事;它管的是客服、行銷、門市這些部門的準備與回報。技術上線流程照走你原本的工具,這裡只確保上線那天沒有部門被漏掉。
- 部門名稱跟我們公司不一樣怎麼辦?
- 「負責部門」與「主辦部門」是選項欄位,直接改成你們的組織名稱即可。但要注意「客服部準備數」這類公式欄位是照選項名稱統計的,改了選項名,對應的公式也要跟著調整。
- 上線之後這個範本還要維護嗎?
- 要,但很輕:請各部門在「📣 發布後回報」留下回報,「是否觸發回退條件」選「是」或「疑似」時,馬上找「回退決策人」拍板;確認穩定後把「目前狀態」改成「已上線」,這次發布就結案了。