ダッシュボードという幻想
ほとんどのMSPにはSLAダッシュボードがあります。緑、黄、赤のインジケーターを表示します。ディスパッチャーがタスクの合間にちらっと見ます。それでもSLA違反は発生します — 誰もダッシュボードを見なかったからではなく、問題を見ることと問題に対処することは別物だからです。
ダッシュボードベースのSLA管理の根本的な問題は、常時人間の注意を必要とすることです。200件のオープンチケットを監視するディスパッチャーは、どのチケットが期限に近づいているかを頭の中で追跡できません。チケットがダッシュボード上で赤に変わった時点で、SLAはすでに違反しています。ダッシュボードは何が起きたかを教えてくれました。何も防いでいません。
JieGouの3段階閾値SLAエンジン
JieGouは異なるアプローチを採用します。SLAステータスを表示して誰かが対処することを期待する代わりに、プラットフォームはすべてのチケットをアクティブに監視し、3つの設定可能な閾値で自動化された応答をトリガーします。
80%閾値 — 早期警告
チケットがSLA応答または解決ウィンドウの80%に達すると、JieGouが最初の介入を発動します。これはアラートで溢れたSlackチャンネルに埋もれる通知ではありません。これはアクティブなワークフローです：
- チケットステータスの確認 — 誰か実際に作業していますか？過去30分間にアクティビティがありましたか？
- 割り当ての評価 — チケットは現在利用可能な技術者に割り当てられていますか？それとも病欠、有給休暇、またはすでに過負荷の人に割り当てられていますか？
- 是正措置の実行 — チケットが未割り当てまたは利用不可の技術者に割り当てられている場合、JieGouはスキルマッチングと現在のワークロードに基づいて次の利用可能な技術者に再割り当てします。
80%閾値はバッファを作るために存在します。この時点ではまだチケットを通常通り解決する十分な時間があります。システムは何も見落とされていないことを確認するだけです。
90%閾値 — アクティブエスカレーション
90%で、JieGouがエスカレートします。具体的なエスカレーションパスはチケットの優先度とクライアントのSLA契約に依存しますが、典型的なアクションは：
- マネージャー通知 — サービスマネージャーがチケット詳細と残り時間を含む直接アラート（SMS、電話、またはTeamsメッセージ — メールだけではなく）を受け取ります。
- 優先度アップ — チケットがそのカテゴリの最高優先度でない場合、JieGouが引き上げます。
- リソース再配分 — AIが低優先度タスクから技術者を引き抜くことで違反を防げるか評価します。計算が成り立つ場合（P3チケット1件の遅延 vs. P1 SLA 1件の保全）、JieGouがディスパッチャーにスワップを提案します。
90%では、目標は人間支援の救済です。システムが十分なコンテキストと十分な時間を持って問題を浮上させ、マネージャーが判断できるようにします。
100%閾値 — 違反対応
チケットがSLAウィンドウの100%に達した場合、違反が発生しています。しかし対応は依然として重要です — クライアントは目標を達成したかどうかだけでなく、どれだけ速く回復するかを気にします。JieGouの違反対応ワークフロー：
- インシデント文書化 — システムが違反の完全なタイムラインを記録：チケットの作成時期、すべての割り当て変更、すべてのステータス更新、閾値がトリガーしたもの。これはクライアントの四半期ビジネスレビュー用の監査対応文書です。
- エグゼクティブエスカレーション — アカウントマネージャーとサービスディレクターに違反サマリーと推奨回復アクションが通知されます。
- クライアントコミュニケーション — 設定されている場合、JieGouはクライアントが苦情の電話をかける前に、遅延を認め ETAを提供するプロアクティブな更新を送信できます。
- 根本原因タグ付け — AIが違反の推定原因（人員不足、誤割り当て、複雑性の過小評価、サードパーティへの依存）をトレンド分析用にタグ付けします。
予測的違反防止
閾値システムはリアクティブです — チケットが期限に近づくと応答します。JieGouの予測レイヤーはさらに進んで、80%マークに達する前に違反の可能性があるチケットを特定します。
予測モデルの評価対象：
- チケット複雑度シグナル — 複数の問題を含むチケット、MSPが過去に扱ったことのないインフラストラクチャに関するチケット、歴史的に複雑な環境のクライアントからのチケットがフラグされます。
- リソース可用性 — ネットワークチケットを処理できる唯一の有資格技術者が今後4時間詰まっている場合、その専門分野に割り当てられたリスクのあるチケットがフラグされます。
- 過去の解決時間 — 類似のチケットが通常3時間かかり、SLAウィンドウが4時間の場合、マージンが薄いためチケットは即座にフラグされます。
予測されたリスクチケットは、琥珀色のインジケーターと推奨アクション（再割り当て、リソース追加、または並列処理可能なサブタスクへのチケット分割）とともにディスパッチャーのキューに表示されます。
実践的な設定
SLAエンジンのセットアップに必要な3つのこと：
1. SLAポリシーのインポート
JieGouはConnectWiseまたはAutotaskからSLA設定を直接読み取ります。応答時間、解決時間、営業時間 vs. 24/7カバレッジ、優先度別ターゲットがすべて自動的に同期されます。再入力は不要です。
2. エスカレーションパスの定義
JieGouのワークフロービルダーを使って、各閾値で何が起こるかを定義します。典型的な設定：
- 80%（応答SLA）： 割り当てを確認、無対応なら再割り当て、Slackでディスパッチャーに通知
- 80%（解決SLA）： アクティビティを確認、割り当て技術者にリマインド、警告をログ
- 90%（すべてのSLA）： SMSでサービスマネージャーに通知、優先度アップ、リソース再配分を提案
- 100%（すべてのSLA）： 違反をログ、アカウントマネージャーに通知、クライアントコミュニケーションワークフローをトリガー
各パスはクライアントティア、チケット優先度、時間帯、またはPSAの任意のフィールドに基づいて分岐できます。
3. 閾値の調整
80/90/100のデフォルトはほとんどのMSPに機能しますが、完全に調整可能です。最高価値クライアント向けに最初の閾値を70%に設定するチームもあれば、P1チケットにはすべての分が重要なため50%のチェックポイントを追加するチームもあります。
影響の測定
重要な指標はSLA違反率です。JieGouのSLAエンジンデプロイ前後でこの指標を追跡するMSPは通常以下を確認しています：
- 初月で違反率60〜80%削減
- 平均エスカレーション時間が「ディスパッチャーが気づいた時」から閾値トリガー後2分以内に短縮
- 顧客満足度スコアの向上 — リアクティブな謝罪がプロアクティブなコミュニケーションに置き換わるため
オペレーションの転換は大きなものです。チームは違反後の消火活動から、クライアントが気づく前の違反防止へ移行します。四半期ビジネスレビューは失敗の説明からプロアクティブなガバナンスの実証へ変わります。
ダッシュボードからオートパイロットへ
進化は明確です：ダッシュボードは問題を見せ、アラートは問題を通知し、JieGouのSLAエンジンは問題を解決します。80/90/100%閾値システムと予測的違反防止の組み合わせにより、SLAコンプライアンスがオートパイロットで運用されます。
ディスパッチャーが一日中時計を見る必要がなくなります。マネージャーが違反レポートに驚かなくなります。クライアントがチケットが6時間オープンしている理由を電話で問い合わせなくなります。これがSLA違反防止がダッシュボードからオペレーティングシステムに進化した姿です。