1. 題目與使用場景
企業客戶希望降低閒置席位成本，但管理員不敢憑一個「最後登入時間」就停用使用者，因為使用者可能是低頻審批者、服務帳號、休假員工或即將參與關鍵專案的人。產品要決定提供提醒、分級建議，還是自動回收。
2. 面試官考察點
- 是否把買方節省成本與終端使用者連續性放在同一目標函數中。
- 是否區分活躍、可計費、被授權和實際使用，避免定義錯誤。
- 是否設計可解釋、可撤銷、分階段的建議，而非直接替管理員做破壞性操作。
- 是否用節省金額、誤停用率、恢復率和客戶留存驗證價值。
Atlassian 文件說明計費可能依據能存取應用程式的使用者數；Microsoft 文件提醒移除授權會影響應用程式使用並可能涉及信箱資料保留。方案必須同時呈現「省錢」與存取、資料後果。
3. 回答前需要釐清的問題
- 計費依據是分配席位、可存取使用者，還是峰值使用者數？
- 哪些身分不能自動建議：服務帳號、外部協作者、審批人或受監管角色？
- 管理員能否先通知使用者、轉移內容並設定恢復窗口？
- 客戶願意提供哪些事件資料，資料保留和隱私邊界是什麼？
4. 30 秒回答框架
用「目標—定義—分級—保護—指標」回答：
我會先定義可計費席位與風險例外，推出唯讀的閒置報告和可解釋建議，不直接自動停用。建議按最近活動、關鍵權限、內容所有權和即將到來的日曆事件分級，並讓管理員預覽影響、通知使用者、轉移內容後再執行。成功指標同時看淨節省、誤停用、恢復操作和客戶續約，而不是只看回收數量。
5. 分步驟深入解答
第一步：定義真實問題與對象
先確認客戶是在浪費付費席位，還是在管理離職和權限風險。建立使用者狀態：已分配席位、可存取應用程式、近期有業務活動、擁有內容、擁有高風險權限。Atlassian 的使用者和層級文件把可存取應用程式的使用者與計費關聯起來，不能用單一登入欄位替代完整定義。
第二步：設計可解釋的建議分級
高信心且低風險的使用者進入「建議移除」；有內容所有權、審批職責或服務帳號特徵的使用者進入「需要人工審核」；近期無活動但即將參與專案的使用者進入「暫緩」。每條建議展示證據、預計節省和潛在影響，管理員可以忽略並說明原因。
第三步：保護存取與資料連續性
執行前傳送通知，允許使用者確認、轉移檔案和保留信箱或稽核資料。Microsoft 文件指出移除授權可能導致應用程式出現未授權狀態，某些信箱資料需要額外保留策略，因此產品要提供預覽、恢復窗口和撤銷入口。預設只改變席位分配，不刪除使用者資料。
第四步：驗證價值與長期信任
先在自願客戶中做分組實驗：一組收到報告，一組收到可執行建議。指標包括淨節省金額、建議採納率、誤停用率、恢復時間、支援工單和續約率。分群分析高權限使用者、低頻使用者和不同規模客戶，避免總體節省掩蓋嚴重個案。
6. 高品質示範回答
我會把產品定位為「席位治理助手」，不做靜默自動回收。第一步給管理員一個唯讀報告，顯示每個使用者的計費狀態、最近業務活動、內容所有權、權限風險和預計每月節省。服務帳號、外部協作者和關鍵審批角色預設排除。
>
對低風險使用者，管理員可以批量選擇，系統先傳送通知並提供內容轉移和七天恢復窗口；執行只取消應用程式存取或席位分配，不刪除帳戶和資料。高風險使用者只顯示人工審核建議。每個動作有預覽、稽核記錄和一鍵撤銷。
>
我會用淨節省、建議採納率、誤停用率、恢復時間、支援工單和續約率評估。若節省提高但誤停用或工單上升，就收緊規則；若客戶只想了解利用率，則優先提供報告而不推動回收。這樣既回應成本問題，也保護關鍵工作流和信任。
7. 常見錯誤
- 把「最後登入」當成唯一活躍標準。
- 直接自動停用高權限、服務帳號或內容所有者。
- 只宣傳節省金額，不展示存取、信箱和資料保留後果。
- 沒有通知、預覽、恢復窗口和撤銷入口。
- 只用回收席位數衡量成功，忽略誤傷和續約。
8. 追問及應對
追問一：客戶要求自動回收，怎麼處理？
提供客戶可配置的策略，但設定高風險例外、通知與恢復窗口；首次預設唯讀或需要確認，累積足夠證據後再允許更進取模式。
追問二：如何識別服務帳號？
結合目錄標記、API 呼叫、登入方式、擁有的權限和客戶確認，給出機率與證據，不用單一啟發式自動決定。
追問三：如果節省很小，為什麼還做？
先驗證客戶是否願意為治理可見性付費；若淨節省不足以覆蓋風險和支援成本，就把能力收斂為報表或與更高價值的權限治理綁定。