產品經理面試：B2B SaaS 是否該上線公開狀態頁？
題幹與適用場景
一家 B2B SaaS 最近經常收到「服務是不是掛了」的客戶詢問。支援團隊統計，約 30% 工單與可用性確認有關。工程團隊建議上線公開狀態頁，銷售擔心公開故障會影響續約。請判斷是否上線，並說明方案、指標與風險控制。
面試官考察什麼
考察你能否把「做不做一個頁面」還原成客戶信任、事故溝通與營運能力的產品決策。高分回答會區分客戶類型與揭露邊界，說明狀態來源與責任人，給出可驗證的指標與分階段上線條件，而不是直接羅列功能。
回答前要釐清的問題
先問四件事：主要客戶是大眾、受監管企業還是少數大客戶；合約是否有可用性承諾與通知約定；目前監控、值班與事故指揮是否成熟；客戶最需要的是自助確認、訂閱通知，還是根因解釋。
也要確認是否已有內部或客戶專屬狀態頁。公開頁、私有頁與面向特定受眾的頁面解決的受眾不同；把所有客戶放在同一個可見性模型裡，容易造成過度揭露或資訊不足。
30 秒回答框架
我會先驗證客戶是否需要一個可信的外部訊號，再決定公開、私有或分層頁面。若 30% 工單確實是可用性確認，且團隊能持續提供準確更新，我會先以 3—4 個客戶可見元件做小範圍上線。頁面只呈現可操作的狀態和預計下一次更新時間，事故指揮官負責發布，安全敏感細節留在內部。用首條更新延遲、準時更新率、重複工單和信任回饋判斷是否擴大範圍；若資料來源不穩定或沒有明確責任人，就先補齊事故流程，不急著公開。
分步驟深入分析
第一步：定義使用者問題與受眾
把工單拆成「確認是否受影響」「知道何時再看」「取得替代操作」三類。管理員可能需要元件級狀態，普通使用者只關心能否登入和核心任務是否可用。銷售、客服和合作夥伴也可能需要不同的訂閱與歷史檢視。先按客戶合約、地區、產品模組和故障影響分群，再決定頁面受眾。
第二步：選擇公開、私有或分層可見性
公開頁適合多數客戶都需要同一事實來源的場景，優點是降低重複詢問並建立透明預期；代價是故障、維護時段和元件名稱對外可見。私有頁適合員工或內部營運。面向特定受眾的頁面可給企業客戶更細的元件和通知，但會增加權限、維護和一致性成本。回答時應說明選擇依據，不把公開頁當成預設答案。
第三步：設計元件、狀態與資訊邊界
只揭露客戶能理解的元件，例如「登入」「API」「檔案匯出」「控制台」，不要直接揭露內部服務名稱。定義 operational、degraded performance、partial outage、major outage、maintenance 等狀態，並規定每種狀態的進入與退出條件。事故可按 investigating、identified、monitoring、resolved 更新；根因、漏洞細節和受限客戶資訊留在安全與客戶溝通流程中。狀態頁本身不負責監控，必須綁定經驗證的監控或事故指揮輸入。
第四步：把發布流程接入事故回應
偵測到影響後，由事故指揮官確認受影響元件、受眾與首條更新內容，再發布「正在調查」狀態；確定原因後更新為「已識別」，恢復觀察期間標為「監控中」，完全恢復後才標記「已解決」。設定例如每 15 分鐘一次的更新節奏，並讓客服、銷售和狀態頁使用同一事實來源。Google SRE 強調預先準備溝通管道、受眾名單和角色；頁面上線不能取代這些職責。
第五步：定義信任、營運和安全指標
上線前設定首條更新延遲、準時更新率、狀態修正率、訂閱送達率、狀態頁自助瀏覽量、重複可用性工單數和客戶信任回饋。假設目標是把重複工單降低 10%，仍要同時觀察誤報和漏報，避免用更少工單掩蓋更差體驗。安全指標包括不當揭露次數、內部服務名稱洩露和權限配置錯誤；出現高風險時應暫停自動發布並回到人工審批。
第六步：分階段 rollout 與 Go/No-Go
先做內部演練，再給一小組客戶開放 3—4 個元件的頁面與訂閱。Go 條件包括明確的值班與發布責任人、可追溯的狀態來源、連續演練能準時更新，以及客服和銷售有統一話術。若首條更新長期超過目標、狀態來源經常漂移，或安全審查未通過，則 No-Go，先修復流程。公開發布後保留事故歷史和復盤入口，定期刪除不再有用的內部細節。
高品質示範回答
我不會先回答「上線或不上線」，而會先判斷客戶是否缺少可信的外部訊號。現在 30% 工單都在確認服務狀態，說明自助可見性可能有價值，但公開故障也會放大錯誤資訊的影響。
我會選擇分階段方案：先內部演練，再向一組客戶開放登入、API、檔案匯出和控制台四個元件。頁面顯示狀態、影響範圍、下一次更新時間和訂閱入口，不顯示內部服務名稱、漏洞細節或未驗證的根因。事故指揮官負責發布，流程使用 investigating、identified、monitoring、resolved 四個階段，每 15 分鐘更新一次，客服和銷售引用同一事實來源。
成功標準包括首條更新延遲、準時更新率、重複可用性工單、訂閱送達率、誤報修正率和客戶信任回饋。假設重複工單下降 10% 且更新準確率達到目標，再擴大到全部客戶；若沒有穩定資料來源、值班責任人或安全邊界，我會先補齊事故回應能力。這樣頁面服務的是信任和溝通目標，而不是孤立的前端專案。
常見錯誤與改進
- 只說「透明會增加信任」：補充客戶分群、揭露代價和可測指標。
- 把狀態頁當監控系統：說明它需要監控或事故指揮輸入。
- 把所有故障都自動公開：定義事故級別、人工審批和安全例外。
- 只展示「正常／故障」：增加影響範圍、更新時間和下一步動作。
- 直接承諾降低工單：用實驗或分階段資料驗證，區分瀏覽量與問題解決率。
追問及應對
Should all incidents be public?
No. Publish customer-impacting facts that are verified and useful; keep security-sensitive, employee-only, or customer-specific details in the appropriate private channel. The visibility rule should be tied to impact and disclosure risk.
What if status data is inaccurate?
Stop automatic publication, assign an incident owner, and show a correction with the next update time. Track false-positive and false-negative rates; accuracy is a release gate for broader rollout.
How do you avoid revealing security details?
Use customer-facing component names and approved message templates. Separate availability communication from the security incident process, with security review before any detailed disclosure.
How do you prove it reduces support load?
Compare similar incident cohorts before and after launch: duplicate availability tickets, time to first customer answer, self-service visits, subscription engagement and trust feedback. A 10% reduction is a test target, not a guaranteed outcome.