部門ではなく成果を説明する
依頼者が認識できる言語でサービス名を付け、何が提供されるか、誰が対象か、必要な情報、予想される時間、費用やポリシー、例外時の処理先を説明する。
サービスリクエスト管理ソフトウェア
明確で管理された履行のためのサービスリクエスト管理ソフトウェア
繰り返し発生する需要を理解しやすい提供内容に変換し、リクエストの完了、適切な承認、責任者が明確な履行、例外処理、依頼者確認済みの結果を行います。
保留中の承認、返却情報、スケジュール済み作業、期限切れの対応、完了したリクエストを含む履行キューを開きます。このライフサイクルは定義済みサービスに使用し、予期しない中断の回復が必要な場合はインシデント管理を使用します。
5ユーザーまで無料。クレジットカードは不要です。
コードを書かずに、項目・ワークフロー・ダッシュボードを調整できます。 1,000以上のアプリテンプレートと活用例を見る
最初のビューはリクエスト実行キューです。空白のフォームの代わりに、承認済み、返却済み、スケジュール済み、期限超過、確認済みの例を含みます。
ライブリクエストデータと適格性
所有承認と履行オーナー
確認済み依頼者によって配達確認済み
キューを自動化する前に提供内容をデザインする
ユーザーが何を依頼できるかを理解し、遂行チームが意思決定可能な完全なデータを受け取ると、依頼の遂行が容易になる。
意思決定に関連するデータのみを収集する
提供内容に応じて、従業員、デバイス、場所、アクセスレベル、業務理由、日付、証拠、費用の文脈などを条件付きフィールドで尋ねる。
カタログとワークフローを一致させる
提供内容が変更された場合は、形態、適格性、承認、実行計画、コミットメント、コミュニケーションを一緒に更新し、公的な約束が運用上の現実から乖離しないようにします。
適切な意思決定を適切な役割に回す
実際のワークフローでは、未完了のリクエストを返し、修正を保持し、実行を開始する前に承認を完了させるべきです。
承認前に適格性を確認する
マネージャーやサービス所有者に承認を依頼する前に、依頼者、雇用または顧客のステータス、サービスの権利、場所、前提条件、資産の文脈、および必要な証拠を確認します。
適切な承認を使用する
ポリシーが許可する場合には低リスクの標準リクエストを自動承認し、リスクの高いアクセスや支出は責任ある役割に回し、委任や例外を明示的にします。
実行計画を完了する
配達を所有するステップ、依存関係、目標日、引き渡し、証拠に分解します。最初のタスクが完了したからといって親リクエストを完了としてマークしないでください。
完了とは、約束されたサービスが提供されたことを意味します。
内部の活動も重要ですが、依頼者が体験するのは結果です。
有用な状態を伝える
リクエストが情報、承認、履行、スケジューリング、または確認を待っているかを示し、不透明な内部ステータスコードではなく、次に予想されるアクションを提供してください。
履歴を失わずに返品を処理する
レビューのメモ、修正値、再提出、および最終決定を可視化して保持します。返品されたリクエストはワークフローの一部であり、メールで最初からやり直す理由ではありません。
確認して学ぶ
配達証拠と依頼者確認を記録し、その後、再作業、経過時間、放棄、例外数、需要パターンを確認して提供内容を改善する。
リクエスト作業を中断や変更と区別する
ユーザーは一つのポータルで開始するかもしれないが、運用記録はタスクと一致させるべきである。
| ユーザーのニーズ | 主要な記録 | 終了条件 |
|---|---|---|
| 定義されたアクセス、機器、情報、またはサービス | サービス依頼 | 承認され、実現された成果 |
| 既存のサービスが予期せず停止する | 事件 | 復旧の確認 |
| 生産変更が必要である | 関連する変更 | 承認され、検証された実施 |
| 提供内容がニーズを満たしていない | 例外または需要の確認 | 明示的な決定と次のルート |
なぜJODOOが適しているか
各サービス提供に応じてリクエストの履行を適応させる
特定のサービスが必要とする情報、適格性、承認、履行手順、例外、および受け入れに基づいてリクエスト記録を作成する。
その結果、ユーザーにとってはシンプルなリクエスト体験を維持しながら、適格性、承認、配達、確認をオペレーターに見えるようにすることができます。意思決定を変えるものだけ尋ねる
提供、役割、場所、アクセスレベル、または機器の必要性に応じてフィールドを条件付きで表示し、リクエスターが一般的なフォームを記入しないようにする。
統制を追加する場合に承認を使用する
コスト、アクセス、ポリシー、または例外の決定を適切なレビュー担当者に回し、未完成のリクエストには明確な修正を求めて返却する。
提供された成果を確認する
タスクの完了状況、依存関係、証拠、リクエスターの確認を分離して保持し、1つの完了ステップで未完了のサービスが隠れないようにする。
フルフィルメント設計を柔軟に保つ必要がある場合には、Jodooを使用してください。
ユーザーにとってリクエストを簡単に保ちながら、承認と配達の管理を実際のサービスに合わせます。
Jodooが適する領域
条件付き受付、適格性、人的承認、返品および再提出、関連するフルフィルメントタスク、例外、証拠、依頼者確認。
サービスを実行するシステムを接続します。
アカウントプロビジョニング、購入、支払い、在庫、アイデンティティ、および専門家によるフルフィルメント取引を、それを実行する権限のあるシステム内に保持します。
パッケージ化されたサービスデスクを選択するとき
成熟したカタログ、オムニチャネルの受付、ディスカバリー、CMDB、リモートサポート、ベンダーコンテンツ、そして豊富な事前構築済みIT統合は、ワークフローの適応性よりも重要です。
システムを変更する前にサービスチームが尋ねる質問
サービスリクエストはインシデントとどう違いますか？
サービスリクエストは、定義された期待されるサービスやアイテムを求めるものです。インシデントは予期しない中断や劣化を報告するものです。受付やサービスの文脈を共有することはありますが、意思決定や完了の証拠は異なります。
すべてのリクエストにマネージャーの承認が必要ですか？
いいえ。リスク、コスト、権利、アクセス、ポリシー、または責任に基づいて意思決定が必要な場合のみ承認を使用してください。リスクの低い標準リクエストは、儀式的な承認手順を追加せずに、承認されたルールに従うことができます。
不完全なリクエストは返却して再提出できますか？
はい。例のアプリは、正確な修正を伴って不完全なリクエストを返し、履歴を保持し、修正された提出物を承認に戻すネイティブワークフローを使用します。
私たちのチームはコードなしでサービスリクエスト履行の設定を適応できますか？
はい。認可されたビルダーは、変更を管理・テストされた状態で保持しながら、関連するフィールド、フォーム、ワークフロー、権限、自動化、ダッシュボードをコードなしで変更できます。
小規模チームは無料プランでサービスリクエスト履行を試せますか？
はい。Jodooの無料プランは最大5ユーザーまで対応し、クレジットカードは不要です。したがって、小規模チームはより広範な展開の前にこの動作シナリオをテストできます。
実際に動くアプリを見る
提供から確認済み配信までのリクエスト実行を確認します。
動作中のリクエストライフサイクルを確認し、サービスポートフォリオに応じて適格性、承認、実行、通信、および確認を調整します。
リクエスト履行を探る