產品經理面試：B2B SaaS 是否應該建置權限申請流程？
題幹與適用場景
一個 B2B SaaS 的企業客戶透過工單或聊天請求應用程式存取、加入群組與臨時管理員權限。IT 團隊認為人工處理慢且容易漏審，安全團隊則擔心核准過寬、核准人缺席與權限永不回收。請判斷是否建置流程、先服務哪些請求，並說明首版範圍與上線門檻。
這題考察產品取捨，不是要你直接畫核准狀態機。你要先區分低風險自助存取、需要資源負責人核准，以及必須由安全管理員處理的高風險權限。
面試官考察什麼
高分回答會從使用者任務與風險分層出發，定義申請人、核准人、資源負責人與執行系統的責任，再用指標驗證等待時間下降是否以安全事件上升為代價。Interview Pilot 將客戶判斷、限制下的產品設計、指標與跨團隊推進列為產品面試核心訊號。
Okta 的 Access Requests 文件展示條件、請求類型、核准序列、任務、計時器與多渠道入口等真實產品邊界；Microsoft Entra 的管理員同意流程則說明，申請、審核、核准、拒絕、封鎖與通知必須分開建模。
回答前要釐清的問題
先問請求的資源類型與風險：一般應用程式、敏感資料、群組、管理員角色還是短時間提升；誰擁有最終核准權；是否需要經理加資源負責人的多級核准；權限是否有時長；核准人離線時如何轉派；客戶已有身分治理工具，還是希望 SaaS 自帶；以及申請記錄是否要進入客戶稽核系統。
這些答案會改變首版：低風險應用程式可用單步核准，高風險角色需要雙人或資源負責人核准；若已有治理平台，應優先提供整合與狀態回寫，而不是複製完整目錄。
30 秒回答框架
我會先驗證高頻且可量化的痛點，優先處理低風險應用程式自助申請與需要明確時限的臨時權限。首版包含資源目錄、申請理由、風險標籤、核准人、狀態通知、到期回收與稽核記錄；高風險管理員角色保留人工雙重核准。用完成時間、待處理佇列、拒絕率、到期回收率與越權事件作為一組指標，先在 5—10 個企業客戶中 beta。
分步驟深入解答
第一步：按資源與風險分層
建立最小資源分類：一般應用程式、業務群組、敏感資料集、管理員角色。為每類定義預設核准人、是否需要理由、是否允許臨時授權與是否必須記錄業務影響。不要把所有請求放進同一條流程；低風險請求追求速度，高風險請求追求可解釋與可回收。
第二步：明確角色與責任邊界
申請人說明用途與時長；經理確認業務需要；資源負責人確認資源風險；安全管理員負責高風險策略；執行系統真正授予或撤銷權限。Microsoft 文件區分指定審核人、可查看的請求，以及具有 RBAC 權限才能核准的動作，說明「能看見」不等於「能核准」。
第三步：設計首版申請體驗
目錄卡片應顯示資源 owner、資料敏感程度、預計時長與已有替代方案。申請表只問會改變核准的欄位，例如用途、專案、結束日期與是否包含客戶資料。送出後顯示狀態、下一位核准人、補充材料與預計處理時間，避免使用者反覆開工單。
第四步：設計核准、轉派與到期
把核准、拒絕、封鎖、補充資訊、轉派與過期分成不同結果。Okta 將核准序列建模為問題、任務、核准與工作流程步驟，並支援委派與停滯升級；首版至少要處理核准人離職、重複請求、逾時與資源 owner 變更。臨時權限必須有明確到期動作，不能只在介面顯示日期。
第五步：安全、稽核與整合
每次申請記錄申請人、資源、理由、核准人、政策版本、授予範圍與撤銷結果。拒絕與封鎖要向申請人解釋不同後果；敏感請求應將事件送入客戶 SIEM 或現有治理平台。若 SaaS 無法可靠撤銷下游權限，就只能提供申請與核准記錄，不能聲稱已完成存取控制。
第六步：驗證價值與 Go/No-Go
先選 5—10 個已有身分目錄、請求量穩定且願意共同測試的企業。Go 條件包括權限實際授予與回收一致、核准越權測試通過、到期任務可重試、稽核記錄完整且佇列延遲可解釋。No-Go 條件包括無法確定 owner、臨時權限無法撤銷、關鍵核准無人接手，或使用者為繞過流程繼續使用人工渠道。
高品質示範回答
我會把問題定義為縮短企業存取申請的等待時間，同時保留風險分級與可回收性，而不是先做一個通用核准器。首批選擇已有身分目錄、低風險應用程式請求量高，且臨時權限有明確業務時長的客戶。高風險管理員角色仍要求資源負責人與安全管理員雙重核准。
首版提供資源目錄、owner 與風險標籤、申請理由與結束日期、狀態通知、轉派、到期回收與稽核記錄。申請人只填寫影響決策的資訊；核准人能看到用途、範圍、已有權限與政策版本。核准、拒絕、封鎖、補充資訊與過期分別建模，避免所有結果都顯示成「處理中」。
我們用申請完成時間、佇列積壓、拒絕率、到期回收成功率、繞過工單比例與越權事件觀察結果。先讓 5—10 個客戶 beta；如果下游權限無法可靠撤銷，或核准與稽核記錄不一致，我會停止擴大範圍，先做整合或只提供可追蹤的申請記錄。
常見錯誤與改進
- 所有權限一條核准鏈 → 失敗原因： 低風險請求被高風險規則拖慢 → 修正： 按資源與風險分層。
- 只做申請表 → 失敗原因： 沒有 owner、到期與實際執行 → 修正： 定義核准責任、下游授予與回收結果。
- 把拒絕與封鎖混為一談 → 失敗原因： 使用者不知道能否再次申請，管理員也無法表達風險判斷 → 修正： 分開結果、理由與通知。
- 只看平均處理時間 → 失敗原因： 速度提高可能伴隨越權或過期權限 → 修正： 同時看回收成功率、越權事件與繞過渠道。
- 忽略核准人缺席 → 失敗原因： 佇列會卡住並誘發線下核准 → 修正： 支援轉派、委派、升級與逾時重試。
追問及應對
Should every request require a manager approval?
No. Use risk and resource ownership. Low-risk applications can use a resource owner or policy-based approval; sensitive data and admin roles need stronger review. A manager may confirm business need but should not be the only security decision-maker.
What if the downstream system cannot revoke temporary access?
Do not promise time-bound access. Limit v1 to a request and approval record, or integrate with a system that can enforce revocation. A visible expiry date without an enforcement action creates false assurance.
How should denial differ from block?
Deny rejects the current request and explains the reason; block also prevents future requests for the resource until policy changes. The UI, notifications, and audit record should expose that difference.
Which metric matters most at launch?
Pair time to access with safety metrics: successful expiry revocation, unauthorized grants, stale queue age, repeat requests, and manual bypasses. Optimize only after confirming the faster path still meets the customer’s control requirements.