カスタマーサービスデータテンプレート

アクティビティは、サービスリクエストのライフサイクルにおける個別のステップやイベントを指します。「サービスリクエスト作成」「リクエストアサイン」「解決策提案」「リクエストクローズ」などがその例です。各アクティビティは特定のサービスリクエストに関連付けられ、発生日時を示すタイムスタンプを持ちます。

この属性は、顧客サービスワークフローの視覚的表現であるプロセスマップを構築するために不可欠です。アクティビティの順序と頻度を分析することで、サービスリクエストが実際にたどる経路を明らかにし、一般的なワークフロー、ボトルネック、逸脱、手戻りのループを浮き彫りにします。これは、あらゆるプロセスマイニング分析の基盤となります。

この属性は、プロセスマップのステップを定義します。どのような作業がどのような順序で行われているかを理解するために不可欠です。

多くの場合、イベントログ、ステータス変更テーブル、または顧客サービスシステム内の監査証跡記録から派生します。

イベント時間、別名「開始時間」は、アクティビティが発生した瞬間を記録します。サービスリクエストの最初の作成から最終的なクローズまで、ログ内のすべてのイベントにはタイムスタンプが付与されます。この時間データは、イベントを時系列に並べる上で非常に重要です。

特定のサービスリクエストに対するこれらのタイムスタンプのシーケンスにより、プロセスマイニングツールは実際に発生したプロセスフローを再構築できます。イベント時間は、アクティビティ間の期間計算、総ケース解決時間の測定、ボトルネックの特定、サービスレベル契約（SLA）遵守の確認を含む、すべての時間ベース分析の基礎となります。

このタイムスタンプはイベントを順序付けし、解決時間の計算やボトルネックの特定など、期間ベースのすべての分析を可能にします。

イベントログや監査証跡テーブルに、アクティビティ名とともによく見られます。「作成日」「イベント日付」「タイムスタンプ」などの名前で呼ばれることがあります。

サービスリクエストIDは、各顧客ケースの作成から最終解決までを一意に識別する主キーです。これはケース識別子として機能し、特定の顧客の問題に関連するすべてのイベント、コミュニケーション、およびアクションをまとまったタイムラインにグループ化します。\n\nプロセスマイニングにおいて、この属性は各サービスリクエストのエンドツーエンドのジャーニーを再構築するために不可欠です。すべてのアクティビティを特定のサービスリクエストIDと関連付けることにより、アナリストはプロセスフローを視覚化し、逸脱を特定し、ケースの期間を正確に測定できます。これにより、パフォーマンスを理解し、改善領域を特定するために不可欠な、ケース中心のプロセスビューが可能になります。

これは不可欠なケース識別子です。これがないと、単一の顧客の問題がプロセスをたどるジャーニーを追跡することはできません。

通常、カスタマーサービス管理システム内のケース、チケット、またはインシデントのヘッダーまたはメインテーブルにあります。

ソースシステム属性は、カスタマーサービスデータが発信されたアプリケーションまたはプラットフォーム（ServiceNow、Salesforce、Zendesk、またはカスタムの自社システムなど）を識別します。複数のシステムからのデータが結合される環境では、このフィールドはデータガバナンスとトレーサビリティのために不可欠です。\n\nほとんどの標準的なプロセスフロー分析で直接使用されるわけではありませんが、重要なコンテキストを提供します。これにより、異なるシステム間でのデータ品質またはプロセス実行の潜在的な変動を理解するのに役立ちます。また、データ検証、データ抽出の問題のトラブルシューティング、およびデータ統合パイプラインの管理にも不可欠です。

データの発生源を特定します。これは、マルチシステム環境でのデータガバナンス、トラブルシューティング、分析にとって重要です。

これは通常、データ抽出（ETL）プロセス中に加えられ、ソースシステムのテーブルには直接存在しない場合があります。

最終データ更新属性は、最新のデータ抽出または更新の日時を記録します。このメタデータは、分析されるデータの鮮度を理解し、データパイプラインを管理するために不可欠です。\n\nこの属性は、ビジネスユーザーとアナリストに対し、自身の分析がどれだけ最新であるかについての透明性を提供します。データのリフレッシュをスケジュールし、意思決定が必要な程度に最新のデータに基づいていることを保証するのに役立ちます。進行中のプロセスを監視する場合、最終更新時刻を知ることは、未処理のケースの現在の状態を正しく解釈するために不可欠です。

データの鮮度を示し、分析やビジネス上の意思決定がタイムリーかつ関連性の高い情報に基づいていることを保証します。

このタイムスタンプは通常、データ抽出（ETL）プロセス中に生成され、追加されます。

エスカレーション済み属性は、サービスリクエストが正式にエスカレーションされたことを示すブール型フラグ（trueまたはfalse）です。エスカレーションは通常、問題が現在のサポートティアには複雑すぎる場合、指定された時間内に解決されない場合、または顧客の不満が非常に高い場合に発生します。\n\nこの属性は、エスカレーション分析に不可欠です。組織は、主要なパフォーマンス指標であるエスカレーション率を計算できます。エスカレーションされたケースのプロセスフローを分析することにより、企業は、フロントラインサポートのスキルギャップ、不明確なプロセス、製品の問題など、エスカレーションの根本原因を特定できます。エスカレーションの削減は、コストがかかり顧客満足度に悪影響を与える可能性があるため、しばしば主要な目標となります。

エスカレーションの頻度と根本原因を特定するのに役立ち、初回解決を改善する機会を浮き彫りにします。

これは、ケースまたはチケットレコード上のチェックボックスまたはフラグフィールドであることがよくあります。「エスカレート」アクティビティを検出することによっても導き出すことができます。

コミュニケーションチャネル属性は、顧客がサービスデスクとやり取りするために使用した媒体を識別します。一般的なチャネルには、Eメール、電話、Webポータル、チャット、ソーシャルメディアなどがあります。チャネルは、顧客の期待と解決プロセスの複雑さに影響を与える可能性があります。\n\nコミュニケーションチャネル別にプロセスを分析することで、パフォーマンスに大きな違いがあることが明らかになる場合があります。たとえば、電話で提出されたリクエストは解決時間が速い場合がありますが、Webポータルからのリクエストと比較してより多くのエージェントリソースを必要とします。この分析は、組織がチャネル戦略を最適化し、リソースを効果的に配分し、異なるコミュニケーション方法に合わせてサービスエクスペリエンスを調整するのに役立ちます。

異なるコミュニケーションチャネルが解決時間、エージェントの労力、および全体的なプロセス効率にどのように影響するかを明らかにします。

通常、メインのケースまたはチケットフォームの標準フィールドとして利用可能で、リクエストがどのように作成されたかを示します。

リクエストステータスは、サービスリクエストのライフサイクルにおける特定の時点での状態を示します。ステータスは、リクエストが処理されるにつれて変化します。たとえば、「新規」から「進行中」、次に「顧客保留中」、そして「解決済み」へと移行します。ステータス変更のシーケンスは、プロセスモデルにおけるアクティビティの基盤となることがよくあります。\n\nステータス変更を分析することは、プロセスフローを理解する主要な方法です。これは、リクエストが「保留中」などの特定の状態でどれだけの時間を費やすかを特定するのに役立ち、外部関係者への依存関係を浮き彫りにすることができます。また、アクティブなケースロードと解決率の報告の基本となる、オープンケースとクローズドケースを区別するためにも使用されます。

リクエストのライフサイクルステージを追跡し、待機状態に費やされた時間を特定し、プロセスアクティビティを定義するのに役立ちます。

ケースまたはチケットレコード上の主要なフィールドです。ステータス変更は、多くの場合、監査履歴テーブルに記録されます。

リクエストタイプは、顧客の問題または問い合わせを大まかに分類するものです。この分類は、サポート組織に寄せられるさまざまな種類の要求を理解するために、サービスリクエストをセグメント化するのに役立ちます。一般的なタイプには、技術的な問題、請求に関する質問、情報要求、苦情などがあります。\n\nこの属性は、さまざまな種類のリクエストのプロセスをフィルタリングおよび比較できるため、分析にとって非常に貴重です。たとえば、「請求に関する質問」の解決プロセスは、「技術的なインシデント」よりもはるかに単純で迅速である可能性があります。これらの違いを理解することは、適切なSLAを設定し、効率的なワークフローを設計し、リソースを効果的に配分するための鍵となります。

リクエストをタイプ別に分類することは、異なるプロセス経路を理解し、特定の課題に合わせた改善を行う上で極めて重要です。

これは、メインのケースまたはチケットフォームの標準フィールドであり、しばしば「タイプ」、「カテゴリ」、または「分類」と名付けられています。

優先度属性は、サービスリクエストの緊急性を示し、これはしばしば対応の迅速さに影響を与えます。このレベルは通常、顧客から報告された問題のビジネスへの影響と重大度に基づいて決定されます。SLAは多くの場合、優先度レベルと関連付けられています。\n\nプロセス分析において、優先度はフィルタリングと比較のための重要な要素です。アナリストは、高優先度のリクエストが期待通り低優先度のものよりも迅速に解決されているかをチェックできます。これにより、優先順位付けルールが守られているかを確認し、リソース配分がビジネス優先度と一致しているかを評価するのに役立ちます。異なる優先度レベルのプロセスフローを比較することで、重要な問題の処理における非効率性が明らかになる可能性があります。

緊急のリクエストが迅速に処理されているかどうかの分析を可能にし、リソースがビジネスニーズに合致していることを確認するのに役立ちます。

ほとんどの顧客サービスシステムにおいて、ケースまたはチケットフォーム上の標準フィールドです。

アサインされたグループ属性は、特定の時点でのサービスリクエストを担当するチームまたは機能部門を識別します。これには、「レベル1サポート」、「経理部門」、または「技術サポートチーム」などが含まれます。サービスリクエストは、進行するにつれて異なるグループ間でルーティングされることがよくあります。\n\nアサインされたグループを分析することは、チーム間の連携と引き継ぎを理解するために非常に重要です。どのチームが過負荷になっているか、グループ間でボトルネックがどこで発生しているか、および異なるタイプのリクエストが組織内でどのような経路をたどるかを特定するのに役立ちます。この情報は、チーム構造、リソース配分、およびルーティングルールを最適化するために不可欠です。

チームのパフォーマンス、ワークロードの配分、および異なる部門間の引き継ぎによって発生する遅延の分析を可能にします。

ケースまたはチケットレコードにあり、多くの場合、「アサインメントグループ」、「チーム」、または「キュー」のようなフィールドにあります。

エージェント属性は、特定の活動を実行した、または現在サービスリクエストにアサインされている個々の従業員を識別します。これは、一意のID、メールアドレス、またはフルネームで構成されます。\n\nこの属性により、個人レベルでのパフォーマンスとワークロードの分析が可能になります。マネージャーは、作業の割り当て状況を確認し、解決時間や顧客満足度などの指標でエージェントのパフォーマンスを比較し、トレーニングの機会を特定できます。また、エージェント間の引き継ぎは遅延や顧客の不満の原因となる可能性があるため、その分析にも不可欠です。

この属性は、エージェントのワークロード、パフォーマンス、および異なるエージェント間の引き継ぎの影響を分析するために不可欠です。

ケースアサイン履歴テーブル、イベントログ、または主要なケース/チケットレコードのフィールドとしてよく見られます。

終了時刻属性は、アクティビティの完了時点を示します。イベント時刻が開始を示唆するのに対し、終了時刻は特定のタスクにかかった時間を測定するために必要なもう一方の時点を提供します。すべてのイベントに明確な終了時刻があるわけではありませんが、「エージェントによる調査」や顧客からの電話など、終了時刻がある場合には貴重な情報となります。\n\n分析において、終了時刻とイベント時刻の差はアクティビティの処理時間を示します。これはボトルネック分析の基本であり、その目的はプロセス内で最も時間を消費するステップを見つけることです。アクティビティの期間を理解することは、リソース計画、パフォーマンス評価、および業務を効率化する機会を特定するのに役立ちます。

この属性は、個々のアクティビティ期間を計算するための鍵であり、ボトルネックの特定と効率測定に不可欠です。

通常、開始時刻とともにイベントログまたは監査証跡テーブルにあります。利用できない場合は、後続イベントの開始時刻から導き出す必要がある場合があります。

顧客満足度は、顧客が受けたサービスに対する認識を測定する重要な成果指標です。通常、問題解決後のアンケートを通じて収集され、1から5の数値スケールや「良い」「普通」「悪い」といったカテゴリ評価で記録されます。

この属性は、プロセスのパフォーマンスをビジネス成果に結びつける上で極めて重要です。満足度スコアをプロセス指標と関連付けることで、アナリストはどのプロセス行動が顧客を満足させ、あるいは不満にさせるのかを特定できます。例えば、複数の再アサインや長い解決時間を要するケースが、一貫して低い満足度スコアを受け取ることを分析が示すかもしれません。これは、顧客体験に最大の影響を与えるプロセス改善を優先するための、明確でデータに基づいた根拠となります。

サービス品質に対する顧客の認識を直接測定し、プロセス効率をビジネス成果に結びつけます。

通常、サービスリクエストレコードにリンクできる別のアンケート回答テーブルに保存されます。

SLA目標時間属性は、管轄するサービスレベル契約（SLA）に従って、サービスリクエストが解決されると予想される期限を示します。この目標は、リクエストの優先度、タイプ、または顧客の契約レベルに依存することがよくあります。特定のタイムスタンプとして、または作成時間からの期間として保存できます。\n\nこの属性はSLA遵守分析の基本です。実際の解決時間とSLA目標時間を比較することで、組織はSLA遵守率を判断できます。プロセスマイニングはこれをさらに細分化し、どの種類のリクエストまたはどのプロセスステップがSLA違反に最も貢献しているかを示すことができます。これにより、サービスコミットメントを満たすための的を絞った改善が可能になります。

これは、顧客サービス組織にとって重要なKPIであるSLA遵守を測定するために不可欠です。

通常、システム内で定義されたSLAポリシーに基づいてケースまたはチケットレコードに計算され、保存されます。

製品属性は、顧客のリクエストの対象となる特定の製品、サービス、または機能を指定します。これにより、サービスリクエストを関連するビジネス分野に基づいて分類できます。\n\n製品別にサービスリクエストを分析することは、根本原因分析と製品改善にとって不可欠です。特定の製品に対するチケットが大量に発生している場合、品質の問題、バグ、またはユーザビリティの問題を示している可能性があります。このデータは、製品開発およびエンジニアリングチームに貴重なフィードバックを提供し、サポートのワークロードを削減し、顧客体験を向上させるための修正や機能強化の優先順位付けに役立ちます。

サービスリクエストを特定の製品にリンクさせ、製品改善と根本原因分析のための重要なフィードバックを提供します。

多くの場合、ケースまたはチケットフォーム上のフィールドであり、製品カタログにリンクするか、手動で入力できます。

顧客属性は、サービスリクエストに関連付けられた外部の顧客（個人または組織）を識別します。これにより、特定の顧客に関するすべてのサービスインタラクションをグループ化して分析できます。\n\n顧客中心の視点は、全体的な顧客体験を理解するために不可欠です。顧客でデータをフィルタリングして分析することで、企業は大量のリクエストを送信する顧客を特定でき、これは製品の問題またはより良いトレーニングの必要性を示している可能性があります。また、主要なアカウントのサービス履歴を追跡し、期待されるレベルのサポートを受けていることを確認するのにも役立ちます。

プロセスを顧客中心の視点で捉えることを可能にし、特定のクライアントにおける頻繁な問題の特定や主要なアカウント管理を支援します。

CRM内の連絡先またはアカウントオブジェクトにリンクする、ケースまたはチケットレコード上の標準フィールドです。