使用請求者熟悉的語言
以結果為先——新員工存取、替換裝置、核准的軟體、資料擷取或帳號變更——而非內部團隊名稱或工具類別。
服務目錄管理軟體
將承諾與履行連結的服務目錄管理軟體
發佈清晰易懂的服務提供、收集可決策的請求，並保持資格、政策、責任歸屬、履行、承諾與改進的一致性。
實時畫廊從服務和配置組合開始，然後展示請求者和履行團隊對產品的需求。它將目錄視為維護的服務產品，而不是靜態的表單鏈接菜單。
最多 5 位使用者可免費使用，無需信用卡。
無需撰寫程式碼，即可調整欄位、工作流程和儀表板。 探索 1,000 多個應用程式範本與使用情境
第一個視圖是服務組合。履行和績效標籤顯示已發布的服務是否在操作上可行。
直播服務承諾與資格
負責履行模型與所有者
已驗證將績效反饋納入設計
在建立表單之前描述結果
一個有用的目錄能幫助人們選擇正確的服務，並設定可操作的期望。
說明適用性與資格
解釋誰可以提出請求、支持的地點或系統、前提條件、排除項、費用或核准條件、預期交付時間，以及非標準需求的流程。
收集最少且完整的資料
詢問判定資格、授權、配置、排程、履行及確認所需的資訊。使用條件區段，而非顯示每個可能的欄位。
保持已發布的承諾與交付同步
目錄、工作流程、服務責任歸屬及度量應同步變更。
將方案連接至服務
將每個請求方案與所屬服務、團隊、依賴關係、配置環境、政策、承諾及升級路徑相關聯，以確保履行不以孤立表單運作。
對有意義的變更進行版本控制
當資格、證據、批准、履行步驟、目標或可用性發生變更時，保留管理進行中請求的版本，並清楚傳達新的承諾。
安全地退役
當某個商品不可用時，停止新選擇，將用戶導向經批准的替代品，並在現有記錄上保留歷史商品，而不是默默地重寫它。
使用需求和履行證據來改善產品組合
當目錄減少混淆並提高交付可靠性時，它就變得有價值。
尋找失敗的選擇
審查已放棄的請求、錯誤的商品選擇、退回的信息、手動重新路由，以及常見的自由文本需求，以識別目錄語言或涵蓋範圍薄弱的地方。
尋找履行摩擦
測量授權延遲、依賴等待、返工、逾期任務、異常使用以及按商品而非僅依賴整體隊列平均的請求者確認。
與服務所有者共同決定
給負責人提供證據以簡化資料、變更政策、自動化步驟、調整承諾、新增服務項目，或退役那些不再產生有用結果的項目。
區分服務、服務項目和請求
這些對象彼此相關，但每個都回答不同的問題。
| 對象 | 所回答的問題 | 範例 |
|---|---|---|
| 維修服務 | 使用者依賴哪些持續能力？ | 身份與存取服務 |
| 服務項目 | 某人可以請求何種具體成果？ | 新增對核准應用程式的存取權 |
| 請求 | 誰需要什麼、在何種條件下、現在何時？ | Taylor 請求財務應用程式的分析師存取權 |
| 履行任務 | 哪些工作可實現核准成果？ | 配置角色並驗證登入 |
為什麼 JODOO 適合
保持服務項目作為真實的交付承諾
使用相關記錄管理服務擁有權、可請求的項目、資格、所需信息、履行設計、承諾和改進信號。
結果是一個目錄，其語言、工作流程和績效可以在不發布程式碼的情況下共同改進。用請求者的語言撰寫服務項目
描述結果、資格、選擇、所需信息、預期時間和支援途徑，而不揭露內部團隊結構。
將承諾與交付保持連結
將每個服務項目與其履行步驟、授權者、負責人、日曆、目標規則和例外流程連接。
安全地淘汰服務項目
停止新的選擇，提供替代方案，保留現有請求的歷史服務項目，並更新相關的工作流程和通信。
使用 Jodoo 來建立會隨交付而改變的目錄
建立並維護那些需要經常由業務自行變更請求體驗和履行規則的產品
Jodoo 適合
服務和產品記錄、資格條件、條件性問題、政策、授權、履行、責任歸屬、承諾以及退役歷史
連接商業與技術權威
將採購、身份、資產發現、財務和專業配置數據保留在其系統中，同時目錄說明面向使用者的承諾
在以下情況選擇專業套件
啟動時需要大型預建企業目錄、高級授權引擎、組合財務、基於發現的 CMDB 關聯或採購整合
服務團隊在更改系統前會問的問題
服務目錄與請求入口之間有什麼不同？
目錄定義了服務和可請求的項目，包括成果、資格、政策、數據、責任歸屬、履行和承諾。入口網站是使用者透過其發現並提交這些項目的介面。
每個內部流程都應該成為目錄項目嗎？
不應如此。發佈使用者能理解且團隊能一致履行的可重複服務。對於新需求、諮詢、例外或缺乏穩定項目的工作，請使用其他受理管道。
應該如何退役一個項目？
防止新的選擇，說明替代或替換方案，保留現有請求中的歷史項目，並更新相關政策、工作流程、承諾及溝通內容。
我們的團隊能否在無程式碼的情況下調整服務目錄運作設置？
是的。獲授權的建置者可以在不撰寫程式碼的情況下變更相關欄位、表單、工作流程、權限、自動化和儀表板，同時保持變更受控和測試。
小型團隊能否在免費方案下嘗試服務目錄運作？
是的。Jodoo 的免費方案最多支援五個使用者，且不需要信用卡，因此小型團隊可以先測試這個運作情境，然後再檢查更廣泛部署的現有限制。