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

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

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

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

顧客サービスシステムのイベントログ、ステータス変更テーブル、監査証跡の記録などから取得できます。

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

サービスリクエストごとのタイムスタンプの順序を使うと、プロセスマイニングツールで実際のプロセスフローを再構築できます。イベント時刻は、アクティビティ間の所要時間やケースの解決時間の計算、ボトルネックの特定、サービスレベル合意（SLA）への適合性チェックなど、時間に基づく分析の基礎となります。

このタイムスタンプでイベントを時系列に並べ、解決時間の計算やボトルネックの特定など、所要時間に基づく分析を行えます。

イベントログや監査証跡テーブルで、アクティビティ名とともに記録されていることが多く、「作成日」「イベント日」「タイムスタンプ」などの名称が使われます。

サービスリクエストIDは、顧客ケースごとに作成から最終解決までを一意に識別する主キーです。ケース識別子として機能し、特定の顧客の問題に関するイベント、連絡、対応を一連のタイムラインにまとめます。

プロセスマイニングでは、この属性を使って各サービスリクエストの一連の流れを再構築します。すべてのアクティビティを特定のサービスリクエストIDに関連付けることで、分析担当者はプロセスフローを可視化し、逸脱を特定して、ケースの所要時間を正確に測定できます。ケースを軸にプロセスを捉えられるため、パフォーマンスの把握や改善点の特定に役立ちます。

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

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

ソースシステム属性は、ServiceNow、Salesforce、Zendesk、社内開発システムなど、顧客サービスデータの発生元となったアプリケーションやプラットフォームを示します。複数のシステムのデータを統合する環境では、データガバナンスと追跡可能性を確保するうえで重要な項目です。

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

データの発生元を特定できるため、複数のシステムを使う環境でのデータガバナンス、問題の調査、分析に役立ちます。

通常、データ抽出（ETL）の過程で追加されるため、ソースシステムのテーブルには直接存在しない場合があります。

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

この属性により、業務担当者や分析担当者は、分析に使うデータがいつ時点のものか確認できます。データ更新のスケジュール設定に役立ち、必要な鮮度を保ったデータに基づいて意思決定できます。進行中のプロセスを監視する際は、最終更新時刻を把握することで、未完了ケースの現在の状態を正しく解釈できます。

データの鮮度を示し、分析や業務上の意思決定に適切なタイミングの情報を使えるようにします。

通常、データ抽出（ETL）の過程で生成、追加されるタイムスタンプです。

エスカレーション済み属性は、サービスリクエストが正式にエスカレーションされたことを示す真偽値（trueまたはfalse）です。問題が現在のサポート階層では対応しきれない場合、所定の時間内に解決できない場合、または顧客の不満が大きい場合などに、エスカレーションが行われます。

この属性は、エスカレーションの分析に欠かせません。主要なパフォーマンス指標であるエスカレーション率を算出できます。エスカレーションされたケースのプロセスフローを分析すると、最前線のサポート担当者のスキル不足、分かりにくいプロセス、製品の問題など、根本原因を特定できます。エスカレーションにはコストがかかり、顧客満足度を損なうおそれがあるため、その削減が大きな目標となることもよくあります。

エスカレーションの頻度や根本原因を特定し、初回連絡での解決率を高める機会を見つけるのに役立ちます。

ケースやチケットのレコードにあるチェックボックスやフラグ項目であることがよくあります。「エスカレーション」アクティビティの検出から導出することもできます。

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

コミュニケーションチャネル別にプロセスを分析すると、パフォーマンスの違いが明らかになります。たとえば、電話で受け付けたリクエストはWebポータル経由のものより早く解決する一方、担当者の作業量が多くなる場合があります。この分析は、組織がチャネルの方針を見直し、リソースを適切に配分して、連絡手段に応じたサービスを提供するうえで役立ちます。

コミュニケーションチャネルの違いが、解決時間や担当者の作業量、プロセス全体の効率性にどう影響するかを把握できます。

通常、ケースやチケットのレコードにある標準項目で、リクエストの受付方法を示します。

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

ステータスの変化を分析することは、プロセスフローを把握する主な方法の1つです。「保留中」などの状態にリクエストがどれだけとどまるかを確認でき、外部関係者への依存が明らかになることもあります。また、オープンケースと終了済みケースを区別できるため、対応中の案件数や解決率のレポート作成にも欠かせません。

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

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

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

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

リクエストを種別ごとに分けることで、プロセス経路の違いを把握し、個々の問題に合わせた改善を検討できます。

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

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

プロセス分析では、優先度は絞り込みや比較に使う重要な切り口です。分析担当者は、想定どおり高優先度のリクエストが低優先度のものより早く解決されているか確認できます。優先順位のルールが守られているか、リソース配分が業務上の優先事項に沿っているかの検証にも役立ちます。優先度ごとのプロセスフローを比較すると、重大な問題への対応における非効率な点が明らかになることがあります。

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

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

割り当て先グループは、特定の時点でサービスリクエストを担当するチームや機能部門を示します。「第1階層サポート」「請求部門」「テクニカルサポートチーム」などが該当します。サービスリクエストは、対応の進行に伴って複数のグループ間で引き継がれることがあります。

割り当て先グループを分析すると、チーム間の連携や引き継ぎの状況を把握できます。業務が集中しているチームや、グループ間でボトルネックが発生している箇所、リクエストの種類ごとに組織内をたどる経路を特定できます。こうした情報は、チーム体制、リソース配分、振り分けルールの見直しに役立ちます。

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

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

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

この属性を使うと、個人単位でパフォーマンスや業務量を分析できます。マネージャーは業務の分担状況を確認し、解決時間や顧客満足度などの指標で担当者のパフォーマンスを比較して、研修が必要な領域を特定できます。また、担当者間の引き継ぎを分析する際にも重要です。引き継ぎは遅延や顧客の不満につながることがあります。

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

ケースの割り当て履歴テーブルやイベントログ、またはケースやチケットのメインレコードにある項目です。

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

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

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

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

顧客満足度は、顧客が受けたサービスをどのように評価しているかを測る成果指標です。通常、解決後のアンケートで取得します。1から5までの数値や、「良好」「普通」「不満」などの段階評価が使われます。

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

顧客がサービス品質をどう評価しているかを直接測定し、プロセスの効率性と業務上の成果を結び付けます。

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

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

この属性は、SLAへの適合性チェックに欠かせません。実際の解決時刻とSLA目標時刻を比較することで、組織のSLA達成率を算出できます。さらにプロセスマイニングを使うと、リクエストの種類やプロセスのステップごとに分析し、SLA未達に最も影響している要因を確認できます。サービス上の約束を守るための改善を、対象を絞って進められます。

顧客サービス組織の重要なKPIであるSLAへの適合性を測定するために欠かせません。

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

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

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

サービスリクエストを特定の製品に関連付け、製品改善や根本原因の調査に役立つ情報を提供します。

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

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

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

顧客を軸にプロセスを捉え、特定の顧客に繰り返し発生する問題の特定や重要顧客の管理に役立ちます。

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