IT 管理会社のサポート業務:チケット対応の高速化(AI補助あり)
多くの中小企業クライアントを支える IT 管理会社が急成長していました。必要なのは新しいヘルプデスクではありません。
いまのツールのまま、1日に扱える件数を増やし、ミスを減らすことです。すべてのステップで、人が確認する運用を前提にしました。
注
これは可能性を示すための架空の事例です。実在のクライアント案件に基づくものではなく、内容と数値はすべて説明用です。
背景
- 約90社の法人クライアントを支援
- サポート:9名 + シニアエンジニア2名
- ツール:ヘルプデスク、共有受信箱、社内ドキュメント、チャット
負荷が高い日常
- 平均:1日あたり約160件
- 更新や障害の後:1日あたり220〜260件
- 繰り返しの多い相談:パスワード、メール設定、端末アクセス、VPN、権限
導入前 → 導入後(1か月)
- 初回返信:平均3時間 → 約50分
- 仕分けと転送:1日あたり2時間15分 → 約35分
- 誤振り分け:1日15件 → 約3件
- シニアが定常的に助ける割合:約30%減
チケットの内容が揃っていない
詳細に書かれたチケットもあれば、「メールが動かない」のように一言だけのものも多くありました。担当者は、何の相談か、誰が対応すべきか、
何が足りないか、既に障害対応が走っていないかを判断するのに時間を使っていました。
- 追加質問のやり取りが増える
- ピーク時に返信が遅れる
- 担当者によって回答がブレる
知識はあるが、見つけるのが遅い
解決済みチケット、手順書、クライアント固有のメモなど、社内知識は豊富でした。しかし、必要なページを素早く探すのは難しく、
記憶や個人メモに頼ったり、シニアに聞いたりする場面が増えていました。
- 検索と読み直しに時間がかかる
- シニアが定常業務に引き込まれる
- 重要な文脈を見落とすリスクが上がる
- 既存のヘルプデスクが主システムのまま。
- クライアントへのメッセージは自動送信しない。
- 提案は必ず根拠を示す(社内ドキュメント、類似の過去チケット)。
- 運用の流れは変えない。チケットは同じように届き、担当者は同じように返信する。
- 自信がないときは推測せず、追加情報を確認する。
- すべての操作を記録し、見直しと改善に使えるようにする。
作ったもの
ヘルプデスクの横で動く、軽量な社内ツールです。
1) チケット要約
新規チケットごとに、短い要点を上部に表示します。
- 想定される内容と対象(メール、アクセス、ネットワークなど)
- クライアントの識別
- 不足情報のチェック(ユーザー、端末、エラー、発生時刻など)
2) 仕分け提案(人が承認)
カテゴリ、担当、緊急度を提案し、理由も添えます。
- カテゴリ:障害、アクセス、請求、一般問い合わせ
- 担当チームや担当者の提案と短い根拠
- ボタン一つで適用できます。必要ならすぐ修正できます。
3) ナレッジ検索
社内ドキュメントと解決済みチケットを検索し、候補をリンク付きで返します。
- 関連する手順書
- 似た解決済みチケット
- 初動チェックリスト
4) 返信下書き(必ず編集)
よくあるパターンの短いメッセージ下書きを作ります。
- 必要な質問だけを明確に
- 解決後の返信テンプレートと次のステップ
- シニア向け引き継ぎメモ(試したこと、参照リンク)
5) 履歴と安全チェック
ピーク時でも安心して回せるようにします。
- 提案内容と採用結果を保存
- 参照した根拠を記録
- 最終的に送った文面も記録
運用フロー
新しさより、速さと確実さを重視しました。
- チケットは通常通りヘルプデスクに届きます。
- 担当者が開くと、要約、クライアント、足りない情報、担当提案が表示されます。
- 担当者は「適用」で割り当てやタグ付けを行うか、すぐ修正します。
- 返信下書きを選び、必要に応じて編集し、手動で送信します。
- 引き継ぎが必要なら、引き継ぎメモを使ってシニアに渡します。
結果
展開後も改善を続け、ピーク時ほど効果が出ました。
- 初回返信:平均3時間 → 約50分
- 仕分けと転送:1日あたり2時間15分 → 約35分
- 誤振り分け:1日15件 → 約3件
- シニアの定常的な手助け:約30%減
- 新人の立ち上がりが早くなった(必要なリンクが運用に組み込まれた)
導入
- ヘルプデスクに接続する、軽量な社内ツール
- 社内ドキュメントとチケット履歴を参照情報として利用
- ヘルプデスクの代替ではなく、横で支える設計
引き継ぎ
- 短いチーム向けガイドと、1枚の運用手順書
- ドキュメントの追加方法と、良い参照になる解決済みチケットの扱い
- ログの見方と、仕分けルールを改善する手順