> 継続的なプロセス改善 > カスタマーサービス > 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	特定のアクティビティまたはイベントが発生した時刻を示すタイムスタンプです。
説明イベント時刻、つまりタイムスタンプには、アクティビティが発生した正確な日時が記録されます。イベントを時系列に並べたり、プロセス内の各ステップにかかった時間を算出したりするうえで重要です。記録するすべてのアクティビティに、対応するタイムスタンプが必要です。分析では、この属性を使ってサービス依頼ごとのタイムラインを作成します。解決時間、初回応答時間、ボトルネックの継続時間など、時間に関するすべての重要業績評価指標を算出する基礎となります。正確なタイムスタンプは、プロセスの実績を把握し、遅延を特定するために欠かせません。重要な理由このタイムスタンプは、イベントを時系列に並べ、サイクルタイムやSLA遵守状況など、時間に基づくすべての指標を算出するうえで欠かせません。入手先 Freshdesk APIでチケットのイベント、返信、ステータス変更に関連付けられた「created_at」または「updated_at」フィールドに該当します。例 2023-10-25T10:00:00Z2023-10-25T10:05:14Z2023-10-26T14:30:00Z
	サービス依頼 ServiceRequest	1件の顧客からの問い合わせや問題を識別する一意のIDです。一般にチケットまたはケースと呼ばれます。
説明サービス依頼は、1件の顧客とのやり取りに関連するすべてのアクティビティを結び付ける、主要なケース識別子です。顧客から新しい問い合わせ、問題、依頼があるたびに、一意のサービス依頼IDが発行されます。このIDは、チケットの作成から割り当て、解決、終了まで変わりません。プロセスマイニングでは、この属性を使って顧客ケースごとのエンドツーエンドの流れを再構成します。関連するすべてのイベントを1つのサービス依頼IDにまとめることで、分析担当者はプロセスの流れを可視化し、サイクルタイムを測定して、個々のケースに影響するばらつきやボトルネックを特定できます。重要な理由関連するすべてのイベントを1つのプロセスインスタンスに結び付け、カスタマーサービスの対応経路を全体的に把握するための、基本となるケースIDです。入手先 Freshdeskの主要なチケットIDです。通常は「Tickets」APIエンドポイントの「id」フィールドにあります。例 SR-2023-10-4831SR-2023-11-0192SR-2023-11-5210
	サービス依頼の種類 ServiceRequestType	「質問」「インシデント」「問題」「機能のリクエスト」など、サービス依頼の分類です。
説明サービス依頼の種類は、顧客からの問い合わせの内容を定義する重要な分類項目です。通常、チケットの作成時または初期の振り分け時に設定され、適切なチームや担当者への割り当てに役立ちます。分析では、この属性を使ってプロセスを分類し、依頼の種類ごとの対応状況を把握できます。「インシデントは質問より解決に時間がかかるか」「再オープンが最も多い依頼の種類は何か」といった問いに答えられます。この分類は、種類ごとのボトルネックを特定し、それに応じてワークフローを改善するうえで重要です。重要な理由プロセスを分類し、インシデントと質問など、顧客の問題の種類ごとに実績やワークフローを比較できます。入手先 Freshdeskの「Tickets」オブジェクトにある「type」フィールドに該当する可能性があります。例質問インシデント問題機能リクエスト
	ステータス Status	サービスリクエストの現在または過去のステータスです。「オープン」「保留中」「解決済み」「クローズ」などがあります。
説明ステータス属性は、特定の時点におけるサービスリクエストの状態を示します。ステータスの変更は、プロセスの重要な節目を表すことがよくあります。たとえば、顧客からの情報を待つ間に「オープン」から「保留中」に変わり、顧客から返信があると「保留中」から「オープン」に戻る場合があります。ステータスの変化を追跡することは、チケットのライフサイクルを把握するうえで欠かせません。チケットが特定の状態にとどまる時間を確認できるため、ボトルネックの特定に役立ちます。たとえば、「保留中」の状態が長く続く場合、顧客からの情報取得に遅れが生じている可能性があります。重要な理由ステータスの変化を追跡すると、チケットのライフサイクルを把握し、「保留中」や「対応待ち」などの状態に案件がとどまる時間を特定できます。入手先 Freshdeskの「Tickets」オブジェクトにある「status」フィールドに対応します。過去のステータスは、アクティビティログから推定する必要があります。例オープン保留中解決済みクローズ
	優先度 Priority	サービスリクエストに設定された優先度です。「低」「中」「高」「緊急」などがあります。
説明優先度属性は、サービスリクエストの緊急度を示し、目標とする初回応答時間や解決時間を左右することがよくあります。優先度は、ルールに基づいて自動設定される場合と、担当者がトリアージ時に手動で設定する場合があります。この属性は、SLAの適合性やリソース配分を分析するうえで欠かせません。プロセスマップを優先度で絞り込むと、優先度の高いチケットが低いチケットより実際に早く処理されているかを確認できます。また、手戻りの一種である優先度の変更がどの程度発生しているか、その変更がプロセスにどのような影響を与えるかも把握できます。重要な理由 SLA分析や、優先度の高い問題に低い問題より多くのリソースを適切に割り当て、迅速に対応できているかの確認に役立ちます。入手先 Freshdeskの「Tickets」オブジェクトにある「priority」フィールドに対応します。例低中高緊急
	担当者 AssignedAgent	イベント発生時にチケットを担当していたカスタマーサービス担当者の名前またはIDです。
説明この属性は、サービス依頼を担当する個々の担当者を識別します。チケットのライフサイクル中に、再割り当てやエスカレーションによって担当者が変わる場合があります。担当者別のデータ分析は、実績管理用ダッシュボードで重要です。平均解決時間、チケット件数、再オープン率など、担当者ごとの重要業績評価指標を測定できます。成果を上げている担当者の特定や研修ニーズの把握、担当者間の移管が全体の解決時間に与える影響の分析にも役立ちます。重要な理由担当者ごとの実績を分析し、成果を上げている担当者や研修の機会、再割り当ての影響を特定できます。入手先 Freshdeskの「Tickets」オブジェクトにある「responder_id」フィールドに該当します。このフィールドを担当者の詳細情報と結合できます。例アリス・ジョンソンロバート・スミスマリア・ガルシア
	SLA未達かどうか IsSlaBreached	サービスリクエストの解決時間がSLA目標を超えたかどうかを示す真偽値です。
説明この計算属性は、サービスリクエストごとのSLA適合状況を明確に示します。実際の「ResolutionTime」と「SlaTargetResolutionTime」を比較して算出し、実際の時間が目標を超えた場合はtrueになります。この属性により、SLAの適合性を簡単に分析し、ダッシュボードに表示できます。SLA未達のチケットを集計・絞り込み、未達の規模をすばやく把握できます。また、未達チケットのプロセスパターンをドリルダウンして原因を調べられます。「SLA Compliance Overview」ダッシュボードとKPIを直接支援します。重要な理由目標を達成できなかった案件を明確に示すため、SLAの適合性を簡単に分析でき、未達の原因調査にも役立ちます。入手先 Freshdeskの実際の解決日時と「SlaTargetResolutionTime」または「due_by」フィールドを比較して算出するフィールドです。例 truefalse
	SLA目標解決時間 SlaTargetResolutionTime	サービスリクエストの解決について、契約で合意された時間または目標時間です。
説明この属性は、サービスレベル契約（SLA）に基づき、サービスリクエストを解決するまでの目標時間を定めます。目標時間は、チケットの優先度や種類によって異なることがあります。 SLAの適合性を算出する際の基準となる属性です。実際の解決時間と目標時間を比較し、SLAを「達成」したか「未達」だったかを判定できます。リクエストの種類、チーム、担当者ごとのSLA実績を分析することは、サービス管理の中核となります。重要な理由 SLAの適合性を測定する基準となり、顧客サービスを担う組織の重要な業績評価指標です。入手先 Freshdeskの「Tickets」オブジェクトに「fr_due_by」（初回応答）や「due_by」（解決）などのフィールドがあれば利用できます。ない場合は、SLAポリシーのルールに基づいて算出する必要があります。例 2023-10-25T14:00:00Z2023-10-27T09:00:00Z2023-11-01T17:00:00Z
	ソースシステム SourceSystem	データの抽出元となるシステムです。この場合は「Freshdesk」です。
説明この属性は、プロセスデータの発生元となるソースアプリケーションを示します。この分析では、「Freshdesk」などの固定値を設定し、すべてのイベントがFreshdeskのカスタマーサービスプラットフォームから取得されたことを示します。単純な属性に見えますが、データガバナンスや複数のシステムのデータを統合する場合に重要です。データの出所とコンテキストが明確になり、分析担当者が対象データの発生元を把握できます。データの整合性を保ち、分析への信頼を確立するうえで欠かせません。重要な理由データの発生元に関する重要なコンテキストを示します。データガバナンスや複数のソースシステムのデータを統合する際に欠かせません。入手先データ変換の際に追加する固定値「Freshdesk」で、データソースを識別します。例 Freshdesk
	再オープンされたかどうか IsReopened	解決済みのサービスリクエストが再オープンされたことがあるかを示す真偽値です。
説明この案件単位の属性は、サービスリクエストのライフサイクル中に「Ticket Reopened」アクティビティが発生した場合にtrueとなるフラグです。手戻りが発生した案件を簡単に特定し、分析できます。再オープンされるチケットの割合が高い場合、最初の解決が不十分または不完全で、業務の非効率や顧客の不満につながっている可能性があります。再オープンされたチケットに絞り込むと、再オープンの主な理由、割合の高い担当者やチーム、再オープンされやすいチケットの種類など、原因を調査できます。重要な理由手戻りが発生した案件を特定できます。解決の品質やプロセスの非効率を示す重要な指標です。分析結果は、初回対応での解決率の向上に役立ちます。入手先計算フィールドです。該当するサービスリクエストに、Activity = 'Ticket Reopened'のイベントが存在する場合にtrueになります。例 truefalse
	最終データ更新日時 LastDataUpdate	ソースシステムからデータを最後に更新した日時を示すタイムスタンプです。
説明この属性には、Freshdeskからデータセットを最後に抽出または更新した日時が記録されます。分析対象のデータがどの程度新しいかを明確にできるため、適切なタイミングで関連性の高い業務判断を行ううえで重要です。分析担当者はこの情報を使って、データが対象とする期間を把握し、利用可能な最新の情報を使っていることを確認できます。プロセスマイニングのダッシュボードやレポートに欠かせないメタデータであり、関係者がデータの更新時期を把握するのに役立ちます。重要な理由データの新しさを示し、最新の情報に基づいて分析や判断を行えるようにします。入手先データ抽出時に生成され、データを取得した時刻を記録するメタデータフィールドです。例 2023-12-01T08:00:00Z
	初回応答時間 FirstResponseTime	チケットの作成から担当者が顧客に初めて応答するまでの時間です。
説明初回応答時間は、サービス担当者が顧客に自動応答以外の最初の返信を行うまでの速さを測定します。「First Response Sent」アクティビティと「Ticket Created」アクティビティのタイムスタンプの差から算出します。このKPIはサービスの応答性を示す重要な指標であり、顧客満足度に大きく影響します。初回応答が早ければ、顧客は問題が受け付けられ、対応が始まっていると確認できます。この指標を分析すると、初回応答に関するSLAの達成状況や、顧客への迅速な対応を確認できます。重要な理由サービスの応答性を測定します。顧客満足度を左右する重要な要素であり、先回りしたサービス提供の目標にも直結します。入手先計算フィールドです。「Ticket Created」イベントと「First Response Sent」イベントのタイムスタンプ間の時間を示します。例 3000009000001800000
	問い合わせチャネル CommunicationChannel	サービスリクエストが寄せられたチャネルです。「メール」「電話」「チャット」「Webポータル」などがあります。
説明この属性は、顧客とのやり取りが始まった経路やチャネルを示します。チャネルによってプロセスの流れや解決時間は異なる場合があります。たとえば、チャットで寄せられたリクエストは、メールで送信されたものより短時間で解決できることがあります。問い合わせチャネルごとにプロセスを分析すると、リソース配分の見直しやチャネルごとの効率の把握に役立ちます。解決が早いチャネルや顧客満足度の高いチャネルが明らかになり、どのチャネルを推進・強化するかを判断する材料になります。重要な理由メール、電話、チャットなど、顧客とのさまざまな連絡チャネルにおけるプロセスの実績と効率を分析できます。入手先 Freshdeskの「Tickets」オブジェクトにある「source」フィールドに対応します。例メール電話Webポータルチャット
	担当グループ AssignedGroup	サービスリクエストの担当先となるチームまたは部門です。
説明担当グループは、特定のサービスリクエストを処理する担当者のチームを示します。チケットは、種類や複雑さに応じて「テクニカルサポート」や「請求部門」などの専門グループに振り分けられることがあります。この属性は、部門間の引き継ぎやチーム単位の実績を分析する際に役立ちます。各グループが処理するチケット数、解決までにかかる時間、グループ間でチケットが転送される頻度を把握できます。こうした情報は、チーム体制やワークフローを見直すうえで重要です。重要な理由チームや部門ごとの実績を分析し、引き継ぎの状況やグループ固有のボトルネックを特定できます。入手先 Freshdeskの「Tickets」オブジェクトにある「group_id」フィールドに対応します。例一次サポート二次テクニカルサポート請求カスタマーサクセス
	担当者間の転送回数 AgentTransferCount	サービスリクエストの担当者が別の担当者に変更された合計回数です。
説明この属性は案件単位の指標で、チケットの担当者が変更された回数を数えます。サービスリクエストごとに「Ticket Reassigned」アクティビティの発生回数を数えて算出します。頻繁な転送、いわゆる「たらい回し」は、引き継ぎのたびにコンテキストが失われ、対応の遅れや顧客の不満につながることがあります。転送回数を分析すると、最初の振り分けの問題、担当者のスキル不足、プロセスの複雑さなどを特定できます。不要な転送を減らし、効率と顧客満足度を高めることが目標です。重要な理由社内での引き継ぎ頻度を測定します。遅延や顧客の不満につながる主な要因を把握し、一次対応での解決率向上に役立てられます。入手先計算フィールドです。サービスリクエストごとの「Ticket Reassigned」アクティビティの回数です。例 0132
	製品 Product	顧客のリクエストに関連する製品またはサービスです。
説明この属性は、サービスリクエストの対象となる製品またはサービスの種類を示します。チケットの振り分けやレポート作成のため、Freshdeskでカスタムフィールドとして設定されていることがよくあります。製品別にプロセスを絞り込むと、製品固有の問題を見つけられます。たとえば、特定の製品にサポートチケットが偏っていないか、新製品の発売によって問い合わせが急増していないかを確認できます。分析結果は、製品開発や製品管理のチームにとって有益な情報となります。重要な理由製品分野ごとにプロセスを絞り込み、サポートリクエストが多い製品や解決に時間がかかる製品を把握できます。入手先通常はカスタムフィールドです。正確な場所はFreshdeskの設定によって異なりますが、「Tickets」APIレスポンスの「custom_fields」に含まれている可能性があります。例アルファプラットフォームベータモバイルアプリガンマサブスクリプション
	顧客名 CustomerName	サービスリクエストを送信した顧客の名前またはIDです。
説明この属性は、サービスリクエストに関連する顧客を特定します。顧客ごとの視点でプロセスを分析し、特定の顧客とのやり取りを時系列で追跡できます。顧客別に分析すると、チケットの送信数が多い顧客や、再オープンが頻発する顧客などの傾向が明らかになります。顧客サクセス施策の検討や、サービス体験の低下による解約リスクがある顧客の特定にも役立ちます。また、複数のサービスリクエストにまたがる顧客体験の全体像を把握するうえでも重要です。重要な理由顧客ごとの視点でプロセスを確認でき、問い合わせの多い顧客や問題が繰り返し発生している顧客を特定できます。入手先この情報は「Tickets」オブジェクトの「requester_id」を介して関連付けられ、Freshdeskの「Contacts」または「Users」オブジェクトに接続されます。例山田太郎佐藤花子グローバルテック株式会社
	顧客満足度評価 SatisfactionRating	チケットの解決後に顧客が回答した満足度スコアです。
説明顧客満足度評価は、プロセスの成果を示す重要な指標です。通常、チケットの解決後に送信するアンケートで収集し、数値スコアまたは「満足」「どちらでもない」「不満」などの評価で表します。この属性を使うと、プロセスのパターンと顧客の評価を関連付けて分析できます。満足度が低くなるプロセスのバリアントを調べることで、顧客体験に悪影響を与える行動や遅延を特定できます。プロセスの効率と顧客満足度の関係を直接確認できます。重要な理由プロセスの実行状況と顧客の評価を結び付け、顧客満足度の高低につながるプロセス上の行動を特定できます。入手先このデータはFreshdeskの顧客満足度評価機能に含まれており、「Surveys」または「Satisfaction Ratings」APIエンドポイントから取得できます。例 5314

必須推奨任意

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

プロセスを正確に把握し、ボトルネックを特定するために、イベントログに記録すべき主なプロセスの手順と重要な節目です。

5 推奨 8 任意

	アクティビティ	説明
	チケット作成	カスタマーサービスの流れにおける最初のイベントで、顧客の依頼がFreshdeskに正式に記録された時点を示します。メール、ポータル、電話、API連携のいずれかを通じて新しいチケットが作成されると、このアクティビティが明示的に記録されます。
重要な理由このアクティビティは、すべてのケースの開始点です。全体の解決時間の算出や、チャネル別・種類別のチケット件数の傾向分析に欠かせません。入手先 Freshdeskの「Ticket Activities」ログに明示的なイベントとして記録されます。新しいチケットレコードの作成時に自動で生成されます。記録作成時にチケットのアクティビティ履歴へ直接記録されます。イベントタイプ explicit
	チケット割り当て	チケットを対応する担当者またはグループに割り当てたことを示します。担当者またはグループのフィールドに値が入力されたときや、値が変更されたときに、チケットの履歴に明示的に記録されます。
重要な理由割り当てを追跡すると、担当者の業務量の分析、振り分けの非効率な箇所の特定、割り当てまでの時間に関する重要業績評価指標の測定に役立ちます。業務の分担状況や、対応開始前に遅延が生じている箇所も把握できます。入手先「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
	チケットの再割り当て	最初の割り当て後に、チケットが別の担当者またはグループへ移管されると発生します。担当者の変更として、チケットのアクティビティログに明示的に記録されます。
重要な理由再割り当てが頻繁に発生する場合や、担当者間の移管率が高い場合、最初の振り分けが適切でないか、知識が組織内で分散している可能性があります。この分析は、最初の窓口での解決率を高める機会の特定に役立ちます。入手先最初の割り当て後に「Ticket Activities」ログで記録された「Agent」または「Group」フィールドの変更から追跡します。記録最初の割り当て後に「Assigned to」フィールドが再度更新されたことを示します。イベントタイプ explicit
	チケット再オープン	ステータスが「Resolved」のチケットに顧客が返信すると発生し、ステータスは自動的に「Open」に戻ります。システムによって明示的に記録されるイベントです。
重要な理由再オープン率が高い場合、最初の解決策が十分に機能せず、手戻りや顧客の不満につながっている可能性があります。このアクティビティの分析は、「Ticket Re-opening Analysis」と最初の窓口での解決率の改善に欠かせません。入手先顧客からの返信によってステータスが「Resolved」から「Open」に自動変更されたときに記録されます。このステータス変更は「Ticket Activities」ログに残ります。記録顧客とのやり取りをきっかけに、「Resolved」から「Open」へステータスが変更されたことを示します。イベントタイプ explicit
	内部メモ追加	担当者が、ほかの担当者との社内連携を目的として、チケットに非公開メモを追加します。このイベントはチケットのアクティビティ履歴に明示的に記録され、担当者だけが閲覧できます。
重要な理由内部メモを追跡すると、連携のパターンを分析し、社内での十分な検討が必要な問題を特定できます。解決までに内部メモが頻繁に追加されている場合、問題が複雑であるか、知識が不足している可能性があります。入手先チケットの会話履歴に「Private Note」として記録され、顧客向けの公開返信と区別できます。記録担当者が「Private」としてメモを追加したときに記録されるイベントです。イベントタイプ explicit
	満足度アンケート送信	顧客満足度アンケートの送信を示します。通常はチケットの解決後に自動化ルールで送信されます。自動化の処理がチケットの履歴に記録されている場合、このイベントを取得できます。
重要な理由フィードバック収集の開始を示します。アンケートの回答とプロセスのバリアントを関連付けると、プロセスの実績が顧客満足度に与える影響を詳しく把握できます。入手先通常は「Automation Rule」によって実行されます。チケットのアクティビティログに個別のイベントとして表示されるかどうかは、Freshdeskの自動化に関するログ設定によって異なります。記録チケット解決後に自動化ルールが実行されたときに記録されるイベントです。イベントタイプ explicit
	顧客からの返信	顧客から新しい返信や連絡を受けたことを示します。チケットの会話スレッドに明示的なイベントとして記録され、通常はステータスが「Pending」から「Open」に変わります。
重要な理由このアクティビティは、顧客とのやり取りが繰り返される状況の把握や、顧客の応答時間の測定に役立ちます。一時停止していたSLAの計測も再開されるため、コンプライアンス指標にも影響します。入手先チケットの会話スレッドに新しい項目として記録されます。このイベントは顧客の連絡先レコードに関連付けられます。記録顧客の連絡先がチケットに追加した新しい公開メモです。イベントタイプ explicit

推奨任意

データ抽出ガイド

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

ステップ

チケットの表示とエクスポートの権限を持つ管理者アカウントでFreshdeskにログインします。
左側のナビゲーションメニューからメインのチケットタブを開き、チケット一覧を表示します。
右側のチケットのフィルターパネルで、抽出するデータの範囲を指定します。最低限、たとえば過去6か月などの作成済み日付範囲を設定してください。必要に応じて、グループ、担当者、ソースなどのフィルターを追加し、対象データを絞り込みます。
フィルターを適用したら、チケット一覧の右上にある、トレイに下向き矢印が入った形のエクスポートアイコンをクリックします。
チケットのエクスポートポップアップウィンドウで、含めるフィールドを選択します。イベントログに必要な標準フィールドとカスタムフィールドをすべて選択してください。チケットID、作成日時、解決日時、クローズ日時、初回返信日時、担当者、グループ、ステータス、優先度、種類のほか、必要なカスタムフィールドも含めます。
選択内容を確定します。Freshdeskはバックグラウンドでエクスポートを処理します。データをダウンロードするためのリンクが記載されたメールが届きます。データ量が多い場合、処理に時間がかかることがあります。
メールに記載されたリンクからCSVファイルをダウンロードします。
エクスポートされたファイルには、チケットごとに1行が含まれ、現在の状態と主なタイムスタンプが記録されています。このデータからイベントログを作成するには、データの変換が必要です。
クエリのセクションにあるPythonスクリプトなどのスクリプト、またはデータ準備ツールを使い、タイムスタンプ列（作成日時、初回返信日時、解決日時、クローズ日時）を複数の行に展開します。展開後の各行が1つのアクティビティを表します。
元のタイムスタンプ列を、それぞれ対応するアクティビティ名に割り当てます。たとえば、「作成日時」列を「チケット作成」アクティビティに割り当てます。
必須列のServiceRequest、アクティビティ、EventTimeと、推奨される属性を含む最終的なイベントログCSVを作成します。
変換したファイルを、プロセスマイニングツールにアップロードできるCSV形式で保存します。

設定

権限：アカウントのチケットを表示およびエクスポートする権限を持つ管理者、またはカスタムロールが必要です。
日付範囲フィルター：履歴全体のエクスポートには時間がかかるため、「作成日時」または「クローズ日時」のフィールドで日付範囲を指定することが重要です。初回の分析では、通常3～6か月の期間を推奨します。
チケットのフィールド：エクスポート画面では、含めるフィールドを選択できます。イベントログの基礎となる「作成日時」「初回返信日時」「解決日時」「クローズ日時」など、利用可能なすべてのタイムスタンプフィールドを選択してください。また、「チケットID」などの識別フィールドと、「担当者」「グループ」「優先度」「種類」などのコンテキストフィールドも含めます。
データ量：一度にエクスポートできるチケット数には上限があり、通常は30,000件です。これを超えるデータセットでは、たとえば月ごとに期間を分けて複数回エクスポートする必要があります。
納品：エクスポートは非同期で処理されます。CSVファイルは直接ダウンロードされず、エクスポートを開始したユーザーのメールアドレスにダウンロードリンクが送信されます。

クエリの例 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キーの取得：管理者としてFreshdeskにログインします。右上のプロフィールアイコンをクリックし、「プロフィール設定」を選択します。APIキーは画面右側に表示されます。キーを安全にコピーしてください。
Pythonスクリプトの準備：新しいPythonファイル（例：extract_freshdesk.py）を作成します。「クエリ」セクションにある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応答を解析し、「チケット作成」「ステータスを保留中に変更」「チケット解決」など、必要な13種類のアクティビティを個別のレコードとして作成します。
出力の確認：スクリプトが完了すると、同じディレクトリにfreshdesk_event_log.csvが作成されます。このファイルには、抽出したアクティビティと属性を含む構造化イベントログが格納されます。
アップロードの準備：作成されたCSVファイルを開き、想定したデータが含まれていることを確認します。ServiceRequest、アクティビティ、EventTimeの各列があり、値が正しく入力されていることを確認してください。これでProcessMindにアップロードできます。

設定

前提条件：APIキーを取得し、チケットデータにフルアクセスするには、管理者権限を持つ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パラメーターを使い、解決時間や応答時間などのメタデータも効率的に取得します。

クエリの例 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、認証方式、認証情報、ワークスペースまたはアカウントの範囲、コネクター固有のオブジェクトを設定します。エクスポートした設定ファイルに認証情報を含めないでください。
チケット、会話、担当者、チケット履歴または監査レコード、SLAレコード、取得可能な場合はアンケートまたは自動化のレコードを抽出対象に設定します。ページネーション、再試行、レート制限への対応を有効にし、ソースシステムが対応する更新日時またはコネクターの差分同期機能を使って差分抽出を設定します。
抽出期間を[開始日]から[終了日]までに設定します。通常は3～6か月分を対象とします。差分実行では、後から届く会話、ステータス変更、SLA更新、アンケートレコードを取りこぼさないよう、遡及期間を設けてください。変換前のコネクター出力は[生データの格納先]に保存します。
[ステージングテーブル名]または同等のETLコンポーネントを使い、生データを標準化してステージングデータセットを作成します。ソースのチケットID、ソースレコードID、イベントのタイムスタンプ、イベントの種類、実行者、割り当てられた担当者、リクエストの種類、ステータス、優先度を保持してください。すべてのタイムスタンプを合意した1つのタイムゾーン、できればUTCに統一し、取得可能な場合は元のタイムゾーンも保持します。
明示的に取得できるアクティビティごとにイベント行を作成します。チケットの作成は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を含むイベントログを作成します。安定したソースイベントIDがある場合は、それを使って完全に重複するソースイベントレコードのみを削除してください。同じタイムスタンプの異なるイベントはまとめないでください。
出力をServiceRequest、EventTimeの順に並べ、可能な場合は安定したソースイベントの順序またはソースレコードIDで並べます。すべての行にServiceRequestとEventTimeが入力されていること、Activityが文書化されたアクティビティ名のみであること、すべてのタイムスタンプが合意した形式であることを検証してください。
最終的なイベントログをUTF-8のCSV、Parquet、またはProcessMindが対応する出力形式でエクスポートします。ファイルまたは出力先のデータセットをProcessMindにアップロードまたは接続し、ServiceRequestをケースID、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コネクターのレート制限内での並列処理、バックオフを伴う再試行、対応している場合は更新日によるパーティション分割を有効にします。会話と履歴の全データを繰り返し抽出することは避けてください。
重複排除：取得可能な場合は、コネクターの安定したソースレコードIDを使用します。再試行による完全な重複レコードは削除しますが、タイムスタンプと値が同じでも、別々の業務イベントは保持してください。
前提条件：ライセンスを取得したETLプラットフォーム、対応するFreshdeskコネクター、有効なFreshdesk連携認証情報、必要なFreshdeskオブジェクトへのアクセス権、出力先への書き込み権限、十分なAPIまたはコネクターの利用枠が必要です。
利用可否に関する注意：オブジェクト名、フィールド名、履歴の対象範囲、SLAの取得可否、アンケートまたは自動化の取得範囲は、ETL製品やFreshdeskのプランによって異なります。[お使いのシステムに合わせて設定]を使って割り当てを設定し、本番環境で使用する前にコネクターのスキーマと照合してください。

クエリの例 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エクスポート

ステップ

設定

クエリの例 json

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

ステップ

設定

クエリの例 python

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

ステップ

設定

クエリの例 json

始める準備はできましたか？

Freshdeskのカスタマーサービスを今すぐ改善