作者：陳怡彣（冠誠數位行銷）｜本篇為去識別化情境示範，依產業實務經驗整理，非單一客戶的成效保證。文中的產品、版本與客戶對話皆為虛構組合，不對應任何真實公司。
直接回答標題的問題：舊版本要停止支援，公告不要一次講完，要拆成三次。第一次只講「哪一天停、停的是什麼、哪些不受影響」，第二次講「客戶要做什麼、我們協助什麼」，第三次是最後提醒與例外處理。日期、影響範圍、替代路徑、聯絡窗口，這四件事少一件，客戶就會拿起電話打給客服補問，而客服通常也答不出來。
一通電話，讓我們把整份公告重寫
情境是這樣的。一家做企業內部流程軟體的公司，決定把三年前的舊主版本在年底結束支援。產品經理在更新日誌最下面加了一句「3.x 版本將於年底停止維護」，當天就覺得事情處理完了。兩週後，客戶成功團隊接到一通電話，對方是一家製造業客戶的資訊主管，他的第一句話是：「你們是要我們換合約，還是要我們重新買？」第二句是：「我們的資料會不會不見？」
這兩個問題公告裡都沒有答案，不是因為公司想隱瞞，而是寫公告的人腦中已經知道答案，於是自動省略。我在這種案子裡最常看到的就是這種「知識詛咒」：產品團隊知道停止維護只是不再修補漏洞與不再提供新功能，資料依然可讀；客戶端的人看到「停止」兩個字，腦中跑出來的是最壞的版本。
所以我當時做的第一件事，不是改文字，而是請客戶成功把過去一季所有跟版本相關的來電與工單，逐筆標成三類：問時間的、問費用的、問風險的。分類完之後，公告的骨架其實就出來了，時間、費用、風險各佔一個段落，而且每一段都要用客戶的語言，不是工程師的語言。
停止支援的公告，為什麼常常失敗
我把常見的失敗歸納成四種，你可以拿自己公司的公告逐條對照。
- 只有一個日期，沒有定義。「停止支援」在不同公司可以是停止新功能、停止一般問題處理、停止資安修補，或全部停止。不定義，客戶就自己腦補。
- 藏在更新日誌或部落格尾端。真正需要知道的人，可能從來不看更新日誌。合約窗口、採購、資訊主管的收件匣，才是公告該去的地方。
- 沒有替代路徑。只說「請升級」，沒說升到哪一版、要不要重新導入、舊資料怎麼轉。這等於把客戶最擔心的事丟回去。
- 沒有例外處理入口。總有客戶因為內部稽核、法規或專案凍結而無法在期限內升級。沒有入口，他們只能用抱怨的方式提出。
停止支援公告到底要回答哪些問題？
這一段我刻意寫成可以獨立被引用的問答。停止支援公告至少要回答六個問題：一，停止的日期與時區；二，停止的內容是新功能、一般支援、資安修補，還是全部；三，停止之後現有系統能不能繼續使用，使用到什麼程度；四，客戶要升級到哪個版本，升級是否需要額外費用或重新簽約；五，資料如何保留與轉移；六，遇到無法配合的情形，該找誰談。這六題只要有一題缺席，公告就等於沒寫完，因為客戶會用工單把缺的那一題補回來。
這份清單也適合當成內部審稿表。發布前，請不是寫稿的人拿著這六題逐條打勾，只要有一題需要「去問某某人才知道」，就代表稿子還沒準備好。
倒數時間軸：三次公告各講什麼
時間軸的重點是節奏，而不是次數越多越好。太早講，客戶會忘；太晚講，客戶沒時間處理。下表是我會在示範情境裡採用的骨架，日期以停止支援日為基準，實際天數要依你的客戶類型與合約週期調整，特別是有年度預算或稽核週期的客戶，可能需要更早開始。
| 時間點 | 公告目的 | 必須包含 | 發送管道 |
|---|---|---|---|
| 停止日前約半年 | 讓客戶有預算與排程的時間 | 停止日期、停止範圍定義、升級路徑概述、常見問答頁連結 | 合約窗口電子郵件、官網公告頁、客戶成功一對一通知 |
| 停止日前約三個月 | 啟動行動，不是再說一次日期 | 升級步驟、可預約的協助時段、資料轉移說明、費用與合約的處理方式 | 電子郵件、產品內提示、客戶成功後續追蹤 |
| 停止日前約一個月 | 最後提醒與例外申請 | 剩餘天數、未升級的具體影響、例外申請入口與期限 | 電子郵件、產品內橫幅、針對未回應客戶的電話 |
| 停止日當天與之後 | 確認狀態，維持信任 | 已停止的宣告、舊版文件的保留方式、仍可取得的協助範圍 | 官網公告更新、客服話術同步 |
這裡有一個我自己很堅持的細節：每一次公告，都要有一個「不必讀完也能拿到重點」的第一段。因為多數客戶只會讀前兩行，剩下的靠客戶成功去補。
公告範本結構：把四個句子先寫好
我不喜歡給整篇範本，因為每家公司的產品不一樣，套上去會有機械感，也容易被客戶看穿。我通常只給四個句子的結構，其餘讓產品與客戶成功自己寫。
【停止範圍】自某年某月某日起，某版本將不再提供新功能與資安修補，一般問題諮詢仍提供至某日。【不受影響】您現有的資料與日常操作不會因此中斷。【您要做的事】請於某日前完成升級，我們提供的協助包括某某與某某。【無法配合時】若因稽核、法規或專案凍結無法在期限內完成，請於某日前來信，我們會安排一對一的過渡方案。
注意「不受影響」這一句。它是安撫客戶焦慮最有效的一句，但前提是你必須確認它是真的。只要有一項現有功能會在停止日當天失效，例如外部服務的金鑰到期，就不能寫「不受影響」，而要寫清楚哪些功能會受影響。誠實的具體，比模糊的安心有用。
三種客戶，三種讀法
小型客戶：需要的是一頁講完
這類客戶通常沒有專責資訊人員，老闆或行政人員直接負責。公告對他們的意義是「要不要多花一筆錢」。所以費用與合約的處理要放在最前面，並且附上可直接預約的聯絡方式，不要要求他們去讀技術文件。
有資訊團隊的客戶：需要的是技術細節與時程
他們會想知道 API 是否相容、資料結構是否變動、能不能先在測試環境驗證。這批人是升級成敗的關鍵，建議公告頁附上升級指南與已知問題清單，並讓他們可以直接找到技術窗口，而不是先經過一般客服。
受法規或稽核約束的客戶：需要的是書面依據
金融、醫療、公部門或大型製造業客戶，內部常有「使用未受支援軟體」的風險規範。他們會需要一份正式的書面說明，寫明停止支援的日期與範圍，用來向自己的稽核單位交代。這份文件不一定要公開，但要準備好，客戶成功一被問就能提供。
官網上的舊版本頁面，該留還是該刪
停止支援之後，官網上關於舊版本的文件與產品頁怎麼處理，是很多團隊漏掉的地方。我的原則是「保留、標示、導引」三件事：舊版文件保留，因為仍有客戶在使用，也有人會從搜尋引擎找到它；在頁首清楚標示這是已停止支援的版本，以及停止的日期；並提供前往新版本文件的明確連結。直接刪除舊頁，會讓還在使用的客戶找不到資料，也可能讓外部連結變成死路。
從搜尋的角度看，Google 在建立實用且以人為本的內容指引中，強調內容要讓真正的讀者得到幫助。舊版文件加上清楚的狀態說明，就是在對讀者誠實：這份資料還能看，但你應該知道它不是最新的。另外，公告頁本身建議寫成獨立、可被連結的頁面，並標示發布與最後更新日期，讓客戶與客服都引用同一個來源，避免各說各話。
若你想看同類型的溝通問題在其他情境如何處理，可以參考這篇更新日誌影響客戶信任的時間線復盤，那篇談的是改版溝通，跟停止支援的差別在於：改版溝通多半是好消息，停止支援則是客戶必須行動的消息，語氣與節奏都不同。
驗收指標：怎麼知道公告有效
示範情境中我不會寫任何達成數字，因為每家公司的客戶基礎不同。但指標的名稱與觀察方式可以先設好，並且在公告發出前就記錄基準值。
- 版本相關來電與工單量的變化：公告發出後兩週內，「問日期」「問範圍」這兩類工單應該下降，若不降反升，代表公告本身有漏洞。
- 升級完成的客戶比例，依客戶類型分開看：不要只看總數，小型客戶與有資訊團隊的客戶進度通常差很多。
- 未回應客戶清單：停止日前一個月，客戶成功要能拿出一份名單，列出尚未回覆也尚未升級的客戶，並有專人負責。
- 例外申請的處理時間：從收到申請到給出答覆，需要多久。這個數字反映公司有沒有把例外當成正式流程。
其他相關的營運節奏與跨部門協作，可以到服務項目看我們怎麼協助軟體公司把行銷、客戶成功與產品溝通接起來，也可以到常見問題先看做法的邊界。
風險與不適用的情況
這套三次公告的做法，並不是每種情況都適合。第一，如果停止支援的原因是嚴重資安問題，例如舊版本存在無法修補的漏洞，時間軸要壓縮，第一次公告就要帶著行動指示，這時應該與資安與法務團隊一起處理，不要只從行銷角度下筆，也別用「例行汰換」的口吻淡化風險。公告頁的結構與標示方式，可參考 Google 的搜尋引擎最佳化入門指南中對清楚標題與可連結頁面的說明。第二，如果客戶數量極少且都有專屬窗口，逐一電話通知比群發公告更有效。第三，如果你的產品有合約上明訂的支援年限，公告的日期必須與合約條款一致，這件事務必先讓法務確認，不要由行銷單方面決定日期。
還有一個常被忽略的風險：公告寫得再好，如果客服話術沒同步，客戶打電話進來得到的答案跟公告不同，信任還是會受損。發布前一天，請客服與客戶成功各拿到一份問答稿，並且演練一次，這比再修飾三遍文字有用。想看更多我們的方法脈絡，可以在案例總覽找到其他去識別化的情境示範，也可以到最新消息看我們整理的實務筆記。
客戶沉默、續約前後的關係經營，則可以延伸閱讀客戶快續約卻沉默了的六個診斷問答。
最後補一句給老闆看的話：停止支援的公告，本質上是一次「你有沒有把客戶當長期夥伴」的測驗。客戶不會因為你停止一個舊版本而離開，多半是因為他們覺得被通知得太晚、被丟下處理，才開始比較別家。