カスタマーサービスのデータテンプレート
カスタマーサービスのデータテンプレート
- 収集を推奨する属性
- 追跡すべき主要アクティビティ
- 抽出ガイダンス
カスタマーサービスの属性
| 名前 | 説明 | ||
|---|---|---|---|
|
アクティビティ名
ActivityName
|
サービスリクエストのライフサイクルにおいて、ある時点で発生した特定のイベントまたはタスクの名前です。 | ||
|
説明
この属性は、カスタマーサービスのプロセスにおける特定のステップや状態変更を示します。各アクティビティは、「Agent Accepted Interaction」や「Wrap-Up Code Assigned」など、個別のイベントを表します。これらのアクティビティの順序と頻度を分析することは、プロセスマイニングの基本です。プロセスフローの可視化、逸脱の特定、ボトルネックや非効率なステップの発見に役立ちます。
重要な理由
アクティビティはプロセスマップの基盤となり、実際のプロセスフローを設計上のフローと比較しながら可視化・分析できます。
入手先
通常は、Genesys Cloud CXのシステムイベント、エージェントの状態、特定の監査証跡エントリを標準化されたアクティビティ名に対応付けて作成します。
例
やり取りを開始エージェントがやり取りを受け入れ通話後処理を終了サービスリクエストを再開
|
|||
|
サービスリクエスト
ServiceRequest
|
顧客とのやり取りに関連するすべてのアクティビティを結び付ける主要な識別子です。 | ||
|
説明
サービスリクエストは、チケットまたはケースとも呼ばれ、1件の顧客からの問い合わせや問題を識別する主要な情報です。初回の連絡から最終的な解決まで、関連するすべてのイベントを1つのプロセスインスタンスにまとめます。サービスリクエスト単位で分析すると、顧客の経路と社内での対応プロセスを最初から最後まで把握できます。総解決時間や初回接触での解決率など、主要な指標を計算する基盤にもなります。
重要な理由
すべてのプロセスステップを結び付ける必須のケースIDです。各顧客とのやり取りを開始から終了まで一貫して分析できます。
入手先
概念上のケース識別子です。Genesysでは通常Conversation IDに対応しますが、導入方法によってはカスタム識別子になる場合があります。
例
SR-20240521-00123SR-20240521-00124SR-20240522-00001
|
|||
|
開始時刻
EventTime
|
アクティビティまたはイベントが開始された時点を示すタイムスタンプです。 | ||
|
説明
この属性は、各アクティビティが発生した正確な日時を示します。イベントを正しい順序に並べ、時間に基づく分析を行ううえで欠かせません。開始時刻を使ってプロセスフローを時系列に構成し、アクティビティ間の所要時間、待ち時間、サイクルタイムを計算します。信頼性の高いプロセス分析とパフォーマンス監視には、正確なタイムスタンプが必要です。
重要な理由
このタイムスタンプによってすべてのアクティビティを時系列に並べ、プロセスフロー、所要時間、ボトルネックを正確に分析できます。
入手先
Genesys Cloud CXのイベントログまたはやり取りの詳細に記録されます。通常は、記録された各システムイベントまたはユーザーイベントに関連付けられています。
例
2024-05-21T10:00:15Z2024-05-21T10:02:30Z2024-05-21T10:15:00Z
|
|||
|
ソースシステム
SourceSystem
|
データを抽出したシステムです。 | ||
|
説明
この属性は、イベントデータの発生元システムを示します。この場合はGenesys Cloud CXです。複数のシステムを連携する環境では、データの系譜、トラブルシューティング、データの背景を把握するうえで重要な項目です。正しいデータソースに基づいて分析できるようにし、複数のシステムが1つのプロセスビューにデータを提供する場合のフィルタリングやセグメント化にも役立ちます。
重要な理由
データの発生元を示します。データガバナンス、検証、複数システムのデータ統合に欠かせない情報です。
入手先
通常は、データの抽出・変換処理中に追加する固定値で、レコードの発生元を示します。
例
Genesys Cloud CXGenesysCloudCX_US1Genesys
|
|||
|
最終データ更新日時
LastDataUpdate
|
直近のデータ更新時点を示すタイムスタンプです。 | ||
|
説明
この属性は、ソースシステムからデータセットが最後に更新された時点を示します。分析対象データの鮮度を把握できるため、適時性と関連性のある業務上の意思決定に欠かせません。ダッシュボードやレポートでは、この情報を目立つ位置に表示し、利用者がデータの更新状況と分析結果の妥当性を確認できるようにします。
重要な理由
データの鮮度を示し、最新の情報に基づいて分析や意思決定を行えるようにします。
入手先
通常は、データを抽出する時点、またはプロセスマイニングツールに読み込む時点でデータセットに生成・付与されます。
例
2024-05-23T04:00:00Z2024-05-24T04:00:00Z
|
|||
|
エージェントID
AgentId
|
やり取りまたはアクティビティを担当したエージェントの一意の識別子です。 | ||
|
説明
エージェントIDは、各カスタマーサービス担当者を識別する一意のキーです。この属性は、エージェントのパフォーマンス、業務量の配分、効率に関する分析に欠かせません。プロセスマップを絞り込み、特定のエージェントやチームによるリクエスト対応を確認できます。解決時間、手戻り率、標準手順の遵守状況などのパフォーマンス指標も比較できます。「エージェントのパフォーマンスと効率」ダッシュボードの基盤となる項目です。
重要な理由
この属性はプロセスアクティビティを特定の従業員に関連付け、個人のパフォーマンス、業務量、チームの効率を分析できるようにします。
入手先
Genesys Cloud CXの会話の詳細レコードから取得します。やり取りの特定の区間を担当したユーザーに関連付けられています。
例
a1b2c3d4-e5f6-7890-1234-567890abcdeff0e9d8c7-b6a5-4321-fedc-ba0987654321
|
|||
|
エージェント名
AgentName
|
やり取りまたはアクティビティを担当したエージェントの氏名です。 | ||
|
説明
エージェント名は、エージェントIDに対応する、担当者を人が読み取れる形式で示す識別情報です。この属性により、管理者やチームリーダーはダッシュボードやレポートを直感的に確認できます。エージェント単位の分析で広く使われ、システムIDを照合しなくても、パフォーマンスの確認、研修ニーズの特定、公平な業務量配分を行えます。
重要な理由
エージェントをわかりやすい名前で表示し、技術的なIDを使わずにパフォーマンスを分析したり、結果を共有したりできます。
入手先
Genesys Cloud CXのUsersまたはDirectoryサービスでAgentIdを検索して取得します。
例
John SmithJane DoePeter Jones
|
|||
|
キュー名
QueueName
|
やり取りが振り分けられたキューの名前です。 | ||
|
説明
この属性は、インタラクションがエージェントに割り当てられる前に待機していた特定のキューを識別します。キュー名によるデータ分析は、「サービスキューのボトルネック検出」ダッシュボードに欠かせません。スキルグループやサービスラインごとの業務量の分布、キューごとの待ち時間、継続的に人員不足または過負荷となっているキューを把握できます。この情報は、リソース配分の最適化と顧客の待ち時間短縮に役立ちます。
重要な理由
サービスリクエストが割り当てを待っている場所を示し、ボトルネックの特定と業務量の分布分析に役立ちます。
入手先
Genesys Cloud CXの会話詳細レコードで利用できます。各インタラクションは、1つ以上のキューを通過する場合があります。
例
Tier 1サポート:音声請求に関する問い合わせ:チャットテクニカルサポート:メール
|
|||
|
コミュニケーションチャネル
MediaType
|
インタラクションで使用されたコミュニケーションチャネルです。音声、チャット、メールなどが該当します。 | ||
|
説明
この属性は、顧客とエージェントがコミュニケーションを取った媒体を示します。一般的なチャネルには、音声、チャット、メール、ソーシャルメディアがあります。「コミュニケーションチャネルのパフォーマンス」ダッシュボードのように、チャネル別にパフォーマンスを分析すると、チャネルごとの件数、解決時間、顧客満足度を把握できます。この分析結果は、チャネル戦略とリソース配分の最適化に役立ちます。
重要な理由
コミュニケーションチャネル別にプロセスを分けて分析すると、チャネルごとのパフォーマンス、顧客行動、必要なリソースを把握できます。
入手先
Genesys Cloud CXの会話詳細レコードに含まれる標準フィールドです。
例
音声チャットメールメッセージ
|
|||
|
ラップアップコード
WrapUpCode
|
インタラクションの結果やトピックを分類するため、インタラクションの終了時にエージェントが割り当てるコードです。 | ||
|
説明
ラップアップコードは、顧客とのインタラクションの内容や解決状況を分類するためにエージェントが選択するラベルです。これらのコードにより、顧客がサポートへ連絡した理由を構造化されたデータとして把握できます。ラップアップコードを分析すると、よくある問題の種類、解決結果、特定のリクエストの発生頻度を特定できます。このデータは、根本原因分析やサービス需要の傾向把握に役立ちます。
重要な理由
インタラクションの結果を分類し、よくある問題、解決の有効性、問い合わせ理由を分析するための構造化データを提供します。
入手先
Genesys Cloud CXの会話詳細レコードで利用できます。具体的には、エージェント参加者のセッション詳細に含まれます。
例
パスワードのリセット請求に関する異議申し立ての解決製品情報の問い合わせTier 2へエスカレーション
|
|||
|
終了時刻
EventEndTime
|
アクティビティまたはイベントが終了した時点を示すタイムスタンプです。 | ||
|
説明
この属性は、アクティビティが終了した正確な時点を記録します。開始時刻と組み合わせることで、個々のアクティビティの所要時間を正確に計算できます。アクティビティの所要時間を分析すると、プロセス内で時間を最も消費しているステップを特定でき、非効率や改善機会の発見に役立ちます。たとえば、「やり取りを保留」や「通話後処理」に長い時間がかかっていることを明らかにできます。
重要な理由
個々のアクティビティの所要時間を正確に計算できます。時間のかかるステップやパフォーマンス上のボトルネックを特定するうえで欠かせません。
入手先
Genesys Cloud CXのイベントログまたはやり取りの詳細に記録されます。後続イベントの開始時刻から算出することもできます。
例
2024-05-21T10:02:30Z2024-05-21T10:15:00Z2024-05-21T10:18:45Z
|
|||
|
CSATスコア
CustomerSatisfactionScore
|
インタラクション後のアンケートで顧客が回答した満足度スコアです。 | ||
|
説明
顧客満足度スコア(CSAT)は、提供されたサービスに対する顧客の評価を直接測定する指標です。通常、インタラクションの終了後に送信するアンケートで収集します。CSATスコアをプロセスデータと組み合わせて分析すると、プロセスの違い、解決時間、特定のエージェントが顧客満足度に与える影響を把握できます。プロセス全体の成果を評価するための重要な指標です。
重要な理由
顧客満足度を直接測定し、プロセスのパフォーマンスと顧客の成果を相関分析できます。
入手先
通常、Genesys Cloud CXの品質管理モジュール、またはGenesysと連携したサードパーティ製アンケートツールから取得します。
例
5413
|
|||
|
SLA準拠
IsSlaCompliant
|
サービスリクエストがSLAの目標時間内に解決されたかどうかを示すフラグです。 | ||
|
説明
このブール型属性は、サービスリクエストが解決時間の目標を達成したかどうかを示します。「ServiceResolutionTime」と「SlaTargetResolutionTime」を比較して算出します。このフラグにより、「SLAコンプライアンス概要」ダッシュボードでの分析と可視化が簡単になり、「SLAコンプライアンス率」KPIの算出基準にもなります。準拠ケースと非準拠ケースをすばやくフィルタリングして分けることで、SLA違反に共通するパターンを特定できます。
重要な理由
各ケースがSLAに準拠しているか違反しているかを明確に示し、SLAパフォーマンスの分析と失敗の根本原因分析を簡単にします。
入手先
算出フィールドです。「ServiceResolutionTime <= SlaTargetResolutionTime」の場合はTrue、それ以外はFalseです。
例
truefalse
|
|||
|
SLA目標解決時間
SlaTargetResolutionTime
|
サービスリクエストを解決するために契約上合意された目標時間です。 | ||
|
説明
この属性は、サービスレベル合意書(SLA)に基づき、サービスリクエストの解決に許容される最大時間を定義します。実際の解決時間を測定する際の基準となります。「SLAコンプライアンス概要」ダッシュボードと「SLAコンプライアンス率」KPIに欠かせないデータであり、組織が顧客との約束に沿って対応できているかを監視し、違反が発生する前に可能性を特定できます。
重要な理由
SLAのコンプライアンスを測定する基準となり、サービス品質と契約上の義務を示す重要な指標です。
入手先
会話のカスタム属性として保存するか、キュー、顧客種別、リクエスト種別に関するルールに基づいて算出できます。
例
86400144003600
|
|||
|
サービスリクエストの種類
ServiceRequestType
|
「問い合わせ」、「苦情」、「技術的な問題」など、サービスリクエストの分類です。 | ||
|
説明
この属性は、サービスリクエストの内容や目的に基づいてリクエストを分類します。リクエストの種類ごとに分析を分け、異なる種類のリクエストがどのように処理されているかを把握できます。たとえば、「苦情」と「一般的な問い合わせ」では、プロセスフローや解決時間が大きく異なる場合があります。この項目は、「社内エスカレーション分析」などのダッシュボードで、特定のリクエストがより頻繁にエスカレーションされているかを確認するために重要です。
重要な理由
プロセスを分けて分析できるため、リクエストの種類ごとの処理方法を比較し、種類固有のボトルネックや非効率を特定できます。
入手先
この情報は、IVRでの選択、顧客がWebフォームで選択した内容、またはエージェントによる割り当てから取得できます。Genesysでは、参加者属性またはラップアップコードとして保存できます。
例
請求に関する問い合わせテクニカルサポートアカウント管理製品に関する苦情
|
|||
|
サービス解決時間
ServiceResolutionTime
|
最初の顧客インタラクションの開始から最終的な解決までに経過した合計時間です。 | ||
|
説明
この指標は、顧客が連絡を開始した時点から問題が解決済みと記録されるまで、サービスリクエストにかかった合計時間を測定します。プロセス全体の効率と顧客体験を評価するための主要なKPIです。この算出属性は、「サービスリクエスト解決時間」ダッシュボードと「平均サービス解決時間」KPIの中心となります。分布を分析すると、長期化しているケースや組織的な遅延を特定できます。
重要な理由
プロセス全体の効率と顧客体験への影響を測定するための重要なKPIです。
入手先
算出フィールドです。最終解決アクティビティのタイムスタンプから、最初の顧客連絡アクティビティのタイムスタンプを引いて求めます。
例
90010800172800
|
|||
|
会話ID
ConversationId
|
Genesysが会話全体に割り当てる一意の識別子です。 | ||
|
説明
会話IDは、1つの顧客会話に関連するすべてのインタラクション、セグメント、参加者をまとめるGenesys Cloud CXの主要な技術キーです。概念上の「サービスリクエスト」をケースIDとして使用する一方、Genesys APIから関連データを取得する際には、会話IDが基盤となるキーとして使われます。データ抽出、異なるデータセットの結合、プロセスデータの技術的な検証に欠かせません。
重要な理由
Genesysにおける主要な技術キーです。データ抽出、トラブルシューティング、ソースシステムへの関連付けに欠かせません。
入手先
すべてのGenesys Cloud CX分析APIと会話APIに含まれる主要フィールドです。
例
d8a7c6b5-e4f3-2109-8765-fedcba098765c7b6a5d4-f3e2-1098-7654-edcbaf987654
|
|||
|
再オープン済み
IsReopened
|
解決済みのサービスリクエストが後から再オープンされたかどうかを示すフラグです。 | ||
|
説明
このブール型属性は、解決済みまたはクローズ済みの状態になった後、再びアクティブになったサービスリクエストを示します。再オープンされたケースは、最初の解決策が有効でなかった、または不十分だったことを示す場合があり、顧客の不満や追加作業につながります。この属性は、「サービスリクエスト再オープン傾向」ダッシュボードと「サービスリクエスト再オープン率」KPIで使用します。これらのケースを分析すると、解決が不十分だった根本原因を特定できます。
重要な理由
解決プロセスの失敗を明らかにし、解決策の品質に関する問題、手戻り、顧客体験の低下を示します。
入手先
算出フィールドです。「サービスリクエスト解決済み」アクティビティの後にケースを再びアクティブにするアクティビティを検出して求めます。
例
truefalse
|
|||
|
初回コンタクト解決
IsFirstContactResolution
|
サービスリクエストが1回のインタラクションで解決されたかどうかを示すフラグです。 | ||
|
説明
このブール型属性は、顧客からの追加連絡や社内での転送を必要とせず、初回のインタラクション中に解決されたケースを識別します。値が「true」の場合は、理想的で効率的な解決を意味します。この属性は、「初回コンタクト解決率」KPIと対応するダッシュボードの基礎となります。初回コンタクトで解決できなかったケースの特徴を分析すると、エージェント研修、ナレッジベース、プロセスを改善する機会を見つけられます。
重要な理由
問題を初回で解決することは、良好なサービス体験につながる重要な要因です。効率と顧客満足度を直接測定できます。
入手先
ケースのイベントシーケンスを分析して算出するフィールドです。転送や再オープンなど、特定の中間アクティビティを経ずに解決されたケースをFCRと判定します。
例
truefalse
|
|||
カスタマーサービスのアクティビティ
| アクティビティ | 説明 | ||
|---|---|---|---|
|
エージェントがやり取りを受け入れ
|
エージェントが提示されたやり取りを受け入れ、顧客と接続された時点を示します。サービスリクエストへの直接対応が始まる重要な節目です。 | ||
|
重要な理由
このアクティビティは、初回接触での解決率とエージェントの対応時間を測定するうえで重要です。エージェントによるリクエスト対応の開始を示します。
入手先
会話の詳細レコードから取得できます。エージェント参加者の状態が「connected」に変わった時点と、対応するタイムスタンプで記録されます。
取得
エージェント参加者の状態が「connected」に変わった時点で記録されます。
イベントタイプ
explicit
|
|||
|
やり取りを切断
|
すべての参加者が切断し、会話が終了したことを示します。サービスリクエストのやり取りにおける技術上のクローズとして扱われることが多いイベントです。 | ||
|
重要な理由
やり取り自体の明確な終了イベントです。やり取りの合計時間を計算するうえで重要であり、リクエストのクローズを示す代替指標としてよく使われます。
入手先
会話の詳細レコードから取得します。通常はconversationEndタイムスタンプに記録された、会話オブジェクトの終了時刻に対応します。
取得
すべての参加者が切断し、会話が終了した時点で記録されます。
イベントタイプ
explicit
|
|||
|
やり取りを転送
|
エージェントがやり取りを別のキューまたはエージェントに転送したことを示します。エージェントが直ちに切断するブラインド転送の場合と、転送先の担当者と事前に話す相談転送の場合があります。 | ||
|
重要な理由
このアクティビティは、社内エスカレーション率KPIに欠かせません。転送率が高い場合、研修の必要性、ルーティングの誤り、またはプロセスの複雑さを示している可能性があります。
入手先
会話の詳細レコードで、最初のエージェントの対応後に新しいACD参加者またはエージェント参加者が追加された時点で特定します。多くの場合、「transfer」イベントによって開始されます。
取得
参加者のセッションデータにあるtransferイベントから特定します。
イベントタイプ
explicit
|
|||
|
やり取りを開始
|
このアクティビティは、着信、チャット、メールなど、顧客とのやり取りの開始を示します。Genesys Cloud CXでは、システム内に新しい会話オブジェクトが作成された時点で、このイベントが明示的に記録されます。 | ||
|
重要な理由
サービスリクエストプロセスの主要な開始イベントです。総解決時間の計算や、顧客からの問い合わせ需要のパターンを把握するうえで欠かせません。
入手先
会話の詳細レコードから取得されます。通常はconversationStartタイムスタンプに記録された、会話オブジェクト自体の開始時刻に対応します。
取得
システム内で新しい会話が開始された時点で記録されます。
イベントタイプ
explicit
|
|||
|
ラップアップコードを割り当て
|
エージェントがあらかじめ定義されたラップアップコード、または処理結果コードをやり取りに割り当てます。「解決済み」や「エスカレーション済み」など、サービスリクエストの結果を明示的に分類します。 | ||
|
重要な理由
ラップアップコードは、リクエストの業務上の結果を判断する主要な情報源です。解決率の計算や、分析対象となるケースの分類に欠かせません。
入手先
会話の詳細レコード、通常はエージェント参加者のセッションデータに記録される明示的なイベントです。wrapUpコードとタイムスタンプが記録されます。
取得
エージェントがやり取りにラップアップコードを選択した時点で記録されます。
イベントタイプ
explicit
|
|||
|
エージェントにやり取りを提示
|
システムが特定のエージェントにやり取りを提示した時点で発生します。エージェントが会話を受け入れるか拒否するまで、システムによってエージェントのステータスが「alerting」に変更されます。 | ||
|
重要な理由
このアクティビティにより、エージェントの応答性とルーティングアルゴリズムの有効性を分析できます。この時点以降の遅延は、エージェントが業務を速やかに受け入れていない可能性を示します。
入手先
会話の詳細レコードにあるエージェントの参加者データから取得します。参加者のセッションには、「alerting」状態のメトリクスと対応するタイムスタンプが記録されます。
取得
ルーティングエンジンがエージェントに新しいやり取りを通知した時点で記録されます。
イベントタイプ
explicit
|
|||
|
サービスリクエストを再開
|
解決済みと判断された直後に、顧客が同じ問題についてサービスセンターへ再度連絡した状況を示します。明示的なイベントではなく、業務ロジックに基づいて計算されます。 | ||
|
重要な理由
再開されたリクエストを追跡することは、サービスリクエスト再開率の測定に欠かせません。初回の解決が有効でなかったことを示し、顧客満足度と業務効率に影響します。
入手先
以前のやり取りが解決された後、あらかじめ定めた期間内に、同じ顧客(Customer ID)から同じ問題(例:Service Request Type)に関する新しい「やり取りを開始」イベントが発生したことを特定して推定します。
取得
同じ顧客と問題について、新しいやり取りを直近でクローズされたやり取りに関連付けて計算します。
イベントタイプ
calculated
|
|||
|
やり取りの保留を解除
|
エージェントが顧客の保留を解除し、会話を再開した時点で発生します。保留期間の終了を示すイベントであり、状態変更として記録されます。 | ||
|
重要な理由
「やり取りを保留」と組み合わせることで、保留時間の合計を正確に計算できます。これは対応時間全体と顧客体験を評価するうえで重要な要素です。
入手先
エージェント参加者のセッションデータで、状態が「held」から「connected」に戻った時点から取得します。
取得
エージェント参加者の状態が「held」から「connected」に変わった時点で記録されます。
イベントタイプ
explicit
|
|||
|
やり取りを保留
|
エージェントがやり取り中に顧客を保留にした時点で記録されます。会話内のエージェント参加者における明示的な状態変更です。 | ||
|
重要な理由
保留の頻度と時間を分析すると、エージェントが情報を探したり、他の担当者に確認したりする必要が頻繁に生じるなど、プロセスの非効率を明らかにできます。
入手先
会話の詳細レコードにあるエージェント参加者のセッションデータから取得します。状態が「held」に変わり、タイムスタンプが記録されます。
取得
エージェント参加者の状態が「held」に変わった時点で記録されます。
イベントタイプ
explicit
|
|||
|
会話をキューに振り分け
|
新しいやり取りが特定のキューに入り、対応可能なエージェントを待つ時点を示します。Genesysのルーティングエンジン(ACD)が明示的に記録するイベントです。 | ||
|
重要な理由
このアクティビティを追跡することは、キュー待ち時間の測定とルーティングプロセスのボトルネック特定に欠かせません。このイベントからエージェントの割り当てまでの時間が長い場合、要員配置やルーティングロジックに問題がある可能性があります。
入手先
会話の詳細レコードから取得します。会話内のACD参加者の「purpose」と「state」を確認し、metrics配列内のキューの「enterTime」からこのイベントを特定します。
取得
ACDルーティングエンジンが会話をキューに入れた時点で記録されます。
イベントタイプ
explicit
|
|||
|
通話後処理を終了
|
エージェントの通話後処理期間の終了を示します。この時点でエージェントは別のやり取りに対応できる状態になります。 | ||
|
重要な理由
このアクティビティを「通話後処理を開始」と組み合わせることで、ラップアップ段階の時間を正確に把握できます。エージェントの生産性やプロセスにかかる間接的な負荷の分析に役立ちます。
入手先
エージェントの状態が「acw」から「idle」などの対応可能な状態に変わった時点から推定します。この状態変更のタイムスタンプを使用します。
取得
エージェントの状態が「acw」から対応可能な状態に変わった時点から推定します。
イベントタイプ
inferred
|
|||
|
通話後処理を開始
|
通話後処理(ACW)期間の開始を示します。エージェントは顧客との接続を切断した後、メモの記録やシステムの更新などの作業を行う専用状態になります。 | ||
|
重要な理由
ACWの時間を測定することは、エージェントの効率と対応時間全体を把握するうえで重要です。ACWが長い場合、やり取り後のプロセスが非効率である可能性があります。
入手先
エージェント参加者のセッションデータから取得します。顧客参加者が切断された後、エージェントの状態が「acw」に変わった時点で記録されます。
取得
エージェント参加者の状態が「acw」に変わった時点で記録されます。
イベントタイプ
explicit
|
|||
|
顧客満足度アンケートを送信
|
やり取りのクローズ後に顧客満足度(CSAT)アンケートを送信した時点で発生します。通常は、あらかじめ定めたルールに基づいてシステムが自動的に実行します。 | ||
|
重要な理由
このアクティビティは、CSATアンケート配信の適時性KPIを測定するために必要です。アンケートを速やかに配信することで、顧客の記憶が新しいうちに正確なフィードバックを収集できます。
入手先
通常はGenesys Cloud CXのアンケートデータまたは品質管理データから取得し、元の会話IDに関連付けます。
取得
特定の会話に対してアンケートが配信された時点で、アンケートモジュールによって記録されます。
イベントタイプ
explicit
|
|||
抽出ガイド
準備はできましたか?
カスタマーサービス業務の可能性を最大限に引き出します。このテンプレートに沿って進めることで、課題を明らかにし、効率を高めるための取り組みを着実に進められます。
繰り返しの問い合わせを減らし、今すぐカスタマーサービスを向上
CSATを向上させ、初回対応での解決率80%を無理なく達成します。
クレジットカードは不要です。数分でトライアルを開始できます。