サービスデスクで問い合わせの優先順位を決め、難しい件を専門チームに回す

## サービスデスクが受け持つ範囲と、各問い合わせの担当者を決める - サービスデスクが対応する利用者、サービス、依頼種別、対応時間、サポート窓口を明記する。 - プロセスの責任者、各キューの責任者、すべての未完了チケットの現担当者を定める。 - ワークフローを設計する前に、インシデント、サービス依頼、アクセス申請、質問、セキュリティ上の懸念を区別する。 - 受領確認、実質的な初回対応、復旧、解決、連絡についてサービス目標を定める。 - 計画メンテナンス、顧客からの回答待ち、承認済みの一時停止などの例外を公開する。 - サービス、要員体制、リスク、顧客の期待が変化するたびに運用モデルを見直す。 ## 問い合わせを受ける時に必要な事を聞き、本人かどうかを確かめる - 承認された窓口で依頼を受け付け、単一の記録システムに集約する。 - 依頼者の本人情報、連絡方法、対象サービス、症状、業務への影響、発生時刻、すでに試した手順を記録する。 - スクリーンショット、ログ、エラーメッセージは有用な場合に限って求め、機密情報や無関係な個人データの除去方法を依頼者に伝える。 - 受領は速やかに通知する。ただし、自動受領通知を最初の実質的な対応とはみなさない。 - アカウント復旧、アクセス変更、保護対象情報の開示を行う前に、承認された方法で本人確認を行う。 - 情報不足のためチケットを黙って止めるのではなく、不足情報の取得を明示的な次の対応として記録する。 ## 影響の大きさと急ぎ具合から、優先順位を決める - 影響を受ける利用者数、業務上の重要度、データまたは安全上のリスク、サービス低下の範囲から影響度を判断する。 - 時間的制約、期限、悪化の速さ、実用的な回避策の有無から緊急度を判断する。 - 複数の根拠を総合して優先度を割り当てる。依頼者が希望する優先度ラベルをトリアージの代わりにしない。 - 組織が承認した応答目標と解決目標を備えた、簡潔な優先度マトリクスを定める。 - 対応範囲、影響、リスク、回避策の状況が変わったら、優先度を再評価する。 - 優先度を上げる場合も下げる場合も理由を記録し、影響を受ける責任者に通知する。 ## 問い合わせを種類に分け、合うチームへ回す - 起こり得るすべての症状ではなく、安定したサービスと作業種別を反映する浅い分類体系を使う。 - 各カテゴリを、既定のキュー、必要な専門知識、承認、通知ルールに対応付ける。 - セキュリティ、プライバシー、安全、法務、主要サービスに関する懸念は、それぞれ専用の対応経路へ振り分ける。 - 1件のチケットが複数カテゴリに該当する場合に優先するルールを定め、補足情報はラベルで保持する。 - 未割り当て、差し戻し、分類変更が繰り返されるチケットを、振り分けの不備として監視する。 - 実際のチケット傾向と後続のレポート要件を確認した後に限って、分類体系を変更する。 ## 元に戻せる確認から原因を調べ、やった事を全部記録する - 何かを変更する前に、報告された状態、影響範囲、最近の変更、依存関係、利用できる根拠を確認する。 - 元に戻せる低リスクの確認から始め、対象サービスで承認済みの診断手順に従う。 - 特権アクセス、影響を伴うテスト、設定変更、データ復元を行う前に、必要な承認を得る。 - 本人確認に関する問題では、侵害されている可能性のある同じ連絡経路に頼らず、強固な確認方法を使う。 - 別の担当者が作業を繰り返さずに続行できるよう、各対応、その結果、除外した原因、次の仮説を記録する。 - より広範なインシデント、セキュリティ上の懸念、安全でない操作、権限不足を示す根拠がある場合は、作業を止めてエスカレーションする。 ## 対応時間の約束（SLA）を見張り、依頼した人に進み具合を伝える - 契約上区別されている場合は、受領確認、応答、復旧、解決、状況更新の各約束を個別に追跡する。 - 各時間計測をいつ開始、一時停止、再開、終了するかを明確に定める。 - 約束を守れなくなる前に、是正措置を取る時間を十分に確保して、現担当者とキュー責任者に警告する。 - 現在の状況、判明している影響、進行中の作業、次の確認時点、依頼者に必要な対応を示す、有用な進捗情報を伝える。 - 期限超過の恐れがある案件を定期的に確認し、違反を個人の失敗の証拠と決めつけず、プロセス上の兆候として分析する。 - 優先度、サービス、キュー、原因、例外種別ごとの傾向を報告し、責任者が繰り返し発生する制約に対処できるようにする。 ## 難しい件は、これまでの経緯を付けて専門チームに回す - 標準的な診断を終えても解決しない場合、専門知識や上位権限が必要な場合、リスクが高まった場合、またはSLAの期限が迫った場合にエスカレーションする。 - 期限超過まで待たず、残りのサービス約束時間を反映した時間基準の条件を使う。 - 受け入れ先のチームに、症状の経緯、影響、根拠、実施済みの対応、結果、除外した原因、推奨する次の手順を渡す。 - 受け入れ先のチームが担当を明示的に引き受けない限り、チケットの説明責任を持つ担当者を1人に保つ。 - 問題が各チームの管理範囲にある場合に限り、開発、インフラ、セキュリティ、または外部事業者へエスカレーションする。 - 停滞したエスカレーションの対応経路を定め、適任の担当者が作業を引き受けない場合は当番責任者に通知する。 ## 直ったことを確かめてから、問い合わせを完了にする - 変更内容、その変更で問題が解決した理由、一時的な回避策、残っているリスクを記録する。 - 観察可能な根拠によってサービス復旧を確認し、必要に応じて依頼者からも確認を得る。 - 平易な言葉で依頼者に通知し、理解しておくべき対応、制限事項、フォローアップを含める。 - 最初の推測ではなく、実際の原因に基づいて最終カテゴリと解決コードを適用する。 - 必要な記録、承認、関連作業、連絡がすべて完了してからチケットを閉じる。 - 再オープン可能な期間を定め、その後に再発した場合は組織の方針に従って振り分ける。 ## 解決した件を、ほかの人が探せる解決方法の記事にする - 解決策を再利用できる場合、問題が再発した場合、または複数の利用者に役立つ場合は、ナレッジを作成または更新する。 - 利用者と担当者が検索に使いそうな言葉でタイトルを書く。 - 症状、対象範囲、前提条件、平易な原因説明、番号付きの手順、確認方法、ロールバックまたはエスカレーションの条件、責任者を含める。 - 公開前に、機密情報、個人データ、一時的な識別子、環境固有の値を除去する。 - 利用状況と有効性を測定できるよう、記事を関連するチケットやサービスに紐付ける。 - 見直し日を設定し、安全でない、古い、重複している、または責任者が不在になったガイダンスを廃止する。 ## くり返す問題を見直し、根本の原因を直す - 一定の周期で、件数、影響の大きい案件、違反、再オープン、エスカレーション、再問い合わせ、顧客のフィードバックを確認する。 - 即時の解決と根本原因への対応を分け、仕組みとしての再発防止が必要な場合は両方を追跡する。 - 問題を生んだ要因、検知や対応を遅らせた要因、再発を防止または軽減できる統制を検討する。 - 調査結果を、責任者、期限、成功指標、確認時点が明確な対応項目に変える。 - 実施しただけで完了とせず、以前の対応によって対象の結果が変化したかを確認する。 - 測定した根拠に基づいて、研修、振り分け、診断、ナレッジ、自動化、対応能力を更新する。 ## シフトや当番が替わる時に、残っている問い合わせを引き継ぐ - 未完了の高優先度チケット、現担当者、次の対応、判断期限、顧客への既知の約束を引き継ぐ。 - 対応中のインシデント、計画メンテナンス、既知のリスク、回避策、外部依存関係、保留中のエスカレーションを含める。 - 引き継ぐ相手が必要なツールにアクセスでき、当番責任者と緊急連絡先を把握していることを確認する。 - 新設、変更中、または不安定な当番体制では、プロセスが一貫して確実に機能するまで対面またはリアルタイムで引き継ぐ。 - 共有システムに引き継ぎを記録し、承認されたチーム連絡経路で担当交代を知らせる。 - 引き継ぎ後に判明した情報不足やアクセス不足は、是正すべきプロセス上の不備として扱う。