SaaS 是否應讓客戶自選故障通知渠道？
題幹與適用場景
一家 B2B SaaS 想讓客戶訂閱服務故障與維護通知，候選渠道包含狀態頁、Email、簡訊、Slack、Teams 與 Webhook，且可按元件訂閱。請決定是否做、先服務誰、如何避免告警疲勞，並說明嚴重故障、局部故障與維護通知的不同策略。假設產品服務多個時區與大型企業，不能把發得越多當作價值。
面試官考察點
考察的是產品取捨：是否把通知視為風險控制與行動入口，而非行銷觸達。強回答按影響與緊急程度定義預設策略，區分可發現性、送達率、重複噪音與合規責任；也能說明元件訂閱、Webhook 與退訂鏈路如何改變工程成本和客戶價值。
回答前需要釐清的問題
- 誰需要行動？值班工程師、業務管理員與一般使用者的時效、渠道和權限不同。
- 事件粒度是什麼？全站中斷、單元件退化、計畫維護與安全事件不能共用一條通知規則。
- 客戶已有何種整合？若已有 SIEM、ITSM 或值班平台，Webhook 的邊際價值高於再做聊天機器人。
- 是否允許控制預設訂閱？關鍵安全或合規事件可能必須發送，普通更新則應允許精細退訂。
- 如何衡量成功？同時看受影響客戶的行動率、有效送達、誤報退訂與支援工單，不能只看發送量。
推薦方案與推導
先做「事件影響 × 緊急程度」矩陣。P1 全站不可用預設進入公開狀態頁，並向受影響訂閱者發送 Email；客戶主動選擇時再增加簡訊或 Webhook。P2 局部元件退化只通知訂閱該元件的管理員；計畫維護提供提前提醒與變更窗口；安全事件按法律與合約處理，避免公開消息洩露內部細節。
第二步建立偏好模型：元件、事件類型、嚴重等級、渠道、時區、免打擾窗口與退訂狀態都應可見。每條訊息帶事件 ID、目前狀態、下次更新時間與管理訂閱入口。發送層要有去重鍵與重試上限，Webhook 需要簽章、指數退避與可重播事件；簡訊需要成本上限與頻率保護。
第三步分階段發布：先做狀態頁加 Email 訂閱，驗證覆蓋率和有效行動；再開放元件訂閱；最後為有明確整合需求的客戶提供 Webhook、Slack 或 Teams。將能否在受影響元件上做出正確動作作為北極星結果，而不是渠道數量。
替代方案與取捨
只提供狀態頁最便宜、噪音最少，但要求客戶主動查看，無法滿足值班回應。全渠道預設推送提高觸達，卻增加成本、重複與退訂。按元件與嚴重等級訂閱相關性更高，但需要穩定的元件目錄、權限模型、事件分類和遷移相容。企業專屬通知策略可滿足合約需求，應優先以策略配置而非硬編碼分支處理。
失敗場景、邊界與反例
- 把每次內部重試或短暫抖動都當成客戶事件，造成告警疲勞。
- 允許客戶完全退訂安全或合約要求的通知，留下責任與合規風險。
- 只記錄發送成功，不驗證簡訊號碼、Webhook 回應、郵件退信與最終行動。
- 元件重命名或拆分後未遷移訂閱，客戶以為仍在保護範圍內。
- 狀態頁、客戶通知與內部值班訊息各自維護事實，導致狀態不一致；應由一個事件狀態源派生不同受眾訊息。
測試與驗證清單
用歷史事件回放驗證矩陣：全站 P1、單元件 P2、計畫維護、誤報後關閉、重複更新與跨時區窗口。測試退訂、重新訂閱、元件遷移、Webhook 重播、簡訊頻率限制與郵件退信。上線後按客戶與事件等級觀察有效送達率、受影響客戶行動率、每事件訊息數、退訂率、支援工單變化與通知成本，並設停止擴展的護欄閾值。
追問與延伸
預設渠道應如何設定？
按風險設定預設：受影響管理員接收 Email；P1 且客戶主動啟用時可接收簡訊或 Webhook；普通維護使用狀態頁與可選提醒。預設值必須解釋原因，並允許在權限範圍內修改。
如何避免多渠道重複轟炸？
以事件 ID 與訂閱者為鍵合併，設更新窗口與渠道優先級；同一狀態變化只發送一次摘要，除非嚴重等級升級。所有渠道共用狀態源和退訂狀態，避免一個渠道退訂、另一個仍持續發送。
什麼時候不應做自選渠道？
當事件分類、元件邊界或送達遙測尚不可靠時，先做單一狀態頁加 Email。若客戶規模小、事件影響低且沒有整合需求，多渠道營運成本可能超過價值，應先用公開狀態頁驗證真實需求。