カスタマーサービスのデータテンプレート
カスタマーサービスのデータテンプレート
- 収集を推奨する属性
- 追跡する主要なアクティビティ
- データ抽出ガイド
カスタマーサービスの属性
| 名前 | 説明 | ||
|---|---|---|---|
|
イベント発生時刻
EventTime
|
特定のアクティビティまたはイベントが発生した日時を示す正確なタイムスタンプです。 | ||
|
説明
イベント発生時刻には、アクティビティが実行された日時が記録されます。このタイムスタンプは、イベントを時系列に並べ、プロセスの各ステップ間の所要時間を算出するための基礎となります。 プロセスマイニングでは、この属性を使ってサイクルタイム、待ち時間、処理時間など、時間に関するすべての指標を算出します。前段階で長い遅延が発生しているアクティビティを見つけてボトルネックを特定し、サービスレベル合意(SLA)に対するパフォーマンスも測定できます。信頼できる分析には、正確で一貫したタイムスタンプが欠かせません。
重要な理由
イベントを正しい順序に並べ、サイクルタイムやボトルネックなどのパフォーマンス指標を算出するうえで重要なタイムスタンプです。
入手先
通常、ServiceNowの監査テーブルや履歴テーブル(例:「sys_audit」)にある「sys_created_on」フィールドに該当します。
例
2023-10-26T10:00:00Z2023-10-26T10:15:32Z2023-10-27T14:05:11Z
|
|||
|
サービスリクエスト
ServiceRequest
|
各顧客サービスリクエスト、ケース、またはチケットを識別する一意のIDです。 | ||
|
説明
サービスリクエストは、1件の顧客の問題に関するすべてのアクティビティとイベントを、作成からクローズまで関連付ける主要なケース識別子です。顧客とのやり取りの全体を追跡するための軸となります。 プロセスマイニングでは、この属性を使ってプロセスフローを再構成します。一意のサービスリクエスト値がプロセスの1つのケースを表すため、ケースごとにサイクルタイム、経路、ばらつきを分析できます。最初の問い合わせから最終的な解決とクローズまでの各ステップを、同じ顧客の問い合わせに正しく関連付けることができます。
重要な理由
すべてのプロセスステップを結び付ける重要なケースIDです。顧客サービスのやり取りごとに、全期間を分析できます。
入手先
通常、ServiceNow CSMの「sn_customerservice_case」テーブルにある「number」フィールドに該当します。
例
CS0010001CS0010045CS0010112
|
|||
|
アクティビティ名
ActivityName
|
サービスリクエストの期間中に発生した特定のイベントまたはタスクの名前です。 | ||
|
説明
アクティビティ名は、「サービスリクエスト作成」「担当者にリクエストを割り当て」「解決策を提示」など、顧客サービスプロセスの各ステップを表します。システムログやテーブルの更新履歴からアクティビティを抽出し、サービスリクエストごとに時系列のイベントを作成します。 この属性は、プロセスマップの可視化、ボトルネックの特定、作業の流れの把握に欠かせません。アクティビティの順序や頻度を分析すると、よくあるプロセス経路、逸脱、手戻りや非効率が生じている箇所を見つけられます。定義するアクティビティの粒度によって、プロセスモデルから得られるインサイトの詳しさが変わります。
重要な理由
プロセスマップの基盤となる属性です。分析対象となる具体的なステップやタスク、その順序と所要時間を定義します。
入手先
システム監査テーブル(例:「sys_audit」)から導出する概念上の属性です。「sn_customerservice_case」テーブルの状態変更や主要フィールドの更新を追跡して定義することもできます。
例
サービスリクエストを作成リクエストを担当者に割り当て顧客への情報依頼サービスリクエストの解決
|
|||
|
SLA違反の有無
IsSlaBreached
|
サービスリクエストが定められたサービスレベル契約(SLA)の目標を超過したかどうかを示す真偽値フラグです。 | ||
|
説明
この計算属性は、サービスリクエストが合意した期間内に解決されたかどうかを示します。通常、解決時間がSLA目標を超えた場合は「True」、それ以外の場合は「False」になります。各ケースのSLAパフォーマンスを明確に判定できます。 この属性は、「SLA遵守状況と違反の傾向」ダッシュボードと「SLA遵守率」KPIに欠かせません。違反したケースを直接絞り込んで集計できるため、どの種類のリクエスト、優先度、チームでSLA違反が多いかを簡単に特定できます。
重要な理由
ケースが期限を守ったかどうかを明確に判定でき、SLAコンプライアンスの測定と報告の基本となります。
入手先
「task_sla」テーブルの「made_sla」フィールドに基づいて計算するか、実際の解決時間と予定された解決時間を比較して算出します。
例
truefalse
|
|||
|
カテゴリ
Category
|
「請求」や「技術的な問題」など、サービスリクエストの主な分類です。 | ||
|
説明
カテゴリは、顧客の問い合わせや問題の内容に基づいてサービスリクエストを大まかに分類します。通常、リクエストの作成時に分類し、適切な割り当てグループへの振り分けに役立てます。 この属性は、プロセス分析を分類するうえで欠かせません。カテゴリで絞り込むと、リクエストの種類ごとにプロセスフローを比較できます。たとえば、「請求」の問題と「技術的な問題」では、解決までのプロセスが大きく異なる場合があります。ほぼすべてのダッシュボードでデータを分類するために使う重要な属性です。
重要な理由
リクエストの種類ごとに分析を分類し、遅延、エスカレーション、SLA未達が起きやすいカテゴリを特定できます。
入手先
「sn_customerservice_case」テーブルの「category」フィールドに該当します。
例
問い合わせ/サポート注文製品に関する問題請求
|
|||
|
優先度
Priority
|
サービスリクエストの優先度です。対応の緊急性に影響します。 | ||
|
説明
優先度は、サービスリクエストの重要性と必要な対応の緊急性を示します。通常、顧客への影響度と緊急度を組み合わせて決定します。一般的な値は「重大」から「低」までです。 プロセスマイニングでは、優先度を使ってデータを絞り込み、比較できます。優先度の高いリクエストが低いものより実際に速く処理されているか、特定の優先度でSLA未達が多いかを分析できます。「サービスリクエストのエンドツーエンドのサイクルタイム」ダッシュボードで使う基本的な属性です。
重要な理由
緊急度別にサービスリクエストを分類できます。重大な問題がそれ以外の問題より速く処理されているかを確認するうえで欠かせません。
入手先
「sn_customerservice_case」テーブルの「priority」フィールドに該当します。
例
1 - 重大2 - 高3 - 中4 - 低
|
|||
|
割り当てグループ
AssignmentGroup
|
サービスリクエストを担当するチームまたは部門です。 | ||
|
説明
割り当てグループは、サービスリクエストが割り当てられるキューまたはチームを表します。問題の内容に応じて、第1階層のサポート窓口、専門技術チーム、請求部門など、異なるグループにリクエストが振り分けられます。 この属性は、部門間の引き継ぎを分析し、チーム単位のボトルネックを特定するうえで欠かせません。機能ごとの業務領域間で作業がどのように進むかを可視化し、業務が集中しているグループや追加のトレーニングが必要なグループを把握できます。「担当者間の引き継ぎと再割り当て」および「プロセスフロー」ダッシュボードを支える属性です。
重要な理由
作業を担当するチームを特定できます。チームのパフォーマンスや業務量、部門間の引き継ぎを分析するうえで重要です。
入手先
「sn_customerservice_case」テーブルの「assignment_group」フィールドに該当します。
例
サービスデスク請求に関する問い合わせ第2階層のテクニカルサポート
|
|||
|
割り当て担当者
AssignedAgent
|
サービスリクエストを現在担当しているサービス担当者です。 | ||
|
説明
この属性は、各時点でサービスリクエストを担当するユーザーを示します。ケースの進行中に、別の担当者や専門担当者へ引き継がれると、値が変わることがあります。 割り当て担当者を分析すると、業務量の配分、担当者のパフォーマンス、引き継ぎ状況を把握できます。最も複雑なケースを担当するのは誰か、ケースの再割り当てはどの程度発生しているか、特定の担当者で解決時間が長くなったり顧客満足度が高くなったりしているか、といった疑問に答えるのに役立ちます。「担当者間の引き継ぎと再割り当て」ダッシュボードで使う重要な属性です。
重要な理由
担当者の責任範囲を追跡し、業務量、パフォーマンス、再割り当ての頻度を分析できます。再割り当ての多さは、プロセスの停滞を示すことがあります。
入手先
「sn_customerservice_case」テーブルの「assigned_to」フィールドに該当します。
例
Beth AnglinDavid LooAbel Tuter
|
|||
|
状態
State
|
サービスリクエストの進行中における現在のステータスまたは状態です。 | ||
|
説明
状態属性は、「新規」「対応中」「情報待ち」「解決済み」「クローズ」など、各時点でのサービスリクエストの進行状況を示します。このフィールドの変更は、プロセスモデルのアクティビティを定義する際によく使われます。 状態を分析すると、ケースがプロセスのどの段階にあるかを大まかに把握できます。「情報待ち」などの状態にとどまる時間を特定でき、遅延の大きな原因を見つけるのに役立ちます。また、「解決からクローズまでの時間」など、主要なKPIの開始点と終了点の定義にも使われます。
重要な理由
各時点でのリクエストの状態を示します。「保留中」や「情報待ち」など、作業が進まない状態に費やした時間の特定に役立ちます。
入手先
「sn_customerservice_case」テーブルの「state」フィールドに該当します。
例
新規対応中ユーザー情報待ち解決済みクローズ
|
|||
|
ソースシステム
SourceSystem
|
データの抽出元となるシステムです。 | ||
|
説明
この属性はデータの取得元を示します。複数のシステムから情報を集約する環境では特に重要です。このプロセスビューでは、値は常に「ServiceNow CSM」です。 分析では、データガバナンスや問題の調査に役立ちます。複数のソースシステムがある場合、特定のシステム内でのプロセスの動作を確認したり、システム間のプロセスの違いを比較したりできます。
重要な理由
データの取得元を明確にし、複数システムの環境での理解を助けるとともに、データガバナンスにも役立ちます。
入手先
データ変換時に追加する固定値で、データセットの取得元を示します。
例
ServiceNow CSM
|
|||
|
チャネル
Channel
|
サービスリクエストの受付に使われたコミュニケーションチャネルです。 | ||
|
説明
チャネルは、顧客がリクエストを送信した方法を示します。たとえば、「メール」「電話」「Webポータル」「チャット」などです。チャネルによって、プロセスの特徴や顧客の期待は大きく異なる場合があります。 チャネル別にプロセスを分析すると、それぞれの連絡方法の有効性を評価できます。たとえば、「電話」で受け付けたリクエストの初回解決率が高いか、「メール」のリクエストはサイクルタイムが長くなる傾向があるかを確認できます。「コミュニケーションチャネルの有効性」ダッシュボードを支える分析です。
重要な理由
電話、メール、Webポータルなど、顧客とのやり取りに使うチャネルごとの効率や結果を把握できます。
入手先
通常、「sn_customerservice_case」テーブルの「contact_type」フィールドに該当します。
例
電話メールセルフサービスチャット
|
|||
|
再オープン回数
ReopenCount
|
解決済みのサービスリクエストが顧客によって再オープンされた回数です。 | ||
|
説明
ケースの状態が「解決済み」または「クローズ」から「対応中」または「オープン」に戻った回数を記録するカウンターです。ケースが再オープンされた場合、最初の解決策が有効でなかった、または不十分だった可能性があります。 この属性は、手戻りや初回解決の品質を示す重要な指標です。再オープン回数が多い場合、担当者がチケットを早まってクローズした、または顧客の根本的な問題に十分対応できていないなど、解決プロセスに課題があると考えられます。提示した解決策の有効性を把握するための重要な指標です。
重要な理由
解決の失敗と手戻りを示します。再オープンが多い場合、解決プロセスの品質に問題があり、顧客の不満につながっている可能性があります。
入手先
これは多くの場合、「sn_customerservice_case」テーブルまたは関連テーブルの「reopen_count」というフィールドで記録されます。
例
012
|
|||
|
再割り当て回数
ReassignmentCount
|
サービスリクエストが別の担当者またはグループに再割り当てされた回数の合計です。 | ||
|
説明
「assigned_to」または「assignment_group」フィールドが変更されるたびに増えるカウンターです。ケースが社内で引き継がれた回数を簡潔に示します。 再割り当て回数は、プロセスの停滞を直接示す指標です。「担当者間の引き継ぎと再割り当て」ダッシュボードや「リクエストあたりの担当者間の平均引き継ぎ回数」KPIの主要なデータとなります。再割り当てが多い場合、最初の振り分けの問題、担当者のスキル不足、ケースの分類の難しさなどが考えられ、いずれも解決時間の長期化につながります。
重要な理由
引き継ぎ回数を数えて、プロセスの非効率を直接測定します。回数が多いケースでは、解決時間が長くなり、顧客満足度が低下する傾向があります。
入手先
「sn_customerservice_case」テーブルが拡張する「task」テーブルにある標準の指標フィールド「reassignment_count」です。
例
0135
|
|||
|
最終データ更新日時
LastDataUpdate
|
ソースシステムからデータを最後に抽出または更新した日時を示すタイムスタンプです。 | ||
|
説明
この属性には、直近のデータ取得日時が記録されます。分析対象のデータがどの程度新しいかを把握でき、ほぼリアルタイムの情報か、過去のある時点のデータかを確認できます。 分析時には、データセットの対象期間を理解するための重要なメタデータです。たとえば、データが1時間前または前日時点のものであることを把握したうえで、ダッシュボードやKPIを正しく読み取るのに役立ちます。
重要な理由
データの新しさを示します。プロセスマイニングのインサイトが現在の状況に即したものかを判断するうえで重要です。
入手先
データの抽出、変換、読み込み(ETL)処理時に生成され、追加されるタイムスタンプです。
例
2023-11-20T08:00:00Z
|
|||
|
初回対応で解決したか
IsFirstContactResolution
|
担当者の変更やエスカレーションを伴わず、最初に割り当てられた担当者がリクエストを解決したかどうかを示す真偽値フラグです。 | ||
|
説明
この計算属性は、最初のやり取りで、または最初にケースを担当したエージェントが効率よく解決したサービスリクエストを特定します。通常、再割り当てがない(「ReassignmentCount」が0)、 「内部エスカレーション発生」のアクティビティがない、顧客に追加情報を求めていない、といった条件を確認します。 この属性は、カスタマーサービスの重要な指標を直接測定し、「初回対応解決率」ダッシュボードとKPIを支えます。FCRの実績を簡単に定量化できるほか、チャネルやリクエストのカテゴリなど、初回対応での解決を促進または妨げる要因の分析にも役立ちます。
重要な理由
初回対応の効率を直接測定します。FCRが高いことは、業務効率と顧客満足度の高さの両方に強く結びついています。
入手先
これは計算属性です。「ReassignmentCount」が0であることや、エスカレーションのアクティビティが発生していないことなどのルールに基づき、データ変換時に算出します。
例
truefalse
|
|||
|
手戻りの有無
IsRework
|
ケースの再オープンや調査の繰り返しなど、大幅な手戻りが発生したかどうかを示す真偽値フラグです。 | ||
|
説明
この計算属性は、非効率や繰り返しのパターンが見られるケースにフラグを付けます。「サービスリクエスト再オープン」などのイベントや、「担当者が調査を開始」に続いて「解決策を提示」といった主要なアクティビティの流れが同じケース内で複数回発生した場合に、フラグが立つ仕組みです。 問題のあるケースをすばやく特定し、プロセス全体の手戻りの程度を定量化するうえで役立ちます。「手戻りと繰り返しの発生箇所」ダッシュボードと「手戻り率」KPIを支え、繰り返しのパターンを手作業で見つけることなく、非効率の要因に注目できます。
重要な理由
繰り返しのループや再オープンがあるケースにフラグを付け、プロセスの非効率や手戻りを定量化し、改善対象を特定しやすくします。
入手先
これは計算属性です。データ変換時に、ゼロ以外の「ReopenCount」やアクティビティの繰り返しなど、手戻りのパターンを検出するビジネスロジックを適用して算出します。
例
truefalse
|
|||
|
解決コード
ResolutionCode
|
最終的な結果や、サービスリクエストの解決方法を示すコードです。 | ||
|
説明
解決コードは、ケースの解決時に担当者が選択する構造化された値です。「ユーザーが解決」「既知のエラー」「重複」「対応不要」など、解決方法の詳細を示します。 この属性は、根本原因の分析に役立ちます。解決コードごとの頻度を分析すると、繰り返し発生する問題、知識不足、製品の問題を特定できます。この情報を改善に役立てることで、特定の種類のサービスリクエストを減らせます。
重要な理由
サービスリクエストの結果を把握できます。根本原因の分析や、繰り返し発生する問題の特定に欠かせません。
入手先
「sn_customerservice_case」テーブルの「close_code」フィールド、またはカスタムの解決コードフィールドに該当します。
例
解決(回避策)解決(恒久対応)未解決(顧客から応答なし)依頼者によりクローズ/解決
|
|||
|
顧客
Customer
|
サービスリクエストを開始した顧客または企業の名前や識別子です。 | ||
|
説明
この属性は、サービスリクエストの対象となる個人または組織など、社外の関係者を特定します。各ケースの顧客に関する情報を示します。 顧客属性を使うと、顧客を軸にサービスプロセスを分析できます。特定の顧客で問題や遅延が多く発生していないかを確認したり、顧客セグメントや顧客価値などのデータと組み合わせて、プロセス改善の優先順位を決めたりできます。たとえば、価値の高い顧客がより速くサービスを受けているかを確認できます。
重要な理由
プロセスを特定の顧客に関連付け、主要顧客や顧客セグメントごとのサービスレベルと問題の発生頻度を分析できます。
入手先
「sn_customerservice_case」テーブルの「caller_id」「opened_for」「account」フィールドなどが該当します。これらのフィールドは、ユーザーテーブルまたは企業テーブルを参照します。
例
John SmithACME CorporationGlobal Tech Inc.
|
|||
カスタマーサービスのアクティビティ
| アクティビティ | 説明 | ||
|---|---|---|---|
|
サービスリクエストのクローズ
|
サービスリクエストのレコードを正式に終了する最後のアクティビティです。解決後の確認期間を経てクローズされる場合もあります。ケースの状態が「クローズ」に変わり、closed_atタイムスタンプが設定された時点で捕捉されます。 | ||
|
重要な理由
プロセスの確定的な終了点となるこのアクティビティは、ケースの全期間を算出するうえで欠かせません。「解決済み」から「クローズ」までの時間を分析すると、事務処理の負担や遅延を把握できます。
入手先
sn_customerservice_caseテーブルの監査履歴で、stateフィールドが「クローズ」に設定されたことから判断します。closed_atフィールドも同時に記録されます。
記録
「state」が「クローズ」に変わったことを検出し、対応するタイムスタンプを使用します。
イベントタイプ
inferred
|
|||
|
サービスリクエストの解決
|
サービス担当者の作業が完了し、問題が解決したと見なされたことを示す重要な節目です。ケースの状態が「解決済み」に変わり、resolved_atタイムスタンプが記録された時点で捕捉されます。 | ||
|
重要な理由
このアクティビティは、解決に向けた実作業の終了を示します。解決までのサイクルタイムやSLAの遵守状況を算出するうえで欠かせません。多くの効率性に関するKPIで、主要な終了点として使われます。
入手先
sn_customerservice_caseテーブルの監査履歴で、stateフィールドが「解決済み」に設定されたことから判断します。通常、resolved_atフィールドも同時に記録されます。
記録
「state」が「解決済み」に変わったことを検出し、対応するタイムスタンプを使用します。
イベントタイプ
inferred
|
|||
|
サービスリクエストを作成
|
このアクティビティは、システムに新しいケースが正式に記録された時点を示し、カスタマーサービスプロセスの開始点となります。sn_customerservice_caseテーブルに新しいレコードが挿入されたことを明示的に記録します。 | ||
|
重要な理由
すべてのケースの開始点となるこのアクティビティは、開始から完了までのサイクルタイムの計算や、リクエストの受付件数の分析に欠かせません。後続のすべてのプロセスとSLAタイマーの起点になります。
入手先
このイベントは、sn_customerservice_caseテーブルにレコードが作成されたことを示します。タイムスタンプにはsys_created_onフィールドの値を使用します。
記録
sn_customerservice_caseテーブルのレコード作成タイムスタンプ(sys_created_on)。
イベントタイプ
explicit
|
|||
|
リクエストを担当者に割り当て
|
サービスリクエストが調査と解決を担当する特定の担当者に割り当てられたときに発生するアクティビティです。ケースレコードのassigned_toフィールドの変更から推定します。 | ||
|
重要な理由
初回応答時間や担当者ごとの業務量を測定するうえで重要な節目です。このフィールドの再割り当てを追跡すると、プロセスの非効率や担当者の対応可能状況に関するボトルネックを特定できます。
入手先
sn_customerservice_caseテーブルの監査履歴(sys_audit)から推定します。assigned_toフィールドへの値の入力や変更を追跡します。
記録
ケースの監査ログでassigned_toフィールドの値の変更を検出。
イベントタイプ
inferred
|
|||
|
社内エスカレーションの発生
|
サービスリクエストの解決に向けて、より上位のサポート担当者や管理者に正式に引き継がれたことを示します。担当グループが上位のチームに変更された場合や、フラグが設定された場合に判断できます。 | ||
|
重要な理由
エスカレーションを追跡すると、プロセス上の課題、一次対応チームの知識不足、複雑なケースの種類を特定できます。プロセスの停滞や顧客満足度の低下を示す重要な指標です。
入手先
監査ログで「assignment_group」が既知のエスカレーションチームに変更されたこと、またはケースレコードの「escalation」フィールドが変更されたことを検出して判断できます。
記録
「escalation」フィールドの変更、または上位の「assignment_group」への移動を検出します。
イベントタイプ
inferred
|
|||
|
SLA未達
|
解決までの時間など、定められたサービスレベル合意(SLA)をサービスリクエストが満たせなかった時点を示します。解決時間とSLAの予定終了時刻を比較して算出するイベントです。 | ||
|
重要な理由
SLA未達の特定は、コンプライアンスの監視とパフォーマンス管理の基本です。このイベントから、どのプロセス段階やケースの種類がSLA違反に最も影響しているかを把握できます。
入手先
ケースに関連するtask_slaテーブルのレコードを分析して算出します。has_breachedフィールドがtrueの場合、またはactual_elapsed_timeがplanned_durationを超えた場合に未達と判定します。
記録
関連するtask_slaレコードの「has_breached」フラグを確認します。
イベントタイプ
calculated
|
|||
|
サービスリクエストの再オープン
|
解決済みのサービスリクエストで問題が再発した場合や、解決策が有効でなかった場合に、ケースが作業中の状態に戻ることで発生します。「解決済み」から「対応中」への状態変更を検出して判断します。 | ||
|
重要な理由
再オープンされたケースは、解決の品質を直接示し、手戻りの主な原因となります。初回問い合わせでの解決率と顧客満足度を高めるには、これらのイベントの分析が欠かせません。
入手先
sn_customerservice_caseテーブルの監査履歴で、stateフィールドが「解決済み」から作業中の状態に変わる一連の記録を特定して判断します。
記録
「state」が「解決済み」から「対応中」などの作業中の値に変わったことを検出します。
イベントタイプ
inferred
|
|||
|
リクエストを分類して優先度を設定
|
サービスリクエストを分類し、緊急度と振り分け先を決めるために優先度を設定する初期トリアージを示します。ケースレコードの監査ログで、カテゴリ、サブカテゴリ、優先度の各フィールドに変更があったことから推定します。 | ||
|
重要な理由
このアクティビティを分析すると、ケースのトリアージにおける遅延を特定し、リクエストが適切に振り分けられ、緊急度に応じて処理されているかを確認できます。最初の担当者が割り当てられるまでの時間や、解決までの業務効率にも影響します。
入手先
sn_customerservice_caseテーブルの監査履歴(sys_audit)から推定します。特に、categoryフィールドとpriorityフィールドの初回入力や更新を追跡します。
記録
categoryフィールドまたはpriorityフィールドの初回設定、もしくは値の変更を検出。
イベントタイプ
inferred
|
|||
|
割り当てグループを変更
|
ケースの担当があるチームから別のチームへ移ったことを示します。ケースレコードのassignment_groupフィールドの変更を監視して、このイベントを推定します。 | ||
|
重要な理由
割り当てグループの変更を追跡することは、部門間の引き継ぎを分析し、振り分けに関する組織的な問題を特定するうえで重要です。このアクティビティの頻度が高い場合、担当範囲やプロセスの定義が不明確な可能性があります。
入手先
sn_customerservice_caseテーブルの監査履歴(sys_audit)から推定します。assignment_groupフィールドの変更を追跡します。
記録
ケースの監査ログでassignment_groupフィールドの値の変更を検出。
イベントタイプ
inferred
|
|||
|
担当者が調査を開始
|
担当者がサービスリクエストへの対応を実際に開始したことを示すアクティビティです。通常、ケースの状態が「新規」や「割り当て済み」から「対応中」などに変わった時点で、このアクティビティが発生したと判断します。 | ||
|
重要な理由
このイベントにより、待ち時間と実作業時間を区別できます。割り当てから調査開始までの時間を分析すると、新しいケースへの着手が遅れている状況を把握できます。
入手先
ケースの状態フィールドが「対応中」などの作業中の値に変わったことから判断します。具体的な状態値は設定によって異なるため、確認が必要です。
記録
「state」フィールドが保留中の値から作業中の値に変わったことを検出します(例:「新規」から「対応中」)。
イベントタイプ
inferred
|
|||
|
解決策を提示
|
担当者が解決策を特定し、顧客に確認を依頼した時点を示すアクティビティです。「承認待ち」などへの状態変更や、特定の作業メモの記録から判断できます。 | ||
|
重要な理由
この節目を境に、調査段階から顧客の確認と解決の段階に移ります。顧客の確認を待つ時間を分析すると、ケースの終盤を効率化できる余地が見つかります。
入手先
sn_customerservice_caseテーブルの監査ログで、stateが解決策の提示を示す値(例:「解決策を提示」)に変わったことから判断します。実装によって異なる場合があります。
記録
「state」フィールドが「解決策を提示」や「承認待ち」などの値に変わったことを検出します。
イベントタイプ
inferred
|
|||
|
顧客アンケートを送信
|
ケースの解決後に顧客満足度アンケートを送信したことを示します。通常、アンケートのインスタンスレコードが作成され、ケースに関連付けられた時点で捕捉されます。 | ||
|
重要な理由
このアクティビティを使うと、プロセスの実行状況と顧客からのフィードバックを関連付けて分析できます。フィードバックの仕組みが有効に機能しているかを調べるには、アンケートがいつ送信されたか、また送信されたかどうかを把握することが重要です。
入手先
asmt_assessment_instanceなどのアンケート専用テーブルに記録される明示的なイベントです。このテーブルには、元のケースレコードへの参照が含まれます。
記録
ケースに関連付けられた「asmt_assessment_instance」テーブルのレコード作成。
イベントタイプ
explicit
|
|||
|
顧客から情報を受領
|
顧客から依頼した情報が届き、担当者が対応を再開できる時点を示すアクティビティです。ケースの状態が「ユーザー情報待ち」から作業中の状態に戻った時点で発生したと判断します。 | ||
|
重要な理由
このイベントにより、顧客の回答を待つ期間が終了します。顧客の応答時間を正確に測定でき、遅延が長いケースの種類や顧客を特定するのに役立ちます。
入手先
sn_customerservice_caseテーブルの監査履歴で、stateフィールドが「情報待ち」から「対応中」などの作業中の状態に変わったことから判断します。
記録
「state」フィールドが「顧客待ち」の値から作業中の値に戻ったことを検出します。
イベントタイプ
inferred
|
|||
|
顧客への情報依頼
|
対応を進めるために担当者が顧客から追加情報を得る必要があり、ケースを保留状態にしたときに発生します。「ユーザー情報待ち」や「保留中」などへの状態変更から判断します。 | ||
|
重要な理由
このアクティビティは、「顧客情報の待ち時間」の分析に欠かせません。社外の相手からの情報待ちによる遅延を切り分け、社内の処理時間と区別できます。
入手先
sn_customerservice_caseテーブルの監査履歴で、stateフィールドが顧客からの入力待ちを示す値(例:「情報待ち」)に変わったことから判断します。
記録
「state」フィールドが、指定した「顧客待ち」の値に変わったことを検出します。
イベントタイプ
inferred
|
|||
データ抽出ガイド
準備はできましたか?
このテンプレートを使ってデータを適切に準備し、カスタマーサービス業務の改善につながるインサイトを見つけましょう。より効率的で顧客を重視したプロセスへの取り組みを、今日から始められます。
カスタマーサービスの効率を今すぐ高めましょう
顧客満足度を高め、初回対応解決率80%を目指しましょう。
クレジットカードは不要です。数分で利用を開始できます。