インシデント管理のデータテンプレート
インシデント管理のデータテンプレート
- 収集を推奨する属性
- プロセスマッピングで追跡する主要なアクティビティ
- データ抽出の手順
インシデント管理の属性
| 名前 | 説明 | ||
|---|---|---|---|
|
イベントのタイムスタンプ
EventTimestamp
|
アクティビティが発生した正確な日時です。 | ||
|
説明
このタイムスタンプは、コメントの追加やステータスの変更など、インシデントのライフサイクルでイベントが発生した正確な時刻を記録します。ケース内のすべてのアクティビティを時系列に並べるために使われます。 時間に基づくプロセスマイニング分析に欠かせない属性です。アクティビティ間のサイクルタイムの算出、待ち時間の特定、ケース全体の所要時間の測定、期間ごとのプロセスパフォーマンスの分析に使います。正確なタイムスタンプは、時間の経過に伴うケースの流れを示すアニメーション付きプロセスマップや、平均解決時間などの重要業績評価指標を追跡するパフォーマンスダッシュボードの作成に不可欠です。
重要な理由
タイムスタンプはすべてのアクティビティを時系列で把握するための情報です。所要時間の算出、ボトルネックの特定、時間の経過に伴うプロセスパフォーマンスの分析に役立ちます。
入手先
Zendesk Ticket Audits API(/api/v2/tickets/{ticket_id}/audits)の各監査イベントに含まれるcreated_atフィールド。
例
2023-04-15T10:00:00Z2023-04-15T10:05:12Z2023-04-16T14:30:00Z
|
|||
|
インシデントID
TicketId
|
各インシデントチケットを一意に識別する、システムが生成したIDです。 | ||
|
説明
Incident IDは、Zendesk Support内の各インシデントケースを一意に識別する主キーです。プロセスマイニングではCaseIdとして使われ、インシデントの作成からクローズまで、関連するすべてのアクティビティ、ステータス変更、連絡を結び付けます。 分析では、このIDを使って各インシデントの全体的な流れを再構成します。イベントデータを集約し、解決までの合計時間、引き継ぎ回数、個々のケースにおけるサービスレベル合意の遵守状況などを追跡できます。このIDでイベントをグループ化すると、プロセスの流れを可視化し、よくある経路を特定して、標準手順からの逸脱を検出できます。
重要な理由
すべてのイベントを1つのインシデントに結び付ける重要な識別子です。ライフサイクル全体を追跡し、プロセスのパフォーマンスを正確に分析できます。
入手先
Zendesk Tickets API(/api/v2/tickets/{id})のidフィールド。
例
19428230113521941055
|
|||
|
アクティビティ
ActivityName
|
インシデントのライフサイクルにおいて、特定の時点で発生した業務上のアクティビティまたはイベントの名前です。 | ||
|
説明
この属性は、インシデント管理プロセスで行われた具体的なステップや操作を表します。たとえば、「インシデント作成」「チケットを担当者に割り当て」「インシデント解決」などです。これらのアクティビティは、Zendeskのイベントログや監査証跡に記録されたシステム変更から導出されます。 プロセスマイニングでは、アクティビティの順序がプロセスマップを構成し、あらゆる分析の基盤となります。アクティビティの流れを分析すると、インシデントが実際にたどる経路を把握し、ステップ間のボトルネックを特定し、手戻り(解決済みチケットの再オープンなど)を測定し、定められた標準プロセスへの適合性を確認できます。
重要な理由
アクティビティの順序がプロセスの流れを定義します。これは、非効率、逸脱、改善機会を特定するプロセスマイニング分析の中核です。
入手先
Zendesk Ticket Audits APIのイベントから導出します。たとえば、statusフィールドに対するChangeイベントを「ステータス変更」に対応付けられます。
例
インシデント作成チケットを担当者に割り当てステータスを保留中に変更インシデント解決インシデントをクローズ
|
|||
|
ソースシステム
SourceSystem
|
インシデントデータの抽出元となるシステムです。 | ||
|
説明
この属性は、プロセスデータの取得元を示します。このビューでは値は固定で、たとえば「Zendesk Support」となります。これは、すべてのイベントと属性がそのシステムから取得されたことを示します。 複数のシステムからデータを統合する環境では、データソースを区別するためにこのフィールドが欠かせません。データの整合性を保ち、Zendeskと別のITSMツールのインシデント管理プロセスを比較するなど、データソースごとの分析にも役立ちます。
重要な理由
データの取得元を示します。データガバナンスや、複数のソースシステムのデータを組み合わせた分析に欠かせません。
入手先
データ変換時に設定する固定値で、データの取得元を示します。
例
Zendesk SupportZendesk
|
|||
|
データの最終更新
LastDataUpdate
|
このプロセスのデータが最後に更新された日時を示すタイムスタンプです。 | ||
|
説明
この属性は、ソースシステムからデータを最後に抽出または更新した日時を記録します。通常、更新サイクルごとにデータセット全体へ1つの値が適用されます。 データガバナンスとプロセスマイニング分析の利用者にとって重要な情報です。データがどの程度新しいかを把握できるため、分析で最新の情報を確認できているか判断しやすくなります。業務パフォーマンスのモニタリングや、分析に基づく迅速な意思決定では特に重要です。
重要な理由
データの鮮度に関する重要な情報を示し、分析がどの時点のデータに基づいているか、データが最後に取得されたのはいつかを把握できます。
入手先
データ更新の完了時にETL/データパイプラインの処理によって生成されるタイムスタンプです。
例
2023-10-27T08:00:00Z2023-10-28T08:00:00Z
|
|||
|
SLAステータス
SlaStatus
|
インシデントに適用されるサービスレベル契約(SLA)の現在のステータスです。 | ||
|
説明
この属性は、インシデントが設定されたSLA目標の達成に向けて順調か、すでに違反しているか、またはSLAの計測が一時停止中かを示します。Zendeskは、設定されたポリシーに基づいてSLA指標を自動的に追跡します。 「SLA遵守状況のモニタリング」ダッシュボードに欠かせない属性です。サービス上の約束に対するパフォーマンスを直接確認できます。SLA違反が発生した時期や原因を分析すると、組織はプロセスの弱点を特定し、サービスの信頼性を高められます。「インシデントSLA遵守率」の重要業績評価指標(KPI)の算出にも使われます。
重要な理由
サービス上の約束に対するパフォーマンスを直接測定できます。SLA違反の分析や、コンプライアンスの状況を先回りして確認するのに役立ちます。
入手先
Zendesk Ticket Metrics API(/api/v2/ticket_metrics.json)。sla_policy、breached_atなどのフィールドから算出されます。
例
アクティブ一時停止違反達成
|
|||
|
イベント終了時刻
EventEndTime
|
アクティビティが完了した時刻を示すタイムスタンプです。 | ||
|
説明
イベント終了時刻は、アクティビティの終了を示します。イベントログでは、あるアクティビティの終了時刻を、同じケース内で次に続くアクティビティの開始時刻から推定することがよくあります。ケースの最後のアクティビティでは、終了時刻と開始時刻が同じになる場合があります。 この属性は、個々のアクティビティの所要時間(ProcessingTime)やアクティビティ間の待ち時間の算出に欠かせません。ボトルネック分析の基礎となる情報であり、各ステップにかかる時間だけでなく、ステップが始まるまでケースがどれだけ停滞していたかも確認できます。
重要な理由
アクティビティの所要時間と待ち時間を算出できます。詳細なボトルネック分析やプロセスの遅延特定に欠かせない情報です。
入手先
同じケース内で次に続くイベントの開始時刻を使用して算出します。最後のイベントの終了時刻は、開始時刻またはケースの終了時刻と同じになる場合があります。
例
2023-04-15T10:05:12Z2023-04-16T14:30:00Z2023-04-16T18:00:00Z
|
|||
|
チケットのステータス
TicketStatus
|
イベント発生時点でのインシデントチケットのステータスです。「オープン」「保留中」「解決済み」などがあります。 | ||
|
説明
この属性は、ライフサイクルの各時点におけるインシデントチケットの状態を示します。Zendeskの標準ステータスには、new、open、pending、on-hold、solved、closedがあります。このフィールドの変更を追跡することは、プロセスマイニングのアクティビティを生成する主な方法の1つです。 チケットのステータス分析は、プロセスの把握に欠かせません。「Pending」など特定の状態にインシデントがどれだけとどまるかを特定できます。この状態は、顧客からの返信待ちを示すことがよくあります。また、ケースの完了条件を定義し、解決時間を算出する際にも重要です。
重要な理由
ステータスの変化を追跡すると、プロセスの進行状況や待ち時間を把握し、インシデントのライフサイクルの開始点と終了点を定義できます。
入手先
Zendesk Tickets APIのstatusフィールド。変更はTicket Audits APIに記録されます。
例
新規オープン保留中解決済みクローズ済み
|
|||
|
優先度
TicketPriority
|
インシデントに設定された優先度です。「低」「通常」「高」「緊急」などがあります。 | ||
|
説明
インシデントの優先度によって、対応や解決に求められる緊急度が決まります。サポートチーム内での作業の優先順位付けやリソース配分にも影響します。 プロセス分析では、優先度ごとにインシデントを分類し、プロセスの流れやパフォーマンスを比較します。たとえば、「緊急」のインシデントが「低」優先度のものより実際に早く解決されているかを確認できます。また、SLAは優先度に応じて設定されることが多いため、SLAの遵守状況の確認にも使われます。「優先度変更率」の重要業績評価指標(KPI)は、このフィールドの変更を追跡して算出します。
重要な理由
分析対象の分類や優先順位付けの有効性の評価、緊急度別のSLA遵守状況の確認に欠かせない属性です。
入手先
Zendesk Tickets APIのpriorityフィールド。変更はTicket Audits APIに記録されます。
例
低通常高緊急
|
|||
|
報告チャネル
Channel
|
インシデントが最初に報告されたチャネルです。「メール」「Web」「API」などがあります。 | ||
|
説明
この属性は、エンドユーザーまたはシステムがインシデントチケットを作成した方法を記録します。インシデントの発生元を分析し、それに応じてサポートプロセスを調整するうえで、チャネルの把握が役立ちます。 チャネル別に分析すると、異なる傾向が見つかることがあります。たとえば、電話で報告されたインシデントは、メールで報告されたものより解決までの時間が短い場合があります。この情報は「インシデント処理量」ダッシュボードに反映でき、リソース計画やチャネルの見直しにも役立ちます。
重要な理由
発生元別にインシデント件数やプロセスのパフォーマンスを分析できます。チャネルに応じたプロセスの改善やリソース配分に役立ちます。
入手先
Zendesk Tickets APIのvia.channelフィールド。
例
WebメールAPI電話
|
|||
|
担当エージェント
Assignee
|
現在、インシデントを担当しているサポートエージェントです。 | ||
|
説明
この属性は、特定の時点でインシデントを担当しているエージェントを示します。担当者の変更は、作業が別の担当者に引き継がれたことを示す重要なイベントです。 担当エージェントを分析すると、業務量の配分や個人のパフォーマンス、連携の傾向を把握できます。このフィールドの変更を追跡することは、「インシデントあたりの平均引き継ぎ回数」という重要業績評価指標(KPI)の算出や、インシデントが頻繁に引き継がれている状況の特定に欠かせません。頻繁な引き継ぎは、知識の不足や非効率な振り分けを示している可能性があります。
重要な理由
担当エージェントを特定し、業務量の分析や引き継ぎの追跡を可能にします。プロセスの非効率な点を見つけるうえで重要です。
入手先
Zendesk Tickets APIのassignee_idフィールド。変更はTicket Audits APIに記録されます。
例
John SmithJane Doeサービスデスクの自動化
|
|||
|
担当グループ
AssignedGroup
|
現在、インシデントを担当しているサポートチームまたはグループです。 | ||
|
説明
この属性は、インシデントを担当するチームを示します。インシデントは、たとえば「L1サポート」から「ネットワークチーム」へと、異なるサポート階層や専門グループの間を移動することがあります。 プロセスの引き継ぎを分析し、ボトルネックを特定するうえで重要な項目です。インシデントがグループ間をどのように移動するかを追跡すると、チーム間の依存関係や特定チームの待ち時間を測定し、振り分けルールを見直せます。「引き継ぎと手戻り分析」ダッシュボードの基礎となるデータです。
重要な理由
チームの担当状況を追跡します。チーム間の引き継ぎやチーム固有のボトルネックの分析、待ち時間の測定に役立ちます。
入手先
Zendesk Tickets APIのgroup_idフィールド。変更はTicket Audits APIに記録されます。
例
L1サポートL2ネットワークチームL3インフラストラクチャ請求
|
|||
|
ケース所要時間
CaseDuration
|
インシデントの作成から最終的なクローズまでに経過した合計時間です。 | ||
|
説明
この算出指標は、1件のインシデントの開始から終了までのサイクルタイムを示します。最初のイベント(例:「インシデント作成」)と最後のイベント(例:「インシデントクローズ」)のタイムスタンプの差から算出します。 ケース所要時間は、プロセス全体の効率を測る主要な重要業績評価指標(KPI)です。ダッシュボードで平均サイクルタイムの表示や、長期化しているケースの特定、経時的な傾向の分析に広く使われます。インシデントにどれだけ迅速に対応し、解決できるかを大局的に把握できます。
重要な理由
プロセス全体の処理速度を測定し、解決時間の長期化につながる要因を特定するための重要なKPIです。
入手先
各インシデントIDについて、最後のイベントと最初のイベントのタイムスタンプの差から算出します。
例
25920060480086400
|
|||
|
タグ
Tags
|
分類やコンテキストの把握のためにインシデントに付けるタグの一覧です。 | ||
|
説明
タグは、チケットに追加してコンテキストを補足したり、分類や振り分けに役立てたりできる柔軟なラベルです。エージェントが手動で追加するほか、トリガーや自動化によって自動で追加することもできます。 タグは、プロセスマイニング分析に役立つデータです。特定の製品リリース(「launch_q4」)や既知の障害(「outage_20231027」)に関連するインシデントに絞り込むなど、細かな条件で分析対象を分類できます。この柔軟性により、標準のチケットフィールドだけでは難しい詳細な調査が可能になります。
重要な理由
インシデントを柔軟に分類、絞り込みできます。標準フィールドだけでは難しい、コンテキストに応じた詳細な分析に役立ちます。
入手先
Zendesk Tickets APIのtagsフィールド。
例
vip_usernetwork_issueoutage_20231027billing_related
|
|||
|
チケット種別
TicketType
|
チケットの分類です。「インシデント」「問題」「質問」「Task」などがあります。 | ||
|
説明
このフィールドは、依頼の内容に応じてチケットを分類します。インシデント管理プロセスでは、ITサービスの予期しない中断や品質低下を表す「インシデント」種別のチケットを対象とします。 分析では、インシデントだけをプロセスビューに含めるためのフィルターとして主に使います。また、ITサービスマネジメント全体の分析では、インシデント、問題、サービスリクエストへの対応プロセスを比較する際にも利用できます。
重要な理由
データをインシデントに絞り込み、インシデント管理のライフサイクルに沿ったプロセス分析を行えます。
入手先
Zendesk Tickets APIのtypeフィールド。
例
インシデント問題質問Task
|
|||
|
初回対応で解決したかどうか
IsFirstContactResolution
|
引き継ぎがなく、最初に割り当てられたエージェントまたはグループがインシデントを解決した場合にtrueとなる真偽値です。 | ||
|
説明
初回対応解決率(FCR)は、サポートセンターの効率と顧客満足度を測る重要な指標です。この算出属性は、別のエージェントやチームに再割り当てされずに解決したインシデントを示します。 通常、チケットが最初に割り当てられたエージェントとグループのまま「解決済み」になったかどうかを確認します。プロセスマイニングでは、FCRを直接算出し、エスカレーションが必要だったインシデントとプロセス経路を比較できます。これにより、一次サポートの対応力を高める機会を特定できます。
重要な理由
最初のサポート対応の効率を直接測定し、プロセスの早い段階で解決するための改善機会を特定できます。
入手先
算出される真偽値です。チケットのステータスが「解決済み」または「クローズ済み」で、インシデントのライフサイクルを通じて担当エージェントまたは担当グループが1つだけの場合にtrueとなります。
例
truefalse
|
|||
|
報告者
Submitter
|
インシデントを最初に報告したエンドユーザーまたはシステムです。 | ||
|
説明
この属性は、チケットを作成した人またはシステムを示します。エージェントが他の人に代わってチケットを作成する場合があるため、依頼者とは異なることがあります。 分析では、報告者を使って問題の報告元を把握できます。組織のデータと組み合わせると、特定の顧客やユーザーグループでインシデントが多発しているかを特定できます。先回りしたサポート施策やトレーニングの検討にも役立ちます。
重要な理由
インシデントの報告元を特定します。特定のユーザーや部門、自動化システムに関連する傾向の分析に役立ちます。
入手先
Zendesk Tickets APIのsubmitter_idフィールド。
例
alice.jones@example.combob.williams@example.comシステムモニター
|
|||
|
引き継ぎ回数
HandoffCount
|
インシデントが別のエージェントまたはグループに再割り当てされた回数の合計です。 | ||
|
説明
この算出指標は、インシデントの担当が引き継がれた回数を示します。ケース内でAssigneeフィールドまたはAssignedGroupフィールドが変更されるたびに、回数が加算されます。 引き継ぎは、インシデント管理における非効率や遅延の原因になりがちです。引き継ぎ回数が多い場合、振り分けルールが不明確である、サポートチームの知識が不足している、プロセスが複雑すぎるといった問題が考えられます。この指標は「インシデントあたりの平均引き継ぎ回数」の重要業績評価指標(KPI)の基礎となり、「引き継ぎと手戻り分析」ダッシュボードにも欠かせません。
重要な理由
担当の引き継ぎによるプロセス上の負荷を数値化し、解決時間を延ばす振り分けの非効率や知識不足の特定に役立ちます。
入手先
インシデントごとにAssignedGroupフィールドまたはAssigneeフィールドが変更された回数を数えて算出します。
例
0135
|
|||
|
根本原因カテゴリ
RootCauseCategory
|
インシデントの根本原因を大まかに分類したカテゴリです。 | ||
|
説明
この属性は、インシデントが発生した根本的な理由を分類するために使います。通常、インシデントのライフサイクルの終盤に、事後検証や問題管理の一環として記録し、カスタムフィールドに保存します。 「根本原因特定の精度」ダッシュボードや「根本原因分析の対象範囲」重要業績評価指標(KPI)に欠かせないデータです。根本原因別にインシデントを分析すると、繰り返し発生する問題を特定し、恒久的な対策の実施や将来のインシデント件数の削減につなげられます。事後対応に追われる状態から、問題の予防に重点を置いた取り組みへと移行できます。
重要な理由
インシデントの原因を分類し、傾向の把握や再発防止に役立てることで、問題管理を先回りして進められます。
入手先
通常はカスタムチケットフィールドです。Zendesk管理センターのチケットフィールド設定を確認してください。
例
ソフトウェアのバグハードウェア障害ユーザーの操作ミスネットワーク障害
|
|||
|
満足度評価
SatisfactionRating
|
インシデントの解決後にエンドユーザーが回答した満足度評価です。 | ||
|
説明
この属性は、通常チケットの解決後に実施するアンケートを通じて、サポート対応に対する顧客の評価を記録します。Zendeskでは「良好」や「不良」などの評価が一般的です。 満足度評価はプロセス効率を直接測るものではありませんが、重要な成果指標です。プロセスマイニングでは、プロセスのバリアントと満足度評価を関連付け、どの解決経路が顧客満足度の向上につながるかを把握できます。たとえば、引き継ぎが多いインシデントほど評価が低くなるかを確認できます。
重要な理由
プロセスの特性と関連付けられる重要な成果指標です。プロセスのパフォーマンスがユーザー満足度にどう影響するかを把握できます。
入手先
Zendesk Ticket Metrics API(/api/v2/ticket_metrics.json)のsatisfaction_rating.scoreフィールド。
例
良好不良提示済み未提示
|
|||
|
自動化済みかどうか
IsAutomated
|
アクティビティが自動化システムと人間のどちらによって実行されたかを示す真偽値です。 | ||
|
説明
この派生属性を使うと、人間のユーザーによるイベントと、システムの自動化、トリガー、API連携によるイベントを区別できます。通常、イベントの作成者が既知のシステムユーザーかどうかを確認して判定します。 現代のプロセス分析では、自動化の度合いを把握することが重要です。自動化ルールの有効性を評価し、自動化できる手作業を特定し、自動化が効率や解決時間に与える影響を測定できます。この属性を使って、自動化されたアクティビティと手動のアクティビティのプロセスの流れを比較できます。
重要な理由
人による操作とシステムによる操作を区別できます。自動化がプロセス効率に与える影響の分析や、新たな自動化の機会の特定に役立ちます。
入手先
Ticket Audits APIのイベント作成者(author_id)が、既知のシステムユーザーまたは自動化ユーザーに該当するかどうかを確認して算出します。
例
truefalse
|
|||
|
重大度
Severity
|
インシデントが業務に与える影響の大きさです。 | ||
|
説明
重大度は、インシデントが業務に与える影響を示します。全体的な緊急度を判断するため、優先度と併せて使われることもあります。通常、Zendeskのカスタムフィールドとして設定します。 重大度を分析すると、対応中のインシデントの深刻さを把握できます。「SLA遵守状況のモニタリング」や「優先順位付けの有効性指標」などのダッシュボードで、データを分類する際の重要な項目です。重大度別にプロセスの流れを比較すると、重大度の高いインシデントに適切な速度とリソースで対応できているかを確認できます。
重要な理由
インシデントが業務に与える影響を示します。重大な問題に絞った分析や、効率的な解決に役立ちます。
入手先
通常はカスタムフィールドです。Zendesk管理センターのチケットフィールド設定を確認してください。
例
1 - 重大2 - 高3 - 中4 - 低
|
|||
|
顧客組織
Organization
|
インシデントの依頼者が所属する組織または企業です。 | ||
|
説明
この属性は、インシデントと顧客の組織を関連付けます。顧客ごとにサービスレベルやサポートプロセスが異なるB2Bサポート環境で重要です。 組織別にインシデントを分析すると、サポートチームは顧客の状況を把握し、特定の顧客に繰り返し発生する問題を見つけ、契約上の義務が果たされているかを確認できます。ダッシュボードやレポートを顧客別に絞り込み、顧客の視点からパフォーマンスを確認する際にも役立つ項目です。
重要な理由
顧客別の分析が可能になり、サービスレベルの確認や重要顧客の傾向把握、顧客との関係管理に役立ちます。
入手先
Zendesk Tickets APIのorganization_idフィールド。
例
Global Tech Inc.Innovate SolutionsData Corp
|
|||
インシデント管理のアクティビティ
| アクティビティ | 説明 | ||
|---|---|---|---|
|
インシデントをクローズ
|
チケットが完全にクローズされ、インシデントのライフサイクルが終了したことを示します。Zendeskでは、解決後に一定期間が経過すると自動的にクローズされることが多く、最終的なステータス変更として記録されます。 | ||
|
重要な理由
プロセスの最終アクティビティです。「インシデント作成」からこのイベントまでの時間を算出すると、サイクルタイムを最初から最後まで把握できます。
入手先
チケット監査ログで、「status」フィールドの新しい値が「closed」になった「Change」イベントから取得します。
記録
「status」フィールドが「closed」に変更された「Change」イベントを特定します。
イベントタイプ
explicit
|
|||
|
インシデント作成
|
Zendeskで新しいチケットが作成され、インシデントのライフサイクルが始まる時点を示します。このイベントはZendeskのチケット作成監査ログに明示的に記録され、各ケースの開始点となります。 | ||
|
重要な理由
プロセスの主な開始アクティビティです。このイベントから他のイベントまでの時間を分析すると、チケットのライフサイクル全体の所要時間や初回応答時間を測定できます。
入手先
Zendeskのチケット監査ログに明示的に記録されるイベントです。新しいチケットが作成されるたびに、対応するタイムスタンプとともに「Create」イベントが記録されます。
記録
監査ログに記録されたチケット作成イベントから直接取得します。
イベントタイプ
explicit
|
|||
|
インシデント解決
|
担当者が解決策を実施し、チケットを「solved」に設定した時点を示す重要な節目です。チケット監査ログにステータス変更として明示的に記録されます。 | ||
|
重要な理由
主な解決アクティビティであり、解決までの時間を測る重要な時点です。このイベントから「インシデントクローズ」までの時間は、ユーザーの確認または自動クローズまでの期間を表します。
入手先
チケット監査ログで、「status」フィールドの新しい値が「solved」になった「Change」イベントから取得します。
記録
「status」フィールドが「solved」に変更された「Change」イベントを特定します。
イベントタイプ
explicit
|
|||
|
ステータスをオープンに変更
|
担当者がインシデントへの対応を開始したことを示します。通常、チケットの「status」フィールドが「new」から「open」に変わったことから推定され、調査と診断の開始を表します。 | ||
|
重要な理由
このイベントは、待機状態から実作業への移行を示します。チケットが「new」から「open」に変わるまでの時間は、初回応答時間を測る重要な指標です。
入手先
チケット監査ログで、「status」フィールドの新しい値が「open」、変更前の値が「new」である「Change」イベントを特定して推定します。
記録
ステータスフィールドが「new」から「open」に変更されたことから推定します。
イベントタイプ
inferred
|
|||
|
チケットの担当者を再割り当て
|
初回の割り当て後に、チケットの担当が別の担当者またはグループに移ると発生します。チケットの監査履歴に明示的なイベントとして記録されます。 | ||
|
重要な理由
再割り当ては、引き継ぎや手戻りの分析に欠かせません。頻繁な再割り当ては、初回の振り分けミス、問題の複雑さ、プロセスのボトルネックを示していることがあります。
入手先
チケット監査ログで、初回の入力後に「assignee_id」または「group_id」フィールドに対する「Change」イベントが発生したことを特定します。
記録
「assignee_id」または「group_id」フィールドに対する、その後の「Change」イベントを特定します。
イベントタイプ
explicit
|
|||
|
チケットを担当者に割り当て
|
チケットが対応する担当者に割り当てられたときに発生するアクティビティです。チケットの監査履歴に明示的に記録され、個人が対応を引き受けたことを示します。 | ||
|
重要な理由
この節目は、初回割り当てまでの時間の測定に欠かせません。また、引き継ぎ、手戻り、初回解決率の分析にも使われます。
入手先
チケット監査ログで「assignee_id」フィールドが入力または変更された際に記録されます。初回の割り当ては、重要業績評価指標の算出における重要な節目です。
記録
チケット監査ログで「assignee_id」フィールドに対する「Change」イベントを特定します。
イベントタイプ
explicit
|
|||
|
SLA目標未達
|
初回返信時間や解決時間など、定められたサービスレベル合意をチケットが満たせなかった時点を示します。SLAポリシーの定義とチケットの更新時刻に基づいて算出されます。 | ||
|
重要な理由
このイベントは、SLA遵守状況のモニタリングに直接役立ちます。違反がいつ、なぜ発生するかを特定することは、サービスの信頼性と顧客の信頼を高めるうえで欠かせません。
入手先
算出されるイベントです。チケットに関連付けられた「sla_policy_metrics」データを分析し、各SLA目標の「breached_at」タイムスタンプを使って導出できます。
記録
チケットのSLA指標データに含まれる「breached_at」タイムスタンプから導出します。
イベントタイプ
calculated
|
|||
|
ステータスを保留中に変更
|
依頼者からの返信を待つ間、プロセスが一時停止していることを示します。チケットの「status」フィールドが「pending」に変わったことから推定します。 | ||
|
重要な理由
このアクティビティは、ユーザー確認待ち時間の算出に欠かせません。この状態が長く続くと、解決までの全体時間が大幅に延び、連絡の遅れも明らかになります。
入手先
チケット監査ログで、「status」フィールドの新しい値が「pending」である「Change」イベントを特定して推定します。
記録
ステータスフィールドが「pending」に変更されたことから推定します。
イベントタイプ
inferred
|
|||
|
チケットをグループに割り当て
|
インシデントを特定のサポートグループに最初に振り分け、トリアージすることを示します。通常、担当を決める最初のステップであり、チケットの監査履歴に明示的な変更イベントとして記録されます。 | ||
|
重要な理由
グループへの割り当てを追跡すると、初期トリアージの効率を分析し、チケットが適切なチームに振り分けられるまでの遅延を特定できます。
入手先
チケット監査ログで「group_id」フィールドが設定または変更された際に記録されます。作成後に最初に発生した変更が初回の割り当てです。
記録
チケット監査ログで「group_id」フィールドに対する「Change」イベントを特定します。
イベントタイプ
explicit
|
|||
|
ユーザー満足度を評価
|
エンドユーザーが受けたサポートに対する満足度を評価した時点を示します。チケットの解決後、Zendeskに明示的なイベントとして記録されます。 | ||
|
重要な理由
満足度評価を分析すると、担当者の対応やプロセスの有効性に関する重要なフィードバックが得られます。プロセス指標と顧客の成果を結び付けて把握できます。
入手先
チケットに関連付けられた満足度評価データから取得します。通常、「good」または「bad」の評価と、任意のコメントが含まれます。
記録
チケットに満足度評価が送信されたときに記録されるイベントです。
イベントタイプ
explicit
|
|||
|
優先度を設定
|
インシデントの優先度(低、通常、高、緊急など)を定義します。明示的な変更イベントとして記録され、チケットの緊急度と必要な応答時間を決定します。 | ||
|
重要な理由
優先度を設定した時期と方法を追跡することは、「優先順位付けの有効性指標」ダッシュボードに欠かせません。重大な問題に迅速に対応できているかを確認できます。
入手先
チケット監査ログの「priority」フィールドに対する「Change」イベントから取得します。その後の変更も追跡し、優先度変更率の重要業績評価指標を測定できます。
記録
チケット監査ログで「priority」フィールドに対する「Change」イベントを特定します。
イベントタイプ
explicit
|
|||
|
公開返信を送信
|
サポート担当者からエンドユーザーへの連絡を示します。チケットに公開コメントが追加されるたびに、Zendeskの明示的なイベントとして記録されます。 | ||
|
重要な理由
公開返信を追跡すると、連絡の頻度を把握できます。また、ユーザーの確認待ちによる遅延を分析する際の重要な時系列情報になります。
入手先
チケットのコメントデータから取得します。「public」属性がtrueのコメントを公開コメントとして識別します。
記録
「public: true」の新しいコメントがチケットに追加されたときに記録されるイベントです。
イベントタイプ
explicit
|
|||
|
内部メモを追加
|
担当者がチーム内の他のメンバーに向けてチケットに非公開メモを追加する、内部での連携を示します。コメントが非公開に設定されたときに明示的に記録されます。 | ||
|
重要な理由
内部メモを分析すると、連携が必要な複雑な問題についてインサイトを得られます。一方、メモが過剰に多い場合は、ナレッジ不足やプロセスの非効率を示している可能性があります。
入手先
チケットのコメントデータから取得します。「public」属性がfalseのコメントを内部メモとして識別します。
記録
「public: false」の新しいコメントがチケットに追加されたときに記録されるイベントです。
イベントタイプ
explicit
|
|||
データ抽出ガイド
始める準備はできましたか?
このテンプレートを使ってデータ準備を効率化し、インシデント管理の状況を詳しく把握しましょう。今すぐプロセスの改善に取り組めます。
インシデント管理を改善し、解決を迅速化
平均解決時間(MTTR)を35%短縮し、繰り返し発生するインシデントをなくして、満足度を高めましょう。
クレジットカード不要。数分で改善を始められます。