顧客サービスのデータテンプレート
顧客サービスのデータテンプレート
- 収集を推奨する属性
- 追跡すべき主なアクティビティ
- Microsoft Dynamics 365の顧客サービスデータ抽出ガイド
顧客サービスの属性
| 名前 | 説明 | ||
|---|---|---|---|
|
サービスリクエスト
ServiceRequest
|
ケースまたはチケットとも呼ばれる、カスタマーサービスリクエストを一意に識別するIDです。 | ||
|
説明
サービスリクエストは主要な識別子として、1件の顧客問い合わせや問題に関するすべてのアクティビティを関連付けます。プロセスマイニングではケースIDとして機能し、作成から終了までの顧客対応を一貫して把握できます。サービスリクエスト単位で分析することで、最初から最後までの経過を追跡し、解決時間を測定し、類似ケースに共通する傾向を特定できます。
重要な理由
関連するすべてのイベントを1つのプロセスインスタンスに結び付ける、必須のケースIDです。これにより、プロセス全体を分析できます。
入手先
Microsoft Dynamics 365 Customer ServiceのCase(incident)エンティティの主キーです。
例
CAS-01024-F3B4V6SR-2023-00589TKT-4815162342
|
|||
|
アクティビティ
ActivityName
|
サービスリクエストに関して、ある時点で発生した特定の業務イベントの名称です。 | ||
|
説明
この属性は、「ケース作成」「エージェントによる問題調査」「ケース解決」など、カスタマーサービスプロセスにおける個々のステップやステータス変更を表します。これらのアクティビティがプロセスマップの基盤となり、プロセスの流れを可視化して分析できます。各アクティビティにタイムスタンプを組み合わせると、プロセスの順序を示すイベントになります。
重要な理由
アクティビティはプロセスの各ステップを示します。その順序や発生頻度の分析は、プロセスの流れを把握し、逸脱やボトルネックを特定するうえで欠かせません。
入手先
通常は、ステータス変更(statuscode)や、Task、Email、Phone Callなどの関連エンティティの特定イベントを、標準化されたアクティビティ名に対応付けて作成します。
例
ケース作成エージェントによる問題調査顧客への解決策の提示ケース終了
|
|||
|
ソースシステム
SourceSystem
|
データの抽出元となるシステムを示します。 | ||
|
説明
この属性は、イベントデータの取得元を示します。このプロセスでは、Microsoft Dynamics 365 Customer Serviceが一貫してソースとして記録されます。複数のシステムを使う環境では、データソースを区別し、データの来歴を確認するうえで欠かせないフィールドです。
重要な理由
データの来歴を明確にできるため、データガバナンスやデータの不整合の調査に役立ちます。特に複数システムのデータを組み合わせて分析する場合に有効です。
入手先
通常は、データ抽出・変換の際にデータセットの取得元を示す固定値を追加します。
例
Microsoft Dynamics 365 Customer Service
|
|||
|
最終データ更新
LastDataUpdate
|
ソースシステムからデータを最後に更新または抽出した時刻です。 | ||
|
説明
この属性は、Microsoft Dynamics 365からデータを最後に取得した時刻を示します。分析対象データの鮮度を把握するために使われ、レポートや監視にも欠かせません。ダッシュボードや分析結果を解釈する際に、データがいつ時点のものかを確認できます。
重要な理由
データの新しさを把握できるため、プロセス分析に基づいて適切なタイミングで正確な業務判断を行うのに役立ちます。
入手先
データ抽出時にこの値を生成し、データセットに記録します。
例
2023-10-27T08:00:00Z
|
|||
|
開始時刻
EventTime
|
アクティビティが発生した時刻を示すタイムスタンプです。 | ||
|
説明
この属性には、特定のアクティビティが発生した正確な日時を記録します。イベントの順序を正しく並べるために必要であり、サイクルタイムや所要時間、アクティビティ間の待ち時間など、時間に基づく分析に使用します。正確で一貫したタイムスタンプは、プロセスマイニング分析の信頼性を保つうえで欠かせません。
重要な理由
このタイムスタンプでイベントを時系列に並べ、所要時間に関する計算を行えます。パフォーマンス分析やボトルネックの特定に欠かせません。
入手先
Case(incident)エンティティや、Email、Task、Phone Callなどの関連アクティビティエンティティにある「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 Instancesを通じてケースに関連付けられます。
例
2592008640014400
|
|||
|
エージェント名
AgentName
|
アクティビティを担当したカスタマーサービスのエージェントまたはユーザーの名前です。 | ||
|
説明
この属性は、キューからアイテムを取得したりケースを解決したりしたエージェントまたはシステムユーザーを特定します。エージェントのパフォーマンス、業務負荷の分布、リソース配分を分析するうえで欠かせません。担当者ごとのアクティビティを追跡すると、優れた成果を上げている担当者やトレーニングの必要性、業務負荷の偏りを把握できます。
重要な理由
個人とチームのパフォーマンスを分析し、業務負荷の調整や、サービス品質の向上に向けた指導機会の特定に役立ちます。
入手先
Case(incident)エンティティの「Owner」(ownerid)フィールドに対応し、System User(systemuser)エンティティに関連付けられています。
例
アリス・スミスボブ・ジョンソンシステム
|
|||
|
サービスリクエスト種別
ServiceRequestType
|
サービスリクエストの主なカテゴリまたは分類です。 | ||
|
説明
この属性は、「請求に関する問い合わせ」「技術サポート」「製品へのフィードバック」など、内容に応じてサービスリクエストを分類します。リクエストの種類ごとの対応状況を把握するための、プロセス分析の基本となる属性です。種別ごとに分析すると、解決に時間がかかるカテゴリや、エスカレーション率が高いカテゴリ、異なるプロセス経路をたどるカテゴリを特定できます。
重要な理由
プロセスを種別ごとに分けて分析することで、特定の種別に関するボトルネック、必要なリソース、改善の機会を把握できます。より適切な振り分けや対応方針の検討にも役立ちます。
入手先
この情報は、Case(incident)エンティティの「Subject」(subjectid)フィールド、またはカスタムカテゴリフィールドに保存されることがよくあります。
例
請求に関する問い合わせ技術サポート製品へのフィードバックアカウント管理
|
|||
|
ステータス理由
StatusReason
|
サービスリクエストの現在のステータスについて、より詳しい理由を示します。 | ||
|
説明
ケースの大まかなステータスが「Active」や「Resolved」であるのに対し、ステータス理由は「情報提供済み」や「問題解決済み」など、より具体的な状況を示します。この属性は、ケースがライフサイクルをどのように、またなぜ進んでいるかを詳しく把握するうえで欠かせません。たとえば、正常に解決したケースと顧客がキャンセルしたケースを区別でき、正確な結果分析に役立ちます。
重要な理由
ケースの結果やステータス変更の理由を詳しく把握できるため、解決までの経路や根本原因をより正確に分析できます。
入手先
Case(incident)エンティティの「Status Reason」(statuscode)フィールドに対応します。
例
進行中保留中問題解決済み情報提供済み
|
|||
|
チャネル
Channel
|
サービスリクエストが開始された連絡チャネルです。 | ||
|
説明
この属性は、電話、メール、Webポータル、チャットなど、顧客とのやり取りが始まったチャネルを示します。チャネルによってプロセスの流れや顧客の期待、解決の難しさが異なることがあります。チャネル別にプロセスを分析すると、チャネルごとのワークフローやリソース配分を見直せます。
重要な理由
顧客との連絡チャネルの違いが、プロセスの効率、解決時間、顧客満足度に与える影響を把握できます。
入手先
Case(incident)エンティティの「Case Origin」(caseorigincode)フィールドに対応します。
例
電話メールWebチャット
|
|||
|
優先度
Priority
|
サービスリクエストに設定された優先度で、対応の緊急性を示します。 | ||
|
説明
この属性は、通常「低」「通常」「高」「緊急」に分類されるサービスリクエストの緊急性を示します。優先度はケースの対応順を決める際に使われ、SLAの目標にも影響することがあります。優先度がプロセスの流れ、リソース配分、解決時間に与える影響を分析すると、重大な問題に迅速に対応できているかを確認できます。
重要な理由
優先度の高いリクエストがより迅速に処理され、目標を達成しているか、また優先度がプロセス全体のパフォーマンスにどう影響するかを把握できます。
入手先
Case(incident)エンティティの「Priority」(prioritycode)フィールドに対応します。
例
低通常高
|
|||
|
顧客名
CustomerName
|
サービスリクエストに関連付けられた顧客またはアカウントの名前です。 | ||
|
説明
この属性は、サービスリクエストを開始した顧客を特定します。顧客の視点からプロセスを分析し、リクエストの件数が多い顧客、解決に時間がかかる顧客、複雑な問題を抱える顧客を把握できます。顧客との関係を管理し、顧客ごとのサービス提供を改善するうえで欠かせません。
重要な理由
顧客単位で分析し、傾向の特定や主要顧客へのサービス改善、顧客のジャーニーの把握に役立てられます。
入手先
Case(incident)エンティティの「Customer」(customerid)参照フィールドです。AccountまたはContactレコードを参照します。
例
グローバルテック株式会社ジェーン・ドウイノベート・ソリューションズ
|
|||
|
SLA違反の有無
IsSlaBreached
|
サービスリクエストがSLAの目標時間を超過したかどうかを示す計算フラグ。 | ||
|
説明
このブール型フラグは、サービスリクエストの実際の解決時間と「SLA目標解決時間」を比較して判定します。実際の時間が目標時間を超えた場合はtrueになります。「SLAコンプライアンス監視」ダッシュボードや「SLA遵守率」KPIの算出に欠かせない属性で、各ケースのSLA達成状況を明確に示します。
重要な理由
各ケースのSLA遵守状況を達成または未達成で明確に示すため、違反の根本原因を簡単に絞り込み、集計・分析できます。
入手先
「ServiceRequestCycleTime」と「SlaTargetResolutionTime」を比較して算出します。
例
truefalse
|
|||
|
エスカレーション済み
IsEscalated
|
サービスリクエストがエスカレーションされたかどうかを示すフラグ。 | ||
|
説明
このブール型属性は、サービスリクエストがエスカレーションされたかどうかを示します。一次サポートで問題を解決できず、上位のチームや専門担当者の対応が必要な場合に、エスカレーションが発生します。このフラグを追跡すると、「社内エスカレーション経路」ダッシュボードや「社内エスカレーション率」KPIを確認でき、エスカレーションの根本原因や初期サポート体制の弱点を特定するのに役立ちます。
重要な理由
エスカレーションの発生頻度を直接測定します。初回対応で解決できていない問題を明らかにし、プロセスや担当者のスキルを改善すべき領域を示します。
入手先
Case(incident)エンティティの「エスカレーション済み」(isescalated)フィールドに対応します。
例
truefalse
|
|||
|
ナレッジ記事ID
KnowledgeArticleId
|
サービスリクエストに関連付けられたナレッジベース記事の識別子。 | ||
|
説明
この属性には、サービスリクエストの解決時に使用または関連付けられたナレッジ記事のIDが記録されます。担当者が顧客の問題解決にナレッジベースをどの程度役立てているかを直接把握できます。「ナレッジ記事の利用状況」ダッシュボードと関連KPIの確認に必要なデータであり、ナレッジベースの価値や内容の充実度を評価するのに役立ちます。
重要な理由
ナレッジベースの利用状況を追跡し、担当者が利用可能な情報を使って、より迅速かつ一貫性のある問題解決を行えているかを把握できます。
入手先
Case(incident)エンティティとKnowledge Article(knowledgearticle)エンティティの関連情報に含まれています。
例
KA-01337KA-02048
|
|||
|
初回対応で解決したか
IsFirstContactResolution
|
初回の問い合わせでリクエストが解決したかどうかを示すフラグ。 | ||
|
説明
この計算属性は、顧客との追加のやり取りや、担当者の再割り当てが必要となる大幅な遅延なしに解決したサービスリクエストを特定します。判定条件の定義は複雑になる場合がありますが、通常は処理時間が短く、初回対応後に再オープンや顧客からの問い合わせがないことを確認します。「初回対応解決率」KPIの基礎となる属性です。
重要な理由
問題を迅速かつ完全に解決できているかを示すため、サービスの効率と顧客満足度を測るうえで重要な指標です。
入手先
各ケースのイベントログに記録されたアクティビティの順序と時刻に基づいて算出します。
例
truefalse
|
|||
|
対象製品
ProductInvolved
|
顧客のサービスリクエストに関連する製品。 | ||
|
説明
この属性は、顧客の問題に関係する製品またはサービスを特定します。製品別にサービスプロセスを分析することで、特定の製品でサポート依頼が多いか、問題が複雑か、専門的なスキルを持つ担当者が必要かを把握できます。分析結果は、製品の改善やリソース計画に役立ちます。
重要な理由
製品ごとのプロセス分析を通じて、繰り返し発生する製品の問題を特定し、サポート文書を改善するとともに、専門知識を持つ担当者を適切に配置できます。
入手先
Case(incident)エンティティの「製品」(productid)参照フィールドに対応します。
例
Alpha-100プリンターZeta CRMソフトウェアOmegaデータプラン
|
|||
|
手戻りの有無
IsRework
|
ケースに手戻りのアクティビティが含まれているかを示す計算フラグ。 | ||
|
説明
このブール型フラグは、「顧客に情報を依頼」イベントの繰り返しや、解決後の「ケース再開」イベントなど、手戻りのループやアクティビティの繰り返しがあるケースを特定します。アクティビティの順序を分析し、非効率や初回で問題を解決できなかったことを示すパターンを検出して算出します。「手戻りと再問い合わせの分析」ダッシュボードに欠かせない属性です。
重要な理由
プロセスの非効率を定量化して特定できるため、分析担当者は作業の繰り返しや労力の浪費につながる根本原因に注目できます。
入手先
プロセスマイニング分析を使い、「解決済み→再開」などの特定のアクティビティの順序や、ケース内でのアクティビティの繰り返しを検出して算出します。
例
truefalse
|
|||
|
担当チーム
OwnerTeam
|
現在、サービスリクエストを担当しているチーム。 | ||
|
説明
この属性は、サービスリクエストを担当するチームを特定します。リクエストの担当は、個人の担当者またはチーム(キュー)です。チーム別の分析は、チームごとの実績や、サポート階層・専門分野間の業務量の分布を把握し、チーム間のプロセスの違いを特定するうえで重要です。
重要な理由
チーム単位で実績を分析できるため、サポート階層や専門チームを効果的に管理するのに役立ちます。
入手先
Case(incident)エンティティの「所有者」(ownerid)フィールドから取得します。所有者がSystem UserではなくTeamレコードの場合に該当します。
例
一次サポート請求部門技術専門チーム
|
|||
|
顧客満足度(CSAT)スコア
CustomerSatisfactionScore
|
ケース解決後に顧客が回答した満足度スコア。 | ||
|
説明
この属性には、通常はサービスリクエストの終了後に実施する顧客満足度(CSAT)調査で得られた数値またはカテゴリ別の評価が記録されます。サービス品質に対する顧客の評価を直接測定できます。「顧客満足度の推移」ダッシュボードや「解決後の平均CSATスコア」KPIに欠かせないデータであり、プロセスの実績と顧客の評価を結び付けて確認できます。
重要な理由
顧客満足度を直接測定し、プロセスの進め方と顧客の評価を関連付けて、改善につなげることができます。
入手先
通常はCustomer Voiceなどの関連する調査エンティティから取得し、Case(incident)エンティティに関連付けます。
例
5341
|
|||
顧客サービスのアクティビティ
| アクティビティ | 説明 | ||
|---|---|---|---|
|
SLAタイマー開始
|
ケースに対するサービスレベル契約(SLA)タイマーの開始を示します。「First Response By」や「Resolve By」など、定義されたサービス指標に対する経過時間の計測が始まります。Dynamics 365のSLAエンジンが管理する明示的なイベントです。 | ||
|
重要な理由
このアクティビティは、SLA適合性の監視や、サービス上の約束に対する計測開始時点の把握に欠かせません。サービス目標を達成できているかどうかの分析に直接役立ちます。
入手先
「Incident」エンティティに関連付けられた「SLA KPI Instance」エンティティに記録されます。該当するSLA KPI Instanceレコードの「createdon」タイムスタンプが開始時刻です。
記録
ケースに関連付けられた「SLA KPI Instance」レコードの作成時刻を使用します。
イベントタイプ
explicit
|
|||
|
ケースのエスカレーション
|
ケースを上位のサポート階層や別のチームに正式に引き継ぐことを示します。指定されたエスカレーションキューやユーザーにケースを再割り当てする、明示的なユーザー操作の場合があります。 | ||
|
重要な理由
エスカレーションを監視すると、「社内エスカレーション率」KPIの把握や、一次対応で解決できない問題の根本原因の特定に役立ちます。プロセス上の課題や、トレーニングが必要な領域も明らかになります。
入手先
「ownerid」フィールドが指定されたエスカレーションキューまたはチームに変更されたことから推定します。ケースをエスカレーション済みとして記録するカスタム操作が明示的に行われる場合もあります。
記録
「ownerid」が既知のエスカレーションキューに変更された時刻を特定します。
イベントタイプ
inferred
|
|||
|
ケース作成
|
このアクティビティは、システムに新しいケースレコードが作成された時点を示し、カスタマーサービスプロセスの開始となります。「Incident」エンティティのレコードが初めて保存された時刻が、明示的なイベントとして記録されます。 | ||
|
重要な理由
主要な開始イベントであるこのアクティビティは、ケースのライフサイクル全体にかかる時間の計算や、ケース件数の推移を把握するうえで欠かせません。以降のプロセス分析の基準点となります。
入手先
新しいレコードごとに、「Incident」(Case)エンティティの「createdon」タイムスタンプからこのイベントを取得します。
記録
Incidentレコードの「createdon」タイムスタンプを使用します。
イベントタイプ
explicit
|
|||
|
ケース割り当て
|
このアクティビティは、対応のためにケースを特定のキューまたはユーザーに割り当てることを示します。システムではケースの所有者の変更が明示的に記録され、監査ログで追跡できます。 | ||
|
重要な理由
割り当てを追跡すると、業務負荷の分布や割り当てに伴う遅延、振り分けの効率を分析できます。ケースが適切なチームや担当者にどれだけ早く届くかを把握するのにも役立ちます。
入手先
「Incident」エンティティの「ownerid」フィールドの変更を追跡して取得します。変更時刻は監査履歴ログで確認できます。
記録
監査ログから「ownerid」フィールドの変更時刻を抽出します。
イベントタイプ
explicit
|
|||
|
ケース終了
|
ケースレコードを最終的に事務処理上終了することを示します。解決と同時に行われる場合もあれば、後から行われる場合もあります。ケースの状態が「Closed」に変更されたことで取得します。 | ||
|
重要な理由
システム上のプロセスライフサイクルの最終時点を示します。「Resolved」から「Closed」までの時間から、事務処理の負担やレコード確定の遅れを把握できます。
入手先
「Incident」エンティティの「statecode」フィールドが「Canceled」(2)またはカスタムの終了状態に変更されたことで取得します。変更時刻は監査履歴で確認できます。
記録
「statecode」が最終状態(例:Canceled/Closed)に変更された時刻を追跡します。
イベントタイプ
explicit
|
|||
|
ケース解決
|
エージェントが顧客の問題に対処できたと判断した時点を示す、重要なマイルストーンです。Dynamics 365で明示的に実行され、ケースに関連付けられた「Case Resolution」アクティビティレコードが作成されます。 | ||
|
重要な理由
成功を示す主要な終了イベントであるこのアクティビティは、解決時間や解決率の計算に欠かせません。ほぼすべてのカスタマーサービスKPIに関わる重要な要素です。
入手先
「Resolution」(Case Resolution)アクティビティレコードの作成に対応します。このレコードの「actualend」タイムスタンプが解決時刻を示します。
記録
関連する「Resolution」アクティビティレコードの「actualend」または「createdon」タイムスタンプを使用します。
イベントタイプ
explicit
|
|||
|
エージェントによるキューアイテム取得
|
エージェントが共有キューからケースを取り出し、対応を開始した時点で発生するイベントです。システムがケースをキューに割り当てる処理とは異なり、ユーザーが意図的に行う操作です。 | ||
|
重要な理由
このアクティビティから、エージェントが対応を始めるまでケースがキューで待機した時間を測定できます。キューのボトルネックや、エージェントの対応開始の状況を把握するうえで役立ちます。
入手先
ケースに関連付けられた「QueueItem」エンティティの「workedbyid」フィールドをユーザーが更新したとき、またはケースの所有者がキューからユーザーに変更されたときに追跡します。
記録
QueueItemの「workedbyid」フィールドに値が設定された時刻を特定します。
イベントタイプ
explicit
|
|||
|
エージェントによる問題調査
|
エージェントが顧客の問題を理解し、原因を調べている状態を示します。推定されるアクティビティで、エージェントがケースにナレッジ記事を関連付けたことを手がかりに、調査が行われたと判断する場合があります。 | ||
|
重要な理由
このアクティビティを追跡すると、ナレッジリソースの利用状況や、解決時間への影響を測定できます。エージェントが利用可能なツールを使って、効率よく問題を解決しているかを把握できます。
入手先
ナレッジ記事とケースを関連付ける「IncidentKnowledgeBaseRecord」エンティティのレコード作成から推定します。レコードの作成時刻を使用します。
記録
ナレッジ記事がIncidentに関連付けられた時刻を使用します。
イベントタイプ
inferred
|
|||
|
ケースの再有効化
|
解決済みのケースが自動または手動で再開されたときに発生します。通常、顧客から返信があった場合や、問題が解決していないと報告された場合に起こります。ケースのステータスが「Resolved」から「Active」に戻る、標準的なシステム動作です。 | ||
|
重要な理由
このアクティビティは、手戻りの特定や「初回問い合わせ解決率」の分析に欠かせません。再有効化が多い場合、最初の解決策が不十分、または効果的でなかった可能性があります。
入手先
「Incident」エンティティの「statecode」フィールドが「Resolved」(1)から「Active」(0)に戻ったことで取得します。この変更時刻は監査履歴に記録されます。
記録
監査ログで「statecode」がResolvedからActiveに変更された時刻を追跡します。
イベントタイプ
explicit
|
|||
|
ケース分類の変更
|
ケースの作成後にエージェントがカテゴリや件名を変更したときに発生するイベントです。システムの監査機能で明示的に追跡されます。 | ||
|
重要な理由
「サービスリクエスト再分類率」KPIを把握するには、再分類の追跡が欠かせません。再分類が頻繁に発生している場合、初期のトリアージに問題があり、誤った振り分けや遅延につながっている可能性があります。
入手先
「Incident」エンティティの監査履歴から取得します。具体的には、「subjectid」フィールドやその他のカスタム分類フィールドの変更を追跡します。
記録
監査ログから「subjectid」フィールドの変更時刻を抽出します。
イベントタイプ
explicit
|
|||
|
満足度調査の送信
|
顧客満足度調査を送信したことを示します。通常、ケースの解決後に自動で送信され、送信メールまたはCustomer Voiceの調査アクティビティとして記録されます。 | ||
|
重要な理由
このアクティビティによって、業務プロセスと顧客体験の結果を関連付けられます。ケースがたどったプロセス経路と満足度スコアを合わせて分析できます。
入手先
調査リンクを含む送信メールの「Email」アクティビティの作成、またはケースに関連する「Customer Voice survey invite」アクティビティレコードから推定します。
記録
調査に関連するアクティビティレコードの作成時刻を使用します。
イベントタイプ
inferred
|
|||
|
顧客への情報提供依頼
|
対応を進めるために、エージェントが顧客から追加情報を得る必要がある時点を示します。ケースのステータスが「waiting」状態に変更されたことや、ケースのタイムラインからメールが送信されたことを手がかりに推定する場合があります。 | ||
|
重要な理由
顧客からの情報待ちによる遅延を測定し、「顧客情報待ち時間」のKPIを把握するうえで欠かせません。外部からの回答を待つプロセス時間を切り分けられます。
入手先
「Incident」エンティティの「statuscode」フィールドが、「On Hold」などの値に変更され、理由が「Waiting for Customer」となったことから推定できます。このステータス変更の時刻を使用します。
記録
指定された「顧客からの回答待ち」状態にstatuscodeが変更された時刻を追跡します。
イベントタイプ
inferred
|
|||
|
顧客への解決策の提示
|
エージェントが解決策をまとめ、顧客に伝えたことを示します。通常は、ケースのタイムラインから送信されたメールや、ステータスが「Pending Customer Confirmation」に変更されたことから推定します。 | ||
|
重要な理由
このマイルストーンは、調査から解決へ移る時点を示します。解決策の提示から確認までの時間を分析すると、顧客の回答待ちによる遅延や、提示した解決策の問題を明らかにできます。
入手先
ケースに関連する送信メールの「Email」アクティビティレコードのタイムスタンプ、または解決前の状態へのstatuscode変更から推定できます。
記録
送信メールのアクティビティ時刻、またはステータスが「Solution Proposed」に変更された時刻を使用します。
イベントタイプ
inferred
|
|||
データ抽出ガイド
始める準備はできていますか?
このデータテンプレートを使って、プロセスマイニングをすぐに始め、カスタマーサービス業務の効率化につなげましょう。ワークフローの改善に取り組み、顧客体験の向上を目指せます。
カスタマーサービスを改善:初回解決率を高め、コストを削減
ボトルネックを特定し、初回問い合わせでの解決率80%を目指して顧客満足度を高めます。
クレジットカードは不要です。数分で設定できます。