カスタマーサービスのデータテンプレート
カスタマーサービスのデータテンプレート
- 収集を推奨する属性
- カスタマーサービスのプロセスで追跡すべき主要なアクティビティ
- Zendesk Supportからの抽出ガイド
カスタマーサービスの属性
| 名前 | 説明 | ||
|---|---|---|---|
|
サービスリクエスト
ServiceRequest
|
チケットまたは案件とも呼ばれる、各カスタマーサービスリクエストを一意に識別するIDです。 | ||
|
説明
サービスリクエストは、1件の顧客からの問い合わせや問題について、作成から最終解決までのすべてのアクティビティを結び付ける主要な案件識別子です。各やり取り、更新、社内アクションは、この一意のIDに関連付けられます。 プロセスマイニングでは、サービスリクエストごとにイベントをグループ化して分析することで、カスタマーサービスの流れを最初から最後まで確認できます。総解決時間などの主要指標の計算、プロセスからの逸脱の特定、各顧客の問題のライフサイクル把握に必要な基盤です。
重要な理由
すべてのプロセスステップを結び付け、個々のカスタマーサービスの流れを再構成・分析できる基本的なCase IDです。
入手先
Zendesk Tickets APIの
例
102451287415332
|
|||
|
開始時刻
StartTime
|
アクティビティまたはイベントが開始した時点を示すタイムスタンプです。 | ||
|
説明
開始時刻、つまりイベントのタイムスタンプは、特定のアクティビティが発生した正確な日時を記録します。たとえば、顧客のコメントが追加された時点、エージェントが割り当てられた時点、チケットのステータスが「Resolved」に変更された時点などです。 このタイムスタンプは、イベントの時系列を定めるため、プロセスマイニングの基盤になります。アクティビティ間の所要時間の計算、サイクルタイムの測定、SLAに対するパフォーマンスの分析、サービスプロセスの時間的な動きの把握に使用します。
重要な理由
イベントの順序付け、所要時間の計算、サービスリクエストプロセスのタイムライン分析に欠かせないタイムスタンプです。
入手先
Zendesk Ticket Audits APIで、監査履歴内の各イベントに対応する
例
2023-04-15T10:00:00Z2023-04-15T10:05:14Z2023-04-16T14:30:00Z
|
|||
|
アクティビティ名
ActivityName
|
サービスリクエストのライフサイクル内で発生した特定のイベントまたはタスクの名称です。 | ||
|
説明
アクティビティ名は、「サービスリクエスト作成」「エージェントへのリクエスト割り当て」「サービスリクエスト解決」など、カスタマーサービスプロセスにおける1つのステップまたは節目を表します。これらのイベントにはタイムスタンプが付与され、各サービスリクエストのアクションの順序を形成します。 この属性は、プロセスフローの可視化、プロセスバリアントの発見、イベントの発生頻度と順序の分析に欠かせません。実行されたアクション、一般的な経路、ボトルネック、標準手順からの逸脱を把握できます。
重要な理由
この属性はプロセスのステップを定義し、プロセスマップの可視化とプロセスフローおよびバリエーションの分析を可能にします。
入手先
変更やアクションを記録するZendeskのチケット監査ログまたはイベントストリームから取得します。
例
サービスリクエスト作成エージェントへのリクエスト割り当てエージェントによる初回公開返信送信サービスリクエスト解決
|
|||
|
ソースシステム
SourceSystem
|
データの抽出元となる記録システムです。 | ||
|
説明
この属性は、サービスリクエストデータの発生元システムがZendesk Supportであることを示します。複数のシステムからデータを統合する場合に、データガバナンスとデータの系譜を管理するのに役立ちます。 分析では、データを正しいソースに関連付けることで、データの完全性を維持し、特に複数システムの環境でプロセスの背景を理解できます。
重要な理由
データの発生元を示します。データガバナンスや、統合環境におけるプロセスデータの識別に欠かせません。
入手先
データ抽出時に追加され、データの発生元を示す固定値です。
例
Zendesk Support
|
|||
|
最終データ更新日時
LastDataUpdate
|
ソースシステムからデータが最後に更新または抽出された時点のタイムスタンプです。 | ||
|
説明
この属性は、Zendesk Supportからデータセットが最後に更新された時点を示します。分析対象データの鮮度を把握するための情報です。 最終更新時刻を知ることで、アナリストやビジネスユーザーは、最新のプロセス情報を見ているかどうかを確認できます。データの新しさに対する期待値の管理に役立ち、レポートやモニタリングにも欠かせません。
重要な理由
データがどの時点のものかを明確にし、プロセス分析がどの程度最新であるかを把握できるようにします。
入手先
データ抽出時に生成・保存され、抽出ジョブのタイムスタンプを記録するメタデータ項目です。
例
2023-10-27T02:00:00Z
|
|||
|
SLA目標解決時間
SlaTargetResolutionTime
|
SLAポリシーに基づき、サービスリクエストを解決することが期待される目標時間です。 | ||
|
説明
この属性は、チケット解決に関するサービスレベル合意(SLA)の目標を定義します。目標は、リクエストの優先度やタイプ、顧客のサービスプランなどによって変わることがあります。 「SLAコンプライアンスパフォーマンス」ダッシュボードの基準となる属性です。実際の解決時間を測定する際の基準として機能します。この目標に対するパフォーマンスを分析することで、サービス提供の品質を定量化し、顧客との契約上の義務を果たしているかを確認できます。
重要な理由
顧客へのサービス約束を定義し、期限内対応のパフォーマンスとSLAコンプライアンスを測定する基準になります。
入手先
チケットに適用されたSLAポリシーから取得します。この情報はZendesk Ticket Metrics APIで利用できます。
例
144002880086400
|
|||
|
SLA違反の有無
IsSlaBreached
|
サービスリクエストの解決時間がSLAの目標時間を超えたかどうかを示すブール型フラグです。 | ||
|
説明
この計算属性は、サービスリクエストが解決時間に関する所定のService Level Agreementを満たせなかったかどうかを示す、単純な真偽フラグです。実際の解決時間と計画されたSLAの目標時間を比較して算出します。 このフラグにより、SLAコンプライアンスの分析が容易になります。「SLA Compliance Performance」ダッシュボードと「SLA Compliance Rate」KPIの基礎データとして、サービス目標を満たしたリクエストと満たさなかったリクエストの件数をすばやく集計・可視化できます。
重要な理由
各ケースのSLAパフォーマンスを明確な二値で示し、コンプライアンスの監視とレポート作成を簡単にします。
入手先
データ変換時に、合計解決時間とSlaTargetResolutionTimeを比較して算出します。
例
truefalse
|
|||
|
コミュニケーションチャネル
CommunicationChannel
|
サービスリクエストの送信やコミュニケーションに使用されたチャネルです。 | ||
|
説明
この属性は、メール、Webフォーム、チャット、電話など、使用されたコミュニケーション手段を示します。顧客がサービスデスクとどのようにやり取りしているかを表します。 チャネルの利用状況を把握することは、リソース計画と顧客体験の改善に重要です。「コミュニケーションチャネル利用状況」ダッシュボードでは、利用の多いチャネルや、解決時間の長さ、異なるプロセス経路との関係を分析できます。サービス改善や自動化に投資すべき領域の判断にも役立ちます。
重要な理由
顧客とエージェントのやり取りの方法を示し、チャネルの効率とプロセスおよび顧客体験への影響を分析できます。
入手先
Zendesk Tickets APIの
例
WebメールAPIチャット
|
|||
|
サービスリクエストタイプ
ServiceRequestType
|
「Question」「Incident」「Problem」「Task」など、サービスリクエストの分類です。 | ||
|
説明
この属性は、サービスリクエストの内容に基づいて分類します。通常は、リクエストの作成時またはトリアージ時に設定され、適切なワークフローと優先度の決定に役立ちます。 分析では、サービスリクエストタイプ別のセグメント化が基本になります。「サービスリクエスト解決時間分析」や「社内エスカレーション率と原因」などのダッシュボードで、問題の種類ごとに解決時間、エスカレーション率、プロセスフローを比較できます。特定のリクエストタイプが、より問題化しやすいか、対応効率が低いかを確認できます。
重要な理由
リクエストを分類し、問題の種類ごとのパフォーマンス比較と分析を可能にします。対象を絞ったプロセス改善に欠かせない属性です。
入手先
Zendesk Tickets APIの
例
質問インシデント問題Task
|
|||
|
優先度
Priority
|
サービスリクエストに設定された優先度です。「Low」「Normal」「High」「Urgent」などがあります。 | ||
|
説明
優先度はサービスリクエストの緊急度を示し、キュー内の順番や目標解決時間に影響することがあります。エージェントが重要度の高い問題から対応するのに役立ちます。 この属性は、パフォーマンス分析とSLA分析に欠かせません。「サービスリクエスト解決時間分析」ダッシュボードでは、優先度別にデータを分けることで、高優先度のリクエストが低優先度のリクエストより速く処理されているか、ビジネス上の必要性に応じてリソースが適切に配分されているかを確認できます。
重要な理由
リクエストの緊急度を示し、SLAコンプライアンスの分析や、重要な問題への迅速な対応に欠かせません。
入手先
Zendesk Tickets APIの
例
低通常高緊急
|
|||
|
担当エージェント
AssignedAgent
|
サービスリクエストへの対応を担当するカスタマーサービスエージェントの名前またはIDです。 | ||
|
説明
この属性は、特定の時点でアクティビティまたはサービスリクエストを担当するエージェントを示します。リクエストが再割り当てされると、ライフサイクルの途中で変わることがあります。 担当エージェント別に分析することで、エージェントの業務量、パフォーマンス、効率を把握できます。「エージェントの業務量と効率」ダッシュボードでは、エージェントごとの対応時間や案件数を比較し、コーチングの機会を特定するとともに、業務量の偏りを防げます。
重要な理由
アクションを実行したエージェントを追跡し、個人のパフォーマンス、業務量の配分、リソース配分を分析できます。
入手先
Zendesk Tickets APIの
例
John SmithJane DoeSupportBot
|
|||
|
エージェントグループ
AgentGroup
|
サービスリクエストが割り当てられたサポートグループまたはチームです。 | ||
|
説明
この属性は、サービスリクエストを担当するエージェントのチームを表します。スキル、製品領域、言語などに基づいて、特定のグループにリクエストを振り分けることがよくあります。 エージェントグループ別に分析することで、チーム単位のパフォーマンス、業務量の配分、チーム間のエスカレーションパターンを把握できます。個々のエージェントの分析よりも高い視点で、特定の部門や機能における構造的な問題を特定できます。
重要な理由
チームの担当範囲を追跡し、グループのパフォーマンス、チーム間の引き継ぎ、異なるサポート層や専門領域におけるリソース配分を分析できます。
入手先
Zendesk Tickets APIの
例
Tier 1サポートテクニカルサポート請求
|
|||
|
再オープンの有無
IsReopened
|
解決済みとしてマークされた後に、サービスリクエストが再オープンされたかどうかを示すブール型フラグです。 | ||
|
説明
この属性は、サービスリクエストが解決済みまたはクローズ済みになった後、再びオープン状態へ移行した場合に真になるフラグです。最初の解決では十分でなかったことを示します。 このフラグは、手戻りや初回対応で解決できなかったケースを追跡するうえで欠かせません。「Reopened Service Request Trends」ダッシュボードと「Service Request Reopen Rate」KPIを支え、追加対応が必要なケースを簡単に集計・分析できます。こうしたケースは、根本的な問題の存在を示すことがよくあります。
重要な理由
手戻りや解決の失敗を特定し、提供した解決策の品質と有効性を測定しやすくします。
入手先
データ変換時に、チケットのステータスが「resolved」または「closed」から「open」に変わったかどうかを確認して算出します。
例
truefalse
|
|||
|
情報リクエスト件数
InformationRequestCount
|
1件のサービスリクエストについて、顧客に情報を依頼した回数の合計です。 | ||
|
説明
この計算指標は、各サービスリクエストにおける「Information Requested From Customer」アクティビティの発生回数を数えます。件数が多い場合、エージェントが必要な情報を最初に十分収集できていない可能性があります。 この属性は「Repeated Information Request Analysis」ダッシュボードで使われます。件数を追跡すると、プロセスの非効率やエージェント研修が必要な領域を特定できます。情報を依頼する回数を減らすことで、解決時間を大幅に短縮し、顧客体験を改善できます。
重要な理由
顧客との往復コミュニケーションを数値化し、解決時間を長引かせ、顧客体験を損なう非効率を明らかにします。
入手先
各Service Requestについて、ActivityNameが「Information Requested From Customer」であるイベントの件数を数えて算出します。
例
013
|
|||
|
満足度評価
SatisfactionRating
|
サービスリクエストの解決後に顧客が提供した満足度スコアです。 | ||
|
説明
この属性は、顧客がサービスを利用した際の体験に対するフィードバックを示します。通常は、チケットの解決後にアンケートで収集します。一般的な評価には、「Good」、「Bad」、数値スコアなどがあります。 これは顧客の感情を直接測る指標であり、主要な成果指標の一つです。「Customer Sentiment Score」KPIの算出に使われます。満足度評価を、解決時間やエージェントの対応回数などのプロセスデータと組み合わせて分析すると、どのようなプロセス上の行動が顧客により良い結果をもたらすかを把握できます。
重要な理由
提供したサービスに対する顧客のフィードバックを直接測定し、プロセスのパフォーマンスと顧客の成果を結び付けます。
入手先
Zendesk Tickets APIの
例
良い悪い提供済み
|
|||
|
終了時刻
EndTime
|
アクティビティまたはイベントが完了した時点を示すタイムスタンプです。 | ||
|
説明
終了時刻は、アクティビティが完了した時点を表します。多くのイベントログ構造では、次のアクティビティの開始時刻を現在のアクティビティの終了時刻として扱えます。「エージェントによる問題調査」のような状態ベースのアクティビティでは、その状態が終了した時点を示します。 この属性は、アクティビティの正確な所要時間を計算するために欠かせません。パフォーマンス分析の中核となる情報であり、時間のかかるステップの特定、詳細なボトルネック分析、リソース効率の計算に利用します。
重要な理由
アクティビティの所要時間を計算できるため、ボトルネックの特定とパフォーマンスの測定に役立ちます。
入手先
多くの場合、対象のサービスリクエストにおける次のイベントのStartTimeを使用して算出します。
例
2023-04-15T10:05:14Z2023-04-15T11:20:30Z2023-04-16T15:00:00Z
|
|||
|
製品・サービスカテゴリ
ProductServiceCategory
|
顧客のリクエストに関係する具体的な製品、サービス、機能です。 | ||
|
説明
この属性は、製品またはサービス領域に基づいてサービスリクエストを分類し、詳細な背景情報を提供します。エージェントが手動で設定する場合と、リクエストの内容に基づいて自動的に設定される場合があります。 「リクエスト分類の正確性」や「調査サイクルタイムの内訳」などのダッシュボードで重要な役割を果たします。どの製品から最も多くのサポートリクエストが発生しているか、どの製品の解決が難しいか、初回分類と最終的な解決策が一致しているかを詳しく分析し、振り分けやエージェント研修の改善につなげられます。
重要な理由
リクエストを特定の事業領域、製品、サービスに関連付け、問題のある領域とプロセスへの影響を重点的に分析できます。
入手先
通常はZendeskのカスタムチケット項目です。正確な項目名は、Zendeskの設定によって異なります。
例
モバイルアプリサブスクリプション管理API連携ハードウェア
|
|||
|
解決コード
ResolutionCode
|
リクエストの最終的な解決または終了の理由を示すコードまたはカテゴリです。 | ||
|
説明
解決コードは、サービスリクエストの結果に関する構造化された情報を提供します。「エージェントが解決」「重複」「対応不要」「既知の問題」などが例です。単なる「Closed」ステータスよりも詳しい背景を示します。 この属性は、根本原因分析に特に役立ちます。「再オープンされたサービスリクエストの傾向」ダッシュボードで解決コード別の再オープン率を分析すると、特定の解決方法の効果が低く、顧客がサポートに再度連絡している可能性を確認できます。
重要な理由
サービスリクエストの結果を把握できるため、根本原因分析や、リクエストが再オープンされる理由の理解に役立ちます。
入手先
通常はZendeskのカスタムチケット項目です。正確な項目名は、Zendeskの設定によって異なります。
例
初回問い合わせでの解決Tier 2へエスカレーション顧客待ち製品の不具合
|
|||
カスタマーサービスのアクティビティ
| アクティビティ | 説明 | ||
|---|---|---|---|
|
エージェントへのリクエスト割り当て
|
サービスリクエストが対応担当の特定のエージェントに割り当てられたことを示します。振り分けルールに基づいて自動的に行われる場合と、チームリーダーまたはエージェントが手動で行う場合があります。 | ||
|
重要な理由
割り当ては、責任の明確化と業務量の管理における重要な節目です。割り当てまでの時間や再割り当てのパターンを分析すると、トリアージと配分プロセスのボトルネックを把握できます。
入手先
Zendesk Ticket Audits APIの明示的な「Change」イベントです。「assignee_id」項目に値が設定されたとき、または値が変更されたときに記録されます。
取得
Ticket Auditsログで「assignee_id」項目の変更を追跡します。
イベントタイプ
explicit
|
|||
|
サービスリクエスト作成
|
このアクティビティは、カスタマーサービスプロセスの開始を示します。メール、Webフォーム、チャットなど、任意のチャネルから新しいチケットがZendeskで作成された時点です。作成時には、固有のチケットIDとタイムスタンプがシステムに明示的に記録されます。 | ||
|
重要な理由
主要な開始イベントであるため、案件全体の所要時間の計算や、時間の経過に伴う受信リクエスト量の分析に欠かせません。初回応答までの時間や総解決時間など、主要なパフォーマンス指標を測定する基準になります。
入手先
Zendesk Ticket Audits APIで取得できる明示的なイベントです。チケットの「Create」イベントに対応し、初回作成時のタイムスタンプを提供します。
取得
Ticket Auditsログのチケット作成イベントから取得します。
イベントタイプ
explicit
|
|||
|
サービスリクエスト再オープン
|
「solved」状態のチケットに顧客が返信した場合に発生します。Zendeskはステータスを自動的に「open」に戻し、問題が完全には解決されていないことを示します。 | ||
|
重要な理由
再オープンは、初回接触での解決に失敗したことや、解決策の品質が不十分であることを示す重要な指標です。再オープンの頻度と理由を分析することで、エージェント研修や解決手順の改善点を特定できます。
入手先
Ticket Audits APIで、「status」が「solved」から「open」に戻ったときに取得される明示的なステータス変更です。
取得
「solved」から「open」へのステータス「Change」イベントを追跡します。
イベントタイプ
explicit
|
|||
|
サービスリクエスト終了
|
サービスリクエストを完全に終了する最後のアクティビティです。通常は、チケットが「solved」に設定されてから一定期間が経過し、その間に顧客から新しい返信がなかった場合に自動的に発生します。 | ||
|
重要な理由
確定した終了イベントとして、チケットのライフサイクルを完了させます。「solved」から「closed」までの時間は再オープンの可能性がある期間を示し、「closed」イベントは解決が受け入れられたことを確認します。
入手先
「status」項目が「closed」に設定されたときに、Zendesk Ticket Audits APIに記録される明示的なステータス変更です。
取得
Ticket Auditsで、チケットのステータスが「closed」に設定された「Change」イベントを特定します。
イベントタイプ
explicit
|
|||
|
サービスリクエスト解決
|
顧客に解決策を提示した後、エージェントがサービスリクエストを「solved」に設定した時点です。顧客から返信があるとチケットが再オープンされる可能性があるため、これは一時的な状態です。 | ||
|
重要な理由
解決時間とエージェントの効率を測定する主要な節目です。エージェントが対応完了と判断した時点を示し、チケットが再オープンされた場合の手戻りを分析する基準になります。
入手先
「status」項目が「solved」に設定されたときに、Zendesk Ticket Audits APIに記録される明示的なステータス変更です。
取得
Ticket Auditsで、チケットのステータスが「solved」に設定された「Change」イベントを特定します。
イベントタイプ
explicit
|
|||
|
顧客への情報依頼
|
エージェントが対応を進めるために顧客から追加情報を必要とし、チケットのステータスを「pending」に変更した時点で発生します。このステータス変更は、プロセスが外部の関係者からの回答を待っていることを明示します。 | ||
|
重要な理由
このアクティビティは顧客への依存関係を示し、社内のSLA計測を一時停止します。同じチケットで頻繁に、または繰り返し発生する場合、初回の情報収集が不十分で、解決時間が長期化している可能性があります。
入手先
Zendesk Ticket Audits APIに記録される明示的なステータス変更イベントです。「status」項目が「pending」に変更されたときに取得されます。
取得
Ticket Auditsで、チケットのステータスが「pending」に設定された「Change」イベントを特定します。
イベントタイプ
explicit
|
|||
|
SLA違反発生
|
初回返信時間や解決時間など、あらかじめ定めたサービスレベル合意をサービスリクエストが満たせなかった時点を示します。チケットのアクティビティのタイムスタンプとSLAポリシーを比較して算出します。 | ||
|
重要な理由
SLA違反は、顧客満足度と契約上のコンプライアンスに直接影響します。いつ、なぜ発生したかを分析することは、構造的な遅延、リソース不足、現実的でないパフォーマンス目標を特定するうえで重要です。
入手先
SLA違反のタイムスタンプ(「breached_at」)を保持するZendesk Ticket Metrics APIから取得できます。また、チケットイベントのタイムスタンプと定義済みのSLAルールを比較して算出することもできます。
取得
Ticket Metrics APIの「breached_at」タイムスタンプを使用するか、解決時間とSLAポリシーで定めた時間を比較して算出します。
イベントタイプ
calculated
|
|||
|
エージェントによる初回公開返信送信
|
自動確認ではなく、エージェントが初めて顧客に公開コメントを送信した時点を示します。顧客の問題に対するエージェントの初期対応を測る重要なイベントです。 | ||
|
重要な理由
「First Reply Time」SLAを測定する重要な節目です。サービス対応の速さを示す主要な指標であり、自動通信と、エージェントが主体となる調査・サポートの開始を区別できます。
入手先
Ticket Commentsストリームで、作成者が人間のエージェントである最初の公開コメントを特定します。自動システムユーザーによるコメントは除外します。
取得
チケットコメントを確認し、エージェントによる公開コメントに絞り込んだうえで、タイムスタンプが最も早いものを選択します。
イベントタイプ
inferred
|
|||
|
リクエストの分類と優先順位付け
|
エージェントまたは自動化によって、タイプ、カテゴリ、優先度などのチケット項目が設定または更新された時点で発生します。このステップは、チケット履歴の変更イベントとして記録されます。 | ||
|
重要な理由
適切な分類と優先順位付けは、効率的な振り分けとリソース配分に欠かせません。このアクティビティを分析することで、初回トリアージの正確性と、解決時間への影響を確認できます。
入手先
Zendesk Ticket Audits APIの「Change」イベントから取得します。「priority」、「type」、または分類に関係するカスタム項目への最初の更新を探すことで特定できます。
取得
作成後に主要な分類項目で発生した最初の「Change」イベントを、Ticket Auditログから抽出します。
イベントタイプ
explicit
|
|||
|
初回確認送信
|
顧客のリクエストを受け付けたことを知らせる、自動送信の初回応答を表します。通常は、チケット作成直後にテンプレート化されたメール通知を送信するZendeskのトリガーによって処理されます。 | ||
|
重要な理由
このアクティビティを追跡することは、初期対応の速さを測定し、顧客の期待値を管理するうえで重要です。リクエストの作成からこの確認までの時間は、顧客満足度を測る主要な指標です。
入手先
作成者が自動ユーザーである場合、またはチケット作成から数秒以内に発生した場合に、チケットへの最初の公開コメントから推定します。Ticket Commentsストリームを分析することで特定できます。
取得
チケット作成直後に、自動化またはトリガーによって作成された最初の公開コメントを特定します。
イベントタイプ
inferred
|
|||
|
満足度アンケート送信
|
顧客満足度(CSAT)アンケートが顧客に自動送信された時点を示します。通常は、チケットが「solved」に設定されてから短時間後に送信されます。 | ||
|
重要な理由
顧客からのフィードバック収集を開始するアクティビティです。アンケートがいつ、また送信されたかを把握することは、満足度スコアを適切に解釈し、フィードバック施策の効果を測定するうえで重要です。
入手先
自動化ログ、またはチケットに特定のタグが追加されたことから推定できます。Ticket Audits APIの「satisfaction_rating」セクションにも、アンケートが提示された時点が記録されます。
取得
「csat_sent」などのタグを探すか、満足度評価が提示された時点のタイムスタンプを使用します。
イベントタイプ
inferred
|
|||
|
満足度評価受信
|
顧客が満足度アンケートへの回答を送信し、「Good」や「Bad」などの評価を付けたときに発生します。評価と関連するコメントはチケットに記録されます。 | ||
|
重要な理由
顧客からの直接的なフィードバックは、サービス品質と顧客の評価を測るうえで非常に有用です。プロセスフローの中で評価を分析することで、特定のアクティビティやエージェントと結果の関係を確認できます。
入手先
「satisfaction_rating」項目に顧客のスコアとコメントが入力されたとき、Ticket Audits APIの「Change」イベントとして取得されます。
取得
Ticket Auditログで「satisfaction_rating」項目の変更を抽出します。
イベントタイプ
explicit
|
|||
|
社内エスカレーション発生
|
サービスリクエストが別の社内チームまたは上位のサポート層に移管されたことを示します。通常は、チケットの割り当て先グループが変更されたことから推定します。 | ||
|
重要な理由
エスカレーションを追跡することは、プロセス上の弱点、一次サポートの知識不足、複雑なリクエストの種類を特定するうえで重要です。エスカレーション率が高い場合、研修やプロセス文書の改善が必要な可能性があります。
入手先
「group_id」項目が変更されたTicket Audits APIの「Change」イベントから推定します。グループの変更は、チーム間の引き継ぎを示します。
取得
Ticket Auditsログで「group_id」項目の変更を監視します。
イベントタイプ
inferred
|
|||
|
顧客からの返信
|
顧客がチケットに返信したときに発生します。通常は「pending」状態のチケットが対象です。Zendeskはチケットのステータスを「pending」から「open」に自動的に変更し、エージェントが対応を再開できることを示します。 | ||
|
重要な理由
待機時間の終了を示し、プロセスを再開するきっかけになります。顧客が返信に要した時間を分析することで、エージェントからの依頼内容が明確だったかを確認できます。
入手先
エンドユーザーによる新しい公開コメントに対応します。Ticket Audits APIでは、「pending」から「open」への明示的なステータス変更が記録されます。
取得
「pending」から「open」へのステータス「Change」イベントを追跡するか、エンドユーザーによる新しい公開コメントを特定します。
イベントタイプ
explicit
|
|||
抽出ガイド
準備はできましたか?
このテンプレートでデータを準備し、今日からカスタマーサービスの改善を始めましょう。価値のある情報を見つけ出し、Zendesk Supportの運用効率を高められます。
カスタマーサービスのボトルネックを解消し、今すぐCSATを向上
繰り返しの問い合わせをなくし、FCR80%を達成して顧客満足度を高めます。
クレジットカードは不要です