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

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

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

このデータテンプレートは、顧客サービスプロセスを分析するために必要な情報を収集する際の指針となります。重要なデータ属性を整理し、追跡すべき主要なアクティビティを定義するとともに、ソースシステムから情報を抽出する方法を示します。このリソースを使ってデータを正確かつ効率的に準備し、プロセスマイニングに備えてください。
  • 収集を推奨する属性
  • 追跡すべき主要なアクティビティ
  • 抽出に関するガイダンス
イベントログを初めて扱いますか。学ぶ プロセスマイニングのイベントログを作成する方法.

カスタマーサービスの属性

カスタマーサービスを詳細に分析するために、イベントログへ含める推奨データ項目です。
3 必須 6 推奨 9 任意
名前 説明
イベント時刻
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」フィールドに対応します。

サービスデスク請求に関する問い合わせTier 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.
必須 推奨 任意

カスタマーサービスのアクティビティ

正確なプロセス発見のために、イベントログへ記録すべき主要なプロセス手順とマイルストーンです。
5 推奨 9 任意
アクティビティ 説明
エージェントへのリクエスト割り当て
サービスリクエストが調査と解決を担当する特定のエージェントに割り当てられた際に発生するアクティビティです。ケースレコードのassigned_toフィールドの変更から推定します。
重要な理由

これは、初回応答時間とエージェントの業務負荷の分布を測定する重要なマイルストーンです。このフィールドの再割り当てを追跡すると、プロセスの非効率やエージェントの対応可能状況に関するボトルネックを明らかにできます。

入手先

sn_customerservice_caseテーブルの監査履歴(sys_audit)から、assigned_toフィールドに値が入力された時点または変更された時点を追跡して推定します。

取得

ケースの監査ログで「assigned_to」フィールドの値の変更を検出します。

イベントタイプ inferred
サービスリクエストをクローズ
サービスリクエストのレコードを正式にクローズする最終アクティビティです。通常は、解決後の確認期間を経て実施します。ケースのstateが「Closed」に変わり、closed_atタイムスタンプが設定された時点で記録されます。
重要な理由

プロセスの確定的な終点となるこのアクティビティは、ケースのライフサイクル全体を計算するうえで欠かせません。「Resolved」から「Closed」までの時間を分析すると、管理上の負荷や遅延を明らかにできます。

入手先

sn_customerservice_caseテーブルのstateフィールドが「Closed」に設定されたことを監査履歴から推定します。closed_atフィールドも同時に入力されます。

取得

「state」が「Closed」に変わったことを検出し、対応するタイムスタンプを使用します。

イベントタイプ inferred
サービスリクエストを解決
サービスエージェントが作業を完了し、問題が解決したとみなされたことを示す重要なマイルストーンです。ケースのstateが「Resolved」に変更され、resolved_atタイムスタンプが入力された時点で記録されます。
重要な理由

このアクティビティは、解決に向けた実作業の終了を示し、解決サイクルタイムとSLA遵守状況の計算に欠かせません。多くの効率性KPIにおける主要な終点となります。

入手先

sn_customerservice_caseテーブルのstateフィールドが「Resolved」に設定されたことを監査履歴から推定します。通常、resolved_atフィールドも同時に入力されます。

取得

「state」が「Resolved」に変わったことを検出し、対応するタイムスタンプを使用します。

イベントタイプ inferred
サービスリクエスト作成
このアクティビティは、新しいケースがシステムに正式に記録された時点で、カスタマーサービスプロセスの開始を示します。sn_customerservice_caseテーブルに新しいレコードが挿入された際に、このイベントが明示的に記録されます。
重要な理由

すべてのケースの起点となるこのアクティビティは、エンドツーエンドのサイクルタイムの計算と、リクエスト受付量の分析に欠かせません。後続するすべてのプロセスとSLAタイマーを開始するトリガーとして機能します。

入手先

このイベントは、sn_customerservice_caseテーブルにレコードが作成されたことに対応します。タイムスタンプにはsys_created_onフィールドの値を使用します。

取得

sn_customerservice_caseテーブルのレコード作成タイムスタンプ(sys_created_on)。

イベントタイプ explicit
社内エスカレーションを開始
サービスリクエストを解決するため、上位のサポートレベルまたは管理者へ正式にエスカレーションしたことを表します。担当グループが上位レベルのチームに変わったこと、またはフラグが設定されたことから推定できます。
重要な理由

エスカレーションを追跡すると、プロセスの弱点、一次サポートの知識不足、複雑なケース種別を特定できます。プロセス上の摩擦や顧客不満を示す重要な指標です。

入手先

監査ログでassignment_groupが既知のエスカレーションチームに変更されたこと、またはケースレコードのescalationフィールドが変更されたことを検出して推定できます。

取得

「escalation」フィールドの変更、または上位レベルの「assignment_group」への移動を検出します。

イベントタイプ inferred
SLA違反
解決までの時間など、サービスリクエストが定められたサービスレベル合意を満たせなかった時点を表します。解決時間とSLAの予定終了時刻を比較して算出するイベントです。
重要な理由

SLA違反の特定は、コンプライアンスのモニタリングとパフォーマンス管理の基本です。このイベントにより、どのプロセス段階やケース種別がSLA違反に最も影響しているかを特定できます。

入手先

ケースに関連するtask_slaテーブルのレコードを分析して算出します。has_breachedフィールドがtrueである場合、またはactual_elapsed_timeがplanned_durationを超えた場合に違反と判定します。

取得

関連するtask_slaレコードの「has_breached」フラグを確認します。

イベントタイプ calculated
エージェントが調査を開始
エージェントがサービスリクエストへの対応を実際に開始したことを示すアクティビティです。通常は、ケースの状態が「New」や「Assigned」などから「Work in Progress」に変わった時点から推定します。
重要な理由

このイベントにより、待機時間と実作業時間を区別できます。割り当てから調査開始までの時間を分析すると、エージェントが新しいケースへの対応を始めるまでの遅延を明らかにできます。

入手先

ケースのstateフィールドが「Work in Progress」などの作業中の状態に変わったことから推定します。具体的な状態値は設定可能なため、確認が必要です。

取得

「state」フィールドが保留中の値から作業中の値に変わったことを検出します(例:「New」から「Work in Progress」)。

イベントタイプ inferred
サービスリクエストを再オープン
以前に解決したサービスリクエストが、問題の再発や解決策の不備によって作業中の状態に戻った際に発生します。「Resolved」から「Work in Progress」への状態変更を検出して推定します。
重要な理由

再オープンされたケースは、解決品質を直接示す指標であり、やり直しの主な原因です。これらのイベントを分析することは、初回接触での解決率と顧客満足度の向上に欠かせません。

入手先

sn_customerservice_caseテーブルの監査履歴で、stateフィールドが「Resolved」から作業中の状態に移る一連の流れを特定して推定します。

取得

「state」が「Resolved」から「Work in Progress」などの作業中の値に変わったことを検出します。

イベントタイプ inferred
リクエストの分類と優先順位付け
サービスリクエストを分類し、緊急度と振り分け先を決めるために優先度を設定する初期トリアージを表します。ケースレコードの監査ログにおけるカテゴリ、サブカテゴリ、または優先度フィールドの変更から推定します。
重要な理由

このアクティビティを分析すると、ケースのトリアージにおける遅延を特定し、リクエストが正しく振り分けられ、緊急度に応じて処理されていることを確認できます。初回割り当てまでの時間と、解決までの全体的な効率に影響します。

入手先

sn_customerservice_caseテーブルの監査履歴(sys_audit)から推定します。具体的には、categoryフィールドとpriorityフィールドへの初回入力または更新を追跡します。

取得

「category」または「priority」フィールドで、最初の値の設定または値の変更を検出します。

イベントタイプ inferred
担当グループの変更
ケースの担当があるチームから別のチームへ移管されたことを示します。ケースレコード内のassignment_groupフィールドの変更を監視して推定します。
重要な理由

担当グループの変更を追跡することは、部門間の引き継ぎを分析し、体系的な振り分けの問題を特定するうえで重要です。このアクティビティの頻度が高い場合、担当範囲やプロセス定義が不明確である可能性があります。

入手先

sn_customerservice_caseテーブルの監査履歴(sys_audit)から、assignment_groupフィールドが変更された時点を追跡して推定します。

取得

ケースの監査ログで「assignment_group」フィールドの値の変更を検出します。

イベントタイプ inferred
解決策を提案
エージェントが解決策を特定し、顧客に伝えて確認を求めた時点を示します。通常は、「Awaiting Acceptance」などへの状態変更、または特定の作業メモの入力から推定します。
重要な理由

このマイルストーンにより、調査段階と確認・解決段階を区別できます。顧客の確認を待つ時間を分析すると、ケースの終盤を効率化できる箇所が明らかになります。

入手先

sn_customerservice_caseテーブルの監査ログで、stateが解決策の提案を示す値(例:「Proposed Solution」)に変わった時点から推定します。実装によって異なる場合があります。

取得

「state」フィールドが「Proposed Solution」や「Awaiting Acceptance」などの値に変わったことを検出します。

イベントタイプ inferred
顧客アンケートを送信
ケースの解決後に顧客満足度アンケートを送信したことを表します。通常は、ケースに関連付けられたアンケートインスタンスのレコードが作成された時点で記録します。
重要な理由

このアクティビティにより、プロセスの実行パターンと顧客からのフィードバックを関連付けられます。アンケートがいつ、または実際に送信されたかを把握することは、フィードバックループの有効性を分析するうえで重要です。

入手先

asmt_assessment_instanceなどのアンケート専用テーブルに記録される明示的なイベントです。このテーブルには、元のケースレコードへの参照が含まれます。

取得

ケースに関連付けられた「asmt_assessment_instance」テーブルでのレコード作成。

イベントタイプ explicit
顧客から情報を受領
顧客が依頼された情報を提供し、エージェントが作業を再開できる状態になった時点を示します。ケースの状態が「Awaiting User Info」から作業中の状態に戻った時点から推定します。
重要な理由

このイベントにより顧客の待機期間が終了し、顧客の回答時間を正確に測定できます。どのケース種別や顧客で遅延が長くなりやすいかを特定するのにも役立ちます。

入手先

sn_customerservice_caseテーブルの監査履歴で、stateフィールドが「Awaiting Info」から「Work in Progress」などの作業中の状態に戻った時点から推定します。

取得

「state」フィールドが「顧客待ち」の値から作業中の値に戻ったことを検出します。

イベントタイプ inferred
顧客への情報依頼
エージェントが対応を進めるために顧客から追加情報を求め、ケースを保留状態にした際に発生します。「Awaiting User Info」や「On Hold」などへの状態変更から推定します。
重要な理由

このアクティビティは、「顧客情報の待機時間」分析に欠かせません。外部依存によるプロセス遅延を切り分け、社内処理時間と区別できます。

入手先

sn_customerservice_caseテーブルの監査履歴で、stateフィールドが顧客からの入力待ちを示す値(例:「Awaiting Info」)に変わった時点から推定します。

取得

「state」フィールドが指定された「顧客待ち」の値に変わったことを検出します。

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

抽出ガイド

ServiceNow CSMからデータを取得する方法

始める準備はできていますか?

このテンプレートを使ってデータを効率的に準備すると、重要な発見につながる情報を見つけ出し、カスタマーサービス業務を改善できます。より効率的で顧客中心のプロセスに向けた取り組みを、今すぐ始めてみませんか。

今すぐカスタマーサービスの効率を最大化

顧客満足度を高め、初回対応での解決率80%を達成します。

無料トライアルを開始

クレジットカードは不要です。数分で始められます。