カスタマーサービスデータテンプレート
カスタマーサービスデータテンプレート
- 収集を推奨する項目
- 追跡すべき主要アクティビティ
- 抽出の手引き
顧客サービス属性
| 名前 | 説明 | ||
|---|---|---|---|
|
サービスリクエスト
ServiceRequest
|
すべての関連アクティビティをリンクする、カスタマーサービスケースまたはチケットの一意の識別子。 | ||
|
説明
サービスリクエストは、チケットまたはケースと呼ばれることが多く、単一の顧客からの問い合わせや問題に関連するすべてのアクティビティをリンクする主要な識別子として機能します。Salesforce Service Cloudでは、これはケース番号に対応します。 この属性は、各顧客インタラクションのエンドツーエンドのジャーニーを再構築するために不可欠です。これにより、プロセスマイニングツールは、「ケース作成」、「エージェントが問題を調査」、「ケース解決」などのすべての関連イベントを単一のプロセスインスタンスにグループ化し、最初から最後まで包括的な分析を可能にします。
その重要性
同じ顧客の問題に属するすべてのイベントを単一のまとまったプロセスインスタンスに接続するため、プロセスマイニングの基本的な構成要素です。
取得元
Salesforce ケースオブジェクト、フィールド: CaseNumber
例
000010240000105800001193
|
|||
|
アクティビティ名
ActivityName
|
カスタマーサービスプロセス内で発生した特定のビジネスイベントまたはステップの名前。 | ||
|
説明
この属性は、サービスリクエストのライフサイクルにおける単一のステップまたはマイルストンを記述します。アクティビティはプロセスマップのノードであり、担当者、自動化システム、または顧客によって実行されるアクションを表します。 「ケース作成」、「内部エスカレーション発生」、「ケースクローズ」などのアクティビティの順序と頻度を分析することは、プロセスマイニングの中心です。これにより、実際のプロセスフローを明らかにし、ボトルネックを特定し、標準的な運用手順からの逸脱を発見するのに役立ちます。
その重要性
アクティビティはプロセスのステップを定義し、その順序がプロセスマップおよびそれに続くすべての分析の基礎を形成します。
取得元
通常、ケースオブジェクトのステータス変更(ステータスフィールド)やCaseHistoryまたはEmailMessageオブジェクトのレコードなど、フィールドの組み合わせから派生します。
例
案件作成エージェントにケース割り当て済み顧客への解決策提示案件クローズ
|
|||
|
イベント日時
EventTime
|
アクティビティが発生した時点を示す正確なタイムスタンプ。 | ||
|
説明
イベントタイムは、システムに特定のアクティビティが記録された日時をキャプチャします。これはプロセス全体の時間的コンテキストを提供し、期間、待機時間、およびサイクル時間の計算を可能にします。 分析では、このタイムスタンプは各サービスリクエストのイベントを時系列に並べ、プロセスディスカバリの基礎を形成するために使用されます。「ケース作成済み」と「初期確認応答送信済み」の間の時間の測定や、総解決時間の計算など、パフォーマンス関連のKPIにとって不可欠です。
その重要性
このタイムスタンプは、プロセスのタイムラインを理解し、パフォーマンスメトリックを計算し、アクティビティ間の遅延を特定するために不可欠です。
取得元
ケースオブジェクトの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
|
ケースがSLA目標内で解決されたかどうかを示します。 | ||
|
説明
この属性は、定義されたサービスレベル契約への遵守に基づいて、解決済みの各ケースを分類します。これは、実際の解決タイムスタンプを「SLA目標解決時間」と比較することで計算されます。 SLA遵守率KPIへの直接的な入力として、この属性はパフォーマンスモニタリングを簡素化します。これにより、すべての非遵守ケースを迅速にフィルタリングして分析し、特定のケースタイプ、製品、プロセスボトルネックなどのSLA違反の共通の根本原因を特定することが可能になります。
その重要性
ケースごとにSLA遵守の明確な二値結果を提供し、これはパフォーマンス監視と遅延の根本原因分析にとって不可欠です。
取得元
データ変換層で、「ケース解決済み」のタイムスタンプと「SlaTargetResolutionTime」属性を比較することで計算されます。
例
達成違反
|
|||
|
SLA目標解決時間
SlaTargetResolutionTime
|
SLAに従って、サービスリクエストが解決されるべき目標日時。 | ||
|
説明
この属性は、ケースを解決するためのサービスレベル契約(SLA)の期限を定義します。通常、ケースの優先度、タイプ、顧客層などの要因に基づいて決定されます。Salesforceは、そのエンタイトルメントおよびマイルストン機能を使用してこれを自動的に計算できます。 このタイムスタンプは、SLA遵守を測定するために不可欠です。実際の解決時間とこの目標を比較することで、組織はSLA遵守率KPIを計算し、SLA違反のリスクがあるケースを特定でき、ケースSLA遵守ダッシュボードを直接サポートします。
その重要性
実際のパフォーマンスを測定するためのベンチマークを提供し、SLA遵守の計算やリスクのあるケースの特定に不可欠です。
取得元
これは多くの場合、Salesforceのエンタイトルメント管理機能の一部であるケースマイルストンオブジェクトのSlaExitDateフィールドに保存されます。
例
2023-04-16T17:00:00Z2023-04-18T09:00:00Z2023-05-01T12:00:00Z
|
|||
|
ケース優先度
CasePriority
|
サービスリクエストに割り当てられた優先度レベル(例:高、中、低など)。 | ||
|
説明
ケース優先度は、サービスリクエストの緊急性を判断するために使用される標準的な分類です。この指定は、多くの場合、サービスレベル契約(SLA)に従って目標応答時間と解決時間を決定します。 優先度に基づいたプロセスパフォーマンスの分析は、優先順位付け戦略の有効性を評価するために重要です。これにより、高優先度ケースが実際に迅速に解決され、そのアグレッシブなSLA目標を達成しているかどうかを判断するのに役立ち、ケース優先度と影響ダッシュボードを直接サポートします。
その重要性
プロセスが緊急性の高いケースを効果的に優先し、ケースの重要度に応じた異なるサービスレベルを満たしているかを分析できます。
取得元
Salesforce ケースオブジェクト、フィールド: Priority
例
高中低
|
|||
|
ケース種別
CaseType
|
サービスリクエストの分類(例:質問、問題、機能リクエストなど)。 | ||
|
説明
ケースタイプは、顧客からの問い合わせや問題の性質を分類するのに役立つ分類属性です。これにより、サービスリクエストをセグメント化し、異なるタイプの問題がどのように処理されているかを理解できます。 ケースタイプに基づいてプロセスを分析することで、特定のタイプのリクエストが異なるパスをたどったり、解決時間が長かったり、より多くの引き継ぎを必要としたりすることが明らかになります。この洞察は、特定の作業カテゴリに合わせてプロセスを調整し、改善するために価値があります。
その重要性
プロセスをセグメント化することで、異なる種類の要求が異なる方法で処理されているか理解し、専門的な改善が必要な領域を特定できます。
取得元
Salesforce ケースオブジェクト、フィールド: Type
例
問題機能リクエスト質問
|
|||
|
ケース解決時間
CaseResolutionTime
|
ケースが作成されてから解決されるまでの経過時間。 | ||
|
説明
このメトリックは、「ケース作成」タイムスタンプから「ケース解決」タイムスタンプまでのサービスリクエストの総期間を測定します。これは、あらゆるカスタマーサービスプロセスにとって最も基本的なKPIの1つです。 この計算された属性は、平均ケース解決時間KPIを直接サポートし、「ケースSLA遵守と解決」ダッシュボードのコアメトリックです。これは、プロセス全体の効率性と顧客体験の明確な尺度を提供します。ケースタイプや優先度などの異なる次元でこのメトリックを分析することは、改善領域を特定するのに役立ちます。
その重要性
これは、プロセス全体の効率性を測定するための主要なKPIであり、顧客のエンドツーエンドの体験を理解するために不可欠です。
取得元
データ変換中に、各サービスリクエストにおける「ケース作成済み」アクティビティと「ケース解決済み」アクティビティのタイムスタンプ間の時間差を見つけることで計算されます。
例
25920000086400000604800000
|
|||
|
コミュニケーションチャネル
CommunicationChannel
|
サービスリクエストが開始されたチャネル(例:メール、電話、ウェブなど)。 | ||
|
説明
この属性は、顧客がサービスリクエストを提出するために使用した通信方法を指定します。Salesforceでは、これは多くの場合「ケース発生源」フィールドに捕捉されます。 コミュニケーションチャネルを理解することは、リソース配分を最適化し、サービス効率を向上させる上で重要です。チャネルごとに解決時間とプロセスフローを分析することで、組織はどのチャネルが異なる種類の問題に最も効果的であるかを特定でき、「コミュニケーションチャネル効率」ダッシュボードをサポートします。
その重要性
異なる顧客接点チャネル間のパフォーマンス比較を可能にし、チャネル戦略とリソース配分の最適化に貢献します。
取得元
Salesforce ケースオブジェクト、フィールド: Origin
例
メール電話番号`Web`チャット
|
|||
|
初回解決かどうかのフラグ
IsFirstContactResolution
|
顧客との最初のやり取りでケースが解決されたかどうかを示すフラグ。 | ||
|
説明
このブール属性は、顧客からの初回連絡後にフォローアップを必要とせずに解決されたサービスリクエストを特定します。これを決定するロジックには、アクティビティのシーケンスとタイミングの分析が含まれることがよくあります。 高い初回解決(FCR)率は、効率的で効果的なカスタマーサービスプロセスの強力な指標です。この計算された属性は、初回解決率KPIの基礎となります。初回連絡で解決されないケースを分析することで、担当者トレーニング、ナレッジベースコンテンツ、およびプロセス設計の改善機会を明らかにすることができます。
その重要性
サービス効率と顧客満足度の主要な側面を直接的に測定し、効果的な問題解決の要因を特定するのに役立ちます。
取得元
データ変換中に特定のケースのイベントログを分析することで計算されます。一般的なルールは、「顧客からの情報要求」またはその後の顧客連絡アクティビティの前に「ケース解決済み」が発生しているかどうかを確認することです。
例
truefalse
|
|||
|
担当者
AssignedAgent
|
サービスリクエストが現在割り当てられているユーザーまたはキュー。 | ||
|
説明
この属性は、特定の時点においてサービスリクエストの処理を担当する個々の担当者またはチームを特定します。Salesforceでは、これは通常ケース所有者です。 この属性への変更を追跡することは、担当者のパフォーマンス、ワークロードの分散、および引き継ぎを分析するために不可欠です。ケースが何回再割り当てされたか、どの担当者が最も複雑なケースを処理するか、ワークロードがチーム全体でバランスが取れているかといった質問に答えるのに役立ちます。これは、「担当者引き継ぎとワークロード分散」ダッシュボードにとって主要な属性です。
その重要性
エージェントのワークロード、パフォーマンス、および引き継ぎ頻度を分析するために不可欠であり、これらは効率性と解決時間に直接影響を与えます。
取得元
Salesforce ケースオブジェクト、フィールド: OwnerId。このフィールドには、ユーザーまたはキューのIDが含まれます。
例
サラ・ジョーンズDavid ChenTier 2サポートキュー
|
|||
|
案件ステータス
CaseStatus
|
サービスリクエストのライフサイクルにおける現在のステータス(例:新規、進行中、クローズ済みなど)。 | ||
|
説明
ケースステータスは、サービスリクエストの現在の状態を示します。「新規」から「進行中」への変更は、「エージェントが問題を調査」アクティビティにマッピングされるなど、ステータス変更はプロセス内のアクティビティを特定するための主要な情報源となることがよくあります。 ケースの最終ステータスを分析することは、解決結果を理解するのに役立ちます。また、オープンまたはクローズされたケースをフィルタリングしたり、特定の状態で長期間停滞している可能性のあるケースを特定するためにも使用されます。
その重要性
ケースの現在の状態と結果に関する洞察を提供し、ステータス変更はアクティビティの順序を導き出すためによく使用されます。
取得元
Salesforce ケースオブジェクト、フィールド: Status
例
新規作業中顧客からの返答待ちクローズ
|
|||
|
終了日時
EndTime
|
アクティビティの完了時刻を示すタイムスタンプ。 | ||
|
説明
終了時刻はアクティビティの完了時刻を表します。開始時刻と組み合わせることで、アクティビティ処理時間の正確な計算が可能になります。Salesforceの多くのイベントでは、イベントは瞬間的であり、開始時刻と終了時刻は同じです。 しかし、長時間実行されるアクティビティの場合、個別の終了時刻を持つことは、タスクに費やされた時間を正確に測定するために不可欠です。これは、アクティブな処理時間とステップ間のアイドル待機時間を区別することで、パフォーマンス分析を直接サポートします。
その重要性
アクティビティの実際の所要時間を計算することが可能になり、エージェントのパフォーマンス分析や時間のかかるステップの特定に不可欠です。
取得元
瞬間的なイベントの場合、これはStartTimeと同じであることがよくあります。期間を伴うアクティビティの場合、完了を示す特定のフィールドから取得する必要があり、カスタム設定が必要になる場合があります。
例
2023-04-15T10:00:00Z2023-04-15T11:55:00Z2023-04-16T14:20:00Z
|
|||
|
エージェント引き継ぎ回数
AgentHandoffCount
|
ケースが別の担当者またはキューに再割り当てされた回数。 | ||
|
説明
このメトリックは、サービスリクエストが解決されるまでに経る再割り当ての回数を定量化します。これは、単一ケースのライフサイクル内で「割り当てられた担当者」属性における個別の変更の数を数えることによって計算されます。 この属性は、「ケースあたりの平均担当者引き継ぎ数KPI」の基礎であり、「担当者引き継ぎと手戻りパターン」ダッシュボードで可視化されます。高い引き継ぎ回数は、多くの場合、プロセスの非効率性、不明確な所有権、または知識のギャップを示し、これらすべてが解決時間の長期化や顧客の不満につながる可能性があります。
その重要性
プロセス内の内部的な摩擦を定量化します。なぜなら、過剰な引き継ぎは遅延や顧客不満の一般的な原因となるからです。
取得元
データ変換中にケースレベルで計算され、各「ServiceRequest」の「AssignedAgent」フィールドの一意の値の数から1を引いた数で算出されます。
例
0135
|
|||
|
エスカレート済み
IsEscalated
|
ケースがエスカレートされたかどうかを示すフラグ。 | ||
|
説明
このブール属性は、サービスリクエストがエスカレーションされたかどうかを示します。Salesforceでは、これはエスカレーションルールに基づいて自動的に設定される標準のIsEscalatedフィールドを介して追跡できます。 このフラグは、「内部エスカレーション分析」ダッシュボードと「内部エスカレーション率KPI」への直接的な入力となります。これにより、すべてのエスカレートされたケースを簡単にフィルタリングおよび集計し、その頻度を定量化し、全体的な解決時間とプロセス複雑性への影響を分析するのに役立ちます。
その重要性
ケースのエスカレーションを直接測定し、プロセスの摩擦、複雑さ、またはエージェントの知識不足を示す重要な指標となります。
取得元
Salesforce ケースオブジェクト、フィールド: IsEscalated
例
truefalse
|
|||
|
ケース件名
CaseSubject
|
顧客の課題やリクエストの簡単な要約またはタイトル。 | ||
|
説明
ケース件名には、サービスリクエストの簡潔なフリーテキスト要約が提供されます。これは多くの場合、メールの件名や担当者または顧客によって入力されたタイトルです。 直接的なプロセス分析のための構造化されたフィールドではありませんが、件名には豊富なコンテキスト情報が含まれています。これは、テキストマイニング技術と組み合わせてケースを分類したり、新たな問題を特定したり、定量的プロセス分析に定性的なコンテキストを追加したりするために使用できます。
その重要性
ケースに関する迅速かつ高レベルのコンテキストを提供し、ドリルダウン分析に役立つだけでなく、テキストマイニングにも活用できます。
取得元
Salesforce ケースオブジェクト、フィールド: Subject
例
ポータルにログインできません請求書に関する質問レポートダッシュボードの機能リクエスト
|
|||
|
手戻り
IsRework
|
ケースが手戻りや前の段階へのループを含んでいたかどうかを示すフラグ。 | ||
|
説明
このブール属性は、クローズ後に再オープンされたり、「担当者調査」と「解決策提案」の間で繰り返しサイクルするような手戻りパターンを示すケースにフラグを立てます。手戻りを特定するロジックは、望ましくないループについてアクティビティのシーケンスを分析する必要があります。 この属性は、「手戻り率KPI」および「担当者引き継ぎと手戻りパターン」ダッシュボードを直接サポートします。手戻りを伴うケースを特定することで、アナリストは不十分な解決策から不完全な情報収集まで多岐にわたる根本原因を調査し、是正措置を講じることが可能になります。
その重要性
プロセスの非効率性や無駄な労力を浮き彫りにし、頻繁に繰り返されるアクティビティを対象とした分析を可能にします。
取得元
データ変換中にアクティビティシーケンスを分析することで計算されます。例えば、同じケース内で「ケースクローズ済み」->「ケース再オープン」や「解決策提案済み」->「エージェントによる問題調査」といったシーケンスは、手戻りとしてフラグ付けされます。
例
truefalse
|
|||
|
関連製品
ProductInvolved
|
顧客の要求が関連する特定の製品またはサービス。 | ||
|
説明
この属性は、サービスリクエストを特定の製品またはサービスにリンクします。Salesforceでは、これは多くの場合、製品オブジェクトへのルックアップを通じて管理されます。 プロセスデータを製品別にセグメント化することは、製品品質分析にとって極めて重要です。これにより、どの製品が最も多くのサポートリクエストを生成しているか、どのような種類の問題を抱えているか、解決プロセスが製品ライン間で異なるかどうかを特定するのに役立ちます。この情報は、製品開発チームにとって不可欠なフィードバックとなります。
その重要性
製品ベースのプロセス分析を可能にし、特定の製品における品質問題やサポートのギャップを明らかにすることができます。
取得元
Salesforce ケースオブジェクト、フィールド: ProductId。これは標準ですがオプションの参照フィールドです。
例
Alpha CRM SuiteBeta Analytics ToolGamma Data Connector
|
|||
|
顧客名
CustomerName
|
サービスリクエストに関連付けられた顧客またはアカウントの名前。 | ||
|
説明
この属性は、サービスリクエストを開始した顧客を特定します。Salesforceでは、これは取引先責任者(個人)または取引先(会社)である可能性があります。 顧客視点からプロセスを分析することで、貴重な洞察が得られます。例えば、特定の顧客がより多くの問題や長い解決時間を経験しているかどうかを特定するのに役立ちます。これは顧客関係管理戦略に情報を提供し、プロアクティブなサポートの機会を強調できます。
その重要性
顧客中心の分析が可能になり、特定の顧客や顧客セグメントにおけるパターンやパフォーマンスの変動を特定するのに役立ちます。
取得元
Salesforce ケースオブジェクト、フィールド: ContactId または AccountId(それぞれ取引先責任者オブジェクトと取引先オブジェクトにリンク)
例
`Global Tech Inc.`Emily White革新的な解決策
|
|||
顧客サービスアクティビティ
| アクティビティ | 説明 | ||
|---|---|---|---|
|
SLAマイルストン違反
|
このイベントは、初回応答や解決時間などのサービスコミットメントが達成されなかったときにトリガーされます。Salesforceは、エンタイトルメントプロセスとマイルストンレコードを使用してこれを追跡します。 | ||
|
その重要性
このアクティビティは、SLA遵守分析とコンプライアンスモニタリングにとって不可欠です。顧客の期待に応えられなかったケースを直接的に浮き彫りにし、ターゲットを絞ったプロセス改善を可能にします。
取得元
CaseMilestoneオブジェクトから取得されます。マイルストンレコードのIsViolatedフィールドがtrueに設定されたときにイベントが生成されます。
取得
イベントは、CaseMilestoneレコードでIsViolatedフラグがtrueになったときのタイムスタンプです。
イベントタイプ
explicit
|
|||
|
エージェントにケース割り当て済み
|
サービスリクエストが特定の担当者またはキューに割り当てられる時点を示します。これはプロセスの基本的なステップであり、ケース所有者フィールドの変更によって捉えられます。 | ||
|
その重要性
このアクティビティは、エージェントのワークロード、割り当て遅延、および引き継ぎ頻度を追跡するために不可欠です。エージェントのパフォーマンスを分析し、割り当てプロセスにおけるボトルネックを特定するための基礎となります。
取得元
CaseオブジェクトのOwnerIdフィールドへの変更から推測されます。この変更のタイムスタンプはCaseHistoryオブジェクトに記録されます。
取得
OwnerIdフィールドへの最初の更新のタイムスタンプを特定します。
イベントタイプ
inferred
|
|||
|
ケース解決
|
この重要なマイルストンは、担当者が顧客の問題を解決するために必要な作業を完了したことを意味します。ケースは現在、最終的なクローズ待ちであり、一定期間後に自動化される場合があります。 | ||
|
その重要性
これは解決時間を測定するための主要なエンドポイントであり、SLA遵守を計算するために不可欠です。ケースに関するアクティブな作業の終了を示します。
取得元
CaseHistoryオブジェクトにおいて、Statusフィールドが「解決済み」に変更されたときに推測されます。この時点ではIsClosedフィールドはまだfalseである可能性があります。
取得
ケースステータスが「解決済み」に変更されたタイムスタンプ。
イベントタイプ
inferred
|
|||
|
内部エスカレーションがトリガーされました
|
このアクティビティは、ケースがより高いレベルのサポートや専門知識を必要とし、正式にエスカレートされるときに発生します。これはSalesforceのエスカレーションルールによって明示的に捕捉されるか、フィールドの変更から推測されます。 | ||
|
その重要性
エスカレーションの分析は、複雑なケースタイプ、現場エージェントのトレーニングニーズ、およびシステム上の問題を特定するのに役立ちます。これは、プロセスの摩擦と解決時間への影響を示す重要な指標です。
取得元
これは、ケースエスカレーションレコードからの明示的なイベントである場合があります。より一般的には、「IsEscalated」のようなチェックボックスフィールドがtrueに設定されたときに、CaseHistoryから推測されます。
取得
「IsEscalated」フィールドがtrueに変更されたタイムスタンプ。
イベントタイプ
inferred
|
|||
|
案件クローズ
|
このアクティビティは、サービスリクエストライフサイクルの最終的かつ決定的な終了を表します。一度ケースがクローズされると、再オープンされない限り、それ以上の作業は想定されません。 | ||
|
その重要性
最終イベントとして、このアクティビティは全体のケース期間を計算するための最終終点を提供します。「解決済み」と「クローズ済み」の間の時間は、クローズプロセスにおける非効率性も明らかにすることができます。
取得元
CaseオブジェクトのIsClosedフィールドがtrueに設定されたときのタイムスタンプから推測されます。このとき、ClosedDateフィールドも入力されます。
取得
IsClosedフィールドがtrueに変更されたタイムスタンプ(CaseHistoryに記録)。
イベントタイプ
inferred
|
|||
|
案件作成
|
このアクティビティは、新しいサービスリクエスト、つまりケースがSalesforceに記録されたときに、カスタマーサービスプロセスの正式な開始を示します。このイベントは、ケースオブジェクトに新しいレコードが作成された際に、正確なタイムスタンプと共に明示的に捕捉されます。 | ||
|
その重要性
主要な開始イベントとして、このアクティビティは全体のケースライフサイクルと解決時間を計算するために不可欠です。SLAに対するパフォーマンスを測定し、ケース量を理解するためのベースラインを提供します。
取得元
このイベントは、ケースオブジェクトのレコード作成イベントに対応します。タイムスタンプは標準のCreatedDateフィールドに捕捉されます。
取得
ケースレコードの作成タイムスタンプから直接。
イベントタイプ
explicit
|
|||
|
エージェントによる問題調査
|
担当者が顧客の問題を診断し、理解するために積極的に作業するフェーズを表します。これは明示的なイベントではなく、ケースステータスが「新規」または「オープン」から「進行中」に変わるときに推測されます。 | ||
|
その重要性
調査フェーズの期間を理解することは、サービスリクエストの複雑さや、担当者により多くのトレーニングやリソースが必要となる領域を特定するのに役立ちます。これは、アクティブな作業時間と待機時間を分離します。
取得元
CaseHistoryオブジェクトにおいて、Statusフィールドが「進行中」や「作業中」など、アクティブな作業を示す値に更新されたときに推測されます。
取得
ケースステータスが「進行中」の値に変更されたタイムスタンプ。
イベントタイプ
inferred
|
|||
|
ケース再割り当て
|
初期割り当て後、ケースが別の担当者またはキューに引き継がれるハンドオフを表します。これは、ケース所有者フィールドへのその後の変更によって推測されます。 | ||
|
その重要性
頻繁な再割り当ては、誤った初期ルーティング、プロセスの非効率性、または知識ギャップを示し、遅延や劣悪な顧客体験につながる可能性があります。このアクティビティは、エージェントの引き継ぎを定量化するのに役立ちます。
取得元
初期割り当て後のCaseHistoryオブジェクト内のOwnerIdフィールドへのすべての変更から推測されます。
取得
最初の更新後のOwnerIdフィールドへのすべての更新を特定します。
イベントタイプ
inferred
|
|||
|
ケース分類および優先順位付け済み
|
このアクティビティは、ケースがタイプ、カテゴリ、優先度レベルで分類されるときに発生します。これは多くの場合、トリアージチームまたは自動化ルールによって行われ、関連するケースフィールドへの変更から推測されます。 | ||
|
その重要性
分類は、ケースの分布とルーティングの有効性を理解するための鍵です。このステップを分析することは、ワークロードの分散を最適化し、高優先度ケースが迅速に処理されることを確実にするのに役立ちます。
取得元
CaseHistoryオブジェクトにおいて、Priority、Type、またはその他の分類フィールドが初めて入力された、またはデフォルト値から変更された時を追跡することによって推測されます。
取得
CaseHistoryで優先度やタイプなどのフィールドへの更新を追跡します。
イベントタイプ
inferred
|
|||
|
初期確認応答送信済み
|
顧客に送信される最初の連絡を表し、サービスリクエストの受領を確認するものです。これは通常、ケース作成ルールによってトリガーされる自動メールであり、最初の送信通信を特定することで推測されます。 | ||
|
その重要性
このアクティビティを追跡することは、初回応答時間を測定し、顧客に迅速に情報が提供されることを保証するために不可欠です。これは「初回応答遅延KPI」を分析し、顧客コミュニケーションを改善するのに役立ちます。
取得元
ケースに関連付けられた最初の送信EmailMessageレコードのタイムスタンプから推測されます。また、自動化ルールによってトリガーされたカスタムフィールドの更新から推測することもできます。
取得
ケースにリンクされた最初の送信EmailMessageのタイムスタンプを特定します。
イベントタイプ
inferred
|
|||
|
案件再開
|
以前に解決またはクローズされたケースが、問題の再発や解決策の無効化により再アクティブ化されるときに発生します。これは手戻りの重要な指標です。 | ||
|
その重要性
再オープンされたケースは、解決策の品質が低い、または初回解決(FCR)に失敗したことを示す強い兆候です。その頻度と根本原因を分析することは、サービス品質の向上に不可欠です。
取得元
CaseHistoryオブジェクトにおいて、IsClosedフィールドがtrueからfalseに変化したとき、またはStatusがクローズ/解決済みの状態からオープン状態に戻ったときに推測されます。
取得
ステータスまたはIsClosedフィールドが最終状態からアクティブ状態に変更されたタイムスタンプ。
イベントタイプ
inferred
|
|||
|
満足度調査送信済み
|
顧客満足度(CSAT)またはネットプロモータースコア(NPS)アンケートの送信を表します。これは通常、ケースの解決またはクローズ後に続く自動化されたアクションです。 | ||
|
その重要性
主要な解決プロセスの一部ではありませんが、このアクティビティはフィードバックループを理解するために重要です。そのタイミングと頻度を分析することで、顧客の声が一貫して捕捉されることを保証します。
取得元
アンケートテンプレートに一致するケースに関連付けられた送信EmailMessageレコードから推測されます。あるいは、SurveyInvitationレコードの作成から取得することもできます。
取得
送信アンケートメールまたはSurveyInvitationレコードの作成を特定します。
イベントタイプ
inferred
|
|||
|
顧客から情報受領
|
このアクティビティは、顧客が要求された情報を提供した際の顧客待機時間の終了を示します。通常、受信通信後にケースステータスがアクティブ状態に戻されたときに推測されます。 | ||
|
その重要性
このイベントを追跡することは、顧客の応答時間とそれがケースライフサイクル全体に与える影響を理解するために不可欠です。これは、担当者によるアクティブな作業の再開を示します。
取得元
ケースに関連付けられた受信EmailMessageのタイムスタンプ、またはCaseHistoryオブジェクトにおける「顧客からの返信待ち」から「処理中」へのステータス変更によって推測されます。
取得
受信メールまたは「待機中」からのステータス変更のタイムスタンプ。
イベントタイプ
inferred
|
|||
|
顧客に情報要求済み
|
このアクティビティは、担当者がケースを進めるために顧客から追加情報を必要とするときに発生します。通常、ケースステータスが「顧客待ち」状態に変わったことから推測されます。 | ||
|
その重要性
このアクティビティは、エージェントの管理下ではない待機時間の開始を示します。この時間を分離することは、内部プロセス効率とエージェントのパフォーマンスを正確に測定するために不可欠です。
取得元
CaseHistoryオブジェクトにおいて、Statusフィールドが「顧客からの返信待ち」や「保留中」のような値に更新されたときに推測されます。
取得
ケースステータスが「待機中」の値に変更されたタイムスタンプ。
イベントタイプ
inferred
|
|||
|
顧客への解決策提示
|
エージェントが顧客に潜在的な解決策を提供した時点を示します。これは、通常、外部へのコミュニケーションまたは特定のステータス変更から推測される概念的なステップです。 | ||
|
その重要性
このマイルストンを追跡することは、調査から解決策提案までの時間を測定するのに役立ちます。解決策が承認されない場合、確認ループの開始となることもあります。
取得元
特定のキーワードを含む送信EmailMessage、またはCaseHistoryオブジェクトにおける「解決策提供済み」へのステータス変更から推測されます。
取得
ステータス変更または送信通信イベントのタイムスタンプ。
イベントタイプ
inferred
|
|||