描述一個結果,而不是一個部門
使用請求者能理解的語言命名服務,說明將提供什麼、誰有資格、需要哪些資訊、預計時間、任何費用或政策,以及例外情況送往何處。
將可重複的需求轉化為可理解的服務,完成請求,進行相應的授權,負責履行,處理例外情況,並由請求者確認結果。
打開包含待授權、已退回資訊、排定工作、逾期操作及已完成請求的履行佇列。對定義的服務使用此生命周期;在出現意外中斷需要恢復時,使用事件管理。
最多 5 位使用者可免費使用,無需信用卡。
無需撰寫程式碼,即可調整欄位、工作流程和儀表板。 探索 1,000 多個應用程式範本與使用情境
第一個視圖是請求履行佇列。它包括已授權、已退回、已排程、逾期和已確認的範例,而不是空白表單。
當使用者了解他們可以請求什麼,並且履行團隊收到完整、可立即決策的資料時,請求就會更容易完成。
使用請求者能理解的語言命名服務,說明將提供什麼、誰有資格、需要哪些資訊、預計時間、任何費用或政策,以及例外情況送往何處。
僅在該服務項目需要時,使用條件欄位要求員工、設備、地點、存取等級、商業理由、日期、證據或費用背景。
當提供項目變更時,請同時更新其形式、資格、批准、履行計畫、承諾和溝通,以免公開承諾與運作現實脫節。
真實的工作流程應返回不完整的請求、保留修正內容,並在開始履行前完成授權。
在請求管理者或服務負責人批准前,請確認請求者、就業或客戶狀態、服務權益、所在地、前提條件、資產背景及所需證據。
在政策允許下,自動批准低風險標準請求,將高風險的訪問或支出路由至負責角色,並明確授權委託和例外情況。
將交付拆分為擁有的步驟、依賴關係、目標日期、交接和證據。不要因為第一個任務完成而標記父請求為完成。
內部活動很重要,但請求者體驗到的是成果。
顯示請求是否等待信息、授權、履行、排程或確認,並提供下一個預期行動,而不是模糊的內部狀態代碼。
保留審查備註、更正值、重新提交和最終決定。退回的請求是工作流程的一部分,而不是在電子郵件中重新開始的理由。
記錄交付證據及請求者確認,然後審查返工、老化、放棄、例外量及需求模式以改進服務。
使用者可能從一個入口開始,但維運記錄應與任務匹配。
| 使用者需求 | 主要記錄 | 結束條件 |
|---|---|---|
| 定義的存取、設備、資訊或服務 | 服務請求 | 授權並完成的結果 |
| 現有服務意外中斷 | 事件 | 已驗證的恢復 |
| 需要生產變更 | 相關變更 | 授權並驗證的實施 |
| 服務不涵蓋需求 | 例外或需求審查 | 明確決策及下一步路徑 |
根據特定服務所需的信息、資格、授權、履行步驟、例外情況和接受條件建立請求記錄。
結果是一種請求體驗,對用戶而言保持簡單,同時讓操作員可以看到資格、授權、交付和確認。根據提供的服務、角色、地點、存取等級或設備需求有條件地顯示欄位,讓請求者不必填寫通用表單。
將成本、存取、政策或例外情況決策送至正確的審核人員,並對不完整的請求返回明確的更正說明。
將任務完成、依賴關係、證據及請求者確認分開,避免一個完成的步驟掩蓋未完成的服務。
保持對用戶的請求簡單,同時將授權和交付控制與實際服務匹配。
條件性接收、資格、人為審批、退回和重新提交、關聯的履行任務、例外、證據和申請人確認。
將帳戶配置、採購、付款、庫存、身份和專家履行交易保留在獲授權執行的系統中。
成熟的目錄、全通路接收、發現、CMDB、遠端支援、供應商內容以及廣泛的預建 IT 整合,比工作流程的彈性設定能力更重要。
服務請求是要求一項明確、可預期的服務或項目。事件則是報告意外中斷或降級。它們可能共用接收和服務背景,但其決策和完成證據不同。
不需要。僅在風險、成本、權利、存取、政策或責任需要決策時才使用批准。低風險的標準請求可以遵循授權規則,而不必增加形式上的批准步驟。
是的。範例應用程式使用原生流程,其會回傳帶有精確修正的不完整請求,保留歷史記錄,並將修正後的提交路由回授權處理。
是的。獲授權的建置者可以在不撰寫程式碼的情況下變更相關欄位、表單、工作流程、權限、自動化和儀表板,同時保持變更受控和測試。
是的。Jodoo 的免費方案最多支援五個使用者,且不需要信用卡,因此小型團隊可以先測試這個運作情境,然後再檢查更廣泛部署的現有限制。