顧客サービスデータテンプレート
顧客サービスデータテンプレート
- 収集を推奨する属性
- 追跡すべき主要なアクティビティ
- 抽出方法
カスタマーサービスの属性
| 名前 | 説明 | ||
|---|---|---|---|
|
サービスリクエスト
ServiceRequest
|
カスタマーサービスのケースまたはチケットを一意に識別し、関連するすべてのアクティビティを結び付ける識別子です。 | ||
|
説明
Service Requestは、TicketまたはCaseとも呼ばれ、単一の顧客からの問い合わせや問題に関連するすべてのアクティビティを結び付ける主要な識別子です。Salesforce Service Cloudでは、Case Numberに対応します。 各顧客とのやり取りを最初から最後まで再構成するために欠かせない属性です。プロセスマイニングツールは、「Case Created」、「Agent Investigates Issue」、「Case Resolved」など、関連するすべてのイベントを1つのプロセスインスタンスにまとめられるため、開始から終了までを一貫して分析できます。
重要な理由
同じ顧客の問題に属するすべてのイベントを1つのまとまったプロセスインスタンスに結び付けるため、プロセスマイニングの基本要素となります。
入手先
Salesforce Caseオブジェクト、フィールド:CaseNumber
例
000010240000105800001193
|
|||
|
アクティビティ名
ActivityName
|
カスタマーサービスプロセス内で発生した、特定の業務イベントまたは手順の名称です。 | ||
|
説明
この属性は、サービスリクエストのライフサイクルにおける1つの手順またはマイルストーンを示します。アクティビティはプロセスマップ上のノードであり、エージェント、自動システム、顧客が実行した操作を表します。 「Case Created」、「Internal Escalation Triggered」、「Case Closed」などのアクティビティの順序と頻度を分析することは、プロセスマイニングの中心です。実際のプロセスフローを明らかにし、ボトルネックを特定し、標準業務手順からの逸脱を見つけられます。
重要な理由
アクティビティがプロセスの手順を定義し、その順序がプロセスマップと以降のすべての分析の基礎になります。
入手先
通常は、Caseオブジェクトのステータス変更(Statusフィールド)や、CaseHistoryまたはEmailMessageオブジェクトのレコードなど、複数のフィールドを組み合わせて生成します。
例
ケース作成ケースをエージェントに割り当て顧客への解決策提案ケースクローズ
|
|||
|
イベント時刻
EventTime
|
アクティビティが発生した時点を示す正確なタイムスタンプです。 | ||
|
説明
イベント時刻は、特定のアクティビティがシステムに記録された日付と時刻を示します。プロセス全体の時間的な文脈を提供し、所要時間、待機時間、サイクルタイムを計算できます。 分析では、このタイムスタンプを使ってサービスリクエストごとにイベントを時系列に並べ、プロセスディスカバリーの基礎を作ります。「Case Created」から「Initial Acknowledgment Sent」までの時間や、解決までの合計時間など、パフォーマンス関連KPIの測定にも欠かせません。
重要な理由
このタイムスタンプは、プロセスの時間軸を把握し、パフォーマンス指標を計算し、アクティビティ間の遅延を特定するために重要です。
入手先
CaseオブジェクトのCreatedDateやCaseHistoryレコードのCreatedDateなど、各イベントに対応するさまざまな日付フィールドから生成します。
例
2023-04-15T10:00:00Z2023-04-15T11:23:14Z2023-04-16T09:05:30Z
|
|||
|
ソースシステム
SourceSystemName
|
プロセスデータの取得元となるシステムです。 | ||
|
説明
この属性は、データが生成された元のアプリケーションを示します。この場合はSalesforce Service Cloudです。複数のシステムのデータを組み合わせてプロセス全体を把握する環境で特に役立ちます。 単一のシステムだけを分析する場合でも、データの出所に関する重要な文脈を提供します。データガバナンスやトラブルシューティングに役立ち、正しいデータセットに基づいて分析できるようにします。
重要な理由
データの出所に関する重要な文脈を提供します。データガバナンスや、複数のシステムのデータを組み合わせる分析に欠かせません。
入手先
通常は、データの抽出・変換処理でデータセットの出所を示すために追加する固定値です。
例
Salesforce Service CloudSFSC
|
|||
|
最終データ更新
LastDataUpdateTime
|
このプロセスのデータが最後に更新された時点を示すタイムスタンプです。 | ||
|
説明
ソースシステムからデータを最後に抽出または更新した時点のタイムスタンプを記録する属性です。個々のイベントではなく、データセット全体に適用されるメタデータフィールドです。 主な用途は、分析対象データの鮮度を利用者に知らせることです。最新かつ関連性の高い情報に基づいて判断できるようにするうえで重要であり、データの更新時点に関する認識も合わせられます。
重要な理由
データの鮮度を明確にし、分析対象がどの時点の情報なのかを把握できるようにします。
入手先
通常は、データの抽出、変換、ロード(ETL)処理の中で生成・保存されます。
例
2023-10-27T04:00:00Z
|
|||
|
SLAステータス
SlaStatus
|
CaseがSLAの目標時間内に解決されたかどうかを示します。 | ||
|
説明
この属性は、定められたService Level Agreementの遵守状況に基づいて、解決済みのCaseを分類します。実際の解決日時と「SLA Target Resolution Time」を比較して算出します。 この属性は、SLA Adherence Rate KPIへの直接的な入力値であり、パフォーマンスの監視を簡単にします。コンプライアンス違反となったCaseをすばやく絞り込み、SLA違反の共通する根本原因を分析できます。原因としては、特定のCaseタイプ、製品、プロセスのボトルネックなどが考えられます。
重要な理由
CaseごとのSLA遵守状況を明確な二値結果で示せるため、パフォーマンスの監視や遅延の根本原因分析に欠かせません。
入手先
データ変換レイヤーで、「Case Resolved」のタイムスタンプと「SlaTargetResolutionTime」属性を比較して算出します。
例
達成違反
|
|||
|
SLA目標解決時間
SlaTargetResolutionTime
|
SLAに基づき、サービスリクエストを解決すべき目標日時です。 | ||
|
説明
この属性は、ケースを解決するためのService Level Agreement(SLA)の期限を定義します。通常は、ケースの優先度、タイプ、顧客ランクなどに基づいて決まります。Salesforceでは、権利付与機能とマイルストーン機能を使って自動計算できます。 このタイムスタンプは、SLA遵守状況を測定するために欠かせません。実際の解決時間と目標を比較することで、組織はSLA遵守率KPIを計算し、SLA違反のリスクがあるケースを特定できます。Case SLA Adherenceダッシュボードにも直接役立ちます。
重要な理由
実際のパフォーマンスを測定する基準となるため、SLAコンプライアンスの計算とリスクのあるケースの特定に欠かせません。
入手先
これは通常、SalesforceのEntitlement Management機能の一部であるCase MilestoneオブジェクトのSlaExitDateフィールドに保存されています。
例
2023-04-16T17:00:00Z2023-04-18T09:00:00Z2023-05-01T12:00:00Z
|
|||
|
ケースステータス
CaseStatus
|
ライフサイクルにおけるサービスリクエストの現在のステータスです。New、In Progress、Closedなどがあります。 | ||
|
説明
ケースステータスは、サービスリクエストの現在の状態を示します。ステータスの変更は、プロセス内のアクティビティを特定する主な情報源です。たとえば、「New」から「Working」への変更を「Agent Investigates Issue」アクティビティに対応付けられます。 ケースの最終ステータスを分析すると、解決結果を把握できます。オープンまたはクローズ済みのケースを絞り込み、特定の状態に長く滞留しているケースを特定する際にも使われます。
重要な理由
ケースの現在の状態と結果を把握でき、ステータスの変更からアクティビティの順序を導出できることが多いです。
入手先
Salesforce Caseオブジェクト、フィールド:Status
例
新規対応中顧客対応待ちクローズ済み
|
|||
|
ケースタイプ
CaseType
|
サービスリクエストの分類です。Question、Problem、Feature Requestなどがあります。 | ||
|
説明
ケースタイプは、顧客からの問い合わせや問題の性質を分類するためのカテゴリ属性です。サービスリクエストを分けて分析し、種類ごとの対応方法を把握できます。 ケースタイプ別にプロセスを分析すると、特定のリクエストが異なる経路をたどる、解決時間が長い、引き継ぎが多いといった傾向を明らかにできます。特定の業務カテゴリに合わせてプロセスを調整・改善するために役立つ情報です。
重要な理由
リクエストの種類ごとに対応方法が異なるかを把握し、専門的な改善が必要な領域を特定できます。
入手先
Salesforce Caseオブジェクト、フィールド:Type
例
問題機能リクエスト質問
|
|||
|
ケース優先度
CasePriority
|
サービスリクエストに設定された優先度です。High、Medium、Lowなどがあります。 | ||
|
説明
ケース優先度は、サービスリクエストの緊急度を判断するための標準的な分類です。この指定に基づき、Service Level Agreement(SLA)に応じた目標応答時間や解決時間が決まることが多いです。 優先度別にプロセスのパフォーマンスを分析することは、優先順位付けの有効性を評価するうえで重要です。優先度の高いケースが実際に早く解決され、厳しいSLA目標を達成しているかを確認でき、Case Prioritization and Impactダッシュボードを直接支援します。
重要な理由
緊急度の高いケースをプロセス上で適切に優先し、ケースの重要度に応じた異なるサービスレベルを満たせているかを分析できます。
入手先
Salesforce Caseオブジェクト、フィールド:Priority
例
高中低
|
|||
|
コミュニケーションチャネル
CommunicationChannel
|
サービスリクエストの開始に使われたチャネルです。メール、電話、Webなどがあります。 | ||
|
説明
この属性は、顧客がサービスリクエストを送信する際に使ったコミュニケーション手段を示します。Salesforceでは、通常Case Originフィールドに記録されます。 コミュニケーションチャネルを把握することは、リソース配分の最適化とサービス効率の向上に欠かせません。チャネル別に解決時間とプロセスフローを分析することで、どの種類の問題にどのチャネルが適しているかを特定でき、Communication Channel Efficiencyダッシュボードを支援します。
重要な理由
異なる顧客接点チャネルのパフォーマンスを比較し、チャネル戦略とリソース配分を最適化できます。
入手先
Salesforce Caseオブジェクト、フィールド:Origin
例
メール電話Webチャット
|
|||
|
初回接触で解決したかどうか
IsFirstContactResolution
|
顧客との最初のやり取りでCaseが解決されたかどうかを示すフラグです。 | ||
|
説明
このブール型属性は、顧客との最初の接触後に追加対応を必要とせず解決されたサービスリクエストを識別します。判定ロジックでは、通常、アクティビティの順序とタイミングを分析します。 初回接触解決率(FCR)が高いことは、顧客サービスプロセスが効率的かつ効果的であることを示す有力な指標です。この計算属性は、First Contact Resolution Rate KPIの基礎になります。初回接触で解決できなかったCaseを分析すると、担当者のトレーニング、ナレッジベースの内容、プロセス設計を改善する機会が見えてきます。
重要な理由
サービスの効率性と顧客満足度に関わる重要な側面を直接測定でき、問題解決を効果的に進める要因の特定に役立ちます。
入手先
データ変換時に、対象Caseのイベントログを分析して算出します。一般的なルールでは、「Case Resolved」が「Information Requested From Customer」またはその後の顧客接触アクティビティより前に発生しているかを確認します。
例
truefalse
|
|||
|
担当エージェント
AssignedAgent
|
現在、サービスリクエストを担当しているユーザーまたはキューです。 | ||
|
説明
この属性は、特定の時点でサービスリクエストを担当する個人のエージェントまたはチームを示します。Salesforceでは、通常Case Ownerに該当します。 この属性の変更を追跡することは、エージェントのパフォーマンス、業務量の配分、引き継ぎを分析するうえで基本となります。ケースが何回再割り当てされたか、どのエージェントが最も複雑なケースを担当しているか、チーム内で業務量が均衡しているかなどを確認できます。Agent HandoffsおよびWorkload Distributionダッシュボードの主要な属性です。
重要な理由
エージェントの業務量、パフォーマンス、引き継ぎ頻度を分析するために欠かせません。これらは効率と解決時間に直接影響します。
入手先
Salesforce Caseオブジェクト、フィールド:OwnerId。このフィールドにはUserまたはQueueのIDが格納されます。
例
Sarah JonesDavid ChenTier 2サポートキュー
|
|||
|
終了時刻
EndTime
|
アクティビティが完了した時点を示すタイムスタンプです。 | ||
|
説明
終了時刻は、アクティビティが完了した時刻を示します。開始時刻と組み合わせることで、アクティビティの処理時間を正確に計算できます。Salesforceの多くのイベントは瞬時に発生するため、開始時刻と終了時刻が同じになります。 一方、長時間にわたるアクティビティでは、作業にかかった時間を正確に測定するために、個別の終了時刻が欠かせません。手順間の待機時間と実際の処理時間を分けて分析できるため、パフォーマンス分析を直接支援します。
重要な理由
アクティビティの実際の所要時間を計算できます。エージェントのパフォーマンスを分析し、時間のかかる手順を特定するために欠かせません。
入手先
瞬時に発生するイベントでは、開始時刻と同じになることが多いです。所要時間のあるアクティビティでは、完了を示す特定のフィールドから取得する必要があり、カスタム設定が必要になる場合があります。
例
2023-04-15T10:00:00Z2023-04-15T11:55:00Z2023-04-16T14:20:00Z
|
|||
|
Caseの件名
CaseSubject
|
顧客の問題またはリクエストを簡潔にまとめた概要やタイトルです。 | ||
|
説明
Caseの件名には、サービスリクエストの簡潔な自由記述の概要が入ります。多くの場合、メールの件名、または担当者や顧客が入力したタイトルです。 構造化されたフィールドではないため、直接的なプロセス分析には向きませんが、件名には豊富な文脈情報が含まれています。テキストマイニングの手法と組み合わせることで、Caseの分類、新たな問題の把握、定量的なプロセス分析への定性的な情報の追加に利用できます。
重要な理由
Caseの概要をすばやく把握できるため、ドリルダウン分析に役立ち、テキストマイニングにも利用できます。
入手先
SalesforceのCaseオブジェクトのフィールド:Subject
例
ポータルにログインできない請求明細についての質問レポーティングダッシュボードの機能リクエスト
|
|||
|
エスカレーション済みかどうか
IsEscalated
|
Caseがエスカレーションされたかどうかを示すフラグです。 | ||
|
説明
このブール型属性は、サービスリクエストがエスカレーションされたかどうかを示します。Salesforceでは、標準のIsEscalatedフィールドで追跡できます。このフィールドは、Escalation Rulesに基づいて自動的に設定されます。 このフラグは、Internal Escalation AnalysisダッシュボードとInternal Escalation Rate KPIへの直接的な入力値です。エスカレーションされたCaseを簡単に絞り込み、集計できるため、発生頻度を定量化し、解決時間全体やプロセスの複雑さへの影響を分析できます。
重要な理由
Caseのエスカレーションを直接測定できるため、プロセス上の摩擦、複雑さ、担当者の知識不足を示す重要な指標になります。
入手先
SalesforceのCaseオブジェクトのフィールド:IsEscalated
例
truefalse
|
|||
|
手戻りがあるかどうか
IsRework
|
Caseに手戻りや前の段階へのループが発生したかどうかを示すフラグです。 | ||
|
説明
このブール型属性は、クローズ後に再オープンされたり、「Agent Investigates」と「Solution Proposed」の間を繰り返し移動したりするなど、手戻りのパターンを示すCaseにフラグを付けます。手戻りの特定には、望ましくないループがないかアクティビティの順序を分析する必要があります。 この属性は、Rework Rate KPIとAgent Handoffs and Rework Patternsダッシュボードを直接支援します。手戻りが発生したCaseを特定することで、解決策の不備や情報収集の不足など、根本原因を調査し、是正措置を講じられます。
重要な理由
プロセスの非効率や無駄な作業を明らかにし、繰り返し発生するアクティビティを重点的に分析できます。
入手先
データ変換時にアクティビティの順序を分析して算出します。たとえば、同じCase内で「Case Closed」→「Case Reopened」、または「Solution Proposed」→「Agent Investigates Issue」という順序が発生した場合、手戻りとしてフラグを付けます。
例
truefalse
|
|||
|
担当者間の引き継ぎ回数
AgentHandoffCount
|
Caseがある担当者またはキューから別の担当者またはキューへ再割り当てされた回数です。 | ||
|
説明
この指標は、サービスリクエストが解決されるまでに発生した再割り当ての回数を定量化します。1件のCaseのライフサイクル中における「AssignedAgent」属性の異なる変更回数を数えて算出します。 この属性は、Average Agent Handoffs per Case KPIの基礎となり、Agent Handoffs and Rework Patternsダッシュボードに表示されます。引き継ぎ回数が多い場合、プロセスの非効率、担当範囲の不明確さ、知識不足が示唆されます。これらは解決時間の長期化や顧客の不満につながる可能性があります。
重要な理由
プロセス内部の摩擦を定量化できます。過度な引き継ぎは、遅延や顧客満足度の低下を招く一般的な要因です。
入手先
データ変換時にCase単位で算出します。各「ServiceRequest」の「AssignedAgent」フィールドに含まれる一意の値の数から1を引いて求めます。
例
0135
|
|||
|
関係する製品
ProductInvolved
|
顧客のリクエストの対象となる具体的な製品またはサービスです。 | ||
|
説明
この属性は、サービスリクエストを特定の製品またはサービスに関連付けます。Salesforceでは、通常、Productオブジェクトへの参照によって管理されます。 製品別にプロセスデータを分類することは、製品品質の分析に欠かせません。どの製品でサポートリクエストが最も多いか、どのような問題が発生しているか、製品ラインによって解決プロセスに違いがあるかを把握できます。この情報は、製品開発チームにとって重要なフィードバックになります。
重要な理由
製品を軸にしたプロセス分析が可能になり、特定の製品に関する品質問題やサポートの不足を見つけられます。
入手先
SalesforceのCaseオブジェクトのフィールド:ProductId。標準フィールドですが、任意で使用できます。
例
Alpha CRM SuiteBeta Analytics ToolGamma Data Connector
|
|||
|
顧客名
CustomerName
|
サービスリクエストに関連付けられた顧客またはアカウントの名前です。 | ||
|
説明
この属性は、サービスリクエストを開始した顧客を識別します。Salesforceでは、個人を表すContact、または企業を表すAccountが該当します。 顧客の視点からプロセスを分析すると、具体的な改善につながる情報を得られます。たとえば、特定の顧客で問題の発生頻度や解決時間が高くなっていないかを確認できます。こうした分析結果は、顧客関係管理の方針策定に役立つほか、先回りしたサポートの機会を見つける手がかりになります。
重要な理由
顧客を軸にした分析が可能になり、特定の顧客や顧客セグメントにおけるパターンやパフォーマンスの違いを把握できます。
入手先
SalesforceのCaseオブジェクトのフィールド:ContactIdまたはAccountId。これらはそれぞれContactオブジェクトとAccountオブジェクトにリンクします。
例
Global Tech Inc.Emily WhiteInnovate Solutions
|
|||
カスタマーサービスのアクティビティ
| アクティビティ | 説明 | ||
|---|---|---|---|
|
SLAマイルストーン違反
|
初回応答時間や解決時間など、サービス上の約束が守られなかった時点で発生します。Salesforceでは、権利付与プロセスとマイルストーンレコードを使って追跡します。 | ||
|
重要な理由
このアクティビティは、SLA遵守状況の分析とコンプライアンス監視に欠かせません。顧客の期待に応えられなかったケースを直接示すため、対象を絞ったプロセス改善が可能になります。
入手先
CaseMilestoneオブジェクトから取得します。マイルストーンレコードのIsViolatedフィールドがtrueに設定された時点でイベントを生成します。
取得
CaseMilestoneレコードのIsViolatedフラグがtrueになった時点のタイムスタンプです。
イベントタイプ
explicit
|
|||
|
ケースクローズ
|
サービスリクエストのライフサイクルが最終的かつ確定的に終了したことを示します。ケースがクローズされると、再オープンされない限り追加の作業は想定されません。 | ||
|
重要な理由
終端イベントとして、ケース期間全体を計算するための最終的な終点になります。「Resolved」から「Closed」までの時間から、クローズ処理の非効率も把握できます。
入手先
CaseオブジェクトのIsClosedフィールドがtrueに設定された時点のタイムスタンプから推定します。この時点でClosedDateフィールドも入力されます。
取得
IsClosedフィールドがtrueに変更され、CaseHistoryに記録された時点のタイムスタンプです。
イベントタイプ
inferred
|
|||
|
ケースをエージェントに割り当て
|
サービスリクエストが、対応を担当する特定のエージェントまたはキューに割り当てられた時点を示します。ケースの所有者フィールドの変更によって記録される、プロセスの基本的な手順です。 | ||
|
重要な理由
このアクティビティは、エージェントの業務量、割り当ての遅延、引き継ぎ頻度を追跡するために欠かせません。エージェントのパフォーマンスを分析し、割り当てプロセスのボトルネックを特定する基盤になります。
入手先
CaseオブジェクトのOwnerIdフィールドの変更から推定します。変更のタイムスタンプはCaseHistoryオブジェクトに記録されます。
取得
OwnerIdフィールドが初めて更新された時点のタイムスタンプを特定します。
イベントタイプ
inferred
|
|||
|
ケース作成
|
このアクティビティは、新しいサービスリクエスト、つまりケースがSalesforceに記録された時点で、カスタマーサービスプロセスが正式に開始されたことを示します。Caseオブジェクトに新しいレコードが作成された際、正確なタイムスタンプとともに明示的に記録されます。 | ||
|
重要な理由
主要な開始イベントであるこのアクティビティは、ケースのライフサイクル全体と解決時間を計算するうえで欠かせません。SLAに対するパフォーマンスを測定し、ケース件数を把握するための基準点になります。
入手先
Caseオブジェクトのレコード作成イベントに対応します。タイムスタンプは標準のCreatedDateフィールドに記録されます。
取得
Caseレコードの作成タイムスタンプから直接取得します。
イベントタイプ
explicit
|
|||
|
ケース解決
|
この重要なマイルストーンは、エージェントが顧客の問題を解決するために必要な作業を完了したことを示します。ケースは最終クローズ待ちの状態となり、一定期間後に自動でクローズされる場合があります。 | ||
|
重要な理由
解決時間を測定するための主要な終点であり、SLA遵守状況の計算に欠かせません。ケースに対する実作業の終了を示します。
入手先
CaseHistoryオブジェクトでStatusフィールドが「Resolved」に変更された時点から推定します。この時点ではIsClosedフィールドがfalseのままの場合があります。
取得
CaseのStatusが「Resolved」に変更された時点のタイムスタンプです。
イベントタイプ
inferred
|
|||
|
社内エスカレーション発生
|
ケースにより高度なサポートや専門知識が必要となり、正式にエスカレーションされた時点で発生します。Salesforceのエスカレーションルールによって明示的に記録することも、フィールドの変更から推定することもできます。 | ||
|
重要な理由
エスカレーションを分析すると、複雑なケースの種類、現場エージェントの研修ニーズ、組織的な問題を特定できます。プロセス上の摩擦と解決時間への影響を示す重要な指標です。
入手先
CaseEscalationレコードから明示的なイベントとして取得できます。より一般的には、CaseHistoryで「IsEscalated」などのチェックボックスフィールドがtrueに設定された時点から推定します。
取得
「IsEscalated」フィールドがtrueに変更された時点のタイムスタンプです。
イベントタイプ
inferred
|
|||
|
エージェントによる問題調査
|
エージェントが顧客の問題を診断し、内容を把握するために実際に対応している段階を示します。明示的なイベントではなく、ケースのステータスが新規またはオープンから対応中に変わった時点から推定します。 | ||
|
重要な理由
調査段階の所要時間を把握すると、サービスリクエストの複雑さや、エージェントに追加の研修・リソースが必要な領域を特定できます。実際の作業時間と待機時間を分けて分析できます。
入手先
CaseHistoryオブジェクトで、Statusフィールドが「In Progress」や「Working」など、対応中を示す値に更新された時点から推定します。
取得
CaseのStatusが「対応中」を示す値に変更された時点のタイムスタンプです。
イベントタイプ
inferred
|
|||
|
ケースの再割り当て
|
初回の割り当て後に、ケースが別のエージェントまたはキューへ移管される引き継ぎを示します。その後のケース所有者フィールドの変更から推定します。 | ||
|
重要な理由
再割り当てが頻繁に発生する場合、初回の振り分けミス、プロセスの非効率、ナレッジ不足などが原因で、遅延や顧客体験の低下につながっている可能性があります。このアクティビティにより、エージェント間の引き継ぎを定量化できます。
入手先
初回の割り当て後にCaseHistoryオブジェクトでOwnerIdフィールドが変更された時点から推定します。
取得
OwnerIdフィールドについて、初回更新後のすべての更新を特定します。
イベントタイプ
inferred
|
|||
|
ケースの分類と優先度設定
|
ケースにタイプ、カテゴリ、優先度が設定された時点で発生するアクティビティです。トリアージチームや自動化ルールによって実施されることが多く、関連するケースフィールドの変更から推定します。 | ||
|
重要な理由
分類は、ケースの分布と振り分けの有効性を把握するための基礎です。この手順を分析することで、業務量の配分を最適化し、優先度の高いケースに速やかに対応できるようになります。
入手先
CaseHistoryオブジェクトから、Priority、Typeなどの分類フィールドが初めて入力された時点、またはデフォルト値から変更された時点を追跡して推定します。
取得
CaseHistoryでPriorityやTypeなどのフィールド更新を追跡します。
イベントタイプ
inferred
|
|||
|
ケース再オープン
|
解決済みまたはクローズ済みのケースが、問題の再発や解決策の不備によって再び有効化された時点で発生します。手戻りを示す重要な指標です。 | ||
|
重要な理由
再オープンされたケースは、解決品質の低さやFirst Contact Resolutionの失敗を強く示します。サービス品質を改善するには、発生頻度と根本原因を分析することが欠かせません。
入手先
CaseHistoryオブジェクトでIsClosedフィールドがtrueからfalseに変更された時点、またはStatusがクローズ済み・解決済みの状態からオープン状態に戻った時点から推定します。
取得
StatusまたはIsClosedフィールドが終端状態から対応中の状態に変更された時点のタイムスタンプです。
イベントタイプ
inferred
|
|||
|
初回確認メール送信
|
サービスリクエストを受け付けたことを顧客に知らせる、最初の連絡を示します。通常は、ケース作成ルールによって送信される自動メールです。最初の送信連絡を特定して推定します。 | ||
|
重要な理由
このアクティビティを追跡することで、初回応答時間を測定し、顧客に速やかに情報を伝えられているかを確認できます。「初回確認遅延」KPIの分析にも役立ち、顧客とのコミュニケーション改善につながります。
入手先
Caseに関連付けられた最初の送信EmailMessageレコードのタイムスタンプから推定します。自動化ルールによって更新されたカスタムフィールドから推定することもできます。
取得
Caseに関連付けられた最初の送信EmailMessageのタイムスタンプを特定します。
イベントタイプ
inferred
|
|||
|
満足度調査を送信
|
顧客満足度(CSAT)またはNet Promoter Score(NPS)の調査を送信したことを示します。通常は、ケースの解決またはクローズ後に自動で実行されます。 | ||
|
重要な理由
コアとなる解決プロセスの一部ではありませんが、フィードバックループを把握するために重要なアクティビティです。送信のタイミングと頻度を分析することで、顧客の声を継続的に収集できます。
入手先
ケースに関連付けられ、調査テンプレートに一致する送信EmailMessageレコードから推定します。SurveyInvitationレコードの作成から取得することもできます。
取得
送信された調査メール、またはSurveyInvitationレコードの作成を特定します。
イベントタイプ
inferred
|
|||
|
顧客から情報を受領
|
顧客が依頼された情報を提供し、顧客待ちの時間が終了した時点を示します。受信連絡の後、ケースのステータスが再び対応中に変更された時点から推定することが多いです。 | ||
|
重要な理由
このイベントを追跡することで、顧客の回答時間とケースのライフサイクル全体への影響を把握できます。エージェントによる対応の再開も示します。
入手先
ケースに関連付けられた受信EmailMessageのタイムスタンプ、またはCaseHistoryオブジェクトでステータスが「Waiting on Customer」から「In Progress」に変更された時点から推定します。
取得
受信メール、または「待機中」からのステータス変更のタイムスタンプです。
イベントタイプ
inferred
|
|||
|
顧客への情報依頼
|
ケースを進めるためにエージェントが顧客から追加情報を必要とした時点で発生します。通常は、ケースのステータスが「顧客の回答待ち」に変更された時点から推定します。 | ||
|
重要な理由
このアクティビティは、エージェントが管理できない待機時間の開始を示します。この時間を分離することは、社内プロセスの効率とエージェントのパフォーマンスを正確に測定するうえで重要です。
入手先
CaseHistoryオブジェクトで、Statusフィールドが「Waiting on Customer Response」や「Pending」などの値に更新された時点から推定します。
取得
CaseのStatusが「待機中」を示す値に変更された時点のタイムスタンプです。
イベントタイプ
inferred
|
|||
|
顧客への解決策提案
|
エージェントが顧客に解決策の候補を提示した時点を示します。概念上の手順であり、通常は送信連絡または特定のステータス変更から推定します。 | ||
|
重要な理由
このマイルストーンを追跡すると、調査から解決策の提案までにかかった時間を測定できます。解決策が受け入れられなかった場合は、確認のループが始まる時点にもなります。
入手先
特定のキーワードを含む送信EmailMessage、またはCaseHistoryオブジェクトでステータスが「Solution Provided」に変更された時点から推定します。
取得
ステータス変更または送信連絡イベントのタイムスタンプです。
イベントタイプ
inferred
|
|||
抽出ガイド
準備はできましたか?
このデータテンプレートを使ってプロセスマイニングを始め、顧客サービス業務に潜む改善機会を見つけ出しましょう。今すぐサービス提供の変革を始めてください。
顧客サービスの効率を最大限に高める
初回接触解決率80%を達成し、CSATスコアを高めます。
クレジットカードは必要ありません