> 継続的なプロセス改善 > 問題管理 > Zendesk Support > データテンプレート

問題管理データテンプレート

Zendesk Support

問題管理データテンプレート

このテンプレートは、Zendesk Support内での問題管理ライフサイクルをマッピングするための包括的なフレームワークを提供します。根本原因分析におけるボトルネックを特定するために必要な必須属性、プロセス上のマイルストーン、および抽出ロジックを概説しています。この構造に従うことで、より深いプロセス洞察を得るための高品質なイベントログを構築できます。

詳細分析に推奨の属性
主要なプロセスアクティビティとステータス遷移
Zendesk Supportデータ抽出ガイド

イベントログについて初めての方へ：プロセスマイニングのイベントログ作成方法.

テンプレートをダウンロード

問題管理属性

これらの推奨データフィールドは、問題解決ライフサイクル全体を通じて、チケットカテゴリ、優先度レベル、および所有権を分析するために必要なコンテキストを提供します。

5 必須 8 推奨 7 任意

	名前	説明
	アクティビティ ActivityName	問題レコードに対して実行されたイベントまたはアクションの名前。
説明この属性は、問題レコードのライフサイクル中に実行された特定のステップまたはアクションを捕捉します。例としては、「オープン（Open）」から「保留中（Pending）」へのステータス変更、担当者の変更、「暫定対応公開済み（Workaround Published）」のような特定のワークフローステップなどがあります。分析においては、これはプロセスマップのノードを形成します。これらのアクティビティの順序により、アナリストは作業の流れを可視化し、ボトルネックを特定し、特定のプロセスステップ間の所要時間を測定することができます。その重要性プロセスの「何」を定義し、プロセスフローの可視化とバリアント分析を可能にします。取得元 Zendeskチケット監査またはチケットメトリックから導出例問題レコード登録済み調査開始暫定対応公開済み
	ソースシステム SourceSystem	`データ`の`発信元``システム`名です。
説明この属性は、プロセスデータが抽出されたソフトウェアプラットフォームを識別します。このコンテキストでは、常に「Zendesk Support」として入力されます。分析においては、特に複数のシステム（例：ZendeskとJira）からのデータを結合する際に、アナリストがデータの発生源に基づいてデータをフィルタリングまたはグループ化することを可能にします。これにより、複数システムプロセスビューにおけるデータのリネージとトレーサビリティを保証します。その重要性データのリネージュを確保し、複数システムに対応するプロセスマイニング構成をサポートします。取得元抽出時にハードコード例 Zendesk Support
	最終データ更新 LastDataUpdate	問題レコードが最終更新された日時を示すタイムスタンプ。
説明この属性は、ソースシステムで問題レコードデータが最後に更新された最新の時刻を反映します。これはイベントのタイムスタンプとは異なり、アクティビティレベルではなくレコードレベルを指します。分析においては、データの鮮度を判断するのに役立ちます。データセットが最新であるか、またはソースシステムとプロセスマイニング環境との間に同期の遅れがあるかどうかを特定するために使用されます。その重要性データ鮮度を追跡し、増分データローディング戦略を支援します。取得元 Zendeskチケットオブジェクト、「updated_at」フィールド例 2023-11-01T14:20:00Z
	問題レコード ProblemRecordId	Zendeskで問題チケットに割り当てられた一意の数値識別子。
説明この属性は、Zendesk Supportシステム内の問題レコードに対する一意のキーを表します。プロセスマイニングの中央ケースIDとして機能し、すべての後続のイベント、更新、およびインタラクションを単一のプロセスインスタンスにグループ化できます。分析においては、このIDは作成からクローズまでの各問題調査ジャーニーを明確に識別するために使用されます。関連するインシデントの相関付けや、さまざまなサポート階層を通じた問題のライフサイクルの追跡を可能にします。その重要性あらゆるプロセスマイニング分析において、イベントをケースにグループ化するために必要な基本的な必須キーです。取得元 Zendeskチケットオブジェクト、「id」フィールド（タイプが「problem」の場合）例 1045293849921
	開始時刻 EventTimestamp	`アクティビティ`が`発生`した`特定`の`日付`と`時刻`です。
説明この属性は、Zendeskシステム内でアクティビティが発生した正確な瞬間を記録します。イベントを正しく順序付けし、ステップ間の期間を計算するために必要な時間的側面を提供します。分析においては、サイクルタイムの計算、遅延の特定、SLA遵守の確認、および時間の経過に伴うプロセスの可視化にとって不可欠です。正確なタイムスタンプがなければ、問題解決プロセスの速度を理解することは不可能です。その重要性アクティビティのソートと、すべての時間ベースのKPIの計算が可能です。取得元 Zendeskチケット監査ログ、「created_at」フィールド例 2023-10-12T08:30:00Z2023-10-12T09:15:22Z
	`SLA`期日 SlaDueDate	問題が解決されるべき目標日時。
説明この属性は、サービスレベルアグリーメント（SLA）設定に基づいた解決期限を表します。通常、優先度とチケットが作成された時刻に基づいて計算されます。分析においては、実際の解決時間と比較して「問題SLA遵守率（Problem SLA Adherence Rate）」を計算するために使用されます。これは、「SLAパフォーマンスとリスク（SLA Performance and Risk）」ダッシュボードを動かし、割り当てられた時間に近づいている、または超過したケースを強調表示します。その重要性コンプライアンスおよび契約上のパフォーマンスを測定するために不可欠です。取得元 ZendeskチケットメトリクスまたはSLAポリシーエンドポイント例 2023-12-01T17:00:00Z
	`サポートグループ` SupportGroup	現在問題レコードに割り当てられているチームまたは部門。
説明この属性は、特定の時点において問題を担当するエージェントの具体的なグループを識別します。チケットがチームから別のチームへ引き継がれる際に変更されます。分析においては、「サポートグループ引き継ぎ分析（Support Group Handover Analysis）」ダッシュボードにとって不可欠です。チームごとのパフォーマンス測定、引き継ぎ時のボトルネック特定、およびリソースの業務負荷分散分析を可能にします。その重要性組織分析と部署間の`ボトルネック`特定を可能にします。取得元 Zendeskチケットオブジェクト、「group_id」フィールド（名前に解決済み）例 L2サポートデータベースチームネットワーク運用
	優先度 Priority	問題レコードに割り当てられた緊急度レベル。
説明この属性は、問題の相対的な重要性を示し、通常は低、通常、高、緊急に分類されます。これは、期待されるサービスレベルアグリーメント（SLA）とリソース割り当てを決定する要因となります。分析においては、プロセスをセグメント化し、異なる緊急度レベル間でパフォーマンスを比較するために使用されます。例えば、「根本原因調査速度（Root Cause Investigation Velocity）」ダッシュボードで求められるように、「緊急」の問題が「低」優先度の問題よりも実際に早く解決されているかを確認するのに役立ちます。その重要性 SLA遵守とリソースの優先順位付けを分析するために、ケースをセグメント化する上で不可欠です。取得元 Zendeskチケットオブジェクト、「priority」フィールド例 `緊急`高通常低
	問題カテゴリ ProblemCategory	問題の分類（例：ソフトウェア、ハードウェア、ネットワーク）。
説明この属性は、影響を受けるサービスまたは技術スタックに基づいて問題を分類します。通常、Zendeskフォームのカスタムドロップダウンフィールドです。分析においては、「問題カテゴリ分類精度（Problem Categorization Accuracy）」ダッシュボードに利用されます。この初期カテゴリと最終的な根本原因を比較することで、初期トリアージが問題を正しいチームに正確にルーティングしているかどうかを特定するのに役立ちます。その重要性テクノロジーまたはビジネスサービスによるセグメンテーションが可能です。取得元 Zendeskチケットカスタムフィールド例データベースUI/UXネットワークインフラストラクチャ
	問題ステータス ProblemStatus	ライフサイクルにおける問題レコードの現在の状態です。
説明この属性は、新規、オープン、保留中、解決済み、またはクローズ済みといった問題の現在のステータスを示します。これは、調査の進捗を反映します。分析においては、オープンなケースとクローズ済みのケースをフィルタリングするために使用されます。「停滞問題レコード監視（Stale Problem Record Monitoring）」ダッシュボードにとって不可欠であり、期待されるステータスライフサイクルを通じて進展していないアクティブなケースを特定します。その重要性ケースを完了状態によってフィルタリングできます。取得元 Zendeskチケットオブジェクト、「status」フィールド例新規オープン待機中解決済みクローズ済み
	担当者名 AssigneeName	問題を担当する特定のエージェント。
説明この属性には、現在問題レコードを担当している個々のユーザーの名前が含まれます。誰が特定のアクションを実行したかについて、詳細な可視性を提供します。分析においては、個々の業務負荷とパフォーマンスを理解するのに役立ちます。グループレベルの分析が一般的ですが、担当者レベルのデータは、トレーニングの必要性や、複雑な根本原因の解決に特に効果的な個人を特定するのに役立ちます。その重要性個人レベルでのリソース分析を可能にします。取得元 Zendeskチケットオブジェクト、「assignee_id」フィールド（名前に解決済み）例 John DoeJane Smithシステム
	根本原因カテゴリ RootCauseCategory	特定された問題の根本原因（例：コードの欠陥、設定エラー）。
説明この属性は、問題の原因となった最終診断結果を捉えます。通常、「根本原因特定済み（Root Cause Identified）」アクティビティ中に記入されます。分析においては、「問題カテゴリ分類精度（Problem Categorization Accuracy）」レポートの生成や、システム障害のトレンド分析に利用されます。これにより、経営層はコード品質、インフラストラクチャの安定性、またはベンダー管理のいずれに注力すべきかを判断するのに役立ちます。その重要性障害パターンの分析を可能にし、長期的な改善努力を指示します。取得元 Zendeskチケットカスタムフィールド例ソフトウェアバグ設定エラー`ユーザーエラー`
	関連インシデント数 RelatedIncidentCount	この問題レコードにリンクされているインシデントチケットの数。
説明この属性は、この問題レコードに関連付けられている個々のインシデントチケットの数をカウントします。Zendeskでは、インシデントチケットの「problem_id」フィールドを通じて、このレコードへのリンクとして管理されます。分析においては、「インシデント相関と影響（Incident Correlation and Impact）」の主要な指標となります。これにより、最も多くのユーザーに影響を与えている問題を優先順位付けし、チケット量の削減という点で最高のROIをもたらす修正に関する戦略的決定を導くのに役立ちます。その重要性問題の規模とユーザーへの影響を示します。取得元 Zendesk Tickets API、タイプが「incident」でproblem_id=ThisIDのチケット数例 015342
	PIRあり HasPostImplementationReview	実装後レビューが実施された場合にフラグを立てます。
説明この属性は、問題解決プロセスにレビューフェーズが含まれていたかどうかを示します。ケース履歴に「導入後レビュー実施済み（Post-Implementation Review Conducted）」アクティビティが存在するかどうかを確認することで導出されます。分析においては、「導入後レビューカバレッジ（Post Implementation Review Coverage）」ダッシュボードをサポートします。これは、組織が主要な問題から学習していることを保証するコンプライアンス指標です。その重要性継続的改善プロセスへの準拠を検証します。取得元「実装後レビュー実施済み」アクティビティの存在から導出例 truefalse
	ナレッジ記事ID KnowledgeArticleId	問題に作成またはリンクされたナレッジベース記事のID。
説明この属性は、Zendesk Guide記事または外部のナレッジアイテムへの参照を保存します。これは、問題から得られた知識が捕捉されたことを示します。分析においては、このフィールドの存在は「ナレッジベース連携率（Knowledge Base Integration Rate）」を計算するために使用されます。これにより、組織が将来の参照のために解決策を文書化することで学習ループを完了していることを検証します。その重要性ナレッジ管理プロセスの有効性を測定します。取得元 Zendeskチケットカスタムフィールドまたはリンクされたコンテンツ例 360045889KB-2991
	停滞中 IsStale	問題が14日間以上活動がない場合にフラグを立てます。
説明この計算属性は、最近更新されていないレコードを特定します。現在の（または分析対象の）日付を最終アクティビティのタイムスタンプと比較します。分析においては、「停滞問題レコード監視（Stale Problem Record Monitoring）」ダッシュボードを動かします。これにより、バックログを圧迫し、管理上のクローズまたは再割り当てが必要となる可能性のある見過ごされたケースを、管理者が迅速に特定するのに役立ちます。その重要性プロセス内の無駄や放置された作業項目を特定するのに役立ちます。取得元プロセスマイニングツールで計算: (現在 - 最終データ更新) > 14日例 truefalse
	問題件名 ProblemSubject	問題レコードの短い要約またはタイトル。
説明この属性には、問題が作成された際に入力されたテキストによる要約が含まれます。通常、症状や調査中の問題について記述されます。分析においては、特定ケースを深掘りする際にアナリストにコンテキストを提供します。また、類似の問題をクラスター化したり、構造化されたカテゴリフィールドでは捕捉されない繰り返し発生するトピックを特定するために、テキストマイニング技術を適用することもできます。その重要性個々のケースに対して人間が読めるコンテキストを提供します。取得元 Zendeskチケットオブジェクト、「subject」フィールド例 EU地域での支払処理ができませんログインサーバーでのレイテンシ急増管理者ユーザーのデータエクスポート失敗
	変更リクエストID ChangeRequestId	修正を実装するためにリンクされた変更要求の識別子。
説明この属性は、問題レコードを最終的な変更管理レコード（別のシステムまたは異なるチケットタイプの場合もある）にリンクします。これは、正式な変更プロセスが開始されたことを示します。分析においては、「変更要求開始率（Change Request Initiation Rate）」ダッシュボードをサポートします。これは、診断から実装への移行を追跡し、特定された根本原因が正式な変更アクションにつながることを保証するのに役立ちます。その重要性問題プロセスと変更管理プロセスを連携させます。取得元 Zendeskチケットカスタムフィールドまたはリンクされたチケット例 CR-1002CHG00394
	暫定対応有効 WorkaroundActive	回避策が提供/公開されたかどうかを示すフラグ。
説明このブール属性は、問題に対する一時的な修正が文書化されたかどうかを示します。「暫定対応公開済み（Workaround Published）」アクティビティの有無、またはフォーム上の特定のチェックボックスから導出されることがよくあります。分析においては、「暫定対応公開遵守（Workaround Publication Compliance）」ダッシュボードに利用されます。これは、長期調査が継続されている間、サポートチームがどれくらいの頻度でユーザーに即座の緩和策を提供しているかを測定します。その重要性調査中のユーザー影響軽減を測定するための鍵となります。取得元「回避策公開済み」アクティビティまたはカスタムフィールドの存在から導出例 truefalse
	調査期間 InvestigationDuration	調査開始から根本原因特定までの所要時間。
説明この計算属性は、核心的な診断フェーズの期間を測定します。「調査開始（Investigation Commenced）」アクティビティと「根本原因特定済み（Root Cause Identified）」アクティビティ間の時間差を計算します。分析においては、「平均根本原因分析期間（Average Root Cause Analysis Duration）」の主要な指標です。これにより、異なるサポートグループや問題カテゴリ間の診断速度のベンチマーク設定を可能にします。その重要性診断プロセスの効率を測定します。取得元プロセスマイニングツールで計算: タイムスタンプ（根本原因） - タイムスタンプ（調査開始）例 48時間5 days

必須推奨任意

問題管理アクティビティ

これらの不可欠なプロセスステップとステータス変更を捉え、初期の問題特定から恒久的な修正の実装までのエンドツーエンドのフローを可視化します。

8 推奨 4 任意

	アクティビティ	説明
	サポートグループに割り当て済み	問題レコードが特定の技術チームまたは部門にルーティングされることです。これは、チケットのグループIDフィールドが更新されたときに追跡されます。
その重要性サポートグループ引き継ぎ分析ダッシュボードにとって、部署間の待ち時間を測定するために不可欠です。取得元チケットの監査ログにある「group_id」フィールドの変更を監視します。取得トランザクション「グループ割り当て変更」が実行されたときに記録イベントタイプ explicit
	問題レコードクローズ済み	チケットがロックされ、それ以上の変更ができない最終的なライフサイクルイベントです。Zendeskでは、これは通常、「解決済み（Solved）」ステータスから4日後に自動的に発生します。
その重要性レコードのライフサイクルが完全に終了したことを示し、データ保持や履歴レポート作成に利用されます。取得元チケットステータスが「クローズ済み」に変わったことから導出されます。取得ステータスがクローズ済みに変更されたときに記録されますイベントタイプ explicit
	問題レコード登録済み	Zendesk Support内での問題チケットの初回作成です。このイベントは、問題がシステムに初めて記録された際のタイムスタンプを捕捉し、通常、プロセスインスタンスをトリガーします。
その重要性エンドツーエンド解決サイクルの開始時間を設定し、その後のすべてのリードタイムメトリックのベースラインとなります。取得元チケットオブジェクトの「created_at」タイムスタンプ、またはチケット監査ログの最初のエントリから導出されます。取得トランザクション「チケット作成」が実行されたときに記録イベントタイプ explicit
	恒久的な修正適用済み	技術的な解決策が環境にデプロイされたことを示します。これは通常、チケットが完全に解決される前に、カスタムステータスの移行または特定のタグを通じて追跡されます。
その重要性診断からデプロイまでの時間を測定するために、修正実装効率ダッシュボードにとって不可欠です。取得元特定のタグ（例：「fix_deployed」）または、存在すればカスタムステータスフィールドから推測されます。取得タグまたはカスタムステータスのドロップダウンを監視するイベントタイプ inferred
	暫定対応公開済み	問題に対する一時的な修正を文書化し、共有するアクションです。Zendeskでは、これはしばしば特定のタグまたは暫定対応が利用可能であることを示すカスタムチェックボックスフィールドを通じて記録されます。
その重要性暫定対応公開遵守ダッシュボードをサポートし、長期調査中にユーザーへ一時的な緩和策が提供されることを保証します。取得元「workaround_published」タグの追加、または「Workaround」という名前のカスタムブールフィールドの変更を監視します。取得カスタムフィールドまたはタグの値を比較イベントタイプ inferred
	根本原因特定済み	問題の根本原因が特定される時点です。これは通常、エージェントによってカスタムの「根本原因（Root Cause）」テキストフィールドまたはドロップダウンカテゴリが入力されたときに記録されます。
その重要性根本原因調査速度ダッシュボードおよび診断効率測定のための重要なマイルストーン。取得元「根本原因（Root Cause）」「RCA」「問題源（Problem Source）」とラベル付けされたカスタムフィールドの、NULL以外の値への変更を監視します。取得入力用カスタムフィールド値を比較イベントタイプ inferred
	解決検証済み	問題が「解決済み（Solved）」として正式にマークされることです。Zendeskでは、標準システムステータスが「Solved」に設定されたときに発生し、修正が検証され、ケースが完了したことを示します。
その重要性 SLAパフォーマンスとリスク計算、および問題SLA遵守率の主要なエンドポイントです。取得元チケットステータスが「解決済み」に変わったことから導出されます。取得ステータスが「解決済み」に変更されたときに記録イベントタイプ explicit
	調査開始	受動的な「新規」ステータスから能動的な作業ステータスへの移行を示します。これは、エージェントが問題を認識し、診断を開始したことを意味します。
その重要性停滞問題レコードのメトリクス計算に使用され、平均根本原因分析期間KPIの出発点となります。取得元チケットステータスが「新規」から「オープン」または「保留中」に変わった場合に推測されます。取得ステータスフィールドを前後で比較イベントタイプ inferred
	問題調査再開	以前「解決済み（Solved）」とマークされた問題レコードが、「オープン（Open）」またはアクティブな状態に戻された場合に発生します。これは、修正の失敗または解決策の却下を示します。
その重要性問題再オープン率KPIをサポートし、解決プロセスにおける品質問題を特定するのに役立ちます。取得元ステータスが「解決済み」から「オープン」、「新規」、「保留中」に戻った場合に推測されます。取得ステータスフィールドを前後で比較イベントタイプ inferred
	変更要求開始	問題を修正するための正式な変更管理プロセスがトリガーされたことを示します。これは通常、「変更要求ID」カスタムフィールドが入力された場合、または「変更」タイプのチケットがリンクされた場合に推測されます。
その重要性変更要求開始率を追跡し、問題管理と変更管理ワークフローを連携させます。取得元「change_reference」のようなカスタムフィールドの更新、または「problem_change」リンクタイプの作成を監視します。取得外部ID入力用のカスタムフィールドを監視するイベントタイプ inferred
	実装後レビュー実施済み	修正後に事後レビューが完了したことを確認します。これは通常、プロセスコーディネーターが更新するチェックボックスまたは日付フィールドです。
その重要性品質基準への準拠を保証するための「導入後レビュー頻度KPI」に必要です。取得元カスタムチェックボックス「PIR完了（PIR Completed）」または日付フィールド「PIR日付（PIR Date）」の更新を監視します。取得カスタムフィールドの完了を監視するイベントタイプ inferred
	解決策案作成済み	問題調査に基づいたナレッジベース記事の作成です。これはZendesk Knowledge Captureアプリの使用または新規記事のリンクから推測されます。
その重要性ナレッジベース連携率KPIをサポートし、組織学習を促進します。取得元「ナレッジキャプチャ（Knowledge Capture）」連携または「kcs_draft」のようなタグに関連するイベントを監視します。取得特定のシステムタグまたはリンクイベントから導出イベントタイプ inferred

推奨任意

抽出ガイド

Zendesk Supportから**データ**を取得する方法

ステップ

Zendeskインスタンスにログインし、プロダクトトレイからExploreレポートインターフェースに移動します。
クエリフォルダー（または新しいバージョンではレポート）をクリックし、「新しいクエリ」を選択します。
データセットの選択を求められたら、サポート、次に更新履歴、そしてサポート: 更新履歴 [デフォルト] を選択します。このデータセットには、現在の状態データではなく、プロセスマイニングに必要なイベントログが含まれています。
メトリックパネルで「カウント（チケット）」または「カウント（更新）」を追加し、データが取得されていることを確認します。
フィルターパネルで、チケット > チケットタイプのフィルターを追加し、「問題」を選択して、データセットを問題管理プロセスに限定します。
行パネルに、イベントログ構造を定義するために、以下の属性をこの特定の順序で追加します: チケット > チケットID、時間 - タイムスタンプ > 更新 - タイムスタンプ、更新者 > 更新者名、変更 > 変更 - フィールド名。
アクティビティ名列を作成するには、標準計算属性を作成する必要があります。右サイドバーの計算アイコンをクリックし、「標準計算属性」を選択し、「アクティビティマッパー」と名前を付け、以下のクエリセクションに記載されているコードを貼り付けます。
この新しいアクティビティマッパー属性を行パネルに追加します。無関係なシステムノイズを除去するために、この属性をNULL値を除外するようフィルタリングします。
コンテキストのために、行パネルに以下の追加属性を追加します: チケット > 優先度、チケット > グループ、チケット > ステータス、および根本原因分析やカテゴリ分析に必要なカスタムフィールド（例：チケット > チケットタグまたは特定のカスタムフィールド）。
フィルターパネルで、時間 - タイムスタンプ > 更新 - 日付を使用して、目的の分析期間（例：過去6ヶ月）を設定します。
視覚化タイプアイコンをクリックし、「テーブル」を選択します。オプションが利用可能な場合は、テーブルがアンピボットまたはフラットであることを確認するか、すべての属性が行セクションにあることを確認するだけです。
エクスポート > CSV をクリックして結果をエクスポートします。ProcessMindのタイムスタンプ形式を保持するために、「属性の書式設定を維持する」のチェックボックスがオンになっていることを確認してください。

設定

データセット: サポート: 更新履歴 (重要: 標準のチケットデータセットは現在の状態しか表示しないため使用しないでください)。
時間フィルター: 更新日 (推奨: データ量に応じて過去90～180日間)。
チケットタイプ: インシデントやサービスリクエストと混同しないよう、厳密に問題にフィルタリングしてください。
行制限: Zendesk Exploreのエクスポートは通常50,000行に制限されています。データセットがこれを超える場合は、更新日フィルターを利用して、より小さい月単位のチャンクでエクスポートし、外部でマージしてください。
カスタムフィールド: 根本原因、変更要求、および回避策に関する特定のフィールドIDをZendeskインスタンスで特定してください。これらは標準のシステムフィールドではありません。
システム権限: Explore ViewerまたはExplore Professionalライセンスが必要です。

a クエリ例 config

IF ([Changes - Field name] = "status" AND [Changes - New value] = "New") THEN "Problem Record Logged"
ELIF ([Changes - Field name] = "group_id") THEN "Assigned to Support Group"
ELIF ([Changes - Field name] = "status" AND [Changes - Previous value] = "New" AND [Changes - New value] = "Open") THEN "Investigation Commenced"
ELIF ([Changes - Field name] = "tags" AND CONTAINS([Changes - New value], "workaround_available")) THEN "Workaround Published"
ELIF ([Changes - Field name] = "[Your Root Cause Field Name]") THEN "Root Cause Identified"
ELIF ([Changes - Field name] = "[Your Change Request ID Field Name]") OR ([Changes - Field name] = "type" AND [Changes - New value] = "change") THEN "Change Request Initiated"
ELIF ([Changes - Field name] = "tags" AND CONTAINS([Changes - New value], "fix_deployed")) THEN "Permanent Fix Applied"
ELIF ([Changes - Field name] = "[Your Knowledge Article Linked Field]") THEN "Proposed Solution Drafted"
ELIF ([Changes - Field name] = "status" AND [Changes - New value] = "Solved") THEN "Resolution Verified"
ELIF ([Changes - Field name] = "status" AND [Changes - Previous value] = "Solved" AND [Changes - New value] = "Open") THEN "Problem Investigation Reopened"
ELIF ([Changes - Field name] = "[Your PIR Completed Checkbox Field]") THEN "Post-Implementation Review Conducted"
ELIF ([Changes - Field name] = "status" AND [Changes - New value] = "Closed") THEN "Problem Record Closed"
ELSE NULL
ENDIF

ステップ

前提条件の確認: 組織でZendeskデータ共有アドオンが有効になっていることを確認してください。通常SnowflakeまたはAmazon Redshiftでホストされている、レプリケートされたZendeskデータベースへの読み取り専用アクセス資格情報があることを確認してください。
データベースへの接続: お好みのSQLクライアント（DBeaver、DataGrip、またはネイティブのSnowflake/Redshiftウェブインターフェースなど）を使用して、提供された資格情報でZendeskデータウェアハウスへの接続を確立してください。
カスタムフィールドの特定: クエリを実行する前に、問題管理プロセスで使用されているカスタムフィールドの一意のIDを特定する必要があります。Zendeskの管理センターに移動し、オブジェクトとルール > チケット > フィールドにアクセスしてください。「根本原因」、「変更要求ID」、「回避策公開済み」、「恒久的な修正適用済み」、「実装後レビュー」のフィールドを見つけて、それぞれのフィールドIDを取得します。これらはクエリ内のプレースホルダーを置き換えるために使用されます。
SQLクエリの確認: 提供されているクエリは、ProblemTicketsという名前の共通テーブル式（CTE）を使用して、まずすべての問題記録を選択・フィルタリングします。これにより、パフォーマンスと可読性が向上します。クエリの主要部分は、次にUNION ALLを使用して、必要な各アクティビティに対応する12個の個別のSELECTステートメントの結果を結合します。
クエリのカスタマイズ: 新しいクエリエディタを開き、提供された完全なSQLスクリプトを貼り付けます。スクリプト内のプレースホルダーを次のように変更します。
- ProblemTickets CTEで、'[YYYY-MM-DD]'を置き換えて目的の日付範囲を設定します。
- カスタムフィールドに依存する各アクティビティについて、プレースホルダーID（例: [あなたの「根本原因カテゴリ」field_id]、[あなたの「変更要求ID」field_id]）をステップ3で特定した実際のIDに置き換えます。
クエリの実行: 変更したSQLスクリプトをデータベースに対して実行します。実行時間は、日付範囲とチケットデータの量によって異なります。
「提案された解決策の草稿作成」ロジックの調査: クエリは、解決策の草稿作成が[あなたの「KB記事ID」field_id]という名前のカスタムフィールドに入力することでキャプチャされると仮定しています。プロセスが異なる場合（例えば、特定のタグやコメントを使用する場合）は、クエリのこの部分をそれに応じて調整する必要があります。
データ検証: クエリが完了したら、結果を簡単にレビューします。妥当な行数があるか、すべての列が存在するかを確認し、ProblemRecordIdやEventTimestampなどの重要な列に予期しないNULL値がないかをスキャンします。
イベントログのエクスポート: SQLクライアントから結果セット全体をCSVファイルにエクスポートします。ファイルがUTF-8エンコーディングを使用しており、列ヘッダーがプロセスマイニングツールで要求される属性名と一致していることを確認してください。
アップロードの準備: アップロードする前に、CSVファイルにフォーマットの問題がないか確認してください。EventTimestamp列の日付と時刻の値がYYYY-MM-DD HH24:MI:SSなどの一貫した形式であることを確認してください。

設定

前提条件: この抽出には、Zendeskデータ共有アドオンと、SnowflakeまたはAmazon Redshiftインスタンス内のレプリケートされたデータへの直接SQLアクセスが必要です。
チケットタイプフィルター: クエリは、typeが'problem'であるチケットのみを分析するように事前設定されています。これは、問題管理プロセスをインシデントや他のチケットタイプから分離するために不可欠です。
日付範囲フィルタリング: パフォーマンスを管理するために、特定の期間でデータをフィルタリングすることを強くお勧めします。クエリには、最初のCTEにプレースホルダーcreated_at >= '[YYYY-MM-DD]'が含まれています。最初の分析では、3〜6ヶ月の範囲が一般的です。
カスタムフィールド設定: この抽出は、特定のZendesk構成に大きく依存します。「根本原因特定済み」、「変更要求開始済み」、「回避策公開済み」などのアクティビティを追跡するカスタムフィールドの正しいfield_idを特定して挿入する必要があります。プレースホルダーIDが置き換えられていない場合、これらのアクティビティのクエリは失敗するか、データを返しません。
データ遅延: レプリケートされたデータベースのデータはリアルタイムではありません。通常、Zendeskでイベントが発生してからデータウェアハウスに表示されるまでに数時間の遅延があります。非常に最近のアクティビティを分析する際には、この点に留意してください。

a クエリ例 sql

WITH ProblemTickets AS (
  SELECT
    t.id,
    t.created_at,
    t.updated_at,
    t.priority,
    g.name AS group_name,
    u.name AS assignee_name,
    t.status,
    (SELECT COUNT(*) FROM problem_incident_links pil WHERE pil.problem_id = t.id) AS related_incident_count,
    t.due_at AS sla_due_date,
    cf_cat.value AS problem_category,
    cf_root.value AS root_cause_category
  FROM tickets t
  LEFT JOIN users u ON t.assignee_id = u.id
  LEFT JOIN groups g ON t.group_id = g.id
  LEFT JOIN custom_field_values cf_cat ON t.id = cf_cat.ticket_id AND cf_cat.custom_field_id = [Your 'Problem Category' field_id]
  LEFT JOIN custom_field_values cf_root ON t.id = cf_root.ticket_id AND cf_root.custom_field_id = [Your 'Root Cause Category' field_id]
  WHERE t.type = 'problem'
  AND t.created_at >= '[YYYY-MM-DD]' -- Set start date for the extraction
)
-- 1. Problem Record Logged
SELECT
  pt.id AS "ProblemRecordId",
  'Problem Record Logged' AS "ActivityName",
  pt.created_at AS "EventTimestamp",
  'Zendesk' AS "SourceSystem",
  pt.updated_at AS "LastDataUpdate",
  pt.priority AS "Priority",
  pt.group_name AS "SupportGroup",
  pt.assignee_name AS "AssigneeName",
  'new' AS "ProblemStatus",
  pt.related_incident_count AS "RelatedIncidentCount",
  pt.sla_due_date AS "SlaDueDate",
  pt.problem_category AS "ProblemCategory",
  pt.root_cause_category AS "RootCauseCategory"
FROM ProblemTickets pt

UNION ALL

-- 2. Assigned to Support Group
SELECT
  pt.id AS "ProblemRecordId",
  'Assigned to Support Group' AS "ActivityName",
  tme.created_at AS "EventTimestamp",
  'Zendesk' AS "SourceSystem",
  pt.updated_at AS "LastDataUpdate",
  pt.priority AS "Priority",
  pt.group_name AS "SupportGroup",
  pt.assignee_name AS "AssigneeName",
  pt.status AS "ProblemStatus",
  pt.related_incident_count AS "RelatedIncidentCount",
  pt.sla_due_date AS "SlaDueDate",
  pt.problem_category AS "ProblemCategory",
  pt.root_cause_category AS "RootCauseCategory"
FROM ticket_metric_events tme
JOIN ProblemTickets pt ON tme.ticket_id = pt.id
WHERE tme.type = 'group'

UNION ALL

-- 3. Investigation Commenced
SELECT
  pt.id AS "ProblemRecordId",
  'Investigation Commenced' AS "ActivityName",
  tme.created_at AS "EventTimestamp",
  'Zendesk' AS "SourceSystem",
  pt.updated_at AS "LastDataUpdate",
  pt.priority AS "Priority",
  pt.group_name AS "SupportGroup",
  pt.assignee_name AS "AssigneeName",
  'open' AS "ProblemStatus",
  pt.related_incident_count AS "RelatedIncidentCount",
  pt.sla_due_date AS "SlaDueDate",
  pt.problem_category AS "ProblemCategory",
  pt.root_cause_category AS "RootCauseCategory"
FROM ticket_metric_events tme
JOIN ProblemTickets pt ON tme.ticket_id = pt.id
WHERE tme.type = 'status' AND tme.value = 'open' AND tme.previous_value = 'new'

UNION ALL

-- 4. Workaround Published
SELECT
  pt.id AS "ProblemRecordId",
  'Workaround Published' AS "ActivityName",
  tme.created_at AS "EventTimestamp",
  'Zendesk' AS "SourceSystem",
  pt.updated_at AS "LastDataUpdate",
  pt.priority AS "Priority",
  pt.group_name AS "SupportGroup",
  pt.assignee_name AS "AssigneeName",
  pt.status AS "ProblemStatus",
  pt.related_incident_count AS "RelatedIncidentCount",
  pt.sla_due_date AS "SlaDueDate",
  pt.problem_category AS "ProblemCategory",
  pt.root_cause_category AS "RootCauseCategory"
FROM ticket_metric_events tme
JOIN ProblemTickets pt ON tme.ticket_id = pt.id
WHERE tme.type = 'custom_field' AND tme.field_name = '[Your ''Workaround Published'' custom field name]' AND tme.value IS NOT NULL -- Example: checkbox being checked or field being filled

UNION ALL

-- 5. Root Cause Identified
SELECT
  pt.id AS "ProblemRecordId",
  'Root Cause Identified' AS "ActivityName",
  tme.created_at AS "EventTimestamp",
  'Zendesk' AS "SourceSystem",
  pt.updated_at AS "LastDataUpdate",
  pt.priority AS "Priority",
  pt.group_name AS "SupportGroup",
  pt.assignee_name AS "AssigneeName",
  pt.status AS "ProblemStatus",
  pt.related_incident_count AS "RelatedIncidentCount",
  pt.sla_due_date AS "SlaDueDate",
  pt.problem_category AS "ProblemCategory",
  pt.root_cause_category AS "RootCauseCategory"
FROM ticket_metric_events tme
JOIN ProblemTickets pt ON tme.ticket_id = pt.id
WHERE tme.type = 'custom_field' AND tme.field_name = '[Your ''Root Cause Category'' custom field name]' AND tme.value IS NOT NULL

UNION ALL

-- 6. Change Request Initiated
SELECT
  pt.id AS "ProblemRecordId",
  'Change Request Initiated' AS "ActivityName",
  tme.created_at AS "EventTimestamp",
  'Zendesk' AS "SourceSystem",
  pt.updated_at AS "LastDataUpdate",
  pt.priority AS "Priority",
  pt.group_name AS "SupportGroup",
  pt.assignee_name AS "AssigneeName",
  pt.status AS "ProblemStatus",
  pt.related_incident_count AS "RelatedIncidentCount",
  pt.sla_due_date AS "SlaDueDate",
  pt.problem_category AS "ProblemCategory",
  pt.root_cause_category AS "RootCauseCategory"
FROM ticket_metric_events tme
JOIN ProblemTickets pt ON tme.ticket_id = pt.id
WHERE tme.type = 'custom_field' AND tme.field_name = '[Your ''Change Request ID'' custom field name]' AND tme.value IS NOT NULL

UNION ALL

-- 7. Permanent Fix Applied
SELECT
  pt.id AS "ProblemRecordId",
  'Permanent Fix Applied' AS "ActivityName",
  tme.created_at AS "EventTimestamp",
  'Zendesk' AS "SourceSystem",
  pt.updated_at AS "LastDataUpdate",
  pt.priority AS "Priority",
  pt.group_name AS "SupportGroup",
  pt.assignee_name AS "AssigneeName",
  pt.status AS "ProblemStatus",
  pt.related_incident_count AS "RelatedIncidentCount",
  pt.sla_due_date AS "SlaDueDate",
  pt.problem_category AS "ProblemCategory",
  pt.root_cause_category AS "RootCauseCategory"
FROM ticket_metric_events tme
JOIN ProblemTickets pt ON tme.ticket_id = pt.id
WHERE tme.type = 'custom_field' AND tme.field_name = '[Your ''Permanent Fix Applied'' custom field name]' AND tme.value IS NOT NULL -- Assumes a custom field indicates this status

UNION ALL

-- 8. Proposed Solution Drafted
SELECT
  pt.id AS "ProblemRecordId",
  'Proposed Solution Drafted' AS "ActivityName",
  tme.created_at AS "EventTimestamp",
  'Zendesk' AS "SourceSystem",
  pt.updated_at AS "LastDataUpdate",
  pt.priority AS "Priority",
  pt.group_name AS "SupportGroup",
  pt.assignee_name AS "AssigneeName",
  pt.status AS "ProblemStatus",
  pt.related_incident_count AS "RelatedIncidentCount",
  pt.sla_due_date AS "SlaDueDate",
  pt.problem_category AS "ProblemCategory",
  pt.root_cause_category AS "RootCauseCategory"
FROM ticket_metric_events tme
JOIN ProblemTickets pt ON tme.ticket_id = pt.id
WHERE tme.type = 'custom_field' AND tme.field_name = '[Your ''KB Article ID'' custom field name]' AND tme.value IS NOT NULL

UNION ALL

-- 9. Resolution Verified
SELECT
  pt.id AS "ProblemRecordId",
  'Resolution Verified' AS "ActivityName",
  tme.created_at AS "EventTimestamp",
  'Zendesk' AS "SourceSystem",
  pt.updated_at AS "LastDataUpdate",
  pt.priority AS "Priority",
  pt.group_name AS "SupportGroup",
  pt.assignee_name AS "AssigneeName",
  'solved' AS "ProblemStatus",
  pt.related_incident_count AS "RelatedIncidentCount",
  pt.sla_due_date AS "SlaDueDate",
  pt.problem_category AS "ProblemCategory",
  pt.root_cause_category AS "RootCauseCategory"
FROM ticket_metric_events tme
JOIN ProblemTickets pt ON tme.ticket_id = pt.id
WHERE tme.type = 'status' AND tme.value = 'solved'

UNION ALL

-- 10. Problem Investigation Reopened
SELECT
  pt.id AS "ProblemRecordId",
  'Problem Investigation Reopened' AS "ActivityName",
  tme.created_at AS "EventTimestamp",
  'Zendesk' AS "SourceSystem",
  pt.updated_at AS "LastDataUpdate",
  pt.priority AS "Priority",
  pt.group_name AS "SupportGroup",
  pt.assignee_name AS "AssigneeName",
  'open' AS "ProblemStatus",
  pt.related_incident_count AS "RelatedIncidentCount",
  pt.sla_due_date AS "SlaDueDate",
  pt.problem_category AS "ProblemCategory",
  pt.root_cause_category AS "RootCauseCategory"
FROM ticket_metric_events tme
JOIN ProblemTickets pt ON tme.ticket_id = pt.id
WHERE tme.type = 'status' AND tme.value = 'open' AND tme.previous_value IN ('pending', 'solved')

UNION ALL

-- 11. Post-Implementation Review Conducted
SELECT
  pt.id AS "ProblemRecordId",
  'Post-Implementation Review Conducted' AS "ActivityName",
  tme.created_at AS "EventTimestamp",
  'Zendesk' AS "SourceSystem",
  pt.updated_at AS "LastDataUpdate",
  pt.priority AS "Priority",
  pt.group_name AS "SupportGroup",
  pt.assignee_name AS "AssigneeName",
  pt.status AS "ProblemStatus",
  pt.related_incident_count AS "RelatedIncidentCount",
  pt.sla_due_date AS "SlaDueDate",
  pt.problem_category AS "ProblemCategory",
  pt.root_cause_category AS "RootCauseCategory"
FROM ticket_metric_events tme
JOIN ProblemTickets pt ON tme.ticket_id = pt.id
WHERE tme.type = 'custom_field' AND tme.field_name = '[Your ''Post-Implementation Review'' custom field name]' AND tme.value IS NOT NULL -- Assumes a checkbox or date field

UNION ALL

-- 12. Problem Record Closed
SELECT
  pt.id AS "ProblemRecordId",
  'Problem Record Closed' AS "ActivityName",
  tme.created_at AS "EventTimestamp",
  'Zendesk' AS "SourceSystem",
  pt.updated_at AS "LastDataUpdate",
  pt.priority AS "Priority",
  pt.group_name AS "SupportGroup",
  pt.assignee_name AS "AssigneeName",
  'closed' AS "ProblemStatus",
  pt.related_incident_count AS "RelatedIncidentCount",
  pt.sla_due_date AS "SlaDueDate",
  pt.problem_category AS "ProblemCategory",
  pt.root_cause_category AS "RootCauseCategory"
FROM ticket_metric_events tme
JOIN ProblemTickets pt ON tme.ticket_id = pt.id
WHERE tme.type = 'status' AND tme.value = 'closed' AND tme.previous_value = 'solved';

ステップ

前提条件: システムにPython 3.6+がインストールされていることを確認してください。ターミナルまたはコマンドプロンプトでpip install requests pandasを実行し、必要なrequestsおよびpandasライブラリをインストールしてください。
Zendesk APIトークンの生成: 管理者としてZendesk Supportにログインします。管理センター > アプリと連携 > API > Zendesk APIに移動します。トークンアクセスセクションで「APIトークンを追加」をクリックして新しいトークンを作成します。このトークンはすぐにコピーして安全に保管してください。再度表示されることはありません。
Pythonスクリプトの設定: 新しいPythonファイル（例: extract_zendesk_problems.py）を作成し、Queryセクションに提供されている完全なスクリプトをこのファイルにコピーします。スクリプトの冒頭にあるプレースホルダー変数: ZENDESK_SUBDOMAIN、ZENDESK_EMAIL、ZENDESK_API_TOKEN、およびSTART_TIMEを更新します。初回実行の場合、START_TIMEを抽出希望開始日のUnixタイムスタンプに設定します。
カスタムフィールドIDのマッピング: 問題管理プロセスで使用されているカスタムフィールドの数値IDを特定します。これらは、管理センター > オブジェクトとルール > チケット > フィールドに移動し、URLまたはフィールドプロパティを検査することで見つけることができます。スクリプト内のCUSTOM_FIELD_MAPPING辞書を、ご自身の特定のIDで更新してください。
スクリプトの実行: ターミナルからpython extract_zendesk_problems.pyコマンドを使用してスクリプトを実行します。スクリプトはZendesk Incremental Export APIからデータの取得を開始します。
実行の監視: スクリプトは、処理されたチケットの数や現在取得しているタイムスタンプなど、進行状況を出力します。必要に応じて一時停止することで、APIレート制限を自動的に処理します。
データ取得と変換: スクリプトはまず、START_TIME以降に作成または更新されたすべての問題チケットを取得します。次に、各問題チケットについて、すべての履歴変更を含む完全な監査証跡を取得します。
イベントログの生成: スクリプトは、各監査イベントを処理し、フィールドの変更（ステータス、グループ、またはカスタムフィールドの更新など）を定義されたビジネスアクティビティにマッピングします。また、ユーザー名とグループ名を取得してキャッシュし、データを充実させます。
増分ロードの処理: 初回の一括ロード後、それ以降の実行では、START_TIME変数を前回の成功した実行の最後に表示されたend_timeに更新します。これにより、重複することなく新規および更新されたデータのみを取得できます。
出力の確認: スクリプトが完了すると、同じディレクトリにzendesk_problem_event_log.csvという名前のファイルが生成されます。このCSVファイルには、分析準備が整った構造化されたイベントログが含まれています。
アップロードの準備: スプレッドシートツールでCSVファイルを開き、その内容を確認します。ProcessMindにアップロードする前に、必要なすべての列（ProblemRecordId、ActivityName、EventTimestamp、SourceSystem、LastDataUpdate）が存在し、正しく入力されていることを確認してください。

設定

Zendesk API認証情報: スクリプトには、Zendeskサブドメイン、APIトークンに関連付けられたユーザーのメールアドレス、および認証用のAPIトークン自体が必要です。
開始時間: START_TIME変数は、データ抽出の開始点を定義するUnixエポックタイムスタンプです。初回実行時には、過去の日付（例：6ヶ月前）に設定して履歴データを取得します。以降の実行では、前回の実行の終了時間を使用してデータを増分的に取得します。
カスタムフィールドマッピング: CUSTOM_FIELD_MAPPING辞書は非常に重要です。「回避策公開済み」や「根本原因特定済み」などのアクティビティを正確にキャプチャするには、プレースホルダーIDをZendeskインスタンスの実際のカスタムフィールドIDで更新する必要があります。
チケットタイプフィルター: スクリプトは、typeが'problem'であるチケットのみを処理するようにハードコーディングされています。これにより、インシデント、タスク、質問が問題管理イベントログから除外されます。
APIレート制限: スクリプトには、429 'Too Many Requests'エラーを処理するための基本的なtime.sleep(60)関数が含まれています。この一時停止期間は、Zendeskプランと抽出されるデータの量に応じて調整が必要になる場合があります。
前提条件: スクリプトを実行するには、requestsおよびpandasライブラリがインストールされたPython 3環境が必要です。APIトークンは、チケットデータを読み取る権限を持つアカウントに関連付けられている必要があります。

a クエリ例 python

import requests
import pandas as pd
import time
import json
from datetime import datetime

class=class="hl-string">"hl-comment"># --- CONFIGURATION --- 
class=class="hl-string">"hl-comment"># Replace with your Zendesk subdomain, email, and API token
ZENDESK_SUBDOMAIN = class="hl-string">'[your_subdomain]'
ZENDESK_EMAIL = class="hl-string">'[your_email@example.com]'
ZENDESK_API_TOKEN = class="hl-string">'[your_zendesk_api_token]'

class=class="hl-string">"hl-comment"># Start time for the incremental export (Unix epoch timestamp)
class=class="hl-string">"hl-comment"># Example: 1641013200 is for Jan 1, 2022 00:00:00 GMT
START_TIME = 1641013200

class=class="hl-string">"hl-comment"># Map your custom field IDs to the corresponding activity names
class=class="hl-string">"hl-comment"># Find IDs in Admin Center > Objects and rules > Tickets > Fields
CUSTOM_FIELD_MAPPING = {
    class="hl-string">'[Your Workaround Published Field ID]': class="hl-string">'Workaround Published',
    class="hl-string">'[Your Root Cause Identified Field ID]': class="hl-string">'Root Cause Identified',
    class="hl-string">'[Your Change Request Initiated Field ID]': class="hl-string">'Change Request Initiated',
    class="hl-string">'[Your Permanent Fix Applied Field ID]': class="hl-string">'Permanent Fix Applied',
    class="hl-string">'[Your Proposed Solution Drafted Field ID]': class="hl-string">'Proposed Solution Drafted',
    class="hl-string">'[Your Post-Implementation Review Field ID]': class="hl-string">'Post-Implementation Review Conducted'
}

class=class="hl-string">"hl-comment"># --- SCRIPT --- 
BASE_URL = fclass="hl-string">'https://{ZENDESK_SUBDOMAIN}.zendesk.com/api/v2'
API_USER = fclass="hl-string">'{ZENDESK_EMAIL}/token'

class=class="hl-string">"hl-comment"># Caching for user and group lookups to reduce API calls
user_cache = {}
group_cache = {}

session = requests.Session()
session.auth = (API_USER, ZENDESK_API_TOKEN)

def get_user_name(user_id):
    if not user_id: return None
    if user_id in user_cache:
        return user_cache[user_id]
    try:
        response = session.get(fclass="hl-string">'{BASE_URL}/users/{user_id}.json')
        response.raise_for_status()
        user_cache[user_id] = response.json()[class="hl-string">'user'][class="hl-string">'name']
        return user_cache[user_id]
    except requests.exceptions.RequestException:
        return str(user_id) class=class="hl-string">"hl-comment"># Return ID if lookup fails

def get_group_name(group_id):
    if not group_id: return None
    if group_id in group_cache:
        return group_cache[group_id]
    try:
        response = session.get(fclass="hl-string">'{BASE_URL}/groups/{group_id}.json')
        response.raise_for_status()
        group_cache[group_id] = response.json()[class="hl-string">'group'][class="hl-string">'name']
        return group_cache[group_id]
    except requests.exceptions.RequestException:
        return str(group_id) class=class="hl-string">"hl-comment"># Return ID if lookup fails

def fetch_tickets(start_time):
    tickets_url = fclass="hl-string">'{BASE_URL}/incremental/tickets.json'
    params = {class="hl-string">'start_time': start_time, class="hl-string">'include': class="hl-string">'metric_sets'}
    all_tickets = []
    while tickets_url:
        try:
            print(fclass="hl-string">"Fetching from: {tickets_url}")
            response = session.get(tickets_url, params=params)
            class=class="hl-string">"hl-comment"># params are only needed for the first request
            params = {}
            if response.status_code == 429:
                print(class="hl-string">"Rate limit reached. Waiting for 60 seconds.")
                time.sleep(60)
                continue
            response.raise_for_status()
            data = response.json()
            all_tickets.extend(data.get(class="hl-string">'tickets', []))
            tickets_url = data.get(class="hl-string">'next_page')
            if not data.get(class="hl-string">'end_of_stream', True):
                 class=class="hl-string">"hl-comment"># Wait a moment before the next page request to be safe
                 time.sleep(1)
            else:
                print(fclass="hl-string">"End of stream reached. Final timestamp: {data.get('end_time')}")
                tickets_url = None
        except requests.exceptions.RequestException as e:
            print(fclass="hl-string">"Error fetching tickets: {e}")
            break
    return all_tickets

def process_ticket_audits(ticket, event_log):
    ticket_id = ticket[class="hl-string">'id']
    audits_url = fclass="hl-string">'{BASE_URL}/tickets/{ticket_id}/audits.json'
    try:
        response = session.get(audits_url)
        response.raise_for_status()
        audits = response.json().get(class="hl-string">'audits', [])
    except requests.exceptions.RequestException as e:
        print(fclass="hl-string">"Error fetching audits for ticket {ticket_id}: {e}")
        return

    base_attributes = {
        class="hl-string">'ProblemRecordId': ticket_id,
        class="hl-string">'SourceSystem': class="hl-string">'Zendesk Support',
        class="hl-string">'LastDataUpdate': ticket[class="hl-string">'updated_at'],
        class="hl-string">'Priority': ticket.get(class="hl-string">'priority'),
        class="hl-string">'RelatedIncidentCount': ticket.get(class="hl-string">'metric_set', {}).get(class="hl-string">'replies', 0), class=class="hl-string">"hl-comment"># Using replies as a proxy if incident_count is not available
        class="hl-string">'SlaDueDate': ticket.get(class="hl-string">'due_at'),
        class="hl-string">'ProblemCategory': next((f[class="hl-string">'value'] for f in ticket.get(class="hl-string">'custom_fields', []) if f.get(class="hl-string">'id') == class="hl-string">'[Your Problem Category Field ID]'), None)
    }

    class=class="hl-string">"hl-comment"># 1. Problem Record Logged
    event_log.append({
        **base_attributes,
        class="hl-string">'ActivityName': class="hl-string">'Problem Record Logged',
        class="hl-string">'EventTimestamp': ticket[class="hl-string">'created_at'],
        class="hl-string">'SupportGroup': get_group_name(ticket.get(class="hl-string">'group_id')),
        class="hl-string">'AssigneeName': get_user_name(ticket.get(class="hl-string">'assignee_id')),
        class="hl-string">'ProblemStatus': class="hl-string">'new',
        class="hl-string">'RootCauseCategory': None
    })

    class=class="hl-string">"hl-comment"># Process audit trail for other activities
    for audit in audits:
        audit_ts = audit[class="hl-string">'created_at']
        for event in audit.get(class="hl-string">'events', []):
            activity_name = None
            field_name = event.get(class="hl-string">'field_name')
            value = event.get(class="hl-string">'value')
            previous_value = event.get(class="hl-string">'previous_value')

            class=class="hl-string">"hl-comment"># 2. Assigned to Support Group
            if field_name == class="hl-string">'group_id' and value is not None:
                activity_name = class="hl-string">'Assigned to Support Group'
            
            class=class="hl-string">"hl-comment"># 3. Investigation Commenced (New -> Open)
            elif field_name == class="hl-string">'status' and value == class="hl-string">'open' and previous_value == class="hl-string">'new':
                activity_name = class="hl-string">'Investigation Commenced'

            class=class="hl-string">"hl-comment"># 4-9. Activities from Custom Fields
            elif str(field_name) in CUSTOM_FIELD_MAPPING and value is not None and value not in [False, class="hl-string">'0', class="hl-string">'']:
                activity_name = CUSTOM_FIELD_MAPPING[str(field_name)]

            class=class="hl-string">"hl-comment"># 10. Resolution Verified (Any -> Solved)
            elif field_name == class="hl-string">'status' and value == class="hl-string">'solved':
                activity_name = class="hl-string">'Resolution Verified'
            
            class=class="hl-string">"hl-comment"># 11. Problem Investigation Reopened (Solved/Closed -> Open)
            elif field_name == class="hl-string">'status' and value == class="hl-string">'open' and previous_value in [class="hl-string">'solved', class="hl-string">'closed']:
                activity_name = class="hl-string">'Problem Investigation Reopened'

            class=class="hl-string">"hl-comment"># 12. Problem Record Closed (Any -> Closed)
            elif field_name == class="hl-string">'status' and value == class="hl-string">'closed':
                activity_name = class="hl-string">'Problem Record Closed'

            if activity_name:
                class=class="hl-string">"hl-comment"># Find the state of attributes at the time of the event
                temp_status = value if field_name == class="hl-string">'status' else None
                temp_group = get_group_name(value) if field_name == class="hl-string">'group_id' else None
                temp_assignee = get_user_name(value) if field_name == class="hl-string">'assignee_id' else None
                temp_root_cause = value if str(field_name) == class="hl-string">'[Your Root Cause Category Field ID]' else None

                event_log.append({
                    **base_attributes,
                    class="hl-string">'ActivityName': activity_name,
                    class="hl-string">'EventTimestamp': audit_ts,
                    class="hl-string">'SupportGroup': temp_group,
                    class="hl-string">'AssigneeName': temp_assignee,
                    class="hl-string">'ProblemStatus': temp_status,
                    class="hl-string">'RootCauseCategory': temp_root_cause
                })

def main():
    print(class="hl-string">"Starting Zendesk Problem ticket extraction...")
    tickets = fetch_tickets(START_TIME)
    problem_tickets = [t for t in tickets if t.get(class="hl-string">'type') == class="hl-string">'problem']
    print(fclass="hl-string">"Found {len(problem_tickets)} problem tickets to process.")

    event_log_data = []
    for i, ticket in enumerate(problem_tickets):
        print(fclass="hl-string">"Processing ticket {i+1}/{len(problem_tickets)}: ID {ticket['id']}")
        process_ticket_audits(ticket, event_log_data)

    if not event_log_data:
        print(class="hl-string">"No events were generated. Exiting.")
        return

    df = pd.DataFrame(event_log_data)

    class=class="hl-string">"hl-comment"># Post-processing to fill forward null values for state attributes
    df = df.sort_values(by=[class="hl-string">'ProblemRecordId', class="hl-string">'EventTimestamp']).reset_index(drop=True)
    df[class="hl-string">'SupportGroup'] = df.groupby(class="hl-string">'ProblemRecordId')[class="hl-string">'SupportGroup'].fillna(method=class="hl-string">'ffill')
    df[class="hl-string">'AssigneeName'] = df.groupby(class="hl-string">'ProblemRecordId')[class="hl-string">'AssigneeName'].fillna(method=class="hl-string">'ffill')
    df[class="hl-string">'ProblemStatus'] = df.groupby(class="hl-string">'ProblemRecordId')[class="hl-string">'ProblemStatus'].fillna(method=class="hl-string">'ffill')
    df[class="hl-string">'RootCauseCategory'] = df.groupby(class="hl-string">'ProblemRecordId')[class="hl-string">'RootCauseCategory'].fillna(method=class="hl-string">'ffill')

    class=class="hl-string">"hl-comment"># Define column order
    column_order = [
        class="hl-string">'ProblemRecordId', class="hl-string">'ActivityName', class="hl-string">'EventTimestamp', class="hl-string">'SourceSystem', class="hl-string">'LastDataUpdate',
        class="hl-string">'Priority', class="hl-string">'SupportGroup', class="hl-string">'AssigneeName', class="hl-string">'ProblemStatus', class="hl-string">'RelatedIncidentCount',
        class="hl-string">'SlaDueDate', class="hl-string">'ProblemCategory', class="hl-string">'RootCauseCategory'
    ]
    df = df[column_order]

    output_filename = class="hl-string">'zendesk_problem_event_log.csv'
    df.to_csv(output_filename, index=False, date_format=class="hl-string">'%Y-%m-%dT%H:%M:%SZ')
    print(fclass="hl-string">"Extraction complete. Event log saved to {output_filename}")

if __name__ == class="hl-string">'__main__':
    main()

問題管理データテンプレート

問題管理データテンプレート

問題管理属性

問題管理アクティビティ

抽出ガイド

Zendesk Explore更新履歴エクスポート

ステップ

設定

a クエリ例 config

Zendeskデータ共有経由でのSQLクエリ

ステップ

設定

a クエリ例 sql

Incremental Export APIを使用したPythonによる抽出

ステップ

設定

a クエリ例 python

今すぐ始めますか？

IT修正を加速するための問題管理の最適化

問題管理データテンプレート

問題管理データテンプレート

問題管理属性

問題管理アクティビティ

抽出ガイド

Zendesk Explore更新履歴エクスポート

ステップ

設定

a クエリ例 config

Zendeskデータ共有経由でのSQLクエリ

ステップ

設定

a クエリ例 sql

Incremental Export APIを使用したPythonによる抽出

ステップ

設定

a クエリ例 python

お客様のプライバシーを大切にしています

今すぐ始めますか？

IT修正を加速するための問題管理の最適化