顧客サービスデータテンプレート

Microsoft Dynamics 365 Customer Service
顧客サービスデータテンプレート

顧客サービスデータテンプレート

このテンプレートは、顧客サービスプロセスの徹底的な分析に必要な重要データを収集するための構造化されたアプローチを提供します。収集すべき重要な属性、追跡すべき主要なアクティビティを概説し、この情報を効果的に抽出する方法に関するガイダンスを提供します。
  • 収集を推奨する項目
  • 追跡すべき主要アクティビティ
  • Microsoft Dynamics 365 Customer Service向け抽出ガイダンス
イベントログについて初めての方へ: プロセスマイニングのイベントログ作成方法.

カスタマーサービス属性

これらは、顧客サービスプロセスの包括的な分析のためにイベントログに含めることを推奨するデータフィールドです。
5 必須 7 推奨 9 任意
名前 説明
サービスリクエスト
ServiceRequest
顧客サービスリクエストの固有識別子で、ケースまたはチケットとも呼ばれます。
説明

サービスリクエストは、単一の顧客からの問い合わせや問題に関連するすべてのアクティビティをリンクする主要な識別子として機能します。プロセスマイニングにおけるケースIDとして、作成からクローズまでの各顧客インタラクションの完全で一貫したビューを保証します。サービスリクエストごとに分析することで、エンドツーエンドのジャーニーを追跡し、解決時間を測定し、類似ケース間のパターンを特定することができます。

その重要性

これは、関連するすべてのイベントを単一のプロセスインスタンスに接続する必須のケースIDであり、エンドツーエンドのプロセス分析を可能にします。

取得元

これは、Microsoft Dynamics 365 Customer Serviceにおけるケース(インシデント)エンティティの主キーです。

CAS-01024-F3B4V6SR-2023-00589TKT-4815162342
アクティビティ
ActivityName
サービスリクエストに対し、ある時点で発生した特定のビジネスイベントの名前です。
説明

この属性は、顧客サービスプロセス内における単一のステップまたはステータス変更(例:「ケース作成済み」、「エージェントが問題を調査済み」、「ケース解決済み」など)を記述します。これらのアクティビティはプロセスマップの基盤を形成し、プロセスフローの可視化と分析を可能にします。各アクティビティは、タイムスタンプと組み合わせることで、プロセスシーケンスを定義するイベントを生成します。

その重要性

活動はプロセスにおけるステップを定義します。活動の順序と頻度を分析することは、プロセスフローを理解し、逸脱を特定し、ボトルネックを見つける上で不可欠です。

取得元

通常、ステータス変更(statuscode)や、タスク、メール、電話などの関連エンティティからの特定のイベントを標準化されたアクティビティ名にマッピングすることによって導き出されます。

案件作成エージェントが問題を調査済み顧客にソリューションを提案済み案件クローズ
ソースシステム
SourceSystem
データが抽出されたソースシステムを特定します。
説明

この属性は、イベントデータの発生元を指定します。このプロセスでは、常にMicrosoft Dynamics 365 Customer Serviceをソースとして識別します。複数のシステムがある環境では、このフィールドはデータソースを区別し、データリネージを保証するために重要です。

その重要性

明確なデータリネージを提供します。これはデータガバナンスにとって不可欠であり、特に複数のシステムを組み合わせた分析におけるデータ不整合のトラブルシューティングに重要です。

取得元

データ抽出・変換の過程で付与する固定値で、データセットのソースを示すラベルとして利用します。

Microsoft Dynamics 365 Customer Service
最終データ更新
LastDataUpdate
ソースシステムからの最終データ更新または抽出のタイムスタンプです。
説明

この属性は、Microsoft Dynamics 365からデータが最後に取得された日時を示します。分析対象データの鮮度を理解するために使用され、レポートおよび監視目的で不可欠です。ユーザーがダッシュボードや分析を解釈する際に、データのタイムリーさを認識できるようにします。

その重要性

プロセスの分析に基づいたタイムリーかつ正確なビジネス意思決定を行う上で不可欠な、データの新しさについてユーザーに通知します。

取得元

この値はデータ抽出時に生成され、データセットに付与されます。

2023-10-27T08:00:00Z
開始時刻
EventTime
アクティビティの発生時刻を示すタイムスタンプです。
説明

この属性は、特定のアクティビティが発生した正確な日付と時刻を記録します。イベントを正しく順序付けし、サイクル時間、期間、アクティビティ間の待機時間を含むすべての時間ベースの分析にとって不可欠です。正確で一貫したタイムスタンプは、プロセスマイニング分析の完全性にとって極めて重要です。

その重要性

このタイムスタンプはイベントを時系列に並べ、期間ベースのすべての計算を可能にします。これはパフォーマンス分析とボトルネック特定に不可欠です。

取得元

これは、ケース(インシデント)エンティティまたは関連するアクティビティエンティティ(例:メール、タスク、電話)の「createdon」や「modifiedon」のようなフィールドに対応します。

2023-04-15T10:00:00Z2023-05-20T14:35:10Z2023-06-01T09:12:45Z
SLA目標解決時間
SlaTargetResolutionTime
サービスリクエストを解決するための、契約上合意された目標時間です。
説明

この属性は、アクティブなサービスレベル契約(SLA)に従ってサービスリクエストが解決されるべき目標期間を指定します。これは、実際のパフォーマンスが測定されるベンチマークとして機能します。この値は、SLAコンプライアンス監視ダッシュボードおよびSLAコンプライアンス率KPIの計算にとって極めて重要であり、プロセスがサービスコミットメントを満たせていない箇所を浮き彫りにします。

その重要性

これは、コミットメントに対するサービスパフォーマンスを測定するための主要なベンチマークであり、SLAコンプライアンスと違反の分析を直接可能にします。

取得元

この値はDynamics 365のSLA構成によって決定され、SLA KPIインスタンスを介してケースに関連付けられます。

2592008640014400
エージェント名
AgentName
アクティビティを担当する顧客サービスエージェントまたはユーザーの名前です。
説明

この属性は、キューからアイテムを選択したり、ケースを解決したりするなど、アクティビティを実行した特定のエージェントまたはシステムユーザーを識別します。これは、エージェントのパフォーマンス、ワークロードの配分、およびリソース配分を分析するために不可欠です。エージェントレベルでアクティビティを追跡することで、組織はトップパフォーマー、トレーニングニーズ、およびワークロードの不均衡を特定できます。

その重要性

個人およびチームのパフォーマンス分析を可能にし、作業負荷のバランスを取り、コーチングの機会を特定して、全体的なサービス品質を向上させます。

取得元

ケース(incident)エンティティの「所有者」(ownerid)フィールドに対応し、システムユーザー(systemuser)エンティティにリンクされます。

Alice SmithBob Johnsonシステム
サービスリクエストの種類
ServiceRequestType
サービスリクエストの主要なカテゴリまたは分類です。
説明

この属性は、サービスリクエストの性質(「請求に関する問い合わせ」、「テクニカルサポート」、「製品フィードバック」など)に基づいてサービスリクエストを分類します。これは、異なるタイプのリクエストがどのように処理されるかを理解するためのプロセス分析をセグメント化する上で不可欠です。タイプ別に分析することで、特定のカテゴリがより長い解決時間、高いエスカレーション率、または異なるプロセスパスを辿ることが明らかになる場合があります。

その重要性

タイプ固有のボトルネック、リソース要件、改善機会を明らかにするためのプロセスセグメンテーションを可能にし、より良いルーティングと処理戦略をサポートします。

取得元

この情報は、ケース(インシデント)エンティティの「件名」(subjectid)フィールドまたはカスタムカテゴリフィールドに保存されることがよくあります。

請求に関する問い合わせテクニカルサポート製品フィードバックアカウント管理
ステータス理由
StatusReason
サービスリクエストの現在のステータスに関するより詳細な理由を提供します。
説明

ケースには「アクティブ」や「解決済み」といった広範なステータスがありますが、「ステータス理由」は「情報提供済み」や「問題解決済み」など、より具体的なコンテキストを提供します。この属性は、ケースがライフサイクルを通じてどのように、なぜ進行するかというニュアンスを理解するために極めて重要です。例えば、正常に解決されたケースと顧客によってキャンセルされたケースを区別でき、正確な結果分析に不可欠です。

その重要性

ケースの結果とステータス変更の理由について詳細な洞察を提供し、解決経路と根本原因のより正確な分析を可能にします。

取得元

これは、ケース(インシデント)エンティティの「ステータス理由」(statuscode)フィールドに対応します。

進行中保留中問題解決済み情報提供済み
チャネル
Channel
サービスリクエストが開始されたコミュニケーションチャネルです。
説明

この属性は、電話、メール、ウェブポータル、チャットなど、顧客とのやり取りの発生元を特定します。異なるチャネルはしばしば、 distinctなプロセスフロー、顧客の期待、および解決の複雑さを持ちます。チャネルごとにプロセスを分析することで、チャネル固有のワークフローとリソース配分を最適化できます。

その重要性

異なる顧客コンタクトチャネルがプロセスの効率性、解決時間、顧客満足度にどのように影響するかについての洞察を提供します。

取得元

これは、ケース(インシデント)エンティティの「ケース発生元」(caseorigincode)フィールドに対応します。

電話番号メール`Web`チャット
優先度
Priority
サービスリクエストに割り当てられた優先度レベルで、その緊急性を示します。
説明

この属性は、サービスリクエストの緊急度を定義し、通常は低、通常、高、緊急に分類されます。優先度は、ケースが処理される順序を決定するために使用され、しばしばSLA目標を左右します。優先度がプロセスフロー、リソース配分、解決時間にどのように影響するかを分析することは、重要な問題が迅速に処理されることを保証するための鍵となります。

その重要性

優先度の高いリクエストがより迅速に処理され、目標を達成しているか、また優先度レベルが全体のプロセスパフォーマンスにどのように影響するかを理解するのに役立ちます。

取得元

これは、ケース(インシデント)エンティティの「優先度」(prioritycode)フィールドに対応します。

通常
顧客名
CustomerName
サービスリクエストに関連付けられた顧客またはアカウントの名前です。
説明

この属性は、サービスリクエストを開始した顧客を特定します。顧客中心の視点からプロセスを分析することを可能にし、どの顧客が最も多くのリクエストを送信し、最も長い解決時間を経験し、または最も複雑な問題を抱えているかを特定するのに役立ちます。これは、顧客関係管理と顧客固有のサービス提供の改善に不可欠です。

その重要性

顧客レベルの分析を可能にし、パターンを特定し、主要アカウントのサービスを改善し、顧客ジャーニーを理解するのに役立ちます。

取得元

これは、ケース(インシデント)エンティティの「顧客」(customerid)ルックアップフィールドであり、アカウントまたは連絡先レコードのいずれかを指すことができます。

`Global Tech Inc.`ジェーン・ドウソリューションの革新
CSATスコア
CustomerSatisfactionScore
ケース解決後に顧客から提供された満足度スコアです。
説明

この属性は、顧客満足度(CSAT)調査からの数値またはカテゴリ評価を保持します。通常、サービスリクエストがクローズされた後に収集されます。これは、サービス品質に対する顧客の認識を直接的に測定するものです。このデータは、顧客満足度トレンドダッシュボードおよび解決後平均CSATスコアKPIにとって不可欠であり、プロセスパフォーマンスと顧客成果を結びつけます。

その重要性

顧客満足度を直接的に測定し、組織がプロセス行動と顧客感情を関連付け、改善を推進できるようにします。

取得元

これは通常、Customer Voiceなどの関連するアンケートエンティティから取得され、ケース(インシデント)エンティティにリンクされます。

5341
SLA違反
IsSlaBreached
サービスリクエストがSLA目標を超過したかどうかを示す算出済みのフラグです。
説明

このブールフラグは、サービスリクエストの実際の解決時間を「SLA目標解決時間」と比較することで決定されます。実際の時間が目標時間より長い場合に「true」に設定されます。この属性は、SLAコンプライアンス監視ダッシュボードおよびSLAコンプライアンス率KPIの計算にとって基本であり、各ケースのSLAパフォーマンスに関する明確な二者択一の結果を提供します。

その重要性

各ケースのSLA遵守の成否を明確に提供し、違反の根本原因を容易にフィルタリング、集計、分析できるようにします。

取得元

「ServiceRequestCycleTime」と「SlaTargetResolutionTime」を比較して算出されます。

truefalse
エスカレート済み
IsEscalated
サービスリクエストがエスカレートされたかどうかを示すフラグです。
説明

このブール属性は、サービスリクエストがエスカレーションされたかどうかを示します。エスカレーションは、一次サポートが問題を解決できず、より上位のチームまたはスペシャリストからの介入が必要な場合に発生します。このフラグを追跡することは、内部エスカレーション経路ダッシュボードおよび内部エスカレーション率KPIにとって不可欠であり、エスカレーションの根本原因と初期サポート層の弱点を特定するのに役立ちます。

その重要性

エスカレーションの頻度を直接測定し、初回解決における問題点を浮き彫りにし、プロセスまたはエージェントのスキル改善が必要な領域を指摘します。

取得元

これは、ケース(インシデント)エンティティの「エスカレート済み」(isescalated)フィールドに対応します。

truefalse
オーナーチーム
OwnerTeam
現在、サービスリクエストを所有しているチームです。
説明

この属性は、サービスリクエストを担当するチームを識別します。リクエストは、個々のエージェントまたはチーム(キュー)によって所有されることがあります。チームごとに分析することは、チームレベルのパフォーマンス、異なるサポート階層や専門分野にわたるワークロードの配分、およびチーム間のプロセス差異を理解するために不可欠です。

その重要性

チームレベルでのパフォーマンス分析を可能にし、サポート階層や専門グループを効果的に管理するために不可欠です。

取得元

ケース(incident)エンティティの「所有者」(ownerid)フィールドがシステムユーザーではなくチームレコードである場合に派生します。

`Tier 1` `サポート`経理部門テクニカルスペシャリスト
サービスリクエストサイクル時間
ServiceRequestCycleTime
サービスリクエストの作成から解決までの経過時間です。
説明

この計算メトリクスは、各サービスリクエストのエンドツーエンドの期間を測定します。「ケース作成済み」アクティビティと「ケース解決済み」アクティビティ間の時間差として計算されます。これは、全体的なプロセス効率を評価するための主要なKPIであり、サービスリクエスト解決時間ダッシュボードの中心となります。これにより、異常に時間がかかるケースを特定し、システム的な遅延を識別するのに役立ちます。

その重要性

これは、エンドツーエンドの解決プロセスの効率性を直接測定し、長期にわたるケースを特定するのに役立つコアプロセスパフォーマンスメトリクスです。

取得元

各ケースIDの最初のアクティビティのタイムスタンプを最後の解決アクティビティのタイムスタンプから差し引くことで算出されます。

1728006048003600
ナレッジ記事ID
KnowledgeArticleId
サービスリクエストにリンクされたナレッジベース記事の識別子です。
説明

この属性は、サービスリクエストの解決中に使用またはリンクされたナレッジ記事のIDを捕捉します。これにより、ナレッジベースがエージェントによって顧客の問題解決にどの程度効果的に活用されているかの直接的な測定値が提供されます。このデータは、ナレッジ記事活用ダッシュボードと対応するKPIにとって重要であり、ナレッジベースの価値と完全性を評価するのに役立ちます。

その重要性

ナレッジベースの利用状況を追跡し、エージェントが利用可能なリソースを活用して問題をより迅速かつ一貫して解決しているかを理解するのに役立ちます。

取得元

この情報は、ケース(インシデント)エンティティとナレッジ記事(knowledgearticle)エンティティ間の関係に見られます。

KA-01337KA-02048
初回解決である
IsFirstContactResolution
最初のお問い合わせでリクエストが解決されたかどうかを示すフラグです。
説明

この計算属性は、顧客からのフォローアップインタラクションやエージェントの再割り当てを必要とする重大な遅延なしに解決されたサービスリクエストを識別します。正確なロジックの定義は複雑になる可能性がありますが、通常は短いサイクル時間と、初期インタラクション後の再オープンまたは顧客からの問い合わせアクティビティがないことを確認することを含みます。これは初回問い合わせ解決率KPIの基礎となります。

その重要性

これは、問題を迅速かつ完全に解決する能力を強調するため、サービス効率と顧客満足度を測る上で重要な尺度です。

取得元

各ケースのイベントログにおける活動の順序とタイミングに基づいて計算されます。

truefalse
手戻り
IsRework
ケースに手戻り活動が含まれていたかどうかを示す算出済みのフラグです。
説明

このブールフラグは、複数の「顧客からの情報要求」イベントや、解決後に「ケース再アクティブ化」イベントなど、手戻りループや繰り返しのアクティビティを含むケースを識別します。これは、非効率性や初回での問題解決の失敗を示すパターンについてアクティビティのシーケンスを分析することで計算されます。この属性は、手戻りおよび再連絡分析ダッシュボードにとって重要です。

その重要性

プロセスの非効率性を定量化し、分離するのに役立ち、分析担当者が繰り返しの作業や無駄な労力の根本原因に集中できるようになります。

取得元

プロセスマイニング分析を使用して、特定の活動シーケンス(例:「解決済み」→「再アクティブ化済み」)またはケース内の繰り返しの活動を検出することで算出されます。

truefalse
関係する製品
ProductInvolved
顧客のサービスリクエストに関連付けられた製品です。
説明

この属性は、顧客の問題が関連する特定の製品またはサービスを識別します。これにより、サービスプロセスの製品ベースのセグメンテーションが可能になり、特定の製品がより多くのサポートリクエストを生成したり、より複雑な問題を抱えていたり、特殊なエージェントスキルを必要としたりするかを明らかにできます。この分析は、製品の改善とリソース計画に役立ちます。

その重要性

製品固有のプロセス分析を可能にし、繰り返しの製品問題を特定し、サポートドキュメントを改善し、専門リソースを効果的に割り当てるのに役立ちます。

取得元

これは、ケース(インシデント)エンティティの「製品」(productid)ルックアップフィールドに対応します。

Alpha-100プリンターZeta CRM SoftwareOmega Data Plan
必須 推奨 任意

カスタマーサービス活動

これらは、顧客サービスの正確な発見と最適化のために、イベントログで取得すべき主要なプロセスステップとマイルストーンです。
6 推奨 7 任意
アクティビティ 説明
SLAタイマー開始済み
ケースのサービスレベル契約(SLA)タイマーの起動を示します。これは「初回応答まで」や「解決まで」のような定義されたサービス指標に対して時間の追跡を開始します。これはDynamics 365 SLAエンジンによって管理される明示的なイベントです。
その重要性

このアクティビティは、SLAコンプライアンスの監視と、サービスコミットメントの開始時期を理解するための基本です。サービス目標が達成されているかどうかの分析を直接サポートします。

取得元

「インシデント」エンティティに関連する「SLA KPIインスタンス」エンティティに記録されます。関連するSLA KPIインスタンスレコードの「createdon」タイムスタンプが開始を示します。

取得

ケースに関連付けられた「SLA KPIインスタンス」レコードの作成タイムスタンプを使用します。

イベントタイプ explicit
ケースエスカレーション
ケースがより上位のサポート階層または別のチームに正式にエスカレートされることを示します。これは、ケースを指定されたエスカレーションキューまたはユーザーに再割り当てする明示的なユーザーアクションである場合があります。
その重要性

エスカレーションの監視は、「内部エスカレーション率」KPIにとって不可欠であり、一次サポートで解決できない問題の根本原因を特定するのに役立ちます。これにより、プロセスの弱点やトレーニング機会が明らかになります。

取得元

owneridフィールドが指定されたエスカレーションキューまたはチームに変更されたことから推測されます。また、ケースをエスカレート済みとしてフラグ付けする明示的なカスタムアクションである場合もあります。

取得

owneridが既知のエスカレーションキューに変更されたタイムスタンプを特定します。

イベントタイプ inferred
ケース割り当て済み
このアクティビティは、ケースが処理のために特定のキューまたはユーザーに割り当てられることを示します。システムはケース所有者への変更を明示的に記録し、これらはシステムの監査ログを通じて追跡できます。
その重要性

割り当てを追跡することは、ワークロードの配分を分析し、割り当てに関連する遅延を特定し、ルーティングの効率を理解するために不可欠です。これにより、ケースが適切なチームや人物にどれだけ迅速にルーティングされるかという疑問に答えるのに役立ちます。

取得元

Incidentエンティティのowneridフィールドへの変更を追跡することで捕捉されます。変更のタイムスタンプは監査履歴ログで確認できます。

取得

監査ログからowneridフィールドへのタイムスタンプ付きの変更を抽出します。

イベントタイプ explicit
ケース解決
これは、エージェントが顧客の問題が対処されたとみなす時点を示す重要なマイルストーンです。これはDynamics 365における明示的なアクションであり、ケースにリンクされた「ケース解決」アクティビティレコードを作成します。
その重要性

主要な成功ベースの終了イベントとして、この活動は解決時間と成功率を計算するために不可欠です。これは、ほぼすべてのカスタマーサービスKPIの重要な構成要素です。

取得元

このイベントは、「解決」(ケース解決)アクティビティレコードの作成に対応します。このレコードの「actualend」タイムスタンプが解決時間を示します。

取得

関連する「解決」アクティビティレコードの「actualend」または「createdon」タイムスタンプを使用します。

イベントタイプ explicit
案件クローズ
これは、ケースレコードの最終的な管理上のクローズであり、解決と同時に、または解決後しばらくして発生する場合があります。このアクティビティは、ケースの状態が「クローズ済み」に変更されることによって捕捉されます。
その重要性

これは、システムにおけるプロセスライフサイクルの絶対的な終わりを示します。「解決済み」から「クローズ済み」までの時間は、管理上のオーバーヘッドやレコードを最終決定する上での遅延を示している可能性があります。

取得元

Incidentエンティティのstatecodeフィールドが「キャンセル済み」(2)またはカスタムのクローズド状態に変更されたことで捕捉されます。タイムスタンプは監査履歴で確認できます。

取得

「statecode」が最終終了状態(例:キャンセル済み/クローズ済み)に変更されたタイムスタンプを追跡します。

イベントタイプ explicit
案件作成
このアクティビティは、システムで新しいケースレコードが作成される、顧客サービスプロセスの開始を示します。「インシデント」エンティティレコードが初めて保存されたときの特定のタイムスタンプとともに、作成は明示的なイベントとしてログに記録されます。
その重要性

主要な開始イベントとして、この活動はケースの全体的なライフサイクル期間を計算し、ケース量の傾向を理解するために不可欠です。これは、その後のすべてのプロセス分析の起点となります。

取得元

このイベントは、各新規レコードの「インシデント」(ケース)エンティティ上の「createdon」タイムスタンプから捕捉されます。

取得

インシデントレコードの「createdon」タイムスタンプを使用します。

イベントタイプ explicit
エージェントが問題を調査済み
エージェントが顧客の問題を理解し診断するために積極的に作業していることを示します。これは推論されるアクティビティであり、多くの場合、エージェントがナレッジ記事をケースにリンクすることで、調査が行われたことを示します。
その重要性

これを追跡することは、ナレッジリソースの利用状況とその解決時間への影響を測定するのに役立ちます。エージェントが利用可能なツールを効率的に活用して問題を解決しているかどうかについての洞察を提供します。

取得元

「IncidentKnowledgeBaseRecord」エンティティにレコードが作成されたことから推測されます。このレコードはナレッジ記事をケースにリンクします。このレコード作成のタイムスタンプが使用されます。

取得

ナレッジ記事がインシデントに関連付けられたときのタイムスタンプを使用します。

イベントタイプ inferred
エージェントによるキューアイテムの選択
このイベントは、エージェントが共有キューからケースを積極的に取り出し、作業を開始する際に発生します。これは、システムがケースをキューに割り当てるのとは異なる、ユーザーによる意図的なアクションです。
その重要性

このアクティビティは、エージェントが作業を開始する前にケースがキューで待機する実際の時間を測定するのに役立ちます。これは、キューのボトルネックを特定し、エージェントの積極性を理解するための鍵となります。

取得元

ケースに関連付けられた「QueueItem」エンティティの「workedbyid」フィールドがユーザーによって更新されたとき、またはケースの所有者がキューからユーザーに変更されたときに追跡されます。

取得

QueueItemのworkedbyidフィールドが入力されたタイムスタンプを特定します。

イベントタイプ explicit
ケース再アクティブ化
以前解決されたケースが、顧客からの返信や問題が未解決であるとの報告により、自動または手動で再オープンされる場合に発生します。これは、ケースステータスが「解決済み」から「アクティブ」に戻る標準的なシステム動作です。
その重要性

このアクティビティは、手戻りを特定し、「初回問い合わせ解決率」を分析するために極めて重要です。再アクティブ化の回数が多いことは、初期解決策が不完全または非効果的であったことを示しています。

取得元

Incidentエンティティのstatecodeフィールドが「解決済み」(1)から「アクティブ」(0)に変化したことで捕捉されます。この変更のタイムスタンプは監査履歴に記録されます。

取得

監査ログで「statecode」が「解決済み」から「アクティブ」に変わったタイムスタンプを追跡します。

イベントタイプ explicit
ケース分類の変更
このイベントは、エージェントがケースの初回作成後にカテゴリまたは件名を変更する際に発生します。これは、システムの監査機能によって追跡される明示的な変更です。
その重要性

再分類の追跡は、「サービスリクエスト再分類率」KPIにとって不可欠です。頻度が高い場合、初期トリアージに問題があり、誤ったルーティングと遅延につながっていることを示します。

取得元

Incidentエンティティの監査履歴から、特にsubjectidフィールドまたは他のカスタム分類フィールドへの変更を追跡することで取得されます。

取得

監査ログからsubjectidフィールドへのタイムスタンプ付きの変更を抽出します。

イベントタイプ explicit
満足度調査送信済み
顧客満足度調査の送信を示します。通常、ケース解決後に自動的にトリガーされます。これは一般的に、送信メールまたはCustomer Voiceアンケートアクティビティとして捕捉されます。
その重要性

このアクティビティは、運用プロセスと顧客体験の成果を結びつけます。これにより、ケースが辿ったプロセスパスのコンテキストで満足度スコアを分析できます。

取得元

アンケートリンクを含む送信「メール」活動レコードの作成、またはケースに関連する「Customer Voiceアンケート招待」活動レコードから推測されます。

取得

アンケート関連のアクティビティレコードの作成タイムスタンプを使用します。

イベントタイプ inferred
顧客からの情報要求
このアクティビティは、エージェントが続行するために顧客から追加情報を必要とする時点を示します。ケースステータスが「待機中」に変更されたり、ケースタイムラインから送信メールが送られたりすることで推測されることがよくあります。
その重要性

これは、顧客関連の遅延を測定し、「顧客情報待ち時間」KPIを理解するために不可欠です。外部入力を待つために費やされたプロセス時間を分離するのに役立ちます。

取得元

Incidentエンティティのstatuscodeフィールドが「顧客からの情報待ち」の理由で「保留中」のような値に変更されたことから推測できます。このステータス変更のタイムスタンプが使用されます。

取得

ステータスコードが指定された「顧客待ち」状態に変更されたタイムスタンプを追跡します。

イベントタイプ inferred
顧客にソリューションを提案済み
このアクティビティは、エージェントが解決策を策定し、顧客に伝達したことを示します。通常、ケースタイムラインから送信されたメールや、「顧客確認待ち」へのステータス変更から推測されます。
その重要性

このマイルストーンは、調査から解決への移行を示します。ソリューションの提案と確認の間の時間を分析することで、顧客の応答の遅延や提案された修正に関する問題が明らかになる場合があります。

取得元

ケースに関連する送信「メール」活動レコードのタイムスタンプ、または解決前のステータスへのstatuscode変更から推測できます。

取得

送信メールアクティビティまたはステータスが「ソリューション提案済み」に変更されたタイムスタンプを使用します。

イベントタイプ inferred
推奨 任意

抽出ガイド

Microsoft Dynamics 365 Customer Serviceからデータを取得する方法