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

アクティビティは、サービスリクエストのライフサイクルにおける個別のステップまたはイベントを表します。例として、「サービスリクエスト作成」、「リクエスト割り当て」、「解決策提案」、「リクエスト終了」などがあります。各アクティビティは特定のサービスリクエストに関連付けられ、発生時刻を示すタイムスタンプを持ちます。

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

この属性によって、プロセスマップ上のステップが定義されます。どの作業が、どの順序で行われているかを把握するために欠かせません。

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

イベント時刻は開始時刻とも呼ばれ、アクティビティが発生した時点を記録します。サービスリクエストの作成から最終終了まで、ログ内のすべてのイベントにタイムスタンプが付与されます。この時系列データは、イベントを時系列に並べるために欠かせません。

特定のサービスリクエストにおけるタイムスタンプの順序により、プロセスマイニングツールは実際のプロセスフローを再構築できます。イベント時刻は、アクティビティ間の所要時間の計算、ケースの総解決時間の測定、ボトルネックの特定、サービスレベル合意（SLA）への準拠確認など、時間に基づく分析の基礎になります。

このタイムスタンプによってイベントの順序が決まり、解決時間の計算やボトルネックの特定など、所要時間に基づく分析が可能になります。

イベントログまたは監査証跡テーブルに、アクティビティ名とともに記録されます。「作成日」、「イベント日」、「タイムスタンプ」などの名称が使われる場合があります。

サービスリクエストIDは、作成から最終的な解決まで、各顧客ケースを一意に識別する主キーです。ケース識別子として機能し、特定の顧客の問題に関するすべてのイベント、コミュニケーション、対応を一貫したタイムラインにまとめます。

プロセスマイニングでは、この属性が各サービスリクエストのエンドツーエンドの流れを再構築する基盤になります。すべてのアクティビティを特定のサービスリクエストIDに関連付けることで、分析担当者はプロセスフローを可視化し、逸脱を特定して、ケースの所要時間を正確に測定できます。ケースを中心にプロセスを捉えられるため、パフォーマンスの把握や改善領域の特定に欠かせません。

これはケースを識別するための必須項目です。これがなければ、1件の顧客の問題がプロセス内でどのように進んだかを追跡できません。

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

ソースシステム属性は、顧客サービスデータの生成元となったアプリケーションまたはプラットフォームを識別します。ServiceNow、Salesforce、Zendesk、社内開発システムなどが該当します。複数のシステムからデータを統合する環境では、この項目がデータガバナンスと追跡可能性を支えます。

通常のプロセスフロー分析で直接使われることは多くありませんが、重要な背景情報を提供します。システムごとのデータ品質やプロセス実行の違いを把握できるほか、データ検証、抽出時の問題の調査、データ統合パイプラインの管理にも役立ちます。

データの出所を特定します。複数システムの環境におけるデータガバナンス、問題調査、分析に欠かせません。

通常、データ抽出（ETL）処理の際に追加され、ソースシステムのテーブルに直接存在しない場合があります。

最終データ更新時刻属性は、直近のデータ抽出または更新が行われた日時を記録します。このメタデータは、分析対象データの新しさを把握し、データパイプラインを管理するうえで重要です。

この属性により、業務ユーザーや分析担当者は、分析対象データがどの時点のものかを確認できます。更新スケジュールの設定にも役立ち、必要な最新性を保ったデータに基づいて意思決定できるようになります。進行中のプロセスを監視する場合、オープンケースの現在の状態を正しく解釈するためにも、最終更新時刻の把握が欠かせません。

データの新しさを示し、分析や業務上の意思決定を適時性と関連性のある情報に基づいて行えるようにします。

通常、データ抽出（ETL）処理の際に生成され、追加されます。

エスカレーション済み属性は、サービスリクエストが正式にエスカレーションされたことを示すブール値（trueまたはfalse）です。エスカレーションは、現在のサポートレベルでは問題が複雑すぎる場合、指定時間内に解決できない場合、または顧客の不満が非常に大きい場合などに発生します。

この属性は、エスカレーション分析に欠かせません。主要なパフォーマンス指標であるエスカレーション率を算出できます。エスカレーションされたケースのプロセスフローを分析すると、現場サポートのスキル不足、不明確なプロセス、製品上の問題など、根本原因を特定できます。エスカレーションはコストが高く、顧客満足度にも悪影響を及ぼすため、その削減が主要な目標になることがよくあります。

エスカレーションの頻度と根本原因を特定し、初回対応での解決率を高める機会を明らかにします。

通常、ケースまたはチケットレコードのチェックボックスやフラグ項目です。「エスカレーション」アクティビティを検出して算出することもできます。

コミュニケーションチャネルは、顧客がサービスデスクとやり取りするために使った手段を示します。一般的なチャネルには、メール、電話、Webポータル、チャット、ソーシャルメディアがあります。チャネルによって、顧客の期待や解決プロセスの複雑さが変わる場合があります。

コミュニケーションチャネル別にプロセスを分析すると、パフォーマンスの大きな違いを明らかにできます。たとえば、電話で寄せられたリクエストはWebポータル経由より解決が速い一方、担当者の工数が多く必要になる場合があります。この分析により、チャネル戦略の改善、リソースの適切な配分、コミュニケーション方法に応じたサービス体験の調整が可能になります。

コミュニケーションチャネルが解決時間、担当者の工数、プロセス全体の効率に与える影響を明らかにします。

通常、ケースまたはチケットレコードの標準項目として用意され、リクエストの作成方法を示します。

リクエストステータスは、ライフサイクルの特定時点におけるサービスリクエストの状態を示します。対応の進行に応じて、「新規」から「対応中」、「顧客待ち」、最終的に「解決済み」へとステータスが変わります。ステータス変更の順序は、プロセスモデルのアクティビティの基礎になることがよくあります。

ステータス変更を分析することは、プロセスフローを把握する基本的な方法です。「保留中」など特定の状態にリクエストがとどまる時間を確認でき、外部関係者への依存を明らかにできます。また、オープンケースと終了ケースを区別するためにも使われ、対応中の案件数や解決率を報告するうえで欠かせません。

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

ケースまたはチケットレコードの主要項目です。ステータス変更は監査履歴テーブルに記録されることがよくあります。

リクエスト種別は、顧客の問題や問い合わせを大まかに分類します。この分類により、サービスリクエストを分けて分析し、サポート組織に寄せられる需要の種類を把握できます。一般的な種別には、技術的な問題、請求に関する質問、情報提供の依頼、苦情などがあります。

この属性は、リクエストの種類ごとにプロセスを絞り込み、比較できるため、分析に非常に役立ちます。たとえば、「請求に関する質問」の解決プロセスは、「技術的なインシデント」よりも単純で短時間の場合があります。こうした違いを把握することは、適切なSLAの設定、効率的なワークフローの設計、リソースの適切な配分に欠かせません。

リクエストを種別ごとに分けることで、異なるプロセス経路を把握し、問題に応じた改善を進められます。

メインのケースまたはチケットフォームにある標準項目です。「種別」、「カテゴリ」、「分類」などの名称が使われます。

優先度属性は、サービスリクエストの緊急性を示し、対応の速さに影響します。通常は、顧客が報告した問題の業務への影響度や深刻度に基づいて決定されます。SLAが優先度に紐づくこともよくあります。

プロセス分析では、優先度が重要な比較軸になります。分析担当者は、想定どおり高優先度のリクエストが低優先度のものより速く解決されているかを確認できます。優先順位付けのルールが守られているか、リソース配分が業務上の優先事項に合っているかも評価できます。優先度ごとのプロセスフローを比較すると、重要な問題への対応における非効率を明らかにできます。

緊急のリクエストがより速く処理されているかを分析し、リソースが業務上のニーズに沿って配分されているかを確認できます。

多くの顧客サービスシステムで、ケースまたはチケットフォームにある標準項目です。

割り当てグループは、特定の時点でサービスリクエストを担当するチームまたは機能単位を示します。「レベル1サポート」、「請求部門」、「テクニカルサポートチーム」などが該当します。サービスリクエストは、進行に応じて複数のグループ間で振り分けられることがあります。

割り当てグループを分析すると、チーム間の連携や引き継ぎを把握できます。負荷が集中しているチーム、グループ間で発生するボトルネック、リクエストの種類ごとの組織内の経路を特定できます。チーム構成、リソース配分、振り分けルールを改善するうえで重要な情報です。

チームのパフォーマンスや業務量の分布、部門間の引き継ぎによる遅延を分析できます。

ケースまたはチケットレコードにあり、「割り当てグループ」、「チーム」、「キュー」などの項目名が使われます。

担当者属性は、特定のアクティビティを実行した、または現在サービスリクエストを担当している従業員を識別します。一意のID、メールアドレス、氏名などが使われます。

この属性により、個人単位でパフォーマンスや業務量を分析できます。管理者は、業務の分担状況を確認し、解決時間や顧客満足度などの指標で担当者のパフォーマンスを比較し、トレーニングの機会を特定できます。また、担当者間の引き継ぎを分析するうえでも重要です。引き継ぎは、遅延や顧客の不満につながる場合があります。

この属性は、担当者の業務量やパフォーマンス、担当者間の引き継ぎによる影響を分析するために欠かせません。

ケース割り当て履歴テーブル、イベントログ、またはメインのケースやチケットレコードの項目として記録されます。

終了時刻属性は、アクティビティの完了時点を示します。イベント時刻が開始時点を示すのに対し、終了時刻によって特定のタスクにかかった時間を測定できます。すべてのイベントに明確な終了時刻があるわけではありませんが、「担当者による調査」や顧客との通話など、終了時刻を記録できるアクティビティでは有用な情報になります。

分析では、終了時刻とイベント時刻の差からアクティビティの処理時間を求めます。これは、プロセス内で最も時間を要するステップを特定するボトルネック分析の基礎です。アクティビティの所要時間を把握すると、リソース計画、パフォーマンス評価、業務効率化の機会の特定に役立ちます。

この属性は、個々のアクティビティの所要時間を計算するための基礎となり、ボトルネックの特定や効率の測定に欠かせません。

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

顧客満足度は、提供されたサービスに対する顧客の評価を測る主要な成果指標です。通常、解決後のアンケートで収集され、1から5までの数値や、「良い」、「普通」、「悪い」などのカテゴリで回答されます。

この属性は、プロセスのパフォーマンスと業務成果を結び付けるうえで重要です。満足度スコアとプロセス指標を関連付けることで、顧客の満足または不満につながるプロセス上の行動を特定できます。たとえば、再割り当てが多いケースや解決までに時間がかかるケースでは、満足度スコアが一貫して低いことが分かる場合があります。これにより、顧客体験に大きな影響を与えるプロセス改善を優先するための、データに基づく明確な根拠が得られます。

顧客が感じたサービス品質を直接測定し、プロセスの効率と業務成果を結び付けます。

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

SLA目標時刻は、適用されるサービスレベル合意（SLA）に基づき、サービスリクエストを解決する期限を示します。通常、この目標はリクエストの優先度、種別、顧客の契約レベルによって決まります。特定のタイムスタンプ、または作成時刻からの所要時間として保存されます。

この属性は、SLAへの準拠を分析する基礎になります。実際の解決時間とSLA目標時刻を比較することで、SLA遵守率を算出できます。プロセスマイニングでは、どの種類のリクエストやプロセスステップがSLA違反に最も影響しているかをさらに細かく確認できます。これにより、サービスの約束を守るための改善を的確に進められます。

顧客サービス組織にとって重要なKPIであるSLA遵守率を測定するために欠かせません。

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

製品属性は、顧客のリクエストの対象となる特定の製品、サービス、機能を示します。これにより、関連する業務領域ごとにサービスリクエストを分類できます。

製品別にサービスリクエストを分析することは、根本原因の分析や製品改善に欠かせません。特定の製品に関するチケットが多い場合、品質上の問題、バグ、使いにくさが示されている可能性があります。このデータは製品開発チームやエンジニアリングチームへの重要なフィードバックとなり、サポート業務の負荷を減らし、顧客体験を改善する修正や機能強化の優先順位付けに役立ちます。

サービスリクエストを特定の製品に関連付け、製品改善や根本原因分析に必要なフィードバックを提供します。

多くの場合、製品カタログに関連付けられたケースまたはチケットフォームの項目で、手入力できる場合もあります。

顧客属性は、サービスリクエストに関連する外部の顧客を識別します。個人の場合も組織の場合もあります。これにより、特定の顧客に関するすべてのサービス対応をまとめて分析できます。

顧客を中心にプロセスを捉えることは、顧客体験全体を理解するうえで重要です。顧客別にデータを絞り込んで分析すると、多数のリクエストを送る顧客を特定できます。これは、製品上の問題や、より適切なトレーニングの必要性を示している場合があります。また、主要顧客のサービス履歴を追跡し、期待されるサポートが提供されているかを確認することにも役立ちます。

顧客を中心にプロセスを捉え、特定顧客に頻発する問題の特定や主要顧客の管理に役立ちます。

ケースまたはチケットレコードの標準項目で、CRMの取引先責任者または取引先オブジェクトに関連付けられます。