カスタマーサービスデータテンプレート
カスタマーサービスデータテンプレート
- 収集を推奨する項目
- 追跡すべき主要アクティビティ
- 抽出の手引き
カスタマーサービス属性
| 名前 | 説明 | ||
|---|---|---|---|
|
イベント日時
EventTime
|
特定のアクティビティまたはイベントが発生した正確なタイムスタンプです。 | ||
|
説明
イベントタイムは、アクティビティが実行された日付と時刻を記録します。このタイムスタンプは、イベントを時系列に並べ、プロセスの異なるステップ間の期間を計算するために不可欠です。 プロセスマイニング分析では、この属性はサイクルタイム、待機時間、処理時間を含むすべての時間ベースのメトリックを計算するために使用されます。これにより、アナリストは、先行する長い遅延があるアクティビティを見つけることでボトルネックを特定し、サービスレベル契約(SLA)に対するパフォーマンスを測定できます。正確で一貫したタイムスタンプは、信頼性の高い分析のために不可欠です。
その重要性
このタイムスタンプは、イベントを正しく順序付けし、サイクルタイムやボトルネックなどのすべてのパフォーマンス指標を計算するために不可欠です。
取得元
これは通常、ServiceNowの監査および履歴テーブル(例:「sys_audit」)の「sys_created_on」フィールドに対応します。
例
2023-10-26T10:00:00Z2023-10-26T10:15:32Z2023-10-27T14:05:11Z
|
|||
|
サービスリクエスト
ServiceRequest
|
各カスタマーサービスリクエスト、ケース、またはチケットの一意の識別子です。 | ||
|
説明
サービスリクエストは、単一の顧客問題に関連するすべての活動とイベントを、作成から終了までリンクする主要なケース識別子です。これは、顧客インタラクションのエンドツーエンドのジャーニーを追跡するための中央スレッドとして機能します。 プロセスマイニングにおいて、この属性はプロセスフローを再構築するために不可欠です。各ユニークなサービスリクエスト値はプロセスの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コンプライアンスの測定と報告に不可欠です。
取得元
例
truefalse
|
|||
|
カテゴリ
Category
|
サービスリクエストの主要な分類で、「請求」や「技術的な問題」などです。 | ||
|
説明
カテゴリは、顧客の問い合わせや問題の性質に基づいたサービスリクエストのハイレベルなグループ化を提供します。この分類は通常、リクエストが最初に作成されたときに行われ、正しいアサインメントグループへのルーティングを支援します。 この属性は、プロセス分析をセグメント化するために不可欠です。カテゴリでフィルタリングすることにより、アナリストは異なるタイプのリクエストのプロセスフローを比較できます。例えば、「請求」に関する問題の解決プロセスは、「技術的な問題」のそれとは大きく異なる場合があります。これは、ほぼすべてのダッシュボードでデータをスライスするための主要な属性です。
その重要性
リクエストタイプごとの分析を可能にし、特定のカテゴリが遅延、エスカレーション、またはSLA違反に陥りやすいかどうかを明らかにします。
取得元
これは「sn_customerservice_case」テーブルの「category」フィールドに対応します。
例
問い合わせ / ヘルプ注文製品の問題請求
|
|||
|
優先度
Priority
|
サービスリクエストの優先度レベルで、その緊急性に影響を与えます。 | ||
|
説明
優先度は、サービスリクエストに対処するために必要な重要性と緊急性を示します。これは多くの場合、リクエストが顧客に与える影響とその緊急性の組み合わせによって決定されます。一般的な値は「緊急」から「低」まであります。 プロセスマイニングにおいて、優先度はフィルタリングと比較のための強力な次元です。これによりアナリストは、高優先度のリクエストが実際に低優先度のものよりも速く処理されているかを確認し、特定の優先度レベルでSLA違反がより頻繁に発生しているかどうかを把握できます。これは「サービスリクエストのEnd-to-Endサイクルタイム」ダッシュボードにとって不可欠です。
その重要性
これにより、サービスリクエストを緊急性によってセグメント化できます。これは、重要な問題が非重要問題よりも迅速に処理されることを検証するために不可欠です。
取得元
これは「sn_customerservice_case」テーブルの「priority」フィールドに対応します。
例
1 - Critical2 - High3 - Moderate4 - Low
|
|||
|
担当グループ
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
|
サービスリクエストが開始されたコミュニケーションチャネルです。 | ||
|
説明
チャネルは、顧客がリクエストを送信するために使用した方法を示します。例えば、「メール」、「電話」、「ウェブポータル」、「チャット」などです。異なるチャネルは、プロセス特性と顧客期待値が著しく異なる場合があります。 チャネルごとにプロセスを分析することで、各コミュニケーション方法の有効性を評価するのに役立ちます。例えば、「電話」経由で提出されたリクエストの方が初回解決率が高いか、または「メール」リクエストの方がサイクルタイムが長い傾向があるかなどを明らかにできます。これは、「コミュニケーションチャネルの有効性」ダッシュボードを直接サポートします。
その重要性
電話、メール、ウェブポータルなど、さまざまな顧客インタラクションチャネルの効率と成果を判断するのに役立ちます。
取得元
これは通常、「sn_customerservice_case」テーブルの「contact_type」フィールドに対応します。
例
電話番号メールセルフサービスチャット
|
|||
|
再オープン件数
ReopenCount
|
解決済みのサービスリクエストが顧客によって再オープンされた回数です。 | ||
|
説明
このカウンターは、ケースが「解決済み」または「終了」状態から「Work in Progress」(進行中)または「Open」(オープン)状態に戻った回数を追跡します。再オープンされたケースは、初期の解決策が効果的でなかったか、完全でなかったことを示唆しています。 この属性は、手戻りや初回解決の品質を示す強力な指標です。再オープン件数が多い場合、担当者がチケットを早めにクローズしたり、顧客の根本的な問題を完全に解決していなかったりするなど、解決プロセスにおける問題を示唆しています。これは、提案された解決策の有効性を理解するための主要な指標です。
その重要性
解決の失敗と手戻りを示します。再オープンの数が多いことは、解決プロセスの品質が低いことを示し、顧客の不満につながります。
取得元
これは多くの場合、「sn_customerservice_case」テーブルまたは関連テーブルの「reopen_count」という名前のフィールドで追跡されます。
例
012
|
|||
|
再割り当て回数
ReassignmentCount
|
サービスリクエストが異なる担当者またはグループに再割り当てされた合計回数です。 | ||
|
説明
この属性は、「assigned_to」または「assignment_group」フィールドが変更されるたびに増分するカウンターです。これは、ケースが経験した内部転送の量を測るシンプルな指標です。 再割り当て件数は、プロセス摩擦の直接的な測定値であり、「担当者引き継ぎと再割り当て」ダッシュボードおよび「リクエストあたりの平均担当者引き継ぎ回数」KPIの重要な入力です。再割り当て件数が多い場合、初期ルーティングの問題、担当者のスキルギャップ、または分類が困難なケースを示していることが多く、これらのすべてが解決時間の延長につながります。
その重要性
引き渡し数を数えることで、プロセスの非効率性を直接測定します。数が多いほど、解決時間の延長や顧客満足度の低下と相関する傾向があります。
取得元
これは、「sn_customerservice_case」が拡張する「task」テーブルの標準的なメトリックフィールド「reassignment_count」です。
例
0135
|
|||
|
最終データ更新
LastDataUpdate
|
データがソースシステムから最後に抽出または更新された日時を示すタイムスタンプです。 | ||
|
説明
この属性は、最新のデータ抽出の日時を記録します。分析されているデータの鮮度に関するコンテキストを提供し、ユーザーがほぼリアルタイムの情報を見ているのか、それとも過去のスナップショットを見ているのかを認識できるようにします。 分析中、これはデータセットの期間を理解するための重要なメタデータです。ユーザーがダッシュボードやKPIを正しく解釈するのに役立ち、例えば、データが過去1時間または前日のものとして最新であることなどを知ることができます。
その重要性
データの鮮度を示します。これは、プロセスマイニングの洞察の関連性と適時性にとって重要です。
取得元
この
例
2023-11-20T08:00:00Z
|
|||
|
処理時間
ProcessingTime
|
アクティビティに実作業として費やした時間。 | ||
|
説明
処理時間(アクティブ時間またはサービス時間とも呼ばれる)は、アクティビティの開始から終了までの期間を測定します。これは、担当者またはシステムがタスクを積極的に実行している時間を表し、タスク間の待機時間とは対照的です。 プロセスマイニングにおいて、この指標は付加価値のある時間と付加価値のない待機時間を区別するために重要です。処理時間を分析することで、どの特定のタスクが最も時間を消費しているかを特定し、効率を改善するための自動化やトレーニングの機会がある場所を特定するのに役立ちます。これはボトルネック分析の基礎となる指標です。
その重要性
アクティビティの実際の作業時間を測定し、プロセスにおける付加価値のある時間と無駄な待機時間を区別するのに役立ちます。
取得元
これは計算属性であり、通常、アクティビティの終了時刻と開始時刻の差として導き出されます。
例
PT15MPT2H30MP1D
|
|||
|
初回解決であるか
IsFirstContactResolution
|
依頼が最初に割り当てられたエージェントによって、転送やエスカレーションなしで解決されたかどうかを示すブール値フラグです。 | ||
|
説明
この計算属性は、最初のインタラクション中、または最初にケースを処理した担当者によって効率的に解決されたサービスリクエストを特定します。そのロジックは通常、再割り当てがゼロ(「ReassignmentCount」が0)、内部エスカレーションがトリガーされたアクティビティがない、および顧客からの追加情報要求がないといった条件をチェックします。 この属性は、重要なカスタマーサービス指標を直接測定し、「初回解決率」ダッシュボードとKPIをサポートします。FCRパフォーマンスの容易な定量化を可能にし、チャネルやリクエストカテゴリなど、初回解決の達成に貢献または妨げる要因を分析するのに役立ちます。
その重要性
初回応答の効率性を直接測定します。高いFCR率は、運用効率と高い顧客満足度の両方と強く関連しています。
取得元
これは計算属性です。データ変換中に、「ReassignmentCount」がゼロでエスカレーションアクティビティが発生しないなどのルールに基づいて導き出されます。
例
truefalse
|
|||
|
手戻り
IsRework
|
再オープンされたケースや繰り返しの調査など、大幅な手戻りが発生したかどうかを示すブール値フラグです。 | ||
|
説明
これは、非効率性や繰り返しパターンを示すケースにフラグを立てる計算属性です。このフラグのロジックは、「サービスリクエスト再オープン」のようなイベントや、「担当者による調査開始」に続いて「解決策提示済み」のような主要なアクティビティのシーケンスが同じケース内で複数回発生した場合にトリガーされることがあります。 このフラグは、問題のあるケースを迅速に特定し、プロセス全体の手戻りのレベルを定量化する上で非常に価値があります。これは、「手戻りおよび繰り返しホットスポット」ダッシュボードと「手戻り率」KPIを直接サポートし、アナリストが手動で繰り返しパターンを特定することなく、非効率性の要因に集中できるようにします。
その重要性
繰り返しループや再開イベントのあるケースにフラグを立てることで、プロセスの非効率性を定量化し、手戻りの測定とターゲット設定を容易にします。
取得元
これは計算属性です。データ変換中に、ゼロではない「ReopenCount」や繰り返されるアクティビティなどの手戻りパターンを検出するビジネスロジックを適用して導き出されます。
例
truefalse
|
|||
|
解決コード
ResolutionCode
|
最終的な結果、またはサービスリクエストがどのように解決されたかを示すコードです。 | ||
|
説明
解決コードは、担当者がケースを解決する際に選択する構造化された値です。これは、「ユーザーによって解決済み」、「既知のエラー」、「重複」、「対応不要」など、解決策に関する具体的な詳細を提供します。 この属性は、根本原因分析に価値があります。さまざまな解決コードの頻度を分析することで、組織は再発する問題、知識のギャップ、または製品の問題を特定できます。この情報は、特定のタイプのサービスリクエストの量を減らす改善策を推進するために使用できます。
その重要性
サービスリクエストの結果に関する洞察を提供します。これは根本原因分析と再発する問題の特定に不可欠です。
取得元
これは「sn_customerservice_case」テーブルの「close_code」フィールド、またはカスタム解決コードフィールドに対応します。
例
解決済み(`ワークアラウンド`)解決済み(恒久的)未解決(顧客からの応答なし)発信者によりクローズ/解決済み
|
|||
|
顧客
Customer
|
サービスリクエストを開始した顧客または企業の名前または識別子です。 | ||
|
説明
この属性は、サービスリクエストの対象となる外部のステークホルダー(個人または組織)を特定します。各ケースの顧客コンテキストを提供します。 分析において、顧客属性はサービスプロセスの顧客中心ビューを可能にします。特定の顧客がより多くの問題や長い遅延を経験しているかどうかを特定するために使用でき、セグメントや価値などの他の顧客データと結合して、プロセス改善の取り組みを優先順位付けすることができます。例えば、高価値の顧客がより迅速なサービスを受けているかを確認することができます。
その重要性
プロセスを特定の顧客に紐付け、主要なアカウントや顧客セグメントにおけるサービスレベルと問題発生頻度の分析を可能にします。
取得元
これは「sn_customerservice_case」テーブル上の「caller_id」、「opened_for」、または「account」フィールドである可能性があり、これらはユーザーまたは企業テーブルを参照します。
例
John SmithACMEコーポレーション`Global Tech Inc.`
|
|||
カスタマーサービス活動
| アクティビティ | 説明 | ||
|---|---|---|---|
|
サービスリクエスト作成済み
|
このアクティビティはカスタマーサービスプロセスの開始を示し、新しいケースがシステムに正式に記録された時です。このイベントは、sn_customerservice_caseテーブルに新しいレコードが挿入されたときに明示的に捕捉されます。 | ||
|
その重要性
すべてのケースの開始点として、このアクティビティはエンドツーエンドのサイクルタイムを計算し、リクエスト受付量を分析するために不可欠です。これは、すべての下流プロセスとSLAタイマーのトリガーとして機能します。
取得元
このイベントはsn_customerservice_caseテーブルでのレコード作成に対応します。タイムスタンプはsys_created_onフィールドから取得されます。
取得
sn_customerservice_caseテーブルにおけるレコード作成タイムスタンプ(sys_created_on)。
イベントタイプ
explicit
|
|||
|
サービスリクエスト終了
|
これは、サービスリクエストレコードの正式な終了を示す最終アクティビティであり、多くの場合、解決後の確認期間を経て行われます。ケースのステータスが「終了」に変更され、closed_atタイムスタンプが設定されたときに捕捉されます。 | ||
|
その重要性
プロセスが最終的に終了したことを示すこのアクティビティは、完全なケースライフサイクルを計算するために不可欠です。「解決済み」から「クローズ済み」までの時間を分析することで、管理上のオーバーヘッドや遅延が明らかになります。
取得元
取得
イベントタイプ
inferred
|
|||
|
サービスリクエスト解決済み
|
これは、サービス担当者が作業を完了し、問題が解決済みと見なされたことを示す重要なマイルストーンです。ケースのステータスが「解決済み」に変更され、resolved_atタイムスタンプが入力されたときに捕捉されます。 | ||
|
その重要性
このアクティビティは、アクティブな解決プロセスの終了を示し、解決サイクルタイムとSLA遵守を計算するために不可欠です。多くの効率性KPIの主要なエンドポイントとして機能します。
取得元
取得
イベントタイプ
inferred
|
|||
|
リクエストが担当者にアサイン
|
このアクティビティは、サービスリクエストが調査と解決のために特定の担当者に割り当てられたときに発生します。これは、ケースレコードのassigned_toフィールドの変更を推測することで捕捉されます。 | ||
|
その重要性
これは、初期応答時間と担当者のワークロード配分を測定するための重要なマイルストーンです。このフィールドの再割り当てを追跡することで、プロセスの非効率性や担当者の可用性における潜在的なボトルネックが浮き彫りになります。
取得元
取得
ケースの監査ログで
イベントタイプ
inferred
|
|||
|
内部エスカレーション発生
|
解決のためにサービスリクエストが上位のサポートレベルまたはマネジメントに正式にエスカレーションされたことを表します。これは、アサインメントグループが上位チームに変更されたり、フラグが設定されたりすることから推測できます。 | ||
|
その重要性
エスカレーションを追跡することで、プロセスの弱点、フロントラインサポートにおける知識のギャップ、および複雑なケースタイプを特定するのに役立ちます。これは、プロセス摩擦と顧客不満足の主要な指標です。
取得元
監査ログから、
取得
イベントタイプ
inferred
|
|||
|
SLA違反
|
解決時間など、サービスリクエストが定義されたSLAを満たさない瞬間を表します。これは、解決時間とSLAの計画終了時間を比較して導き出される計算イベントです。 | ||
|
その重要性
SLA違反の特定は、コンプライアンス監視とパフォーマンス管理にとって不可欠です。このイベントは、どのプロセス段階またはケースタイプがSLA違反に最も貢献しているかを特定するのに役立ちます。
取得元
ケースに関連する
取得
リンクされた
イベントタイプ
calculated
|
|||
|
エージェントが調査を開始
|
このアクティビティは、担当者がサービスリクエストに積極的に着手したことを示します。これは通常、ケースのステータスが「新規」や「アサイン済み」から「Work in Progress」(作業中)に変化したときに推測されます。 | ||
|
その重要性
このイベントは、キュー時間と実際の作業時間を区別するのに役立ちます。割り当てから調査開始までの期間を分析することで、担当者が新規ケースに着手する際の遅延が明らかになります。
取得元
ケースのステータスフィールドが「Work in Progress」(作業中)などのアクティブな作業状態に変化したことから推測されます。具体的なステータス値は設定可能であり、確認が必要です。
取得
イベントタイプ
inferred
|
|||
|
サービスリクエスト再オープン
|
以前解決されたサービスリクエストが、問題の再発や解決策の無効化によりアクティブな状態に戻った場合に発生します。これは、「解決済み」から「Work in Progress」(作業中)へのステータス変更を検出することで推測されます。 | ||
|
その重要性
再オープンされたケースは、解決品質を直接示す指標であり、手戻りの主要な要因です。これらのイベントを分析することは、初回解決率と顧客満足度を向上させるために不可欠です。
取得元
取得
イベントタイプ
inferred
|
|||
|
リクエストを分類・優先順位付け
|
最初のトリアージを表し、サービスリクエストが分類され、その緊急性とルーティングを決定するために優先度が割り当てられます。これは、ケースレコードの監査ログにおけるカテゴリ、サブカテゴリ、または優先度フィールドの変更から推測されます。 | ||
|
その重要性
このアクティビティを分析することで、ケーストリアージの遅延を特定し、リクエストが適切にルーティングされ、緊急性に応じて処理されることを確認できます。これは、最初の割り当てまでの時間と全体の解決効率に影響します。
取得元
取得
イベントタイプ
inferred
|
|||
|
担当グループ変更
|
ケースの責任が別のチームに転送されたことを示します。このイベントは、ケースレコード内の`assignment_group`フィールドの変更を監視することによって推論されます。 | ||
|
その重要性
アサインメントグループの変更を追跡することは、部門間の引き継ぎを分析し、体系的なルーティングの問題を特定するために極めて重要です。このアクティビティの頻度が高い場合、所有権の不明確さやプロセス定義の問題を示唆する可能性があります。
取得元
取得
ケースの監査ログで
イベントタイプ
inferred
|
|||
|
解決策提示済み
|
このアクティビティは、担当者が解決策を特定し、顧客に確認のために伝達した時点を示します。これは、「Awaiting Acceptance」(承認待ち)のような値へのステータス変更、または特定の作業メモのエントリから推測されることがよくあります。 | ||
|
その重要性
このマイルストーンは、調査フェーズと確認・解決フェーズを区別します。顧客からの確認を待つ時間を分析することで、ケースのクローズ段階を合理化する機会が明らかになることがあります。
取得元
取得
イベントタイプ
inferred
|
|||
|
顧客アンケート送信済み
|
ケース解決後に顧客満足度調査が送信されたことを表します。このイベントは通常、調査インスタンスレコードが作成され、ケースに関連付けられたときに捕捉されます。 | ||
|
その重要性
このアクティビティは、プロセス実行パターンと顧客フィードバックを関連付けるのに役立ちます。アンケートがいつ、そして送信されたかどうかを理解することは、フィードバックループの有効性を分析するために重要です。
取得元
これは、asmt_assessment_instanceのような調査固有のテーブルに記録される明示的なイベントで、ソースケースレコードへの参照を含みます。
取得
ケースにリンクされた「asmt_assessment_instance」テーブルでのレコード作成。
イベントタイプ
explicit
|
|||
|
顧客からの情報を受領
|
このアクティビティは、顧客が要求された情報を提供し、担当者が作業を再開できるようになった時点を示します。これは、ケースのステータスが「Awaiting User Info」(ユーザー情報待ち)からアクティブな状態に戻ったときに推測されます。 | ||
|
その重要性
このイベントは顧客の待機期間を終了させ、顧客応答時間の正確な測定を可能にします。これにより、どのケースタイプや顧客が最も長い遅延と関連しているかを特定するのに役立ちます。
取得元
取得
イベントタイプ
inferred
|
|||
|
顧客への情報依頼
|
担当者が処理を進めるために顧客から追加情報を必要とし、ケースを保留状態にした場合に発生します。これは、「Awaiting User Info」(ユーザー情報待ち)や「On Hold」(保留中)といった値へのステータス変更から推測されます。 | ||
|
その重要性
このアクティビティは「顧客情報待機時間」分析にとって極めて重要です。外部依存関係によって引き起こされるプロセス遅延を分離し、それらを内部処理時間から区別します。
取得元
取得
イベントタイプ
inferred
|
|||