サービスリクエスト管理データテンプレート
サービスリクエスト管理データテンプレート
- 包括的な分析のための推奨属性
- 追跡すべき主要なサービスリクエストアクティビティ
- Zendesk Supportデータ抽出ガイド
サービスリクエスト管理の属性
| 名前 | 説明 | ||
|---|---|---|---|
|
アクティビティ
ActivityName
|
サービスリクエストに対して発生したビジネスアクティビティまたはイベントの名称。 | ||
|
説明
アクティビティは、サービスリクエストのライフサイクルにおける個別のステップやイベントを表します。例えば、「サービスリクエスト作成済み」、「エージェントにリクエスト割り当て済み」、「サービスリクエスト解決済み」などです。これらのアクティビティは、Zendeskチケットの監査ログに記録された変更から派生しており、ステータス、担当者、優先度などのフィールドの変更やコメントの追加を追跡します。 アクティビティの分析はプロセスマイニングの核となります。これにより、プロセスマップの可視化、ステップ間のボトルネックの特定、および手戻りループの分析が可能になります。アクティビティの順序と頻度を理解することで、組織は非効率性を特定し、プロセス改善の機会を見つけることができます。
その重要性
この属性はプロセスのステップを定義し、プロセスマップの可視化、プロセスフロー、バリエーション、コンプライアンスの分析を可能にします。
取得元
これはZendesk Ticket Audits APIにログされたイベントから概念的に派生します。例えば、「status」フィールドが「new」から「open」に変わったことは、「リクエスト選別済み」のようなアクティビティにマッピングできます。
例
サービスリクエスト作成済みエージェント再割り当て済みサービスリクエスト解決済み
|
|||
|
サービスリクエストID
ServiceRequestId
|
Zendesk内の各サービスリクエストチケットの一意の識別子。 | ||
|
説明
サービスリクエストIDは、ZendeskではチケットIDと呼ばれることが多く、各ケースのプライマリキーとして機能します。これは、リクエストが作成された瞬間からクローズされるまで、関連するすべてのアクティビティ、コメント、ステータス変更を紐付けます。これにより、単一のリクエストの完全なエンドツーエンドのライフサイクルを追跡できます。 プロセスマイニング分析において、この属性は非常に重要です。ケースを定義し、プロセスフローの再構築、バリアントの特定、サイクル時間などのケースレベルメトリクスの計算を可能にします。データセット内のすべてのイベントは、プロセス全体におけるコンテキストを理解するために、サービスリクエストIDに関連付けられている必要があります。
その重要性
これは、サービスリクエストのジャーニーにおけるすべてのイベントを繋ぐ必須のケース識別子であり、エンドツーエンドのプロセス分析を可能にします。
取得元
Zendesk Tickets API、「id」フィールド。
例
102451024610247
|
|||
|
開始時刻
EventTimestamp
|
アクティビティが発生した正確な日時。 | ||
|
説明
イベントタイムスタンプ、または開始時刻は、アクティビティが発生した正確な瞬間を記録します。例えば、エージェントが割り当てられた時、公開返信が送信された時、またはチケットのステータスが「解決済み」に変更された時などを捕捉します。この時間データは、各Zendeskチケットの監査ログから取得されます。 この属性は、あらゆる時間ベースの分析にとって重要です。イベントを時系列に並べ、アクティビティ間の期間を計算し、待ち時間を測定し、ケース全体のサイクルタイムを分析するために使用されます。ボトルネックの特定や、SLAのような時間ベースの目標に対するパフォーマンス評価の基本となります。
その重要性
このタイムスタンプはイベントを時系列で並べ、すべての期間、パフォーマンス、ボトルネック分析に不可欠です。
取得元
Zendesk Ticket Audits API、各監査イベントの「created_at」フィールド。
例
2023-10-26T10:00:00Z2023-10-26T10:15:30Z2023-10-27T14:20:10Z
|
|||
|
ソースシステム
SourceSystem
|
`データ`が抽出されたシステムを示します。 | ||
|
説明
この属性は、サービスリクエストデータの発生元を指定します。このプロセスビューでは、値は常に「Zendesk Support」となり、すべてのサービス管理アクティビティの記録システムとして識別されます。 複数の統合システムを持つ環境では、このフィールドはデータリネージュとトラブルシューティングにとって不可欠です。分析が意図したシステムに正確にスコープされ、さまざまなソースからマージされたデータが区別されることを保証します。
その重要性
データの発生源システムを特定し、データリネージを保証し、複数のシステムからのデータが結合された際の混乱を防ぎます。
取得元
これは、データ抽出と変換の際に加えられる静的値(「Zendesk Support」)です。
例
Zendesk Support
|
|||
|
最終データ更新
LastDataUpdate
|
ソースシステムからデータが最後に更新されたことを示すタイムスタンプです。 | ||
|
説明
この属性は、Zendesk Supportからの最新のデータ抽出日時を記録します。これにより、分析対象データの鮮度に関するコンテキストが提供され、ユーザーは現在のプロセスビューがどれほど最新であるかを把握できます。 継続的なモニタリングとダッシュボード化にとって、この情報は不可欠です。これにより、アナリストとビジネスユーザーは、ほぼリアルタイムのデータを見ているのか、それとも以前の期間のスナップショットを見ているのかを理解でき、彼らの結論の妥当性に影響を与えます。
その重要性
データの鮮度に関する重要なコンテキストを提供し、分析がどれだけ最新であるかをユーザーに知らせます。
取得元
これは、データ抽出時にデータセットに生成され、付与されるメタデータフィールドです。
例
2023-10-27T08:00:00Z
|
|||
|
エージェント名
AgentName
|
イベント発生時にサービスリクエストに割り当てられていたエージェントの名前。 | ||
|
説明
この属性は、サービスリクエストの処理を担当するサポートエージェントを特定します。割り当てられたエージェントは、チケットのライフサイクル中に複数回変更される可能性があり、このフィールドは各ステップで誰が担当していたかを記録します。 エージェント名はパフォーマンス分析にとって極めて重要です。ワークロードの分散、エージェントごとの解決時間、再割り当ての頻度を評価するためにデータをフィルタリングおよびセグメント化できます。これにより、「エージェント&チームパフォーマンスダッシュボード」の構築を支援し、全体的なプロセス効率に対する個々の貢献を理解するのに役立ちます。
その重要性
この属性は、エージェントのパフォーマンス、ワークロードの分散、および再割り当てが解決時間に与える影響を分析するために不可欠です。
取得元
Zendesk Tickets APIレスポンスからの'assignee_id'を結合することで、Zendesk Users APIを利用します。
例
ジェーン・ドウJohn Smithエミリー・ジョーンズ
|
|||
|
サービスタイプ
ServiceType
|
サービスリクエストのカテゴリまたは種類(例:インシデント、質問、問題、タスク)。 | ||
|
説明
サービスタイプは、サービスリクエストの性質を分類します。Zendeskでは、「type」フィールドを使用して、さまざまな種類のサポートインタラクションを区別します。この初期分類は、チケットを適切なチームにルーティングし、適切なプロセスを適用するのに役立ちます。 この属性は、フィルタリングと比較に不可欠です。アナリストは、解決パスやSLAが大きく異なることが多い、さまざまな種類のリクエストのプロセスフローを調査できます。これは、特定の要求タイプを誰が最も適切に処理できるかを確認するための「エージェント&チームパフォーマンスダッシュボード」の主要な要素です。
その重要性
リクエストを分類し、インシデントと質問など、異なる経路をたどる様々なプロセスを個別に分析できるようにします。
取得元
Zendesk Tickets API、「type」フィールド。
例
質問インシデント問題タスク
|
|||
|
チケットタグ
TicketTags
|
カテゴリ分けとルーティングのためにサービスリクエストに適用されたタグのリストです。 | ||
|
説明
タグは、エージェントが手動で、またはビジネスルールによって自動的にチケットに追加できる柔軟なラベルです。これらは、タイプや優先度などの標準フィールドではカバーされない特定のコンテキストやカテゴリをチケットに追加するために使用されます。 タグは、プロセスマイニング分析において非常に汎用性の高い属性です。非常に特定のシナリオをフィルタリングしたり、カスタムワークフローを追跡したり、根本原因を特定したりするために使用できます。例えば、「VIP」タグは主要顧客のプロセス分析に使用でき、「product_bug」タグは欠陥報告のライフサイクルを追跡するために使用できます。
その重要性
データを柔軟にスライス&ダイスする機能を提供し、他のフィールドでは捕捉されない特定のサブプロセスやチケット属性に対する詳細な分析を可能にします。
取得元
Zendesk Tickets API、「tags」フィールド。これは文字列の配列です。
例
sales_inquirybilling_issuefeature_requestvip_customer
|
|||
|
リクエストステータス
RequestStatus
|
イベント発生時のサービスリクエストのステータス(例:新規、オープン、保留中)。 | ||
|
説明
リクエストステータスは、特定の時点でのチケットの状態を表します。Zendeskには、New、Open、Pending、On-hold、Solved、Closedなどのいくつかの標準ステータスがあり、これらはリクエストのライフサイクルにおける進行状況を示します。このフィールドの変更は、イベントログ内でアクティビティを作成する主要なトリガーとなります。 異なるステータスで費やされた時間を分析することは、ボトルネック分析の核となる部分です。例えば、「Pending」または「On-hold」の状態でチケットが過度に停滞している箇所を特定するのに役立ちます。ステータス遷移を理解することは、手戻りループを発見するための鍵でもあります。
その重要性
ステータスを追跡することは、リクエストの進捗状況を理解し、待機状態またはアクティブ状態に費やされる時間を特定するために不可欠です。
取得元
Zendesk Tickets API、「status」フィールド。
例
新規オープン保留中解決済みクローズ
|
|||
|
リクエストチャネル
RequestChannel
|
サービスリクエストが送信されたチャネル(例:メール、ウェブフォーム、電話)。 | ||
|
説明
この属性は、サービスリクエストの提出元を特定します。Zendeskは、チケットがメール、ウェブポータル、API連携、チャット、その他のチャネルのいずれを通じて作成されたかを記録します。これにより、顧客のインタラクション方法に関するコンテキストが提供されます。 リクエストチャネルは、分析において強力な要素です。異なるチャネル間での解決時間、満足度、手戻り率の比較を可能にすることで、「リクエストチャネル効率」ダッシュボードをサポートします。これは、企業がサポートチャネルを最適化し、ユーザーを最も効率的なチャネルに誘導するのに役立ちます。
その重要性
異なる顧客サポートチャネルの効率と成果を分析するのに役立ち、的を絞った改善を可能にします。
取得元
Zendesk Tickets API、「via」オブジェクトと、その「channel」プロパティ。
例
webemailapichat
|
|||
|
リクエスト優先度
RequestPriority
|
サービスリクエストに割り当てられた優先度レベル(例:低、通常、高、緊急)。 | ||
|
説明
リクエスト優先度は、サービスリクエストの緊急性を示す分類です。このレベルはしばしば、目標解決時間やチケットに適用されるSLAポリシーを決定します。優先度はシステムまたはユーザーによって最初に設定されることがあり、チケットのライフサイクル中にエージェントによって変更されることがあります。 この属性は、セグメンテーションと根本原因分析にとって重要です。高優先度のチケットが低優先度のチケットよりも迅速に解決されているかを分析するのに役立ち、「サービスリクエストエスカレーショントレンド」および「SLA遵守」ダッシュボードの主要な要素となります。
その重要性
リクエストを緊急度でセグメント化することを可能にし、SLAコンプライアンスの分析や重要な問題が迅速に処理されることを保証するために不可欠です。
取得元
Zendesk Tickets API、「priority」フィールド。
例
低通常高`緊急`
|
|||
|
担当チーム
AssignedTeam
|
サービスリクエストに割り当てられたサポートチームまたはグループ。 | ||
|
説明
この属性は、サポート組織内でどのチームまたはグループがサービスリクエストを担当しているかを示します。Zendeskでは、これらは「グループ」として知られています。チケットは通常、個々のエージェントが対応する前に、まずグループに割り当てられます。 割り当てられたチームによる分析は、チームレベルのパフォーマンスとワークロードを理解するために不可欠です。どのチームがどのタイプのリクエストを処理しているか、平均解決時間、SLA順守率に関する疑問に答えるのに役立ちます。これは「エージェント&チームパフォーマンスダッシュボード」の主要な要素です。
その重要性
チームのパフォーマンス、ワークロードのバランス調整、異なるサポートグループ間のルーティング効率の分析を可能にします。
取得元
Zendesk Tickets APIレスポンスからの'group_id'を結合することで、Zendesk Groups APIを利用します。
例
`Tier 1` `サポート`テクニカルサポートBilling
|
|||
|
SLAポリシー名
SlaPolicyName
|
リクエストに適用されたサービスレベル合意(SLA)ポリシーの名称。 | ||
|
説明
この属性は、サービスリクエストの目標応答時間および解決時間を規定する特定のSLAポリシーを特定します。ポリシーは通常、リクエストの優先度、タイプ、または顧客のサブスクリプションレベルなどの要因によって決定されます。 適用されたSLAポリシーを知ることは、「SLA順守および違反分析」ダッシュボードにとって不可欠です。異なるポリシーには異なる目標があるため、パフォーマンスを評価するために必要なコンテキストを提供します。これにより、チケットが特定のサービスレベル目標を達成したかどうかを公正かつ正確に評価できます。
その重要性
リクエストがどの目標セットに対して測定されたかを特定することで、SLA分析のコンテキストを提供し、正確なコンプライアンスレポート作成を可能にします。
取得元
Zendesk Ticket Metrics API。SLAデータは、チケットのメトリクスと関連付けられることが多いです。
例
緊急 - 1時間以内応答標準 - 24時間解決Premium Customer SLA
|
|||
|
SLA違反
IsSlaBreached
|
サービスリクエストがいずれかのSLA目標に違反したかどうかを示すフラグです。 | ||
|
説明
この属性は、チケットのSLA結果を示すブール値またはカテゴリフラグです。これは「達成済み」、「違反」、「アクティブ」などの状態を示すことができます。これは、実際の応答時間または解決時間を適用されたSLAポリシーで定義された目標と比較することで決定されます。 これは「SLA順守および違反分析」ダッシュボードにとって重要な属性です。これにより、コンプライアンス準拠チケットと非準拠チケットを簡単にカウントし、視覚化できます。さらに、違反チケットのプロセス特性に焦点を当てて、長い待機時間や過剰な再割り当てなどの根本原因を特定することができます。
その重要性
サービスレベルコミットメントに対するパフォーマンスを直接測定し、サービス品質と顧客満足度の主要な指標となります。
取得元
各チケットのSLAステータスに関する情報を提供するZendeskチケットメトリックAPIから派生します。
例
達成違反アクティブ
|
|||
|
エージェント再割り当て回数
AgentReassignmentCount
|
リクエストが他のエージェントに再割り当てされた総回数。 | ||
|
説明
この属性は、チケットの「assignee_id」フィールドが変更されるたびに増加するカウンターです。単一のチケットに対する再割り当てが多い場合、初期ルーティングの誤り、エージェントの知識不足、または単一のエージェントでは処理が複雑すぎるリクエストなど、さまざまなプロセス上の問題を示している可能性があります。 これはプロセス効率を測定するための重要な指標であり、「エージェント再割り当て率」KPIを直接サポートします。再割り当て回数が多いケースを分析することで、ルーティングルール、エージェントトレーニング、またはナレッジベースのリソースを改善し、チケットをより迅速に適切な担当者に届ける機会を明らかにできます。
その重要性
内部引き継ぎを定量化し、プロセスの摩擦を特定するのに役立ちます。高い再割り当て率はしばしば遅延と非効率性につながるためです。
取得元
各チケットのZendeskチケット監査APIにおける「assignee_id」変更の回数を数えることで計算されます。
例
013
|
|||
|
サービスリクエストサイクル時間
ServiceRequestCycleTime
|
サービスリクエストの作成から最終解決までの全期間。 | ||
|
説明
この計算メトリクスは、サービスリクエストのエンドツーエンドの処理時間を測定します。通常、「サービスリクエスト解決済み」アクティビティと「サービスリクエスト作成済み」アクティビティの時間差として計算されます。これは、あらゆるサポートプロセスにとって最も重要な高レベルKPIの一つです。 この属性は、「平均サービスリクエストサイクル時間」KPIと「エンドツーエンドサイクル時間」ダッシュボードを直接サポートします。リクエストタイプや優先度などの異なる側面でこのメトリクスを分析することで、全体的な効率に最大の影響を与える要因を特定するのに役立ちます。
その重要性
これは、全体的なプロセス効率と顧客体験を測定するための主要なKPIであり、解決策を提供するまでにかかる時間を示します。
取得元
ケースの最初と最後(解決)のイベントタイムスタンプ間の差として計算されます。
例
259200s (3 days)86400s (1 day)3600s (1 hour)
|
|||
|
依頼者名
RequestorName
|
サービスリクエストを提出したエンドユーザーまたは顧客の名前。 | ||
|
説明
この属性は、サービスリクエストを開始した個人を特定します。リクエストを特定の顧客と紐付けることで、サポートプロセスをユーザー中心の視点から見ることができます。 プロセス分析では、申請者を使用して特定の顧客または顧客セグメントのパターンを分析できます。例えば、特定の顧客がより長い解決時間を経験しているか、または手戻り率が高いかどうかを調査できます。これは、彼らが使用している製品やサービスに問題があることを示唆している可能性があります。
その重要性
プロセスと顧客を結びつけ、顧客固有の問題、繰り返しのリクエスト、満足度レベルの分析を可能にします。
取得元
Zendesk Tickets APIレスポンスからの'requester_id'を結合することで、Zendesk Users APIを利用します。
例
Alice JohnsonBob WilliamsCharlie Brown
|
|||
|
初回解決であるか
IsFirstContactResolution
|
最初に割り当てられたエージェントによって、再割り当てや依頼者からの返信なしにリクエストが解決されたかどうかを示すフラグです。 | ||
|
説明
顧客の課題が単一のインタラクションで解決されたことを示す重要な指標です。この計算済み属性は、チケットが最初に割り当てられたエージェントによって、再割り当てやエージェントからの返信が一度もなかった場合に真となるブール型フラグです。 この属性は「初回接触解決率」KPIを直接サポートします。FCRケースの特性を分析することは、プロセスエクセレンスの青写真を提供することができます。逆に、FCRに失敗したケースを分析することは、より良いエージェントトレーニング、改善されたナレッジベース記事、またはより効果的な初期トリアージの機会を浮き彫りにします。
その重要性
単一の接触で問題を効率的に解決する能力を測定し、顧客満足度と運用効率の両方の強力な推進要因となります。
取得元
これは複雑な計算属性です。チケットのイベントログを分析し、エージェントの再割り当てとエージェントからの公開返信数をチェックする必要があります。
例
truefalse
|
|||
|
手戻り
IsRework
|
サービスリクエストが解決済みになった後に再オープンされた場合、真となるフラグです。 | ||
|
説明
このブールフラグは、手戻りが発生したケースを特定します。サービスリクエストは、ステータスが「解決済み」からオープン状態に戻った場合、手戻りと見なされます。これは、最初の解決策が不十分であり、顧客が同じ問題について再度連絡する必要があったことを示しています。 この属性は、「サービスリクエスト手戻り率」KPIの計算と、「手戻りおよび再開アクティビティ分析」ダッシュボードにとって不可欠です。手戻りケースにフラグを立てることで、アナリストはこれらの非効率なプロセスフローを特定し、再開の根本原因を発見し、初回解決率の改善に取り組むことができます。
その重要性
解決が最終的でなかったプロセス障害を特定し、顧客満足度に直接影響を与える品質と効率の問題を浮き彫りにします。
取得元
Zendeskチケット監査APIでのチケットのステータスシーケンスを分析することで計算されます。「解決済み」から「オープン」への移行は手戻りを示します。
例
truefalse
|
|||
|
満足度評価
SatisfactionRating
|
チケット解決後に申請者から提供された満足度スコア。 | ||
|
説明
この属性は、顧客のサポート体験に関するフィードバックを捉えるもので、通常、チケットが解決済みとマークされた後にアンケートを通じて収集されます。一般的な評価には「良い」または「悪い」があり、コメントが付随することもあります。 満足度評価は、重要な成果指標です。プロセスパターンを満足度スコアと関連付けることで、どのようなプロセス行動が顧客を満足または不満に導くかを明らかにできます。例えば、分析により、高い再割り当て率や長い解決時間が負の満足度評価と強く相関していることが示される場合があります。
その重要性
プロセス実行と顧客成果の間の直接的なリンクを提供し、どのプロセス行動が顧客満足度を向上させるかを特定するのに役立ちます。
取得元
Zendesk Tickets API、「satisfaction_rating.score」または「satisfaction_rating.reason」フィールド。
例
良好BadOffered
|
|||
|
申請者組織
RequestorOrganization
|
申請者が所属する組織または企業。 | ||
|
説明
この属性は、サービスリクエストを特定の顧客組織にリンクします。これは、サービスレベル契約やサポート契約が組織レベルで定義されることが多いB2Bサポートシナリオにおいて特に重要です。 組織別にデータを分析することで、サポートパフォーマンスを企業レベルで把握できます。これにより、大量のチケットを発生させている組織、繰り返し発生する問題を抱えている組織、または満足度スコアが低い組織を特定するのに役立ちます。これは、アカウント管理や広範な顧客健全性トレンドの特定に価値があります。
その重要性
企業ごとにリクエストをグループ化することでB2Bサービス分析を可能にし、組織レベルでの顧客関係とSLA管理に不可欠です。
取得元
Zendesk Tickets APIレスポンスからの'organization_id'を結合することで、Zendesk Organizations APIを利用します。
例
アクメコーポレーション`Global Tech Inc.`革新的な解決策
|
|||
|
終了日時
EndTime
|
アクティビティが完了した正確な日時。 | ||
|
説明
終了時刻はアクティビティの完了を示します。Zendeskの多くのイベントでは、期間は瞬間的であるため、終了時刻は開始時刻と同じです。ただし、「リクエスト保留中」のような状態ベースのアクティビティの場合、終了時刻はチケットが保留解除された時点となります。 この属性は、特定の活動の期間を計算する上で不可欠であり、ボトルネック分析の鍵となります。活動の開始時刻と終了時刻を比較することで、その処理時間を直接測定し、どのステップが最も時間を消費しているかを特定するのに役立ちます。
その重要性
個々のアクティビティ期間の計算を可能にし、プロセスボトルネックの特定とステップレベルの効率測定に不可欠です。
取得元
これは、個別のイベントの開始時刻と同一であることがよくあります。ステータス期間の場合、ステータスを変更する次のイベントのタイムスタンプです。
例
2023-10-26T10:00:00Z2023-10-26T10:15:30Z2023-10-27T14:20:10Z
|
|||
サービスリクエスト管理アクティビティ
| アクティビティ | 説明 | ||
|---|---|---|---|
|
SLA Target Breached
|
このアクティビティは、サービスリクエストが定義されたSLA目標(初回返信時間や解決時間など)を満たせなかった時点をマークします。Zendeskは、目標が達成されなかった場合にこれを明示的なイベントとしてログに記録します。 | ||
|
その重要性
これはコンプライアンス監視にとって重要なイベントであり、SLA順守率KPIの主要な入力値となります。サービスコミットメントの不履行を特定します。
取得元
Zendeskチケットイベントまたは監査ログ内の「SLABreach」イベントから取得されます。このイベントは、どのSLAメトリックが違反されたかを指定します。
取得
チケットデータ内の明示的な「SLABreach」イベントを通じて特定されます。
イベントタイプ
explicit
|
|||
|
サービスリクエストクローズ済み
|
サービスリクエストの最終的かつ永続的な終了を表します。チケットは「解決済み」の状態から一定期間経過後、自動的に「終了」状態に移行し、再オープンすることはできません。 | ||
|
その重要性
このアクティビティは、サービスリクエストプロセスの決定的な終了を示します。これにより、完全なケース期間を計算するための最終的な終点となります。
取得元
チケット監査ログの「status」フィールドにおける「変更」イベントで、新しい値が「closed」であることから推測されます。
取得
監査ログでステータスが「終了」になった「変更」イベントから推測されます。
イベントタイプ
inferred
|
|||
|
サービスリクエスト作成済み
|
リクエスターが任意のチャネルを通じて新しいチケットを提出する際、サービスリクエストのライフサイクルが始まることを示します。これはZendeskチケット監査ログの「作成」イベントとして捕捉され、プロセスの確定的な開始時間を提供します。 | ||
|
その重要性
このアクティビティは、すべてのサービスリクエストの主要な開始イベントとして機能し、エンドツーエンドのサイクルタイムを計算し、リクエスト受付量を分析するために不可欠です。
取得元
これはZendeskチケット監査ログに「作成」イベントタイプとして記録されます。このイベントのタイムスタンプは、サービスリクエストチケットの作成時刻です。
取得
チケット監査ログの「作成」イベントから直接取得されます。
イベントタイプ
explicit
|
|||
|
サービスリクエスト再オープン済み
|
リクエスターが「解決済み」状態のリクエストに返信すると発生し、そのステータスが自動的に「オープン」に戻ります。これは、提案された解決策が不十分であったことを意味します。 | ||
|
その重要性
このアクティビティは手戻りの主要な指標です。その頻度を分析することで、解決品質を測定し、顧客不満の原因を特定するのに役立ちます。
取得元
チケット監査ログの「status」フィールドにおける「変更」イベントで、以前の値が「solved」であり、新しい値が「open」であることから推測されます。
取得
「解決済み」から「オープン」へのステータス変更から推測されます。
イベントタイプ
inferred
|
|||
|
サービスリクエスト解決済み
|
このアクティビティは、エージェントが解決策を提供し、チケットステータスを「解決済み」に変更した時点をマークします。リクエストはエージェントの視点からは完了したと見なされますが、申請者によって再開される可能性があります。 | ||
|
その重要性
これは、エージェントの積極的な作業の終了を示す重要なマイルストーンです。この状態に到達するまでの時間は、解決効率の主要な指標となります。
取得元
チケット監査ログの「status」フィールドにおける「変更」イベントで、新しい値が「solved」であることから推測されます。
取得
監査ログでステータスが「解決済み」になった「変更」イベントから推測されます。
イベントタイプ
inferred
|
|||
|
リクエストが担当者にアサイン
|
このアクティビティは、サービスリクエストが特定の担当エージェントに初めて割り当てられたときに発生します。これは、チケット監査ログの「変更」イベントで、「assignee_id」フィールドがnullまたはグループIDから入力されたことから推測されます。 | ||
|
その重要性
これはエージェントによるアクティブな作業の開始を示し、初期応答時間、初回割り当ての遅延、およびエージェントのワークロード分散を測定するために不可欠です。
取得元
チケット監査ログの「assignee_id」フィールドにおける最初の「変更」イベントで、特定のユーザーIDが設定されていることから推測されます。
取得
「assignee_id」フィールドをエージェントに設定する最初の変更イベントから推測されます。
イベントタイプ
inferred
|
|||
|
公開返信が送信されました
|
このアクティビティは、エージェントから申請者へ送信されたあらゆるコミュニケーションをマークします。これは、Zendeskチケットデータにおいて「public」属性がtrueである明示的な「コメント」イベントとしてキャプチャされます。 | ||
|
その重要性
これらのイベントは、コミュニケーション頻度の分析、エージェント応答時間の測定、および解決に必要なインタラクション数の特定に不可欠です。
取得元
これはチケットデータにおける明示的な「コメント」イベントです。イベント詳細には「public: true」属性が含まれており、内部メモと区別されます。
取得
「public」フラグがtrueに設定されているチケットの「Comment」イベントから取得されます。
イベントタイプ
explicit
|
|||
|
SLAターゲット適用済み
|
サービスレベルアグリーメント(SLA)ポリシーがサービスリクエストチケットに適用された瞬間を表します。このイベントは、チケットのプロパティがアクティブなSLAポリシーの条件と一致したときに明示的にログに記録されます。 | ||
|
その重要性
SLAがいつ適用されたかを追跡することは、コンプライアンスの監視、潜在的な違反の分析、および異なるリクエストタイプに対する期待されるサービスタイムラインを理解するために非常に重要です。
取得元
Zendeskチケットイベントまたは監査ログ内の「SLAPolicyApplied」イベントから取得されます。このイベントは、どのポリシーが一致したかを指定します。
取得
チケットデータ内の明示的な「SLAPolicyApplied」イベントを通じて特定されます。
イベントタイプ
explicit
|
|||
|
エージェント再割り当て済み
|
サービスリクエストの所有権が1人のエージェントから別のエージェントに移行したことを表します。これは、最初の割り当て後の「assignee_id」フィールドにおける2回目以降の「変更」イベントから推測されます。 | ||
|
その重要性
再割り当てを追跡することは、エージェント再割り当て率KPIの計算に不可欠であり、プロセス上の非効率性、誤ったルーティング、または知識のギャップを特定するのに役立ちます。
取得元
チケット監査ログの「assignee_id」フィールドにおける「変更」イベントから推測されますが、そのチケットの最初の割り当てイベントは除外されます。
取得
「assignee_id」フィールドにおける2回目以降の「変更」イベントから推測されます。
イベントタイプ
inferred
|
|||
|
リクエストエスカレート済み
|
サービスリクエストがより上位のサポート階層、別のチーム、または管理部門に正式にエスカレーションされたことを表します。これは通常、チケットの割り当てられたグループの変更、またはエスカレーション追跡用に指定されたカスタムフィールドの変更から推測されます。 | ||
|
その重要性
エスカレーションを監視することは、複雑なリクエスト、第一線エージェントのトレーニングニーズ、およびより上位レベルの介入を必要とするシステム的な問題を特定するのに役立ちます。
取得元
これは標準的なイベントではありません。「group_id」フィールドからエスカレーショングループへの「変更」イベント、またはエスカレーション追跡に使用されるカスタムチケットフィールドへの変更から推測する必要があります。
取得
「group_id」の変更、またはカスタムの「escalation」フィールドから推測されます。
イベントタイプ
inferred
|
|||
|
リクエスト一時保留
|
このアクティビティは、サービスリクエストのステータスが「保留中」に変更されたときに発生します。これは通常、エージェントが申請者または第三者からの情報を待っていることを示します。ステータス変更イベントから推測されます。 | ||
|
その重要性
これにより、サポートチームの直接的な管理外にある待機時間を分離・測定し、エージェントの対応時間をより正確に把握するのに役立ちます。
取得元
チケット監査ログの「status」フィールドにおける「変更」イベントで、新しい値が「on-hold」であることから推測されます。
取得
監査ログでステータスが「一時保留」になった「変更」イベントから推測されます。
イベントタイプ
inferred
|
|||
|
優先度変更済み
|
サービスリクエストの優先度レベル(「低」、「通常」、「高」、「緊急」など)が更新されたことを示します。これは、チケット監査ログの「priority」フィールドにおける「変更」イベントとして捕捉されます。 | ||
|
その重要性
優先度の変更を分析することで、時間の経過とともに緊急性が高まるリクエストを特定し、優先順位付けが効果的に管理されているかを評価するのに役立ちます。
取得元
Zendeskチケット監査ログ内の「priority」フィールドにおける「変更」イベントとして記録され、以前の値と新しい値が示されます。
取得
監査ログの「priority」フィールドにおける「変更」イベントから推測されます。
イベントタイプ
inferred
|
|||
|
内部メモが追加された
|
エージェントによってサービスリクエストに内部メモまたはコメントが追加され、他のエージェントのみに表示されます。これは、「public」属性がfalseである「Comment」イベントとして記録されます。 | ||
|
その重要性
内部メモを追跡することで、エージェントやチーム間の連携に関するインサイトが得られ、これが遅延の原因となったり、効率的な問題解決の鍵となったりする場合があります。
取得元
これはチケットデータにおける明示的な「コメント」イベントです。イベント詳細には「public: false」属性が含まれており、これが内部メモであることを示します。
取得
「public」フラグがfalseに設定されているチケットの「Comment」イベントから取得されます。
イベントタイプ
explicit
|
|||