業務系統存取權限
收集系統、申請角色、業務用途，並在需要時填寫到期日。審核人核准存取後，由獲授權管理員在實際系統授予權限，再為申請人記錄結果。申請應用程式中的狀態變更，不等於帳號佈建。
寫下您打算交付的服務
| 決策 | 政策範例 | 應避免的常見錯誤 |
|---|---|---|
| 成果 | 員工所需筆電與辦公桌設備已設定就緒 | 不要只因採購單已核准，就將申請標為完成。 |
| 必要背景資訊 | 業務需求、地點、日期與設備要求 | 收集會影響交付決策的事實，不必涵蓋所有可能的資產欄位。 |
| 授權 | 指定設備審核人 | 審核決定允許團隊做出承諾，並不能證明已實際交付。 |
| 交付任務 | 整備筆電；交付擴充基座 | 每項任務都需要負責人與完成資訊。 |
| 驗收 | 員工確認兩項交付內容 | 任務尚未完成或受阻時，無法進行最終驗收。 |
圍繞決策建立流程
區分服務申請與非預期問題
「因職務調整需要一台筆電」是明確的服務；「現有筆電無法充電」是支援問題。處理人員可能相同，但所需資訊、決策與完成條件不同。
指定成果負責人
指派能釐清跨團隊責任的服務負責人。任務負責人完成各自工作，服務負責人則持續對完整申請與承諾成果負責。
只在影響決策時要求授權
支出、存取權限或例外情況可能需要人工審核，例行且低風險的交付則未必需要。避免只有形式、延誤工作卻未增加有效控制的簽核。
讓不完整資訊可以補正
審核人需要能退回申請、說明缺少的資訊，並接收修正版。不要刪除原始決定，也不要透過未留說明的欄位修改，悄悄改變駁回結果。
定義何謂交付完成
列出必要任務及各負責人需記錄的佐證，讓員工知道自己驗收的是什麼。不能因單一項目已完成，就掩蓋尚未完成的相依任務。
不同申請需要不同處理方式
故障的會議室顯示器
這是非預期問題，不是從服務目錄選購服務。記錄會議室與影響、指派處理人員、登錄診斷與等待，並確認顯示器恢復正常。此生命週期可使用內部服務台範例。
先導入一項完整服務
從一項服務與幾個真實情境開始
測試例行申請、需授權的申請、部分交付、退回補正及完整交付，並請實際服務負責人確認每種情況是否都能進入正確的下一步。
新增儀表板前，先檢視停滯的工作
查看資訊缺漏、無人負責的任務、阻礙及驗收延遲。建立能幫助人員排除這些狀況的檢視；只有數量無法說明該採取什麼行動。
擴充時明確界定範圍
當另一項服務的輸入資訊與交付內容都能說清楚時，再加入該服務。機密申請、技術佈建及專業事件應變，應留在具備相應設計與權限的系統中。
服務申請流程規劃常見問題
誰應負責服務申請管理？
指定了解承諾成果、能協調跨團隊交接的服務負責人。個別交付任務仍需各自的負責人；管理儀表板不等於對服務負責。
應先設計政策，再選擇軟體嗎？
至少先定義服務成果、必要資訊、需要時的授權人、任務負責人與驗收條件，再確認應用程式能否讓這些決策與例外處理實際可用。
不完整的申請應如何處理？
附上具體問題退回，並保留歷程。明確指出誰應補正資訊、何時可以繼續；不要只為了將申請移出處理中佇列，就標記為駁回。
小團隊應先使用哪個指標？
先從需要做出的決策出發：哪些申請沒有負責人、哪些任務受阻、哪些交付待確認？先定義開始、結束、工作日曆與等待政策，再加入交付時間指標。
服務交付與服務台範例是同一個同步應用程式嗎？
不是。兩者是獨立範例，分別處理明確定義的服務交付與員工非預期問題。若需要兩者交接，應設計關聯與責任歸屬，不要假設會自動同步。
選擇團隊的下一步
將書面的服務政策變成可運作的流程
先用範例申請與交付任務測試團隊交接，再擴充更多服務。