サービスデスクの月次報告が、受付件数、応答時間、一次解決率、未処理件数だけで終わっていないでしょうか。 これらは体制と負荷を管理するために必要ですが、数字が良くても、同じ問い合わせが繰り返され、利用者が仕事を止め、 サービス側の分かりにくさが残ることがあります。速く処理するだけでは、問い合わせが生まれた理由までは変わりません。

PeopleCertのITIL 4 Practitioner: Service Deskは、サービスデスクをサービス提供者と利用者の中央接点として位置づけ、 利用者・顧客体験とサービス関係の成功を改善する実務として説明しています。Service Request Managementも、 事前に定義された利用者起点の要求を、合意した品質で効果的かつ利用者に配慮して扱うことを目的としています。 つまり、窓口の役割はチケットを閉じることだけではなく、需要を正しく受け取り、関係する実務へつなぐことです。

英国政府のService Manualは、利用者支援をサービスの「目と耳」とし、組織から孤立した反応型の業務にせず、 得られたフィードバックをサービス改善へ使うよう求めています。本記事ではこの考え方を土台に、 サービスデスクを問い合わせ処理の窓口から、事業とITの改善センサーへ変える5つのステップを整理します。

具体的な課題：閉じたチケットの外に、利用者の摩擦が残る

サービスデスクは、障害、サービス要求、利用方法の質問、権限申請、苦情、改善要望など、性質の異なる需要を受け取ります。 ところが、受付時の分類が担当部署への振り分けだけを目的にしていると、似た問い合わせが別カテゴリへ散り、 サービス全体で何が利用者を止めているのか見えなくなります。

  • 処理件数が目的になる：早く閉じることを優先し、再発や自己解決できなかった理由を記録しない。
  • 分類が担当組織中心になる：利用者の目的ではなく、どのチームへ渡すかだけでカテゴリを決める。
  • チャネルごとに記録が分かれる：電話、メール、チャット、ポータルの需要を横断して見られない。
  • 現場の気づきが消える：担当者が知る曖昧な画面、古い手順、重複申請が改善候補へ上がらない。
  • 自動化が摩擦を隠す：FAQや仮想エージェントの利用率だけを追い、離脱や再問い合わせを見落とす。
良いサービスデスクは、問い合わせを早く閉じるだけでなく、「なぜ利用者が支援を必要としたか」を改善できる形で残します。

考え方：一件の問い合わせを4つの情報へ変換する

すべてのチケットを詳細に分析する必要はありません。受付時に最小限の共通情報をそろえ、一定期間のまとまりで傾向を見ます。 ITIL 4の実務はプロセスだけでなく、関係者、役割、情報・技術、パートナー、価値ストリームを含む多面的な運用を重視しています。 窓口内で完結させず、サービス所有者や業務部門が判断できる情報へ変換することが要点です。

  1. 需要：利用者は何を達成しようとし、どの時点で支援を求めたか。
  2. 摩擦：障害、分かりにくさ、権限、手待ち、重複作業のどれが妨げたか。
  3. 影響：誰のどの業務が、どの程度・どの期間止まったか。
  4. 改善先：知識、画面、手順、監視、要求モデル、教育のどこを変えるか。

この4点を、応答時間や一次解決率と置き換えるのではなく、補完関係で扱います。運用品質を守る指標と、 問い合わせそのものを減らす改善指標を同じ場で見れば、処理能力とサービス品質を両立しやすくなります。

実践手順1：代表的な利用者目的を一つ選ぶ

全問い合わせを一度に再設計せず、件数が多い、業務影響が大きい、複数部門をまたぐなどの理由がある利用者目的を一つ選びます。 たとえば「新任者が業務を開始する」「顧客提案に必要な権限を得る」「障害後に作業を再開する」です。 サービスデスク、利用者、サービス所有者、実際の対応チームで、受付から完了までを時系列に並べます。

現在のチケット分類を正解とせず、電話や口頭相談、途中離脱、別ルートで解決した事例も確認します。 公式な窓口に届かなかった需要を除外すると、ポータル上の数字だけは良くても、現場負担を見誤ります。

実践手順2：受付記録を「判断に必要な最小項目」へ整える

利用者目的、対象サービス、影響、緊急度、問い合わせ理由、最終的な解決方法、再問い合わせの有無を共通項目として定義します。 入力項目を増やしすぎると記録品質が下がるため、改善判断に使わない項目は持たないか、自動取得を検討します。 自由記述は残しつつ、後から集計できる選択肢との役割を分けます。

分類は恒久的な正解ではありません。一定期間ごとに「その他」が増えていないか、担当者ごとに判断が分かれていないかを確認し、 定義と例を更新します。利用者の個人情報や機微な業務情報は、目的、権限、保存期間を確認し、必要以上に記録しないことが重要です。

実践手順3：問い合わせを原因別に束ね、改善仮説を作る

件数順だけでなく、影響、再問い合わせ、処理の手戻り、回避可能性を見て束ねます。似た問い合わせでも、 本当の原因が知識不足、画面表示、承認待ち、システム障害では改善先が異なります。サンプルの記録と担当者への短い聞き取りで、 「この表示を変えれば迷いが減る」「この要求モデルを標準化すれば待ち時間が減る」といった検証可能な仮説にします。

PeopleCertのAI活用サービスデスクに関する公式マスタークラスも、AIや自動化の前に、プロセス、データ品質、運用規律を整える必要性を示しています。 分類や解決記録が不安定なまま自動化すると、誤った振り分けや不適切な回答を速く広げる可能性があります。

実践手順4：小さな変更を届け、利用者行動で確かめる

改善仮説に応じて、知識記事の修正、フォームの簡素化、状態通知の追加、権限モデルの見直し、監視の改善などを一つ選びます。 変更前後で、問い合わせ件数だけでなく、目的完了率、再問い合わせ、途中離脱、解決までの手戻り、利用者の短いフィードバックを確認します。

問い合わせが減っても、利用者が諦めただけなら改善ではありません。対象者への確認、関連業務の処理量、別チャネルへの移動を見て、 利用者が自力で目的を達成できたのか確かめます。重要な業務では段階展開や戻し方を用意し、影響を限定します。

実践手順5：月次報告を改善の意思決定会へ変える

サービスデスクだけで改善を抱えず、サービス所有者、業務部門、開発・運用、セキュリティ、必要な外部パートナーが、 上位の需要、利用者影響、仮説、実施中の変更、結果を同じ一覧で確認します。誰がいつ判断するかを決め、 知識更新で済むもの、バックログへ入れるもの、問題管理や変更実現へつなぐものを分けます。

報告書を厚くするのではなく、「何を変えるか」「誰が持つか」「いつ結果を見るか」を残します。 改善後も問い合わせが戻った場合は失敗として隠さず、仮説、対象範囲、伝え方、測り方を見直します。 サービスデスク担当者が改善結果まで確認できる循環を作ることで、現場の記録品質も高まりやすくなります。

注意点：問い合わせ削減を、支援の削減にしない

  • 件数だけを削減目標にしない：チャネル閉鎖や入力負担で、必要な支援まで届かなくなる可能性がある。
  • 自己解決を強制しない：アクセシビリティ、緊急性、利用者の状況に応じて有人支援を残す。
  • 一次解決率を絶対視しない：専門判断が必要な案件を無理に窓口で抱えると、品質や安全性を損なう。
  • 自由記述を無断で広く再利用しない：利用目的、アクセス権、保存期間、匿名化の要否を確認する。
  • AIの回答を無監督で広げない：対象範囲、根拠となる知識、承認、誤回答時の引継ぎ、評価を設計する。
  • ITILを手順書として固定しない：自社の利用者、サービス、影響、体制に合わせ、継続的に改善する。

まとめ：サービスデスクを、改善が始まる接点にする

サービスデスクを改善センサーにするとは、すべての問い合わせを分析対象にすることではありません。 代表的な利用者目的を選び、判断に必要な記録をそろえ、需要を原因別に束ね、小さな変更を届け、 月次の場で次の意思決定へつなぐことです。応答の速さを守りながら、問い合わせを生んだ摩擦そのものを減らします。

最初の一歩として、先月多かった問い合わせを一つ選び、「誰が何を達成しようとしたか」「どこで止まったか」 「どのサービス変更なら確かめられるか」を一枚にまとめてください。閉じた件数ではなく、 利用者が次に支援を求めず目的を達成できたかまで確認すると、サービスデスクの価値が具体的な改善として見えてきます。

参考にした公式資料

本記事は公式資料をもとに、一般的なITサービスマネジメントと利用者支援の考え方を整理したものです。 個別組織の契約、労務、個人情報、法令適合性、セキュリティその他の法律上・専門上の助言を行うものではありません。 公式資料は2026年8月24日時点で確認しています。実際の運用では、自社のサービス、利用者、委託関係、 適用される法令・規格、リスク許容度を踏まえ、必要に応じて関係部門や専門家へ確認してください。

FW

WRITTEN BYFourthWall Consulting Teamテクノロジーと経営の両面から、企業変革を支援しています。

← 技術ブログ一覧へ戻る