営業時間内の対象期間
300分設定したサポート営業時間内の5時間を対象とする例です。
営業時間と認められた待機時間を考慮して、社内サポートの初回応答・解決目標を追跡し、注意が必要なチケットを確認します。
サンプルデータで試せます。フィールド、ビュー、ワークフローをチームに合わせて調整してください。
サポートアプリによる具体的な計算例です。サンプルの計算結果であり、顧客の実績を示すものではありません。
設定したサポート営業時間内の5時間を対象とする例です。
対象となる30分と15分の2回の待機を、解決時間から除外します。
サンプルのポリシーでは、ベンダー対応待ちで計測を停止しません。
300 − 45。実作業の工数でも、初回応答までの時間でもありません。
| 計測対象 | 対象期間 | 計算ルール |
|---|---|---|
| 初回応答 | 報告時刻 → 最初の応答の記録時刻 | 営業時間内の分数で計測します。その後に進捗メモを追加しても、初回応答はリセットされません。 |
| 解決 | 現在の対応サイクルと過去の対応サイクルの合計 | チケットに保持されたポリシーが認める理由の待機時間だけを差し引きます。 |
| クローズしていた期間 | 解決 → 再オープン | クローズしていた期間は、新たな対応サイクルに加算しません。 |
| サポートカレンダー | 月曜–金曜、1日1つの営業時間帯 | 設定した休業日を除外し、記録されたUTCオフセットを使用します。 |
対象となる2回目の待機を15分から5分に変更すると、同じ例の合計は265分になります。修正が紐づくチケットの計算に反映されるため、コピーされた古い合計値が残ることはありません。
再オープン後に営業時間内でさらに60分が経過すると、前回の265分に加算され、325分になります。クローズしていた夜間の時間は、解決時間に含めません。
目標の達成状況と紐づくエスカレーションレコードで、管理者の対応が必要なサービス目標を特定します。責任者の対応を記録してください。ステータスに色を付けるだけでは対応したことになりません。
休業日は明示し、重複なく登録します。このサンプルは固定のUTCオフセットと月曜–金曜の単一営業時間帯に対応しています。交代制シフトや夏時間の自動切り替えには対応していません。
対応中のチケットは、設定可能なスケジュールで再確認します。サンプルは15分間隔で、常時監視ではありません。定期チェックとレコード変更による更新は自動化の実行回数を消費するため、対応中のチケット数に合わせて間隔とプランを選んでください。
いいえ。経過時間には夜間、週末、クローズしていた期間、対象となる待機時間も含まれます。解決時間は、設定した営業カレンダーと計測停止ルールに従います。技術担当者の実作業時間は、別途作業ログに記録します。
このサンプルでは、初回応答を明示的な対応として記録します。サービス方針で実質的な応答の定義を決め、自動受付通知を人による回答と暗黙に同一視しないようにしてください。
サービスカレンダーで休業日を管理します。営業時間の計算では、該当する日付を除外します。契約に関する報告に使う前に、カレンダーと固定のUTCオフセットを確認してください。
いいえ。月曜–金曜の単一営業時間帯と、固定のUTCオフセットを使います。1日に複数のシフトがある場合、交代制勤務、夏時間の自動変更、複雑な契約用カレンダーには、追加設計や専用サービスツールが必要です。
レコード変更時に再計算し、対応中のチケットには定期チェックも行います。サンプルでは15分間隔です。チェックの実行まで検知が遅れる場合があるため、リアルタイムの障害監視として扱わないでください。
いいえ。自動化の実行回数とデータ使用量にはプランごとの上限があります。対応中のチケット数に定期チェック回数を掛け、さらに対応記録による自動化も含めて見積もり、実行間隔とプランを選んでください。
計算と待機履歴を確認し、チームが運用できる方針に合わせて、目標、営業時間、エスカレーションの担当範囲を調整してください。