> 継続的なプロセス改善 > カスタマーサービス > Freshdesk > データテンプレート

カスタマーサービスのデータテンプレート

Freshdesk

カスタマーサービスの属性 (19) カスタマーサービスのアクティビティ (13) 抽出ガイド (3)

カスタマーサービスのデータテンプレート

このテンプレートでは、カスタマーサービスを効果的に分析するために必要な主要なデータ属性とプロセスアクティビティを詳しく説明します。データを効率的に収集するための抽出方法も紹介しています。この資料を使ってデータ収集を効率化し、プロセスマイニングの準備を進めてください。

収集を推奨する属性
追跡すべき主要なアクティビティ
抽出方法

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

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

カスタマーサービスの属性

カスタマーサービスを詳細に分析し、深いインサイトを得るために、イベントログに含めることを推奨するデータ項目です。

3 必須 4 推奨 12 任意

	名前	説明
	アクティビティ Activity	カスタマーサービスプロセス内で発生した、特定の業務イベントまたはステップの名称です。
説明アクティビティ属性は、サービスリクエストのライフサイクルにおける個別の操作やステータス変更を示します。「Ticket Created」、「Ticket Assigned」、「First Response Sent」、「Ticket Resolved」などの主要な業務イベントを記録します。これらのアクティビティがプロセスマップのノードになります。アクティビティの順序と頻度を分析することは、プロセスマイニングの中心です。プロセスフローの可視化、よくある経路とまれな経路の特定、標準業務手順からの逸脱の検出が可能になります。アクティビティを把握することは、「Ticket Reopened」のような手戻りループや非効率な箇所、コンプライアンス上の問題を特定するうえで重要です。重要な理由プロセスマップ上のステップを定義し、開始から終了までのプロセスフローを可視化・分析できるようにします。入手先 Freshdesk内のイベント種別から導出します。「Tickets」APIエンドポイントのステータス変更と、「Conversations」エンドポイントのメモや返信などの特定イベントを組み合わせて作成できます。例チケット作成初回返信送信ステータスを保留中に変更チケット解決チケット終了
	イベント時刻 EventTime	特定のアクティビティまたはイベントが発生した時点を示すタイムスタンプです。
説明イベント時刻、つまりタイムスタンプは、アクティビティが発生した正確な日付と時刻を記録します。イベントを時系列に並べたり、プロセス内の異なるステップ間の所要時間を計算したりするための重要な要素です。記録されたすべてのアクティビティには、対応するタイムスタンプが必要です。分析では、この属性を使って各サービスリクエストのタイムラインを作成します。解決時間、初回応答時間、ボトルネックの継続時間など、時間に関するすべてのKPIを計算する基盤になります。正確なタイムスタンプは、プロセスのパフォーマンスを把握し、遅延を特定するために欠かせません。重要な理由イベントを時系列に並べ、サイクルタイムやSLAコンプライアンスなど、所要時間に基づくすべての指標を計算するために欠かせないタイムスタンプです。入手先 Freshdesk APIでチケットのイベント、返信、ステータス変更に関連付けられた「created_at」または「updated_at」項目に対応します。例 2023-10-25T10:00:00Z2023-10-25T10:05:14Z2023-10-26T14:30:00Z
	サービスリクエスト ServiceRequest	1件の顧客からの問い合わせや問題を識別する一意の識別子で、一般にチケットまたはケースと呼ばれます。
説明サービスリクエストは、1件の顧客とのやり取りに関連するすべてのアクティビティを結び付ける主要なケース識別子です。顧客から新しい問い合わせ、問題、リクエストが発生するたびに、一意のサービスリクエストIDが生成されます。このIDは、チケットの作成から割り当て、解決、終了まで、ライフサイクル全体を通じて変わりません。プロセスマイニングでは、この属性が各顧客ケースのエンドツーエンドの流れを再構築する基盤になります。関連するすべてのイベントを1つのサービスリクエストIDにまとめることで、分析担当者はプロセスフローを可視化し、サイクルタイムを測定し、個々のケースに影響するばらつきやボトルネックを特定できます。重要な理由関連するすべてのイベントを1つのプロセスインスタンスに結び付け、各カスタマーサービスの流れを完全に把握するための基本的なケースIDです。入手先 Freshdeskの主要なチケットIDで、通常は「Tickets」APIエンドポイントの「id」項目にあります。例 SR-2023-10-4831SR-2023-11-0192SR-2023-11-5210
	サービスリクエスト種別 ServiceRequestType	「Question」、「Incident」、「Problem」、「Feature Request」など、サービスリクエストの分類です。
説明サービスリクエスト種別は、顧客からの問い合わせの性質を定義する重要な分類項目です。通常はチケット作成時または初回のトリアージで設定され、適切なチームや担当者への振り分けに役立ちます。分析では、この属性を使ってプロセスを分け、リクエストの種類ごとの対応状況を把握できます。「インシデントは問い合わせより解決に時間がかかるか」「どの種別のリクエストが最も頻繁に再オープンされるか」といった問いにも答えられます。種類ごとのボトルネックを特定し、それに応じてワークフローを改善するための重要な切り口です。重要な理由プロセスを分けて分析し、インシデントと問い合わせなど、顧客の問題の種類ごとにパフォーマンスとワークフローを比較できます。入手先 Freshdeskの「Tickets」オブジェクトで利用できる「type」項目に該当する可能性があります。例質問インシデント問題機能リクエスト
	ステータス Status	「Open」、「Pending」、「Resolved」、「Closed」など、サービスリクエストの現在または過去のステータスです。
説明ステータス属性は、ある時点におけるサービスリクエストの状態を示します。ステータス変更は、「Open」から顧客の情報を待つ「Pending」へ移行する場合や、顧客の返信によって「Pending」から「Open」へ戻る場合など、プロセス上の重要な節目を表します。ステータス変更の追跡は、チケットのライフサイクルを把握する基本です。各状態にチケットがどれだけ滞在したかを特定でき、ボトルネックの発見に役立ちます。たとえば、「Pending」状態が長く続いている場合、顧客からの情報取得に遅延が生じている可能性があります。重要な理由ステータス変更を追跡することは、チケットのライフサイクルを把握し、「Pending」や「On Hold」など特定の状態にケースが滞在した時間を特定するうえで重要です。入手先 Freshdeskの「Tickets」オブジェクトの「status」フィールドに対応します。過去のステータスはアクティビティログから推定する必要があります。例未処理保留中解決済みクローズ済み
	優先度 Priority	サービスリクエストに設定された優先度です。「Low」、「Medium」、「High」、「Urgent」などがあります。
説明 Priority属性はサービスリクエストの緊急度を示し、目標応答時間や解決時間を決める基準になることがよくあります。優先度は、ルールに基づいて自動設定することも、トリアージ中に担当者が手動で設定することもできます。この属性は、SLAコンプライアンスとリソース配分を分析するうえで欠かせません。優先度でプロセスマップを絞り込むと、高優先度のチケットが低優先度のチケットより本当に速く処理されているかを確認できます。また、再作業の一種である優先度変更がどの程度発生しているか、プロセスにどのような影響を与えているかも把握できます。重要な理由 SLA分析や、高優先度の問題を低優先度の問題より速く処理できるよう、リソースが適切に配分されているかを把握するために役立ちます。入手先 Freshdeskの「Tickets」オブジェクトの「priority」フィールドに対応します。例低中高緊急
	割り当て担当者 AssignedAgent	イベント発生時点でチケットを担当していたカスタマーサービス担当者の名前またはIDです。
説明サービスリクエストの対応を担当する特定の担当者を識別する属性です。再割り当てやエスカレーションによって、チケットのライフサイクル中に担当者が変わる場合があります。割り当て担当者別にデータを分析することは、パフォーマンス管理用ダッシュボードに欠かせません。平均解決時間、チケット量、再オープン率など、担当者別のKPIを測定できます。成果を上げている担当者の特定、研修ニーズの把握、担当者間の転送が解決時間全体に与える影響の分析にも役立ちます。重要な理由担当者ごとのパフォーマンス分析を可能にし、成果を上げている担当者、研修機会、再割り当ての影響を特定できます。入手先 Freshdeskの「Tickets」オブジェクトにある「responder_id」項目に対応し、担当者の詳細情報と結合できます。例 Alice JohnsonRobert SmithMaria Garcia
	SLA目標解決時間 SlaTargetResolutionTime	サービスリクエストの解決について、契約上合意された時間または目標時間です。
説明この属性は、サービスレベル合意（SLA）に基づいてサービスリクエストを解決すべき目標時間を定義します。目標時間は、チケットの優先度や種類によって異なることがよくあります。 SLAコンプライアンスを計算するための重要な入力値です。実際の解決時間とこの目標時間を比較することで、「Met」または「Breached」を判定できます。リクエストの種類、チーム、担当者ごとにSLAパフォーマンスを分析することは、サービス管理の中心的な取り組みです。重要な理由 SLAコンプライアンスを測定する基準となり、あらゆるカスタマーサービス組織にとって重要なパフォーマンス指標です。入手先 Freshdeskの「Tickets」オブジェクトにある「fr_due_by」（初回応答）や「due_by」（解決）などのフィールドで取得できる場合があります。SLAポリシーのルールに基づいて算出する必要がある場合もあります。例 2023-10-25T14:00:00Z2023-10-27T09:00:00Z2023-11-01T17:00:00Z
	SLA違反の有無 IsSlaBreached	サービスリクエストの解決時間がSLA目標時間を超えたかどうかを示すブール値フラグです。
説明この計算属性は、サービスリクエストごとのSLAコンプライアンスを明確に示す二値の指標です。実際の「ResolutionTime」と「SlaTargetResolutionTime」を比較して算出します。実際の時間が目標時間を超えている場合、フラグはtrueになります。この属性により、SLAコンプライアンスの分析やダッシュボード作成が簡単になります。SLA違反チケットを容易に集計・絞り込みできるため、SLA不遵守の規模をすばやく把握し、違反チケットのプロセスパターンを詳しく調べて根本原因を特定できます。「SLA Compliance Overview」ダッシュボードとKPIにも直接役立ちます。重要な理由目標を達成できなかったケースを明確なフラグで示すため、SLAコンプライアンスの分析が簡単になり、違反の根本原因を調査できます。入手先計算フィールドです。実際の解決タイムスタンプと、Freshdeskの「SlaTargetResolutionTime」または「due_by」フィールドを比較して算出します。例 truefalse
	コミュニケーションチャネル CommunicationChannel	サービスリクエストが開始されたチャネルです。「Email」、「Phone」、「Chat」、「Web Portal」などがあります。
説明この属性は、顧客とのコミュニケーションの起点やチャネルを示します。チャネルによってプロセスフローや解決時間は異なります。たとえば、チャットで開始されたリクエストは、メールで送信されたリクエストより想定解決時間が短い場合があります。コミュニケーションチャネル別にプロセスを分析すると、リソース配分を最適化し、チャネルごとの効率を把握できます。解決が速いチャネルや顧客満足度の高いチャネルを明らかにし、どのチャネルを推奨・強化すべきかを判断する材料になります。重要な理由メール、電話、チャットなど、顧客との接点となるチャネルごとにプロセスのパフォーマンスと効率を分析できます。入手先 Freshdeskの「Tickets」オブジェクトの「source」フィールドに対応します。例メール電話Webポータルチャット
	ソースシステム SourceSystem	データを抽出したシステムです。この場合は「Freshdesk」です。
説明プロセスデータの元となったアプリケーションを識別する属性です。この分析では、値は「Freshdesk」などの固定値となり、すべてのイベントがFreshdeskのカスタマーサービスプラットフォームから取得されたことを示します。単純な属性に見えますが、データガバナンスや複数のシステムからデータを統合する場面で重要です。データの出所と背景を明確にし、分析担当者が対象データの起点を把握できるようにします。データの完全性を維持し、分析結果への信頼を高めるうえで欠かせません。重要な理由データの出所に関する重要な背景情報を提供します。データガバナンスや複数のソースシステムからデータを統合する際に欠かせません。入手先データ変換の過程で追加される固定値「Freshdesk」です。データソースを識別するために使います。例 Freshdesk
	再オープンの有無 IsReopened	解決済みのサービスリクエストが一度でも再オープンされたかどうかを示すブール値フラグです。
説明このケースレベルの属性は、サービスリクエストのライフサイクル中に「Ticket Reopened」アクティビティが一度でも発生した場合にtrueとなるフラグです。再作業が必要になったケースを簡単に特定・分析できます。再オープンされたチケットの割合が高い場合、初回の解決が有効または十分でなかった可能性があり、非効率や顧客の不満につながります。再オープンされたチケットに絞り込むことで、再オープンの主な理由、割合の高い担当者やチーム、再オープンされやすいチケットの種類など、根本原因を調査できます。重要な理由再作業が必要になったケースを特定します。解決品質とプロセスの非効率を示す重要な指標であり、分析結果を初回対応での解決率の改善に役立てられます。入手先計算フィールドです。ケースに「Activity = 'Ticket Reopened'」のイベントが存在する場合、そのService Requestに対してtrueを設定します。例 truefalse
	最終データ更新日時 LastDataUpdate	ソースシステムからデータが最後に更新された時点を示すタイムスタンプです。
説明 Freshdeskからデータセットを最後に抽出または更新した日付と時刻を記録する属性です。分析対象データの鮮度を明らかにし、適時性と関連性のある業務判断を行ううえで重要です。分析担当者はこの情報を使って、データが対象とする期間を把握し、利用可能な最新情報を使っていることを確認します。プロセスマイニングのダッシュボードやレポートに必要なメタデータであり、関係者がデータの更新時点を把握できるようにします。重要な理由データの鮮度を示し、最新情報に基づいて分析や判断を行えるようにします。入手先データ抽出の過程で生成されるメタデータ項目です。データを取得した時点のタイムスタンプを記録します。例 2023-12-01T08:00:00Z
	初回応答時間 FirstResponseTime	チケットの作成から、担当者が顧客に初めて応答するまでの経過時間です。
説明 First Response Timeは、顧客がサービス担当者から自動送信ではない初回応答を受け取るまでの速さを測定します。「First Response Sent」アクティビティのタイムスタンプと「Ticket Created」アクティビティのタイムスタンプの差分として算出します。このKPIはサービスの応答性を示す重要な指標であり、顧客満足度に大きく影響します。初回応答が速いと、問題を受け付けて対応中であることを顧客に伝えられます。この指標を分析すると、初回応答SLAを満たし、迅速な顧客体験を提供できているかを確認できます。重要な理由サービスの応答性を測定します。顧客満足度を左右する重要な要素であり、先回りしたサービス提供という目標にも直結します。入手先計算フィールドです。「Ticket Created」イベントと「First Response Sent」イベントのタイムスタンプ間の時間として算出します。例 3000009000001800000
	割り当て先グループ AssignedGroup	サービスリクエストが割り当てられたチームまたは部門です。
説明 Assigned Groupは、特定のサービスリクエストを担当する担当者チームを示します。チケットは、種類や複雑さに応じて、「Technical Support」や「Billing Department」などの専門グループに振り分けられることがよくあります。この属性は、部門間の引き継ぎやチーム単位のパフォーマンスを分析する際に役立ちます。どのグループが最も多くのチケットを処理しているか、解決時間が最も長いグループはどこか、グループ間でチケットがどの程度移管されているかを確認できます。こうした情報は、チーム構成やワークフローの改善に役立ちます。重要な理由チームまたは部門単位でパフォーマンスを分析し、引き継ぎを可視化するとともに、グループ固有のボトルネックを特定できます。入手先 Freshdeskの「Tickets」オブジェクトの「group_id」フィールドに対応します。例 L1サポートL2テクニカルサポート請求カスタマーサクセス
	担当者移管回数 AgentTransferCount	サービスリクエストが担当者から別の担当者へ再割り当てされた回数の合計です。
説明この属性はケースレベルの指標で、チケットの担当者が変更された回数を数えます。各サービスリクエストについて、「Ticket Reassigned」アクティビティの発生回数を数えて算出します。「ピンポン」とも呼ばれる頻繁な移管は、引き継ぎのたびに情報が失われるため、大幅な遅延や顧客の不満につながることがあります。移管回数を分析すると、初期振り分けの問題、担当者のスキル不足、プロセスの複雑さを特定できます。多くの場合、不要な移管を減らすことが効率と顧客満足度の向上につながります。重要な理由社内での引き継ぎ頻度を測定します。遅延や顧客の不満を生む大きな要因を把握し、一次対応での解決率の向上に役立ちます。入手先計算フィールドです。各一意のService Requestについて、「Ticket Reassigned」アクティビティの数を示します。例 0132
	満足度評価 SatisfactionRating	チケットの解決後に顧客が回答した満足度スコアです。
説明 Satisfaction Ratingは、チケット解決後に送信するアンケートで収集する主要な成果指標です。通常は数値スコア、または「Satisfied」、「Neutral」、「Unsatisfied」などのカテゴリ評価で構成されます。この属性を使うと、プロセスのパターンと顧客の成果を関連付けて分析できます。満足度スコアが低くなるプロセスバリアントを分析すれば、顧客体験に悪影響を与える具体的な行動や遅延を特定できます。プロセス効率と顧客満足度の関係を直接確認できる点が特徴です。重要な理由プロセスの実行と顧客の成果を関連付け、顧客満足度の向上または低下につながるプロセス上の行動を特定できます。入手先このデータはFreshdeskの満足度評価機能に含まれており、「Surveys」または「Satisfaction Ratings」APIエンドポイントから取得できます。例 5314
	製品 Product	顧客のリクエストに関連する製品またはサービスです。
説明この属性は、サービスリクエストの対象となる製品またはサービスラインを示します。チケットの分類、振り分け、レポート作成を目的に、Freshdeskで設定するカスタムフィールドであることがよくあります。製品別にプロセスを絞り込むと、製品固有の問題を見つけ出せます。たとえば、特定の製品でサポートチケットが過剰に発生していないか、新製品の発売によって問い合わせが急増していないかを確認できます。この分析結果は、製品開発チームや製品管理チームへの有用なフィードバックになります。重要な理由製品領域でプロセスを絞り込み、どの製品でサポートリクエストが最も多く発生しているか、解決時間が最も長い製品はどれかを把握できます。入手先通常はカスタムフィールドです。正確な場所はFreshdeskの設定によって異なりますが、「Tickets」APIレスポンスの「custom_fields」部分に含まれている可能性があります。例 Alpha PlatformBeta Mobile AppGamma Subscription
	顧客名 CustomerName	サービスリクエストを開始した顧客の名前またはIDです。
説明この属性は、サービスリクエストに関連する顧客を特定します。特定の顧客とのやり取りを時系列で追跡し、顧客を起点にプロセスを分析できます。顧客別に分析すると、どの顧客が最も多くチケットを送信しているか、どの顧客で再オープンされた問題が多いかなどの傾向が分かります。顧客成功施策の検討や、サービス体験の低下によって離反リスクが高まっている顧客の特定にも役立ちます。また、複数のサービスリクエストにまたがる顧客のエンドツーエンドの体験を把握するうえでも重要です。重要な理由顧客を起点としたプロセスの見方が可能になり、リクエストの多い顧客や、同じ問題を繰り返し経験している顧客を特定できます。入手先この情報は「Tickets」オブジェクトの「requester_id」を介して関連付けられます。「requester_id」は、Freshdeskの「Contacts」または「Users」オブジェクトに接続します。例 John DoeJane SmithGlobal Tech Inc.

必須推奨任意

カスタマーサービスのアクティビティ

正確なプロセスディスカバリーとボトルネック特定に向けて、イベントログに記録すべき主要なプロセス手順と重要なマイルストーンです。

5 推奨 8 任意

	アクティビティ	説明
	チケット作成	カスタマーサービスのライフサイクルにおける最初のイベントで、顧客のリクエストがFreshdeskに正式に記録された時点を示します。メール、ポータル、電話、API連携のいずれかで新しいチケットが作成されると、このアクティビティが明示的に記録されます。
重要な理由このアクティビティはすべてのケースの開始点となるため、全体の解決時間の計算や、チャネル別・種類別のチケット量の傾向分析に欠かせません。入手先 Freshdeskの「Ticket Activities」ログに明示的なイベントとして記録されます。新しいチケットレコードが作成されると、自動的に生成されます。取得作成時にチケットのアクティビティストリームへ直接記録されます。イベントタイプ explicit
	チケット割り当て	チケットが対応担当の特定の担当者またはグループに割り当てられたことを示します。割り当てられた担当者またはグループの項目に値が入力されたとき、または変更されたとき、チケット履歴に明示的に記録されます。
重要な理由割り当てを追跡することは、担当者の業務量の分析、振り分けの非効率な箇所の特定、割り当てまでの時間に関するKPIの測定に欠かせません。業務の分担状況や、作業開始前に遅延が発生している箇所を把握できます。入手先「Ticket Activities」ログから取得します。ここには「Agent」または「Group」項目の変更がタイムスタンプ付きで記録されます。取得担当者またはグループの「Assigned to」項目が更新されたときに記録されるイベントです。イベントタイプ explicit
	チケット終了	チケットが完全に終了したことを示す最後のアクティビティです。通常は、顧客から新しい返信がないまま「Resolved」状態が一定期間続いた後、システムによって自動的に実行されます。
重要な理由サービスリクエストのライフサイクルが確定的に終了したことを示します。エンドツーエンドの正確なサイクルタイムを計算するための最終地点になります。入手先最終ステータスが「Closed」に変更されたことを記録する「Ticket Activities」ログから取得します。多くの場合、システムの自動化によってトリガーされます。取得チケットの「Status」項目が「Closed」に更新されたときに記録されるイベントです。イベントタイプ explicit
	チケット解決	担当者が解決策を提示し、チケットのステータスを「Resolved」に変更した重要な節目を示します。チケット履歴に明示的なステータス変更として記録されます。
重要な理由チケットに対する実作業の終了を示し、解決時間の測定基準になります。担当者のパフォーマンスとプロセス全体の効率を分析するうえで重要なイベントです。入手先「Resolved」への具体的なステータス変更とタイムスタンプを記録する「Ticket Activities」ログから取得します。取得チケットの「Status」項目が「Resolved」に更新されたときに記録されるイベントです。イベントタイプ explicit
	初回返信送信	チケット作成後、担当者が顧客に送信した最初の公開返信を示します。Freshdeskでは、SLA追跡のための「First Response Time」を測定するイベントとして明示的に記録されます。
重要な理由顧客への応答性とSLAコンプライアンスを測定する重要な節目です。このアクティビティまでの時間を分析すると、顧客への初回対応における遅延を特定できます。入手先 FreshdeskがSLAの目的で追跡する特定のイベントです。担当者が追加した最初の公開コメントのタイムスタンプに対応します。取得チケットの会話履歴にある、担当者からの最初の公開返信によって特定されます。イベントタイプ explicit
	SLA違反	チケットへの応答または解決にかかった時間が、定義されたSLAポリシーの目標を超えたときに発生する計算上のイベントです。FreshdeskはSLAのステータスを追跡し、チケットを「violated」としてマークします。この情報からアクティビティを導出できます。
重要な理由サービスレベルの約束がいつ、どこで守られていないかを特定できるため、SLAコンプライアンスの分析を直接支援します。遅延の構造的な原因を特定するうえで重要です。入手先チケットの「SLA」ステータスを確認して推定または計算します。チケットのSLAステータスが「Violated」に変わったときにアクティビティを生成するか、応答・解決のタイムスタンプとSLA目標を比較して求めます。取得「Time to Resolve」が「SLA Target Resolution Time」を超えた場合に、チケットデータから導出します。イベントタイプ calculated
	ステータスを保留中に変更	担当者が顧客からの情報を待つ際に、チケットのステータスを「Pending」に変更すると発生します。このイベントは、チケットのアクティビティ履歴にステータス変更として明示的に記録されます。
重要な理由外部からの情報を待つためにプロセスが停止している期間を特定できます。このステータスに費やした時間を分析すると、顧客側の遅延を定量化できます。また、この状態ではSLAタイマーが停止することが多いため、SLAコンプライアンスの分析にも役立ちます。入手先「Pending」への移行を含むすべてのステータス変更を記録する「Ticket Activities」ログから取得します。取得チケットの「Status」項目が「Pending」に更新されたときに記録されるイベントです。イベントタイプ explicit
	チケット優先度変更	担当者または自動化ルールがチケットの優先度を「Low」から「High」などに変更すると発生します。チケットのアクティビティログに明示的な更新として記録されます。
重要な理由優先度の変更は、エスカレーションや問題の緊急度の再評価を示す場合があります。こうした変更を分析すると、エスカレーションの要因と解決時間への影響を把握できます。入手先「Priority」項目を含むチケットのすべてのプロパティ変更を記録する「Ticket Activities」ログから取得します。取得「Priority」項目の値が更新されたときに記録されるイベントです。イベントタイプ explicit
	チケット再オープン	すでに「Resolved」状態になっているチケットに顧客が返信すると発生し、ステータスが自動的に「Open」に戻ります。システムによって明示的に記録されるイベントです。
重要な理由再オープン率が高い場合、最初の解決策が有効でなく、手戻りや顧客満足度の低下につながっている可能性があります。このアクティビティの分析は、「Ticket Re-opening Analysis」と初回対応での解決の改善に欠かせません。入手先顧客の返信によってステータスが「Resolved」から「Open」に自動変更されたときに取得されます。このステータス変更は「Ticket Activities」ログに記録されます。取得顧客とのやり取りによって「Resolved」から「Open」へステータスが変更されたことを示します。イベントタイプ explicit
	チケット再割り当て	初回の割り当て後に、チケットが担当者またはグループから別の担当者またはグループへ移管されると発生します。チケットのアクティビティログには、担当者の変更として明示的に記録されます。
重要な理由再割り当てが頻繁に発生する場合や、担当者間の転送率が高い場合、初回の振り分けが適切でない、または知識が分断されている可能性があります。この分析により、初回対応での解決を改善できる箇所を特定できます。入手先初回割り当て後の「Ticket Activities」ログで、「Agent」または「Group」項目の変更を追跡します。取得初回の割り当て後に「Assigned to」項目が更新されたことを示します。イベントタイプ explicit
	内部メモ追加	担当者が、他の担当者との社内連携を目的とした非公開メモをチケットに追加します。チケットのアクティビティストリームに明示的なイベントとして記録され、担当者だけが閲覧できます。
重要な理由内部メモを追跡すると、連携のパターンや、社内での詳細な検討が必要な問題を分析できます。解決前に内部メモが頻繁に追加されている場合、問題が複雑であるか、知識が不足している可能性があります。入手先チケットの会話履歴に「Private Note」として記録され、顧客への公開返信とは区別されます。取得担当者が「Private」としてマークされたメモを追加したときに記録されるイベントです。イベントタイプ explicit
	満足度調査送信	通常はチケット解決後に自動化ルールによって送信される、顧客満足度調査を示します。自動化アクションがチケット履歴に記録される場合に取得できます。
重要な理由フィードバック収集プロセスの開始を示します。調査回答とプロセスのバリアントを関連付けることで、プロセスのパフォーマンスが顧客満足度に与える影響を詳しく把握できます。入手先通常は「Automation Rule」によってトリガーされます。チケットのアクティビティログに独立したイベントとして表示されるかどうかは、Freshdeskの自動化に関するログ設定によって異なります。取得チケット解決後に自動化ルールが実行されたときに記録されるイベントです。イベントタイプ explicit
	顧客からの返信	顧客から新しい返信または連絡を受け取ったことを示します。チケットの会話スレッドに明示的なイベントとして記録され、通常はステータスを「Pending」から「Open」に変更するきっかけになります。
重要な理由顧客とのやり取りが往復する状況を把握し、顧客の応答時間を測定するうえで重要なアクティビティです。停止していたSLAタイマーも再開するため、コンプライアンス指標に影響します。入手先チケットの会話スレッドに新しいエントリとして記録されます。イベントは顧客の連絡先レコードと関連付けられます。取得顧客の連絡先がチケットに追加した新しい公開メモです。イベントタイプ explicit

推奨任意

抽出ガイド

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

ステップ

チケットの表示とエクスポート権限を持つ管理者アカウントでFreshdeskにログインします。
左側のナビゲーションメニューからメインのTicketsタブに移動し、チケット一覧を表示します。
右側のFilter Ticketsパネルで、データ抽出の範囲を設定します。最低限、Createdの日付範囲を設定します。たとえば、過去6か月を指定します。Group、Agent、Sourceなどのフィルターを追加して、データセットを絞り込むこともできます。
フィルターを適用したら、チケット一覧の右上にあるExportアイコンをクリックします。アイコンは、トレイに向かう下向き矢印の形です。
Export Ticketsポップアップウィンドウで、含めるフィールドを選択します。イベントログに必要な標準フィールドとカスタムフィールドをすべて選択してください。Ticket ID、Created at、Resolved at、Closed at、First responded at、Agent、Group、Status、Priority、Type、その他の有用なカスタムフィールドが対象です。
選択内容を確認します。Freshdeskはバックグラウンドでエクスポート処理を開始します。データをCSVファイルとしてダウンロードするリンクが記載されたメールが届きます。大規模なデータセットでは時間がかかる場合があります。
メール内のリンクからCSVファイルをダウンロードします。
エクスポートされたファイルには、チケットごとに1行が含まれ、チケットの現在の状態と主要なタイムスタンプのスナップショットを表します。イベントログを作成するには、このデータを変換する必要があります。
QueryセクションにあるPythonスクリプトなどのスクリプト、またはデータ準備ツールを使用して、タイムスタンプ列（Created at、First responded at、Resolved at、Closed at）をアンピボットし、個別の行に変換します。新しい各行が1つのアクティビティを表します。
元のタイムスタンプ列を特定のActivity名にマッピングします。たとえば、Created at列をTicket Createdアクティビティにマッピングします。
必須列ServiceRequest、Activity、EventTimeと、その他の推奨属性を含む最終イベントログCSVを生成します。
変換したファイルを、プロセスマイニングツールへのアップロードに適したCSV形式で保存します。

設定

権限：アカウントからチケットを表示およびエクスポートするには、Administratorまたは同等の権限を持つカスタムロールが必要です。
日付範囲フィルター：履歴全体のエクスポートによる処理遅延を避けるため、CreatedまたはClosedの時間フィールドで日付範囲を設定することが重要です。初回分析では、通常3～6か月の期間が推奨されます。
チケットフィールド：エクスポートダイアログで、含めるフィールドを選択できます。イベントログの基礎となるCreated at、First responded at、Resolved at、Closed atなど、利用可能なタイムスタンプフィールドをすべて選択してください。Ticket IDなどの識別フィールドに加え、Agent、Group、Priority、Typeなどのコンテキストフィールドも含めます。
データ量：一度にエクスポートできるチケット数には上限があり、通常は30,000件です。より大きなデータセットでは、たとえば月単位で期間を分割し、複数回に分けてエクスポートする必要があります。
納品：エクスポートは非同期処理です。CSVファイルは直接ダウンロードされず、エクスポートを開始したユーザーのメールアドレスにダウンロードリンクとして送信されます。

a サンプルクエリ json

### Part 1: Freshdesk Export Configuration

This process uses the user interface for extraction. In the **Export Tickets** dialog, configure the following settings:

```json
{
  "filter_by": {
    "created": "[Specify Date Range, e.g., Last 6 Months]",
    "status": ["Open", "Pending", "Resolved", "Closed"],
    "// additional_filters": "Optionally filter by Group, Agent, Type, etc."
  },
  "export_fields": [
    "Ticket ID",
    "Created at",
    "First responded at",
    "Resolved at",
    "Closed at",
    "Group",
    "Agent",
    "Status",
    "Priority",
    "Type",
    "// include_custom_fields": "[Select any relevant custom fields]"
  ]
}
```

### Part 2: Data Transformation Script (Python with Pandas)

The exported CSV is a snapshot and must be transformed into an event log. The following script reshapes the data to create a row for each key activity.

```python
import pandas as pd

# --- Configuration ---
# Replace with the actual path to your downloaded Freshdesk CSV export
input_csv_path = 'freshdesk_export.csv'
output_csv_path = 'freshdesk_event_log.csv'

# --- Load Data ---
def transform_freshdesk_export(file_path):
    """Loads the Freshdesk export and transforms it into an event log."""
    try:
        df_raw = pd.read_csv(file_path)
    except FileNotFoundError:
        print(f"Error: The file {file_path} was not found.")
        return None

    # --- Rename and Select Columns ---
    # Adjust column names based on your specific export file
    column_mapping = {
        'Ticket ID': 'ServiceRequest',
        'Agent': 'AssignedAgent',
        'Type': 'ServiceRequestType',
        'Status': 'Status',
        'Priority': 'Priority',
        'Created at': 'Time_Ticket_Created',
        'First responded at': 'Time_First_Response_Sent',
        'Resolved at': 'Time_Ticket_Resolved',
        'Closed at': 'Time_Ticket_Closed'
    }
    df = df_raw.rename(columns=column_mapping)

    # Define the columns that are common to all events for a given ticket
    base_columns = ['ServiceRequest', 'AssignedAgent', 'ServiceRequestType', 'Status', 'Priority']
    # Ensure all required base columns exist
    for col in base_columns:
        if col not in df.columns:
            df[col] = None # Add missing columns as null

    # --- Unpivot Timestamp Columns to Create Events ---
    events = []
    activity_map = {
        'Time_Ticket_Created': 'Ticket Created',
        'Time_First_Response_Sent': 'First Response Sent',
        'Time_Ticket_Resolved': 'Ticket Resolved',
        'Time_Ticket_Closed': 'Ticket Closed'
    }

    for time_col, activity_name in activity_map.items():
        if time_col in df.columns:
            # Select rows where the timestamp exists
            df_event = df[df[time_col].notna()].copy()
            if not df_event.empty:
                df_event['Activity'] = activity_name
                df_event['EventTime'] = pd.to_datetime(df_event[time_col])
                events.append(df_event[base_columns + ['Activity', 'EventTime']])

    if not events:
        print("No events could be generated. Please check your column names and data.")
        return None

    # --- Combine, Sort, and Finalize ---
    df_event_log = pd.concat(events, ignore_index=True)

    # Calculate Resolution Time (optional, as an attribute)
    if 'Time_Ticket_Created' in df.columns and 'Time_Ticket_Resolved' in df.columns:
        df_res_time = df[['ServiceRequest', 'Time_Ticket_Created', 'Time_Ticket_Resolved']].dropna()
        df_res_time['ResolutionTime'] = (pd.to_datetime(df_res_time['Time_Ticket_Resolved']) - pd.to_datetime(df_res_time['Time_Ticket_Created'])).dt.total_seconds() / 3600.0 # In hours
        df_event_log = df_event_log.merge(df_res_time[['ServiceRequest', 'ResolutionTime']], on='ServiceRequest', how='left')

    # Sort the event log for proper ordering
    df_event_log = df_event_log.sort_values(by=['ServiceRequest', 'EventTime'], ascending=[True, True])

    return df_event_log

# --- Execute Transformation ---
if __name__ == "__main__":
    event_log = transform_freshdesk_export(input_csv_path)
    if event_log is not None:
        event_log.to_csv(output_csv_path, index=False)
        print(f"Event log successfully created at: {output_csv_path}")
```

ステップ

前提条件：システムにPython 3.6以降がインストールされていることを確認します。API呼び出しに使うrequestsと、データ操作に使うpandasを、次のコマンドでインストールします：pip install requests pandas。
Freshdesk APIキーの取得：AdministratorとしてFreshdeskインスタンスにログインします。右上のプロフィールアイコンをクリックし、「Profile Settings」を選択します。APIキーが右側に表示されます。このキーを安全にコピーします。
Pythonスクリプトの設定：新しいPythonファイル（例：extract_freshdesk.py）を作成します。「query」セクションに記載された完全なPythonスクリプトを、このファイルにコピーします。
スクリプトパラメーターの設定：スクリプトを開き、先頭にあるプレースホルダー変数を更新します。DOMAINにはFreshdeskドメイン（例：yourcompany.freshdesk.com）、API_KEYには取得したキー、START_DATE_STRにはデータ抽出の開始日を「YYYY-MM-DD」形式で設定します。
スクリプトの実行：ターミナルで次のコマンドを実行します：python extract_freshdesk.py。スクリプトがFreshdesk APIからチケットデータの取得を開始します。
抽出状況の監視：スクリプトはコンソールに進捗状況を出力し、現在処理しているチケットのページを表示します。期間とチケット数によっては、APIのレート制限により処理に時間がかかることがあります。
APIレスポンスの処理：スクリプトには、チケットをページ単位で取得してAPIのページネーションを処理するロジックが含まれています。また、429 Too Many Requestsエラーを受信した場合は、Freshdeskが指定する時間だけ処理を一時停止し、その後再試行してAPIのレート制限に対応します。
データ変換：チケットごとに、関連する会話とアクティビティを取得します。その後、生のJSONレスポンスを解析し、「Ticket Created」「Status Changed to Pending」「Ticket Resolved」など、必須の13種類のアクティビティごとに明示的なレコードを作成します。
出力の確認：スクリプトが完了すると、同じディレクトリにfreshdesk_event_log.csvというファイルが作成されます。このファイルには、抽出したすべてのアクティビティと属性を含む、構造化されたイベントログが格納されます。
アップロードの準備：作成されたCSVファイルを開き、想定どおりのデータが含まれていることを確認します。ServiceRequest、アクティビティ、EventTimeの各列が存在し、正しく入力されていることを確認します。これで、ファイルをProcessMindにアップロードできます。

設定

前提条件：APIキーを取得し、チケットデータに完全にアクセスするには、Administrator権限を持つFreshdeskアカウントが必要です。Python 3.6以降とrequestsおよびpandasライブラリをインストールしておく必要があります。
API認証情報：スクリプトには、固有のFreshdesk DOMAINと有効なAPI_KEYが必要です。これらをスクリプト内の変数として設定します。
日付範囲：START_DATE_STR変数で抽出の開始点を指定します。処理時間とAPI使用量を抑えるため、まずは3～6か月などの短い期間から始めることを推奨します。スクリプトでは効率化のため、updated_sinceフィルターを使用します。
APIエンドポイントのバージョン：このスクリプトはFreshdesk v2 API向けに作成されています。アカウントがこのバージョンに対応していることを確認してください。
パフォーマンスに関する考慮事項：スクリプトはFreshdeskのAPIレート制限の対象です。組み込みの遅延処理により制限超過を防ぎますが、大量のデータを抽出する場合は処理が遅くなります。数年分の全履歴を読み込む場合は、バッチに分けるか、利用の少ない時間帯に実行することを検討してください。
取得対象データ：スクリプトは、チケットと関連する会話を取得するよう設定されています。include=statsパラメーターを使用し、解決時間や応答時間などのメタデータを効率的に取得します。

a サンプルクエリ python

import requests
import pandas as pd
import time
import datetime
import re

class=class="hl-string">"hl-comment"># --- Configuration ---
class=class="hl-string">"hl-comment"># Replace with your Freshdesk domain
DOMAIN = class="hl-string">'[your_domain].freshdesk.com'
class=class="hl-string">"hl-comment"># Replace with your Freshdesk API Key
API_KEY = class="hl-string">'[your_api_key]'
class=class="hl-string">"hl-comment"># Set the start date for the extraction in class="hl-string">'YYYY-MM-DD' format.
START_DATE_STR = class="hl-string">'2023-01-01'

BASE_URL = fclass="hl-string">'https://{DOMAIN}/api/v2'
AUTH = (API_KEY, class="hl-string">'X')

def make_api_request(url, params=None):
    class="hl-string">"""Makes a GET request to the Freshdesk API, handling rate limits."""
    while True:
        try:
            response = requests.get(url, auth=AUTH, params=params)
            response.raise_for_status()
            return response
        except requests.exceptions.HTTPError as err:
            if err.response.status_code == 429:
                retry_after = int(err.response.headers.get(class="hl-string">'Retry-After', 60))
                print(fclass="hl-string">"Rate limit exceeded. Retrying after {retry_after} seconds...")
                time.sleep(retry_after)
            else:
                print(fclass="hl-string">"HTTP Error: {err}")
                return None
        except requests.exceptions.RequestException as err:
            print(fclass="hl-string">"Request Error: {err}")
            return None

def parse_iso_timestamp(ts):
    class="hl-string">"""Parses Freshdesk's ISO 8601 timestamp string."""
    if not ts or not isinstance(ts, str):
        return None
    return datetime.datetime.strptime(ts, class="hl-string">'%Y-%m-%dT%H:%M:%SZ')

def get_freshdesk_event_log(start_date):
    class="hl-string">"""Fetches and processes Freshdesk tickets to create an event log."""
    events = []
    page = 1
    
    class=class="hl-string">"hl-comment"># Convert start_date to the required format for the API query
    start_datetime = datetime.datetime.strptime(start_date, class="hl-string">'%Y-%m-%d')
    query_date = start_datetime.strftime(class="hl-string">'%Y-%m-%dT%H:%M:%SZ')

    while True:
        print(fclass="hl-string">"Fetching tickets page {page}...")
        tickets_url = fclass="hl-string">'{BASE_URL}/tickets'
        class=class="hl-string">"hl-comment"># Use class="hl-string">'updated_since' for incremental loads. For a full load, consider filtering by class="hl-string">'created_at'.
        params = {class="hl-string">'page': page, class="hl-string">'per_page': 100, class="hl-string">'order_by': class="hl-string">'updated_at', class="hl-string">'order_type': class="hl-string">'asc', class="hl-string">'updated_since': query_date, class="hl-string">'include': class="hl-string">'stats,requester'}
        
        response = make_api_request(tickets_url, params=params)
        if not response:
            break
            
        tickets_data = response.json()
        if not tickets_data:
            print(class="hl-string">"No more tickets found.")
            break

        for ticket in tickets_data:
            ticket_id = ticket[class="hl-string">'id']
            created_at = parse_iso_timestamp(ticket[class="hl-string">'created_at'])
            resolved_at = parse_iso_timestamp(ticket.get(class="hl-string">'stats', {}).get(class="hl-string">'resolved_at'))
            
            resolution_time_hours = (resolved_at - created_at).total_seconds() / 3600 if resolved_at and created_at else None

            common_attrs = {
                class="hl-string">'ServiceRequest': ticket_id,
                class="hl-string">'ServiceRequestType': ticket.get(class="hl-string">'type'),
                class="hl-string">'Priority': ticket.get(class="hl-string">'priority'),
                class="hl-string">'AssignedAgent': ticket.get(class="hl-string">'responder_id'),
                class="hl-string">'ResolutionTime': resolution_time_hours
            }
            
            class=class="hl-string">"hl-comment"># 1. Ticket Created
            events.append({
                **common_attrs,
                class="hl-string">'Activity': class="hl-string">'Ticket Created',
                class="hl-string">'EventTime': created_at.strftime(class="hl-string">'%Y-%m-%d %H:%M:%S'),
                class="hl-string">'Status': class="hl-string">'Open' 
            })
            
            class=class="hl-string">"hl-comment"># 2. First Response Sent
            first_responded_at = ticket.get(class="hl-string">'stats', {}).get(class="hl-string">'first_responded_at')
            if first_responded_at:
                events.append({
                    **common_attrs,
                    class="hl-string">'Activity': class="hl-string">'First Response Sent',
                    class="hl-string">'EventTime': parse_iso_timestamp(first_responded_at).strftime(class="hl-string">'%Y-%m-%d %H:%M:%S'),
                    class="hl-string">'Status': ticket.get(class="hl-string">'status')
                })

            class=class="hl-string">"hl-comment"># Fetch conversations for detailed activities
            conv_url = fclass="hl-string">'{BASE_URL}/tickets/{ticket_id}/conversations'
            conv_response = make_api_request(conv_url)
            if conv_response:
                conversations = conv_response.json()
                for conv in conversations:
                    event_time = parse_iso_timestamp(conv[class="hl-string">'created_at']).strftime(class="hl-string">'%Y-%m-%d %H:%M:%S')
                    
                    class=class="hl-string">"hl-comment"># 3. Customer Responded vs 4. Internal Note Added
                    if conv[class="hl-string">'source_type'] == class="hl-string">'note':
                        if conv.get(class="hl-string">'private', False):
                            events.append({
                                **common_attrs,
                                class="hl-string">'Activity': class="hl-string">'Internal Note Added',
                                class="hl-string">'EventTime': event_time,
                                class="hl-string">'Status': ticket.get(class="hl-string">'status')
                            })
                        else: class=class="hl-string">"hl-comment"># System generated notes for status changes etc.
                            body_text = conv.get(class="hl-string">'body_text', class="hl-string">'')
                            class=class="hl-string">"hl-comment"># 5. Status Changed to Pending
                            if class="hl-string">'Status changed from' in body_text and class="hl-string">'to Pending' in body_text:
                                events.append({**common_attrs, class="hl-string">'Activity': class="hl-string">'Status Changed to Pending', class="hl-string">'EventTime': event_time, class="hl-string">'Status': class="hl-string">'Pending'})
                            class=class="hl-string">"hl-comment"># 6. Ticket Assigned / Reassigned
                            if class="hl-string">'Assigned to' in body_text:
                                activity_name = class="hl-string">'Ticket Assigned' if any(e[class="hl-string">'Activity'] == class="hl-string">'Ticket Assigned' for e in events if e[class="hl-string">'ServiceRequest'] == ticket_id) else class="hl-string">'Ticket Reassigned'
                                events.append({**common_attrs, class="hl-string">'Activity': activity_name, class="hl-string">'EventTime': event_time, class="hl-string">'Status': ticket.get(class="hl-string">'status')})
                            class=class="hl-string">"hl-comment"># 7. Ticket Priority Changed
                            if class="hl-string">'Priority changed from' in body_text:
                                events.append({**common_attrs, class="hl-string">'Activity': class="hl-string">'Ticket Priority Changed', class="hl-string">'EventTime': event_time, class="hl-string">'Status': ticket.get(class="hl-string">'status')})
                            class=class="hl-string">"hl-comment"># 8. Satisfaction Survey Sent
                            if class="hl-string">'Satisfaction Survey was sent to the contact' in body_text:
                                events.append({**common_attrs, class="hl-string">'Activity': class="hl-string">'Satisfaction Survey Sent', class="hl-string">'EventTime': event_time, class="hl-string">'Status': ticket.get(class="hl-string">'status')})
                    else: class=class="hl-string">"hl-comment"># Not a note, so it's a reply
                        class=class="hl-string">"hl-comment"># 9. Customer Responded
                        if conv.get(class="hl-string">'incoming', False):
                            events.append({
                                **common_attrs,
                                class="hl-string">'Activity': class="hl-string">'Customer Responded',
                                class="hl-string">'EventTime': event_time,
                                class="hl-string">'Status': class="hl-string">'Open' class=class="hl-string">"hl-comment"># Typically a customer response re-opens the ticket
                            })
            
            class=class="hl-string">"hl-comment"># 10. SLA Breached
            if ticket.get(class="hl-string">'fr_escalated', False) or ticket.get(class="hl-string">'resolution_escalated', False):
                 breach_time = ticket.get(class="hl-string">'stats', {}).get(class="hl-string">'status_updated_at', ticket.get(class="hl-string">'updated_at'))
                 events.append({
                    **common_attrs,
                    class="hl-string">'Activity': class="hl-string">'SLA Breached',
                    class="hl-string">'EventTime': parse_iso_timestamp(breach_time).strftime(class="hl-string">'%Y-%m-%d %H:%M:%S'),
                    class="hl-string">'Status': ticket.get(class="hl-string">'status')
                })

            class=class="hl-string">"hl-comment"># 11. Ticket Resolved
            if resolved_at:
                events.append({
                    **common_attrs,
                    class="hl-string">'Activity': class="hl-string">'Ticket Resolved',
                    class="hl-string">'EventTime': resolved_at.strftime(class="hl-string">'%Y-%m-%d %H:%M:%S'),
                    class="hl-string">'Status': class="hl-string">'Resolved'
                })

            class=class="hl-string">"hl-comment"># 12. Ticket Reopened
            reopened_at = ticket.get(class="hl-string">'stats', {}).get(class="hl-string">'reopened_at')
            if reopened_at:
                events.append({
                    **common_attrs,
                    class="hl-string">'Activity': class="hl-string">'Ticket Reopened',
                    class="hl-string">'EventTime': parse_iso_timestamp(reopened_at).strftime(class="hl-string">'%Y-%m-%d %H:%M:%S'),
                    class="hl-string">'Status': class="hl-string">'Open'
                })
                
            class=class="hl-string">"hl-comment"># 13. Ticket Closed
            closed_at = ticket.get(class="hl-string">'stats', {}).get(class="hl-string">'closed_at')
            if closed_at:
                events.append({
                    **common_attrs,
                    class="hl-string">'Activity': class="hl-string">'Ticket Closed',
                    class="hl-string">'EventTime': parse_iso_timestamp(closed_at).strftime(class="hl-string">'%Y-%m-%d %H:%M:%S'),
                    class="hl-string">'Status': class="hl-string">'Closed'
                })

        page += 1

    class=class="hl-string">"hl-comment"># Create DataFrame and sort by time
    df = pd.DataFrame(events)
    df[class="hl-string">'EventTime'] = pd.to_datetime(df[class="hl-string">'EventTime'])
    df = df.sort_values(by=[class="hl-string">'ServiceRequest', class="hl-string">'EventTime']).reset_index(drop=True)
    df[class="hl-string">'EventTime'] = df[class="hl-string">'EventTime'].dt.strftime(class="hl-string">'%Y-%m-%d %H:%M:%S')

    return df

if __name__ == class="hl-string">'__main__':
    print(class="hl-string">"Starting Freshdesk data extraction...")
    event_log_df = get_freshdesk_event_log(START_DATE_STR)
    if not event_log_df.empty:
        output_filename = class="hl-string">'freshdesk_event_log.csv'
        event_log_df.to_csv(output_filename, index=False)
        print(fclass="hl-string">"Extraction complete. Event log saved to {output_filename}")
    else:
        print(class="hl-string">"No data extracted.")

ステップ

保守されたFreshdeskコネクターを提供し、増分抽出に対応し、データウェアハウスやフラットファイルなど必要な出力先に書き込める商用ETLプラットフォームを選択します。コネクターのバージョンが、チケット、会話、エージェント、チケット履歴または監査データ、SLA情報、コネクターで公開されている場合は自動化またはアンケートのレコードに対応していることを確認します。
コネクターに必要な最小限の読み取り権限を持つFreshdesk連携認証情報を作成します。FreshdeskアカウントURL、認証方式、認証情報、ワークスペースまたはアカウントの範囲、コネクター固有のオブジェクトを、［Configure based on your system］を使用して構成します。エクスポートした構成ファイルに認証情報を含めないでください。
チケット、会話、エージェント、チケット履歴または監査レコード、SLAレコード、利用可能な場合はアンケートまたは自動化レコードの抽出オブジェクトを構成します。ページネーション、再試行処理、レート制限処理を有効にし、ソースシステムが対応する更新タイムスタンプまたはコネクターの増分同期機能を使用して増分抽出を設定します。
抽出期間を［Start date］から［End date］までに設定し、通常は3～6か月を対象にします。増分実行ではルックバック期間を設け、遅れて到着する会話、ステータス変更、SLA更新、アンケートレコードを取りこぼさないようにします。変換前の生のコネクター出力を［Your raw landing location］に保存します。
［Your staging table name］または同等のETLコンポーネントを使用して、生のデータをステージングデータセットに標準化します。ソースチケット識別子、ソースレコード識別子、イベントタイムスタンプ、イベントタイプ、実行者、担当エージェント、依頼タイプ、ステータス、優先度を保持します。すべてのタイムスタンプを合意した1つのタイムゾーン、できればUTCに変換し、利用可能な場合は元のタイムゾーンも保持します。
明示的に利用できるアクティビティごとに1つのイベント行を作成します。チケット作成をTicket Created、担当者変更をTicket Assigned、最初の公開エージェント返信をFirst Response Sent、Pendingへのステータス変更をStatus Changed to Pending、顧客からの返信をCustomer Responded、エージェントの非公開メモをInternal Note Added、優先度変更をTicket Priority Changed、その後の担当者変更をTicket Reassigned、SLA違反をSLA Breached、Resolvedへのステータス変更をTicket Resolved、解決後の再オープンをTicket Reopened、記録されたアンケート送信をSatisfaction Survey Sent、Closedへのステータス変更をTicket Closedにマッピングします。
記録されていないイベントを推測せず、イベント固有のルールを適用します。Ticket Assignedは初回の割り当てを表し、Ticket Reassignedは以前の担当者またはグループからの後続の変更を表す必要があります。First Response Sentは、チケット作成後に行われた最初の公開エージェント返信である必要があります。SLA Breachedは、明示的なSLA違反または同等のソースステータスがある場合に限り導出できます。Satisfaction Survey Sentは、送信または自動化アクションを明示的に取得できる場合に限り含めます。
すべてのイベント固有データセットを結合し、必須列ServiceRequest、Activity、EventTimeと、推奨列AssignedAgent、ServiceRequestType、Status、Priorityを含む1つのイベントログにします。利用できる場合は安定したソースイベント識別子を使用し、完全に重複するソースイベントレコードだけを削除します。同じタイムスタンプを持つ異なるイベントをまとめないでください。
出力をServiceRequestとEventTimeで並べ替え、利用できる場合は安定したソースイベント順序またはソースレコード識別子でも並べ替えます。すべての行でServiceRequestとEventTimeが入力されていること、Activityに文書化されたアクティビティ名だけが含まれていること、すべてのタイムスタンプが合意した形式であることを検証します。
最終イベントログをUTF-8 CSV、Parquet、またはProcessMindが対応する出力形式でエクスポートします。ファイルまたは出力先データセットをProcessMindにアップロードまたは接続し、ServiceRequestをケース識別子、Activityをアクティビティフィールド、EventTimeをイベントタイムスタンプとしてマッピングします。その後、必要なすべてのアクティビティが明示的なイベント行として含まれていることを確認します。

設定

コネクターの範囲：[システムに応じて設定]を使い、Freshdeskアカウント、ワークスペース、またはテナントの範囲を設定します。コネクターで公開されている場合は、チケット、会話、エージェント、チケット履歴または監査レコード、SLAレコード、アンケートまたは自動化レコードを抽出します。
認証：対応している場合は、読み取り専用の専用連携用認証情報を使用します。認証情報はETLプラットフォームの安全な接続マネージャーに保存し、承認された管理者だけがアクセスできるようにします。
日付範囲：まずは3～6か月分の履歴から始めます。増分ロードでは、コネクターがサポートするカーソルまたは更新日時を使用し、後から到着したレコードや修正されたレコードを取得できるようルックバック期間を設けます。
必須出力フィールド：すべてのイベント行でServiceRequest、Activity、EventTimeを入力する必要があります。
推奨出力フィールド：利用可能な場合はAssignedAgent、ServiceRequestType、Status、Priorityを保持します。履歴値は現在のチケット状態から推測せず、イベントレコードまたは該当するチケット履歴レコードから取得します。
アクティビティフィルター：Ticket Created、Ticket Assigned、First Response Sent、Status Changed to Pending、Customer Responded、Internal Note Added、Ticket Priority Changed、Ticket Reassigned、SLA Breached、Ticket Resolved、Ticket Reopened、Satisfaction Survey Sent、Ticket Closedに必要なすべてのソースレコードを含めます。
イベントルール：最終的なチケット状態からイベントを推測しないでください。明示的なステータス変更、担当変更、会話タイプ、SLA違反レコード、記録されたアンケートアクションを、それぞれ別の行として抽出します。
タイムスタンプの処理：EventTimeをUTCまたは別途合意したタイムゾーンに統一します。監査に備え、利用可能な場合はステージングでソースのタイムスタンプとソースのタイムゾーンを保持します。
保存先：[保存先テーブル名]または[出力ファイル名]を使用します。イベントマッピングを監査して再実行できるよう、生データ層と変換済みデータ層を保持します。
パフォーマンス：ページネーション、増分同期、Freshdeskコネクターのレート制限内での並列処理、バックオフ付きの再試行、対応している場合は更新日によるパーティション分割を有効にします。会話と履歴の全データ量を繰り返し抽出することは避けてください。
重複排除：利用可能な場合は、コネクターの安定したソースレコード識別子を使用します。再試行による完全な再送レコードは重複排除しますが、タイムスタンプと値が同一でも、異なる業務イベントは保持します。
前提条件：ライセンス済みのETLプラットフォーム、対応するFreshdeskコネクター、有効なFreshdesk連携用認証情報、必要なFreshdeskオブジェクトへのアクセス権、保存先への書き込み権限、十分なAPIまたはコネクターの割り当て量が必要です。
利用可能性に関する注意：コネクターのオブジェクト名、フィールド名、履歴の対象範囲、SLAの公開状況、アンケートまたは自動化の対象範囲は、ETL製品とFreshdeskプランによって異なります。本番利用前に、[システムに応じて設定]を使ってマッピングを設定し、コネクターのスキーマと照合してください。

a サンプルクエリ json

SELECT
    ServiceRequest,
    Activity,
    EventTime,
    AssignedAgent,
    ServiceRequestType,
    Status,
    Priority
FROM [Your transformed event log source]
WHERE EventTime >= [Start date]
  AND EventTime < [End date]
  AND Activity IN (
      'Ticket Created',
      'Ticket Assigned',
      'First Response Sent',
      'Status Changed to Pending',
      'Customer Responded',
      'Internal Note Added',
      'Ticket Priority Changed',
      'Ticket Reassigned',
      'SLA Breached',
      'Ticket Resolved',
      'Ticket Reopened',
      'Satisfaction Survey Sent',
      'Ticket Closed'
  )
  AND ServiceRequest IS NOT NULL
  AND EventTime IS NOT NULL
ORDER BY ServiceRequest, EventTime;

今すぐ始めませんか？

プロセスを明確に把握し、カスタマーサービス業務の変革を始めましょう。このテンプレートは、データに基づく最適化に向けた最初の一歩です。

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

Freshdeskのカスタマーサービスを今すぐ最適化

初回対応での解決率80％を達成し、顧客満足度を高めましょう。

無料トライアルを開始

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

カスタマーサービスのデータテンプレート

カスタマーサービスのデータテンプレート

カスタマーサービスの属性

カスタマーサービスのアクティビティ

抽出ガイド

FreshdeskネイティブチケットデータのCSVエクスポート

ステップ

設定

a サンプルクエリ json

Freshdesk REST APIを使用したPythonスクリプトによる抽出

ステップ

設定

a サンプルクエリ python

Freshdeskコネクターを備えたサードパーティETLツール

ステップ

設定

a サンプルクエリ json

今すぐ始めませんか？

Freshdeskのカスタマーサービスを今すぐ最適化

カスタマーサービスのデータテンプレート

カスタマーサービスのデータテンプレート

カスタマーサービスの属性

カスタマーサービスのアクティビティ

抽出ガイド

FreshdeskネイティブチケットデータのCSVエクスポート

ステップ

設定

a サンプルクエリ json

Freshdesk REST APIを使用したPythonスクリプトによる抽出

ステップ

設定

a サンプルクエリ python

Freshdeskコネクターを備えたサードパーティETLツール

ステップ

設定

a サンプルクエリ json

今すぐ始めませんか？

Freshdeskのカスタマーサービスを今すぐ最適化

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