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

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

Zendesk Support

問題管理の属性 (19) 問題管理のアクティビティ (12) 抽出ガイド (3)

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

このテンプレートは、Zendesk Support内の問題管理ライフサイクルをマッピングするための詳細な枠組みを提供します。根本原因分析におけるボトルネックを特定するために必要な属性、プロセス上の節目、データ抽出ロジックを整理しています。この構成に従うことで、プロセスをより深く分析するための高品質なイベントログを作成できます。

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

イベントログを初めて扱いますか。学ぶプロセスマイニングのイベントログを作成する方法.

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

問題管理の属性

チケットのカテゴリ、優先度、担当を問題解決ライフサイクル全体で分析するために必要なコンテキストを提供する、推奨データ項目です。

5 必須 8 推奨 6 任意

	名前	説明
	アクティビティ ActivityName	問題レコードに対して実行されたイベントまたはアクションの名前です。
説明この属性は、問題レコードのライフサイクル中に実行された具体的な手順またはアクションを取得します。例として、「Open」から「Pending」へのステータス変更、割り当て変更、「Workaround Published」などの特定のワークフロー手順があります。分析では、プロセスマップのノードを形成します。これらのアクティビティの順序により、分析担当者は作業の流れを可視化し、ボトルネックを特定し、プロセス手順間の所要時間を測定できます。重要な理由プロセスの「何を」にあたる情報を定義し、プロセスフローの可視化とバリアント分析を可能にします。入手先 Zendesk Ticket AuditsまたはTicket Metricsから導出例問題レコードを記録調査を開始回避策を公開
	ソースシステム SourceSystem	データの取得元となるシステムの名前です。
説明この属性は、プロセスデータを抽出したソフトウェアプラットフォームを識別します。この場合は常に「Zendesk Support」が入力されます。特にZendeskやJiraなど複数のシステムからデータを統合する分析では、この項目によって取得元ごとにデータを絞り込んだり、グループ化したりできます。複数システムにまたがるプロセスビューで、データの系譜と追跡可能性を確保します。重要な理由データの系譜を確保し、複数システムのプロセスマイニング設定を支えます。入手先抽出時に固定値を設定例 Zendesk Support
	最終データ更新 LastDataUpdate	問題レコードが最後に変更された日時を示すタイムスタンプです。
説明この属性は、ソースシステムで問題レコードのデータが最後に更新された時刻を示します。イベントのタイムスタンプとは異なり、アクティビティ単位ではなくレコード単位の時刻を表します。分析では、データが最新かどうかを判断するのに役立ちます。データセットが最新の状態か、ソースシステムとプロセスマイニング環境の間に同期遅延があるかを特定するために使用します。重要な理由データの鮮度を追跡し、増分データ読み込みの方針策定を支援します。入手先 Zendesk Ticketオブジェクトの「updated_at」項目例 2023-11-01T14:20:00Z
	問題レコード ProblemRecordId	Zendeskの問題チケットに割り当てられた一意の数値識別子です。
説明この属性は、Zendesk Supportシステム内で問題レコードを一意に識別するキーです。プロセスマイニングにおける中心的なCase IDとして機能し、その後のすべてのイベント、更新、やり取りを1つのプロセスインスタンスにまとめられます。分析では、このIDを使って、作成からクローズまでの各問題調査の経過を一意に識別します。関連するインシデントを関連付け、さまざまなサポート階層を通過する問題のライフサイクルを追跡できます。重要な理由プロセスマイニング分析でイベントをケースにまとめるために必要な、基本的かつ必須のキーです。入手先 Zendesk Ticketオブジェクトの「id」項目（typeが「problem」のもの）例 1045293849921
	開始時刻 EventTimestamp	アクティビティが発生した具体的な日時です。
説明この属性は、Zendeskシステム内でアクティビティが発生した正確な時刻を記録します。イベントを正しい順序に並べ、手順間の期間を計算するために必要な時間情報を提供します。分析では、サイクルタイムの計算、遅延の特定、SLAコンプライアンスの確認、時間経過に伴うプロセスの可視化に欠かせません。正確なタイムスタンプがなければ、問題解決プロセスの進行速度を把握できません。重要な理由アクティビティの並べ替えと、時間に基づくすべてのKPIの計算を可能にします。入手先 Zendesk Ticket Auditsの「created_at」項目例 2023-10-12T08:30:00Z2023-10-12T09:15:22Z
	SLA期限 SlaDueDate	問題を解決する目標日時です。
説明この属性は、サービスレベル合意書の設定に基づく解決期限を示します。通常は、優先度とチケットの作成時刻を基に算出します。分析では、実際の解決時刻と比較して「問題SLA遵守率」を算出します。「SLAパフォーマンスとリスク」ダッシュボードでは、割り当てられた時間が近づいているケースや超過したケースを明らかにします。重要な理由コンプライアンスと契約上のパフォーマンスを測定するうえで欠かせません。入手先 Zendesk Ticket MetricsまたはSLA Policiesエンドポイント例 2023-12-01T17:00:00Z
	サポートグループ SupportGroup	現在、問題レコードを担当しているチームまたは部門です。
説明この属性は、ある時点で問題を担当する担当者グループを識別します。チケットがあるチームから別のチームへ引き継がれると、値が変わります。分析では、「Support Group Handover Analysis」ダッシュボードに欠かせません。チームごとのパフォーマンスを測定し、引き継ぎ時のボトルネックを特定し、リソース負荷の分布を分析できます。重要な理由組織の分析と、部門間のボトルネックの特定を可能にします。入手先 Zendesk Ticketオブジェクトの「group_id」項目（名前に解決済み）例レベル2サポートデータベースチームネットワーク運用
	優先度 Priority	問題レコードに割り当てられた緊急度です。
説明この属性は、問題の相対的な重要度を示し、通常はLow、Normal、High、Urgentに分類されます。期待されるサービスレベル合意（SLA）とリソース配分を決定します。分析では、プロセスを区分し、緊急度ごとにパフォーマンスを比較するために使用します。たとえば、「Root Cause Investigation Velocity」ダッシュボードで求められるとおり、「Urgent」の問題が「Low」の問題より速く解決されているかを確認できます。重要な理由 SLA遵守状況とリソースの優先順位を分析するため、ケースを区分するうえで欠かせません。入手先 Zendesk Ticketオブジェクトの「priority」項目例緊急高通常低
	問題カテゴリー ProblemCategory	問題の分類です（例：Software、Hardware、Network）。
説明この属性は、影響を受けたサービスまたはテクノロジースタックに基づいて問題を分類します。通常は、Zendeskフォームに設定されたカスタムドロップダウンフィールドです。分析では、「問題カテゴリー分類精度」ダッシュボードに使用します。初期カテゴリーと最終的な根本原因を比較することで、初期トリアージによって問題が適切なチームへ正しく振り分けられているかを確認できます。重要な理由テクノロジーまたは業務サービス別にセグメント化できます。入手先 Zendesk Ticketカスタムフィールド例データベースUI／UXネットワークインフラストラクチャ
	問題ステータス ProblemStatus	ライフサイクルにおける問題レコードの現在の状態です。
説明この属性は、New、Open、Pending、Solved、Closedなど、問題の現在のステータスを示します。調査の進捗状況を反映します。分析では、オープンケースとクローズドケースを絞り込むために使用します。「滞留問題レコード監視」ダッシュボードでは、アクティブなケースのうち、想定されるステータスのライフサイクルに沿って進んでいないケースを特定するために欠かせません。重要な理由完了状態に基づいてケースを絞り込めます。入手先 Zendesk Ticketオブジェクト、フィールド「status」例新規オープン保留中解決済みクローズ
	担当者名 AssigneeName	問題への対応を割り当てられた特定の担当者です。
説明この属性には、現在問題レコードを担当している個人ユーザーの名前が含まれます。誰が特定のアクションを実行したかを詳細に把握できます。分析では、個人ごとの作業負荷とパフォーマンスを理解するのに役立ちます。グループ単位の分析が一般的ですが、担当者単位のデータから、トレーニングが必要な担当者や、複雑な根本原因の解決に特に優れた担当者を特定できます。重要な理由個人単位でのリソース分析を可能にします。入手先 Zendesk Ticketオブジェクト、フィールド「assignee_id」（名前に解決済み）例 John DoeJane Smithシステム
	根本原因カテゴリー RootCauseCategory	特定された問題の根本原因です（例：Code Defect、Config Error）。
説明この属性には、問題を引き起こした原因の最終診断結果を記録します。通常は「Root Cause Identified」アクティビティの実行時に入力します。分析では、「問題カテゴリー分類精度」レポートの作成や、システム障害の傾向分析に使用します。コード品質、インフラストラクチャの安定性、ベンダー管理のどこに注力すべきかを、管理者が判断するために役立ちます。重要な理由障害パターンの分析を可能にし、長期的な改善活動の方向性を示します。入手先 Zendesk Ticketカスタムフィールド例ソフトウェアのバグ設定エラーユーザーエラー
	関連インシデント数 RelatedIncidentCount	この問題レコードにリンクされたインシデントチケットの数です。
説明この属性は、この問題レコードに関連付けられた個々のインシデントチケットの数を示します。Zendeskでは、インシデントチケットの「problem_id」フィールドを通じて、このレコードとの関連付けを管理します。分析では、「インシデントの関連付けと影響」を測る主要な指標です。最も多くのユーザーに影響している問題の優先順位付けに役立ち、チケット数の削減という観点で最も高いROIが見込める修正を判断するための戦略的な意思決定を支援します。重要な理由問題の規模とユーザーへの影響を示します。入手先 Zendesk Tickets API、type='incident'かつproblem_id=ThisIDであるチケットの件数例 015342
	PIRの有無 HasPostImplementationReview	実装後レビューが実施されたかどうかを示します。
説明この属性は、問題解決プロセスにレビュー段階が含まれていたかどうかを示します。ケース履歴に「Post-Implementation Review Conducted」アクティビティが存在するかを確認して算出します。分析では、「実装後レビュー実施率」ダッシュボードを支援します。組織が重大な問題から学びを得ているかを確認するコンプライアンス指標です。重要な理由継続的改善プロセスへのコンプライアンスを検証します。入手先「Post-Implementation Review Conducted」アクティビティの有無から算出例 truefalse
	ナレッジ記事ID KnowledgeArticleId	問題に対して作成またはリンクされたナレッジベース記事のIDです。
説明この属性には、Zendesk Guideの記事または外部のナレッジ項目への参照を保存します。問題から得られた知識が記録されていることを示します。分析では、このフィールドの有無を使って「ナレッジベース統合率」を算出します。将来参照できるように解決策を文書化し、組織が学習サイクルを完了させているかを確認できます。重要な理由ナレッジマネジメントプロセスの有効性を測定します。入手先 Zendesk Ticketカスタムフィールドまたはリンク済みコンテンツ例 360045889KB-2991
	問題の件名 ProblemSubject	問題レコードの短い概要またはタイトルです。
説明この属性には、問題の作成時に入力された概要テキストが含まれます。通常は、調査対象となる症状や問題を説明します。分析では、特定のケースを詳しく調べる際に、分析担当者へ背景情報を提供します。ここにテキストマイニング手法を適用すると、類似する問題をクラスタリングしたり、構造化されたカテゴリーフィールドでは捉えられない繰り返し発生するトピックを特定したりできます。重要な理由個々のケースについて、人が読みやすい背景情報を提供します。入手先 Zendesk Ticketオブジェクト、フィールド「subject」例 EU地域で決済を処理できないログインサーバーの遅延急増管理者ユーザーのデータエクスポート失敗
	回避策の有効状態 WorkaroundActive	回避策が提供または公開されたかどうかを示すフラグです。
説明このブール型属性は、問題に対する一時的な修正が文書化されているかどうかを示します。通常は、「Workaround Published」アクティビティの有無、またはフォーム上の特定のチェックボックスから判定します。分析では、「回避策公開コンプライアンス」ダッシュボードに使用します。長期的な調査を続ける間に、サポートチームがユーザーへどの程度速やかに暫定対応を提供しているかを測定します。重要な理由調査中のユーザー影響の緩和を測定するうえで重要です。入手先「Workaround Published」アクティビティまたはカスタムフィールドの有無から算出例 truefalse
	変更要求ID ChangeRequestId	修正を実施するためにリンクされた変更要求の識別子です。
説明この属性は、問題レコードを変更管理レコード（別のシステムまたは別のチケット種別に存在する場合があります）にリンクします。正式な変更プロセスが開始されたことを示します。分析では、「変更要求開始率」ダッシュボードを支援します。診断から実装への移行を追跡し、特定された根本原因が正式な変更アクションにつながっていることを確認できます。重要な理由問題プロセスと変更管理プロセスをリンクします。入手先 Zendesk Ticketカスタムフィールドまたはリンク済みチケット例 CR-1002CHG00394
	滞留状態 IsStale	14日を超えてアクティビティがない問題を示します。
説明この計算属性は、最近更新されていないレコードを特定します。現在日（または分析日）と最終アクティビティのタイムスタンプを比較します。分析では、「滞留問題レコード監視」ダッシュボードに使用します。バックログを圧迫している放置ケースを管理者がすばやく特定し、管理上のクローズや再割り当てが必要なケースを把握できます。重要な理由プロセス上の無駄や放置された作業項目の特定に役立ちます。入手先 Process Miningツールで算出：（Now - LastDataUpdate）> 14日例 truefalse

必須推奨任意

問題管理のアクティビティ

初期の問題特定から恒久対策の実施まで、エンドツーエンドのフローを可視化するため、これらの重要なプロセス手順とステータス変更を記録します。

8 推奨 4 任意

	アクティビティ	説明
	サポートグループに割り当て	問題レコードを特定の技術チームまたは部門に振り分けることです。チケットのGroup ID項目が更新された時点で追跡します。
重要な理由 Support Group Handover Analysisダッシュボードで、部門間の待機時間を測定するために欠かせません。入手先チケット監査ログで「group_id」項目の変更を監視します。取得 Group Assignment Changeトランザクションの実行時に記録イベントタイプ explicit
	問題レコードをクローズ	チケットがロックされ、それ以上変更できなくなるライフサイクル上の最終イベントです。Zendeskでは通常、Solved状態になってから4日後に自動的に発生します。
重要な理由レコードの存続期間の完全な終了を示し、データ保持と履歴レポートに使用します。入手先チケットのステータスが「Closed」に変更されたことから導出します。取得ステータスがClosedに変更された時点で記録イベントタイプ explicit
	問題レコードを記録	Zendesk Support内で問題チケットを最初に作成することです。このイベントは、問題が初めてシステムに記録された時刻を取得し、通常はプロセスインスタンスを開始します。
重要な理由 End To Endの解決サイクルの開始時刻を定め、その後のすべてのリードタイム指標の基準になります。入手先チケットオブジェクトの「created_at」タイムスタンプ、またはチケット監査ログの最初のエントリから取得します。取得 Ticket Createdトランザクションの実行時に記録イベントタイプ explicit
	回避策を公開	問題に対する一時的な修正を文書化し、共有するアクションです。Zendeskでは、回避策が利用可能であることを示す特定のタグやカスタムチェックボックス項目で取得することがよくあります。
重要な理由 Workaround Publication Complianceダッシュボードを支え、長期にわたる調査中もユーザーに一時的な対処を提供できるようにします。入手先「workaround_published」タグの追加、または「Workaround」という名前のカスタムブール項目の変更を監視します。取得カスタム項目またはタグの値を比較イベントタイプ inferred
	恒久的な修正を適用	技術的な解決策が環境に展開されたことを示します。通常は、チケットが完全に解決される前のカスタムステータス遷移や特定のタグで追跡します。
重要な理由 Fix Implementation Efficiencyダッシュボードで、診断から展開までの時間を測定するために欠かせません。入手先特定のタグ（例：「fix_deployed」）または存在する場合はカスタムステータス項目から推定します。取得タグまたはカスタムステータスのドロップダウンを監視イベントタイプ inferred
	根本原因を特定	問題の根本的な原因が判明した時点です。通常は、担当者がカスタムの「Root Cause」テキスト項目またはドロップダウンカテゴリーに値を入力した時点で取得します。
重要な理由 Root Cause Investigation Velocityダッシュボードにおける重要なマイルストーンであり、診断効率の測定にも使用します。入手先「Root Cause」、「RCA」、「Problem Source」と表示されたカスタム項目が、空でない値に変更されたことを監視します。取得入力状況を確認するため、カスタム項目の値を比較イベントタイプ inferred
	解決を検証	問題をSolvedとして正式に記録することです。Zendeskでは、標準システムステータスが「Solved」に設定された時点で発生し、修正が検証され、ケースが完了したことを示します。
重要な理由 SLA Performance and Riskの計算およびProblem SLA Adherence Rateにおける主要な終点です。入手先チケットのステータスが「Solved」に変更されたことから導出します。取得ステータスがSolvedに変更された時点で記録イベントタイプ explicit
	調査を開始	受動的な「New」状態から、対応中のアクティブな状態へ移行したことを示します。担当者が問題を認識し、診断を開始したことを意味します。
重要な理由 Stale Problem Record指標の算出に使用し、Average Root Cause Analysis Duration KPIの起点になります。入手先チケットのステータスが「New」から「Open」または「Pending」に変更された時点から推定します。取得変更前後のステータス項目を比較イベントタイプ inferred
	問題調査を再開	Solvedとして記録された問題レコードが、Openまたは対応中の状態に戻されたときに発生します。修正の失敗または解決策の却下を示します。
重要な理由 Problem Re-opening Rate KPIを支え、解決プロセスの品質上の問題を特定するのに役立ちます。入手先ステータスが「Solved」から「Open」、「New」、または「Pending」に戻った時点から推定します。取得変更前後のステータス項目を比較イベントタイプ inferred
	変更リクエストを開始	問題を修正するための正式な変更管理プロセスが開始されたことを示します。通常は、「Change Request ID」カスタム項目への入力、または「Change」タイプのチケットのリンクから推定します。
重要な理由 Change Request Initiation Rateを追跡し、問題管理と変更管理のワークフローを結び付けます。入手先「change_reference」などのカスタム項目の更新、または「problem_change」リンクタイプの作成を監視します。取得外部IDの入力についてカスタム項目を監視イベントタイプ inferred
	実装後レビューを実施	修正後に振り返りレビューが完了したことを確認します。通常は、プロセスコーディネーターがチェックボックスまたは日付項目を更新します。
重要な理由品質基準へのコンプライアンスを確保するため、Post-Implementation Review Frequency KPIに必要です。入手先カスタムチェックボックス「PIR Completed」または日付項目「PIR Date」の更新を監視します。取得完了状況についてカスタム項目を監視イベントタイプ inferred
	提案された解決策を草案化	問題調査に基づいてナレッジベース記事を作成することです。Zendesk Knowledge Captureアプリの使用、または新しい記事のリンクから推定します。
重要な理由 Knowledge Base Integration Rate KPIを支え、組織の学習を促します。入手先「Knowledge Capture」連携に関連するイベント、または「kcs_draft」などのタグを監視します。取得特定のシステムタグまたはリンクイベントから導出イベントタイプ inferred

推奨任意

抽出ガイド

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

ステップ

Zendeskのインスタンスにログインし、製品トレイからExploreのレポート画面に移動します。
Queriesフォルダー（新しいバージョンではReports）をクリックし、New queryを選択します。
データセットの選択を求められたら、Support、Updates History、Support: Updates History [default]の順に選択します。このデータセットには、現在の状態データだけでなく、プロセスマイニングに必要なイベントログが含まれています。
MetricsパネルでCount (Tickets)またはCount (Updates)を追加し、データが取得されていることを確認します。
FiltersパネルでTicket > Ticket typeのフィルターを追加し、Problemを選択してProblem Managementプロセスに限定します。
Rowsパネルに次の属性をこの順序で追加し、イベントログの構造を定義します：Ticket > Ticket ID、Time - Timestamp > Update - Timestamp、Updater > Updater name、Changes > Changes - Field name。
Activity Name列を作成するには、Standard Calculated Attributeを作成する必要があります。右側のサイドバーでCalculationアイコンをクリックし、Standard calculated attributeを選択します。名前にActivity Mapperを指定し、以下のQueryセクションに記載されたコードを貼り付けます。
この新しいActivity Mapper属性をRowsパネルに追加します。この属性をNULL以外に絞り込み、不要なシステムノイズを除外します。
コンテキスト情報として、Rowsパネルに追加属性を設定します：Ticket > Priority、Ticket > Group、Ticket > Status、および根本原因やカテゴリ分析に必要なカスタム項目（例：Ticket > Ticket tagsまたは特定のCustom Fields）。
FiltersパネルでTime - Timestamp > Update - Dateを使い、希望する分析期間（例：Last 6 Months）を設定します。
Visualization typeアイコンをクリックし、Tableを選択します。利用できる場合は、テーブルがピボット解除またはフラットになっていることを確認します。そのオプションがない場合は、すべての属性がRowsセクションに入っていることを確認してください。
Export > CSVをクリックして結果をエクスポートします。ProcessMindでタイムスタンプ形式を保持できるよう、Keep attribute formattingにチェックが入っていることを確認してください。

設定

データセット：Support: Updates History（重要：標準のTicketsデータセットは現在の状態しか表示しないため、使用しないでください）。
時間フィルター：Update - Date（推奨：データ量に応じて過去90～180日）。
チケットタイプ：IncidentsやService Requestsが混在しないよう、必ずProblemに限定します。
行数制限：Zendesk Exploreのエクスポートは、多くの場合50,000行に制限されます。データセットがこれを超える場合は、Update - Dateフィルターで月単位の小さなデータに分けてエクスポートし、外部で結合します。
カスタムフィールド：Root Cause、Change Request、Workaroundに対応するフィールドIDは、Zendeskインスタンスごとに異なります。対象のIDを特定してください。
システム権限：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 Data Sharingアドオンが有効になっていることを確認します。通常はSnowflakeまたはAmazon Redshiftでホストされている、複製済みZendeskデータベースへの読み取り専用アクセス認証情報があることを確認してください。
データベースへの接続： 任意のSQLクライアント（DBeaver、DataGrip、SnowflakeまたはRedshiftのネイティブWeb画面など）を使い、提供された認証情報でZendeskデータウェアハウスに接続します。
カスタム項目の特定： クエリを実行する前に、Problem Managementプロセスで使用するカスタム項目の一意のIDを特定します。ZendeskのAdmin Centerで、Objects and rules > Tickets > Fieldsに移動します。Root Cause、Change Request ID、Workaround Published、Permanent Fix Applied、Post-Implementation Reviewの項目を探し、それぞれの項目IDを取得します。これらのIDをクエリ内のプレースホルダーの置き換えに使用します。
SQLクエリの確認： 提供されたクエリでは、ProblemTicketsという共通テーブル式（CTE）を使い、最初にすべての問題レコードを選択して絞り込みます。これにより、パフォーマンスと可読性が向上します。クエリの主要部分では、必須アクティビティごとに1つずつ、12個のSELECT文の結果をUNION ALLで結合します。
クエリのカスタマイズ： 新しいクエリエディターを開き、完全なSQLスクリプトを貼り付けます。スクリプト内のプレースホルダーを変更します：
- ProblemTickets CTEで、'[YYYY-MM-DD]'を置き換えて希望する日付範囲を設定します。
- カスタム項目に依存する各アクティビティについて、プレースホルダーのID（例：[Your 'Root Cause Category' field_id]、[Your 'Change Request ID' field_id]）を手順3で特定した実際のIDに置き換えます。
クエリの実行： 変更したSQLスクリプトをデータベースに対して実行します。実行時間は、日付範囲とチケットデータ量によって異なります。
「Proposed Solution Drafted」ロジックの確認： このクエリでは、[Your 'KB Article ID' field_id]というカスタム項目に値を入力することで、解決策の草案作成を記録することを想定しています。タグやコメントを使うなど、プロセスが異なる場合は、クエリの該当部分を調整してください。
データ検証： クエリの完了後、結果を簡単に確認します。行数が妥当であること、すべての列が存在すること、ProblemRecordIdやEventTimestampなど重要な列に予期しないNULL値がないことを確認してください。
イベントログのエクスポート： SQLクライアントから結果セット全体をCSVファイルにエクスポートします。UTF-8エンコーディングを使用し、列見出しがプロセスマイニングツールで必要な属性名と一致していることを確認してください。
アップロードの準備： アップロード前に、CSVファイルの形式に問題がないことを確認します。EventTimestamp列の日付と時刻が、YYYY-MM-DD HH24:MI:SSなど一貫した形式になっていることを確認してください。

設定

前提条件：この抽出には、Zendesk Data Sharingアドオンと、SnowflakeまたはAmazon Redshiftにある複製データへの直接SQLアクセスが必要です。
チケットタイプのフィルター：クエリは、typeが「problem」のチケットだけを分析するよう事前設定されています。インシデントやその他のチケットタイプから問題管理プロセスを分離するために重要です。
日付範囲のフィルタリング：パフォーマンスを維持するため、特定の期間にデータを絞り込むことを強く推奨します。初期CTEにはcreated_at >= '[YYYY-MM-DD]'というプレースホルダーが含まれています。最初の分析では、3～6か月の範囲が一般的です。
カスタムフィールドの設定：この抽出は、Zendeskの固有の設定に大きく依存します。「Root Cause Identified」、「Change Request Initiated」、「Workaround Published」などのアクティビティを記録するカスタムフィールドについて、正しい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にログインします。「Admin Center」>「Apps and integrations」>「APIs」>「Zendesk API」に移動します。「Token Access」セクションで「Add API token」をクリックし、新しいトークンを作成します。トークンは再表示されないため、すぐにコピーして安全に保管します。
Pythonスクリプトの設定：新しいPythonファイル（例：「extract_zendesk_problems.py」）を作成し、「Query」セクションに記載された完全なスクリプトをコピーします。スクリプト上部のプレースホルダー変数「ZENDESK_SUBDOMAIN」、「ZENDESK_EMAIL」、「ZENDESK_API_TOKEN」、「START_TIME」を更新します。初回実行時は、「START_TIME」に抽出開始日のUnixタイムスタンプを設定します。
カスタムフィールドIDのマッピング：問題管理プロセスで使用するカスタムフィールドの数値IDを特定します。「Admin Center」>「Objects and rules」>「Tickets」>「Fields」に移動し、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」辞書は重要です。Zendeskインスタンスの実際のカスタムフィールドIDにプレースホルダーIDを更新し、「Workaround Published」や「Root Cause Identified」などのアクティビティを正しく取得できるようにします。
チケット種別フィルター：スクリプトは「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環境に適用し、ITの安定性を高めます。データ抽出の調整やプロセスマイニングの開始について、当社チームがサポートします。

改善ガイドに戻るテンプレートをダウンロード

問題管理を最適化し、IT修正を迅速化

解決サイクルを30％短縮し、ITのボトルネックを解消します。

無料トライアルを開始

クレジットカードは不要です。数分で設定できます。

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

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

問題管理の属性

問題管理のアクティビティ

抽出ガイド

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

ステップ

設定

a サンプルクエリ config

Zendesk Data Sharing経由のSQLクエリ

ステップ

設定

a サンプルクエリ sql

Incremental Export APIを使用したPython抽出

ステップ

設定

a サンプルクエリ python

準備はできましたか？

問題管理を最適化し、IT修正を迅速化

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

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

問題管理の属性

問題管理のアクティビティ

抽出ガイド

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

ステップ

設定

a サンプルクエリ config

Zendesk Data Sharing経由のSQLクエリ

ステップ

設定

a サンプルクエリ sql

Incremental Export APIを使用したPython抽出

ステップ

設定

a サンプルクエリ python

準備はできましたか？

問題管理を最適化し、IT修正を迅速化

プライバシーを大切にしています