您的客户服务数据模板
您的客户服务数据模板
- 建议收集的属性
- 需要追踪的关键活动
- 提取指南
客户服务属性
| 名称 | 描述 | ||
|---|---|---|---|
|
开始时间
EventTime
|
指示某项活动或事件开始的时间戳。 | ||
|
描述
该属性提供每项活动发生的精确日期和时间。它对于正确排序事件以及所有基于时间的分析都必不可少。开始时间用于按时间顺序构建流程,并且是计算不同活动之间时长、等待时间和周期时间的基础。准确的时间戳对于可靠的流程分析和绩效监控至关重要。
为何重要
此时间戳按时间顺序排列所有活动,从而能够准确分析流程、时长和瓶颈。
获取方式
可在 Genesys Cloud CX 的事件日志或交互详情中找到,通常与每条记录的系统或用户 event 相关联。
示例
2024-05-21T10:00:15Z2024-05-21T10:02:30Z2024-05-21T10:15:00Z
|
|||
|
服务请求
ServiceRequest
|
客户服务互动的核心标识,关联了所有相关的活动。 | ||
|
描述
服务请求(通常称为工单或 Case)是单次客户咨询或问题的核心标识。它将从最初联系到最终解决的所有相关事件归为一个流程实例。按服务请求进行分析,可以获得客户旅程和内部处理流程的完整端到端视角。它是计算总解决时长和首次解决率等关键指标的基础。
为何重要
这是连接所有流程步骤的关键 Case ID,使您能够对从开始到结束的每次客户互动进行全面分析。
获取方式
这是概念上的 Case ID。在 Genesys 中,这通常对应于 Conversation ID,但根据实施情况,也可能是一个自定义标识。
示例
SR-20240521-00123SR-20240521-00124SR-20240522-00001
|
|||
|
活动名称
ActivityName
|
在服务请求生命周期的某个时间点发生的特定事件或任务的名称。 | ||
|
描述
该属性描述了客户服务流程中的特定步骤或状态变更。每项活动代表一个独立事件,例如“坐席接受互动”或“已分配 Wrap-Up Code”。分析这些活动的顺序和频率是流程挖掘的基础。它有助于可视化流程流向、识别偏差并精准定位瓶颈或低效步骤。
为何重要
Activity 构成了流程图的骨架,让您可以将实际流程与设计流程进行可视化对比分析。
获取方式
这通常是通过将 Genesys Cloud CX 中的系统事件、坐席状态或特定审计轨迹条目映射到标准活动名称来派生的。
示例
交互已开始坐席已接受交互通话后处理已结束服务请求已重新开启
|
|||
|
最后数据更新
LastDataUpdate
|
最近一次数据刷新的时间戳。 | ||
|
描述
该属性指示了数据集从源系统更新的最后时间。它提供了所分析数据的新鲜度背景,这对于做出及时且相关的业务决策至关重要。仪表板和报告应突出显示此信息,以便用户了解数据的时效性并评估见解的有效性。
为何重要
指示 data 的新鲜度,确保分析和决策基于最新信息。
获取方式
此值在数据提取或加载到流程挖掘工具时生成并标记在数据集上。
示例
2024-05-23T04:00:00Z2024-05-24T04:00:00Z
|
|||
|
源系统
SourceSystem
|
数据提取来源系统。 | ||
|
描述
该属性标识事件数据的来源系统,在本例中为 Genesys Cloud CX。在包含多个集成系统的环境中,此字段对于数据血缘、故障排除和理解数据背景至关重要。它有助于确保分析基于正确的数据源,并允许在多个系统共同构成单一流程视图时过滤或细分数据。
为何重要
识别 data 来源,这对于数据治理、验证以及合并来自多个系统的 data 至关重要。
获取方式
这通常是在数据提取和转换过程中添加的静态值,用于标记记录的来源。
示例
Genesys Cloud CXGenesysCloudCX_US1Genesys
|
|||
|
Wrap-Up Code
WrapUpCode
|
坐席在交互结束时分配的代码,用于对结果或主题进行分类。 | ||
|
描述
Wrap-Up Code 是坐席选择的标签,用于对客户互动的性质或解决结果进行分类。这些代码提供了有关客户联系支持原因的结构化数据。分析 Wrap-Up Code 有助于识别常见问题类型、追踪解决结果并衡量特定请求的频率。这些数据对于根因分析和理解服务需求模式非常有价值。
为何重要
对交互结果进行分类,为分析常见问题、解决有效性和联系原因提供结构化 data。
获取方式
可在 Genesys Cloud CX 会话详情记录中找到,具体位于坐席参与者的会话详情中。
示例
密码重置账单争议已解决产品信息咨询已升级至二线支持
|
|||
|
坐席 ID
AgentId
|
处理该互动或活动的坐席唯一标识符。 | ||
|
描述
Agent ID 是每个客户服务代表的唯一密钥。该属性对于任何与坐席绩效、工作量分配和效率相关的分析都至关重要。它允许您过滤流程图以观察特定坐席或团队处理请求的方式,并对比其绩效指标(如解决时间、重做率以及对标准流程的遵守情况)。这是“坐席绩效与效率”仪表板的基石。
为何重要
该属性将流程活动连接到特定员工,从而实现对个人绩效、工作量和团队效率的分析。
获取方式
可从 Genesys Cloud CX 会话详情记录中获取,关联至处理该交互环节的用户。
示例
a1b2c3d4-e5f6-7890-1234-567890abcdeff0e9d8c7-b6a5-4321-fedc-ba0987654321
|
|||
|
沟通渠道
MediaType
|
互动所使用的沟通渠道,例如语音、聊天或邮件。 | ||
|
描述
该属性指定了客户与坐席沟通的媒介。常见渠道包括语音、聊天、邮件和社交媒体。正如“沟通渠道绩效”仪表板所示,按渠道分析绩效有助于企业了解各渠道特有的业务量、解决时长和客户满意度。这种洞察对于优化渠道策略和资源配置至关重要。
为何重要
按沟通渠道细分流程,对于理解各渠道特有的绩效表现、客户行为和资源需求至关重要。
获取方式
Genesys Cloud CX 会话详情记录中的标准字段。
示例
voicechatemailmessage
|
|||
|
经办人姓名
AgentName
|
处理该互动或活动的坐席全名。 | ||
|
描述
Agent Name 提供了对应于 Agent ID 的易读标识。该属性使仪表板和报告对经理和团队主管来说更加直观。它广泛应用于以坐席为中心的分析,用于审查绩效、识别培训需求并确保工作量公平分配,而无需反复比对系统 ID。
为何重要
提供坐席的易读名称,使分析绩效和传达发现更加直观,无需查阅复杂的技术 ID。
获取方式
通过在 Genesys Cloud CX 的用户或目录服务中查询 AgentId 获取。
示例
约翰·史密斯Jane DoePeter Jones
|
|||
|
结束时间
EventEndTime
|
指示活动或事件结束的时间戳。 | ||
|
描述
该属性记录活动结束的精确时刻。配合开始时间,它可以精确计算每项独立活动的持续时长。分析活动时长是识别流程中哪些步骤最耗时的关键,有助于发现低效环节和优化机会。例如,它可以突出显示过长的“通话等待”时间或过长的“通话后处理”时长。
为何重要
支持精确计算单个 Activity 的持续时间,这对于识别耗时步骤和性能瓶颈至关重要。
获取方式
可在 Genesys Cloud CX 的事件日志或交互详情中找到。也可以通过后续 event 的开始时间推导得出。
示例
2024-05-21T10:02:30Z2024-05-21T10:15:00Z2024-05-21T10:18:45Z
|
|||
|
队列名称
QueueName
|
互动路由至的队列名称。 | ||
|
描述
该属性标识了互动在分配给坐席之前所等待的特定队列。按队列名称分析数据对于“服务队列瓶颈检测”仪表板至关重要。它能帮助经理了解不同技能组或服务线的工作量分配,衡量每个队列的等待时间,并识别始终人手不足或超负荷的队列。这些信息是优化资源配置和缩短客户等待时间的关键。
为何重要
通过展示服务请求在何处等待分配,帮助识别瓶颈并分析工作负载分布。
获取方式
可从 Genesys Cloud CX 会话详情记录中获取。每个交互可能流经一个或多个队列。
示例
一线支持 - 语音账单查询 - 在线聊天技术支持 - 邮件
|
|||
|
Conversation ID
ConversationId
|
Genesys 为整个对话分配的唯一标识符。 | ||
|
描述
Conversation ID 是 Genesys Cloud CX 中的核心技术密钥,它将单次客户对话中所有相关的互动、片段和参与者分在一组。虽然概念上的“服务请求”被用作 Case ID,但 Conversation ID 是用于从 Genesys API 检索所有相关数据的底层密钥。它对于数据提取、整合不同数据集以及对流程数据进行技术验证至关重要。
为何重要
这是 Genesys 中的核心技术密钥,对于数据提取、故障排除以及追溯到源系统至关重要。
获取方式
这是所有 Genesys Cloud CX 分析和对话 API 中的核心字段。
示例
d8a7c6b5-e4f3-2109-8765-fedcba098765c7b6a5d4-f3e2-1098-7654-edcbaf987654
|
|||
|
CSAT 评分
CustomerSatisfactionScore
|
客户在互动后调查中提供的满意度评分。 | ||
|
描述
客户满意度评分(CSAT)是衡量客户对所接受服务感知的直接指标。通常在互动关闭后通过调查问卷收集。结合流程数据分析 CSAT 评分,可以揭示流程变动、解决时长或特定坐席如何影响客户幸福感。这是评估整体流程成功与否的关键结果指标。
为何重要
直接衡量客户满意度,支持对流程绩效与客户结果之间的关联性进行分析。
获取方式
这些数据通常来自 Genesys Cloud CX 的质量管理模块或与 Genesys 集成的第三方调查工具。
示例
5413
|
|||
|
SLA 目标解决时间
SlaTargetResolutionTime
|
合同约定的服务请求解决目标时间。 | ||
|
描述
该属性根据服务等级协议 (SLA) 定义了服务请求解决的最长允许时间。它作为衡量实际解决时间的基准。这些数据对于“SLA 合规性概览”仪表板和“SLA 合规率”KPI 至关重要,使企业能够根据对客户的承诺监控绩效,并在违规发生前识别潜在风险。
为何重要
为衡量 SLA 合规性提供基准,这是衡量服务绩效和履行合同义务的关键指标。
获取方式
这可能存储为对话上的自定义属性,也可能根据涉及队列、客户类型或请求类型的规则派生。
示例
86400144003600
|
|||
|
处理时间
Duration
|
完成单项活动所需的时间(以秒为单位)。 | ||
|
描述
该属性量化了单个流程步骤的时长,计算方式为结束时间与开始时间的差值。分析处理时间有助于识别哪些活动最耗时。这些信息对于绩效仪表板(如“坐席绩效与效率”仪表板)评估坐席效率并寻找培训或流程改进机会至关重要。
为何重要
量化每项活动所花费的时间,有助于精准发现效率低下的环节,并在细粒度层面上衡量绩效。
获取方式
计算字段:EventEndTime - EventTime。部分 Genesys API 可能会直接提供特定环节的持续时间字段。
示例
12075045
|
|||
|
是否为首呼解决
IsFirstContactResolution
|
指示该服务请求是否在单次交互中解决的标志。 | ||
|
描述
该布尔属性识别出在首次互动中即被解决的 case,无需客户跟进或内部转接。“true”值代表理想、高效的解决。该属性是“首次解决率 (FCR)”KPI 及其对应仪表板的基础。分析未能在首次解决的 case 特征,可以发现坐席培训、知识库改进或流程变革的机会。
为何重要
直接衡量效率和客户满意度,因为首次即解决问题是提供优质服务体验的核心驱动力。
获取方式
计算字段,通过分析 case 的 event 序列得出。如果 case 在解决过程中没有发生转接或重新开启等特定 Activity,则视为 FCR。
示例
truefalse
|
|||
|
是否符合SLA
IsSlaCompliant
|
指示服务请求是否在 SLA 目标时间内解决的标志。 | ||
|
描述
该布尔属性指示服务请求是否达到了解决时长目标。它是通过对比“服务解决时长”和“SLA 目标解决时长”计算得出的。此标记简化了“SLA 合规性概览”仪表板的分析和可视化,也是计算“SLA 合规率”KPI 的基础。它允许快速过滤和细分合规与违规 case,从而识别 SLA 违规中的共同模式。
为何重要
通过清晰标注每个 case 是否符合 SLA 或已违规,简化 SLA 绩效分析,从而实现故障根因分析。
获取方式
计算字段:如果服务解决时间 <= SLA 目标解决时间,则为 True,否则为 False。
示例
truefalse
|
|||
|
是否重新打开
IsReopened
|
指示已解决的服务请求随后是否被重新开启的标志。 | ||
|
描述
该布尔属性标记了曾被设为“已解决”或“已关闭”状态,但随后又重新变为“活跃”的服务请求。重新开启的 case 通常意味着最初的解决方案无效或不完整,会导致客户不满并产生额外工作量。此属性为“服务请求重新开启趋势”仪表板和“服务请求重新开启率”KPI 提供支持。分析这些 case 有助于识别无效解决的根因。
为何重要
突出显示解决流程中的失败环节,指出解决方案质量问题,这些问题会导致返工和糟糕的客户体验。
获取方式
计算字段,通过检测在“服务请求已解决” Activity 之后使 case 重新进入活跃状态的 Activity 得出。
示例
truefalse
|
|||
|
服务解决时长
ServiceResolutionTime
|
从客户第一次发起互动到最终解决所经历的总时长。 | ||
|
描述
此指标衡量服务请求的总时长,从客户发起联系的那一刻起,直到问题被标记为已解决。它是衡量整体流程效率和客户体验的关键绩效指标。该计算属性是“服务请求解决时长”仪表板和“平均服务解决时长”KPI 的核心。分析其分布有助于识别耗时过长的 case 和系统性延迟。
为何重要
这是衡量整体流程效率及其对客户体验影响的关键 KPI。
获取方式
计算字段:最终解决 Activity 的 timestamp 减去首次客户接触 Activity 的 timestamp。
示例
90010800172800
|
|||
|
服务请求类型
ServiceRequestType
|
服务请求的分类,例如“咨询”、“投诉”或“技术问题”。 | ||
|
描述
该属性根据服务请求的性质或目的对其进行分类。它允许通过细分分析来了解不同类型的请求是如何处理的。例如,“投诉”的流程和解决时间可能与“一般咨询”有很大不同。这一维度对于“内部升级分析”等仪表板至关重要,可以查看某些请求类型是否更容易被升级。
为何重要
支持流程细分,以便对比不同类型的请求处理方式,并识别特定类型下的瓶颈或低效点。
获取方式
这些信息可能通过 IVR 选择、客户在网页表单上的选择捕获,或由坐席分配。在 Genesys 中,它可以存储为参与者属性或 Wrap-Up Code。
示例
账单查询技术支持账户管理产品投诉
|
|||
客户服务 Activity 一览
| 活动 | 描述 | ||
|---|---|---|---|
|
交互已开始
|
此活动标志着客户服务互动的开始,如呼入通话、聊天或邮件。当系统创建新的对话对象时,Genesys Cloud CX 会明确记录此事件。 | ||
|
为何重要
这是服务请求流程的核心起始事件。它对于计算总解决时长和理解呼入客户需求模式至关重要。
获取方式
此事件从对话详情记录中捕获。它对应于对话对象本身的开始时间,通常位于 conversationStart 时间戳中。
捕获
当系统中发起新会话时记录。
事件类型
explicit
|
|||
|
交互已断开
|
此活动表示对话结束,此时所有参与者均已断开连接。这通常被视为服务请求互动的技术性结案。 | ||
|
为何重要
这是互动本身的最终结束事件。它对于计算总互动时长至关重要,且通常被用作请求结案的代理指标。
获取方式
此数据从对话详情记录中捕获。它对应于对话对象的结束时间,通常位于 conversationEnd 时间戳中。
捕获
当所有参与者都断开连接且会话结束时记录。
事件类型
explicit
|
|||
|
交互已转接
|
表示坐席将互动转移到另一个队列或坐席。这可以是坐席立即断开连接的盲转,也可以是先与接收者沟通的咨询转接。 | ||
|
为何重要
此活动对“内部升级率”这一 KPI 至关重要。高转接率可能意味着培训需求、错误的路由设置或流程过于复杂。
获取方式
当在初始坐席介入后,又有新的 ACD 或坐席参与者加入对话(通常由“转接”事件发起)时,系统会在对话详情记录中识别到此情况。
捕获
通过参与者会话 data 中的转接 event 来识别。
事件类型
explicit
|
|||
|
坐席已接受交互
|
标志着坐席接受互动并与客户建立连接的时刻。这是开始直接处理服务请求的关键里程碑。 | ||
|
为何重要
此活动对于衡量首次解决率和坐席处理时间至关重要。它标志着坐席开始处理该请求。
获取方式
可在会话详情记录中找到。以坐席参与者状态变为“已连接”为标志,并带有相应的 timestamp。
捕获
当坐席参与者状态变为 “connected” 时记录。
事件类型
explicit
|
|||
|
已分配 Wrap-Up Code
|
坐席为交互分配预定义的完成代码或处置代码。这明确了服务请求的结果类别,例如“已解决”或“已升级”。 | ||
|
为何重要
Wrap-up code 是确定请求业务结果的核心依据。它们对于计算解决率和细分 case 进行分析至关重要。
获取方式
这是在对话详情记录中发现的显式事件,通常位于坐席参与者的会话数据中。wrapUp 代码和时间戳都会被记录。
捕获
当坐席为交互选择完成代码时记录。
事件类型
explicit
|
|||
|
交互已取消保持状态
|
当坐席结束等待状态并恢复与客户的对话时触发。此事件标志着等待期的结束,并在系统中记录为状态变更。 | ||
|
为何重要
与“互动进入等待状态”配合使用,该活动可精确计算总等待时长,这是衡量整体处理时间及客户体验的关键指标。
获取方式
源自坐席参与者的会话 data,记录其状态从 “held” 回到 “connected” 的时刻。
捕获
当坐席参与者状态从 “held” 变为 “connected” 时记录。
事件类型
explicit
|
|||
|
交互已置于保持状态
|
当坐席在互动过程中让客户处于等待状态时记录。这是对话中坐席参与者的显式状态变更。 | ||
|
为何重要
通过分析“保持”状态的频率和时长,可以发现流程中的效率漏洞,例如坐席是否频繁因查找信息或咨询他人而中断服务。
获取方式
从会话详情记录中的坐席参与者会话 data 提取。当状态变为 “held” 时,记录对应的 timestamp。
捕获
当坐席参与者状态变为 “held” 时记录。
事件类型
explicit
|
|||
|
会话已路由至队列
|
代表新互动进入特定队列等待可用坐席的时刻。这是由 Genesys 路由引擎 (ACD) 记录的显式事件。 | ||
|
为何重要
追踪此活动对于衡量队列等待时间和识别路由过程中的瓶颈至关重要。此活动与坐席分配之间的时间间隔过长,通常预示着人员配置或路由逻辑存在问题。
获取方式
从会话详情记录中提取,具体查看会话中 ACD 参与者的 “purpose” 和 “state”。指标数组中的队列 “enterTime” 标记了此 event。
捕获
当 ACD 路由引擎将会话置入队列时记录。
事件类型
explicit
|
|||
|
向坐席分配交互
|
当系统向特定坐席提供互动时触发。当系统等待坐席接受或拒绝对话时,坐席状态变更为“alerting (提醒中)”。 | ||
|
为何重要
此活动有助于分析坐席响应速度和路由算法的有效性。此时点后的延迟可能表明坐席未能及时接受任务。
获取方式
可在会话详情记录的坐席参与者 data 中找到。参与者的会话将显示状态为 “alerting” 的指标及相应的 timestamp。
捕获
当路由引擎提醒坐席有新交互时记录。
事件类型
explicit
|
|||
|
客户满意度调查已发送
|
此活动在互动关闭后发送客户满意度 (CSAT) 调查时发生。这通常由系统根据预设规则自动触发。 | ||
|
为何重要
此活动对于衡量“CSAT 调查发送及时性”KPI 是必要的。确保及时发送调查有助于在客户记忆犹新时捕获最准确的反馈。
获取方式
这些信息通常可从 Genesys Cloud CX 内的调查或质量管理数据中获得,并可关联回原始会话 ID。
捕获
当针对特定会话派发调查时,由调查模块记录。
事件类型
explicit
|
|||
|
服务请求已重新开启
|
表示客户在问题被视为已解决后不久,再次就同一问题联系服务中心的情况。这并非显式事件,而是基于业务逻辑计算得出的。 | ||
|
为何重要
追踪重新开启的请求是衡量“服务请求重新开启率”的关键。它表明初始解决无效,从而影响客户满意度和运营效率。
获取方式
该活动是通过在先前互动解决后的预设时间窗口内,识别到同一客户(Customer ID)针对相关问题(如服务请求类型)发起的新“互动开始”事件推断出来的。
捕获
通过将新交互与同一客户及问题的近期关闭记录进行关联计算得出。
事件类型
calculated
|
|||
|
通话后处理已开始
|
此活动标志着通话后处理 (ACW) 阶段的开始。坐席已与客户断开连接,但目前处于专门状态以完成记笔录或更新系统等任务。 | ||
|
为何重要
衡量 ACW (通话后处理) 时长对于了解坐席效率和整体处理时间至关重要。ACW 时间过长可能预示着后期处理流程效率低下。
获取方式
从坐席参与者的会话 data 中获取。在客户断开连接后,坐席状态变为 “acw” 时记录。
捕获
当坐席参与者状态变为 “acw” 时记录。
事件类型
explicit
|
|||
|
通话后处理已结束
|
这标志着坐席通话后处理阶段的结束。此时,坐席变更为可用状态,可以处理另一次互动。 | ||
|
为何重要
此活动与“开始通话后处理”相结合,可提供整理阶段的精确时长,有助于分析坐席生产力和流程开销。
获取方式
当坐席状态从“acw”变更为“idle (空闲)”等可用状态时推断得出。系统将采用此状态变更的时间戳。
捕获
通过坐席状态从 “acw” 变为就绪状态推断得出。
事件类型
inferred
|
|||