您的客户服务数据模板
您的客户服务数据模板
- 建议采集的属性
- 需要跟踪的关键活动
- 数据提取指南
客户服务属性
| 名称 | 说明 | ||
|---|---|---|---|
|
开始时间
EventTime
|
活动或事件开始时的时间戳。 | ||
|
说明
此属性记录每项活动发生的准确日期和时间,对于正确排列事件顺序及开展所有基于时间的分析至关重要。开始时间用于按时间顺序构建流程路径,也是计算不同活动之间持续时间、等待时间和周期时间的依据。准确的时间戳是可靠开展流程分析和绩效监控的关键。
重要性
此时间戳按时间顺序排列所有活动,从而准确分析流程路径、持续时间和瓶颈。
获取途径
可在Genesys Cloud CX的事件日志或交互详情中找到,通常与每条已记录的系统事件或用户事件相关联。
示例
2024-05-21T10:00:15Z2024-05-21T10:02:30Z2024-05-21T10:15:00Z
|
|||
|
服务请求
ServiceRequest
|
客户服务交互的主要标识符,用于关联所有相关活动。 | ||
|
说明
服务请求通常也称为工单或案例,是单个客户咨询或问题的主要标识符。它将从首次联系到最终解决的所有相关事件归入同一个流程实例。按服务请求进行分析,可以完整了解客户旅程和内部处理过程。这也是计算总解决时间和首次联系解决率等关键指标的基础。
重要性
这是关键的案例ID,用于关联所有流程步骤,从头到尾全面分析每次客户交互。
获取途径
这是概念上的案例标识符。在Genesys中,它通常对应对话ID,但具体取决于实施方式,也可能是自定义标识符。
示例
SR-20240521-00123SR-20240521-00124SR-20240522-00001
|
|||
|
活动名称
ActivityName
|
服务请求生命周期中某个时间点发生的具体事件或任务名称。 | ||
|
说明
此属性描述客户服务流程中的具体步骤或状态变更。每项活动都代表一个独立事件,例如“坐席接受交互”或“分配结束代码”。分析这些活动的顺序和频率是流程挖掘的基础,有助于呈现流程的实际流转情况、识别偏差,并找出瓶颈或低效步骤。
重要性
活动构成流程图的基础,可用于呈现和分析实际流程与设计流程之间的差异。
获取途径
通常通过将Genesys Cloud CX中的系统事件、坐席状态或特定审计跟踪记录映射为标准化活动名称得出。
示例
交互开始坐席接受交互通话后处理结束服务请求重新打开
|
|||
|
最近数据更新时间
LastDataUpdate
|
最近一次数据刷新的时间戳。 | ||
|
说明
此属性表示数据集最近一次从源系统更新的时间,可帮助您判断所分析数据的新鲜度,从而及时作出相关业务决策。仪表板和报告应醒目显示此信息,让用户了解数据的时效性,并评估分析结果是否有效。
重要性
显示数据的新鲜度,确保分析和决策基于最新信息。
获取途径
此值在提取数据或将数据加载到流程挖掘工具时生成,并写入数据集。
示例
2024-05-23T04:00:00Z2024-05-24T04:00:00Z
|
|||
|
源系统
SourceSystem
|
数据提取自哪个系统。 | ||
|
说明
此属性标识事件数据的来源,本例中为Genesys Cloud CX。在集成多个系统的环境中,此字段对于追踪数据来源、排查问题和了解数据背景至关重要。它有助于确保分析使用正确的数据源;当多个系统共同构成一个流程视图时,也可用于筛选或细分数据。
重要性
标识数据来源,对于数据治理、验证以及合并多个系统的数据至关重要。
获取途径
通常在数据提取和转换过程中添加固定值,用于标记记录来源。
示例
Genesys Cloud CXGenesysCloudCX_US1Genesys
|
|||
|
坐席ID
AgentId
|
处理交互或活动的坐席唯一标识符。 | ||
|
说明
坐席ID是每位客服代表的唯一标识。分析坐席绩效、工作量分配和效率时,离不开此属性。您可以按坐席或团队筛选流程图,了解他们如何处理请求,并比较解决时间、返工率和标准流程遵循情况等指标。这也是“坐席绩效与效率”仪表板的核心数据。
重要性
此属性将流程活动关联到具体员工,便于分析个人绩效、工作量和团队效率。
获取途径
可在Genesys Cloud CX对话详情记录中找到,与处理交互特定片段的用户相关联。
示例
a1b2c3d4-e5f6-7890-1234-567890abcdeff0e9d8c7-b6a5-4321-fedc-ba0987654321
|
|||
|
坐席姓名
AgentName
|
处理交互或活动的坐席全名。 | ||
|
说明
坐席姓名是与坐席ID对应的易读标识,便于管理者和团队负责人查看仪表板和报告。坐席分析会广泛使用此属性来评估绩效、发现培训需求并公平分配工作量,无需再查找系统ID。
重要性
显示坐席姓名,便于您分析绩效和交流发现,无需使用技术ID。
获取途径
通过查询AgentId,从Genesys Cloud CX的Users或Directory服务中获取。
示例
约翰·史密斯简·多伊彼得·琼斯
|
|||
|
沟通渠道
MediaType
|
交互使用的沟通渠道,例如语音、聊天或电子邮件。 | ||
|
说明
此属性指定客户与坐席沟通所用的渠道,常见渠道包括语音、聊天、电子邮件和社交媒体。像“沟通渠道绩效”仪表板一样,按渠道分析绩效有助于企业了解各渠道的交互量、解决时间和客户满意度。这些信息对优化渠道策略和资源分配至关重要。
重要性
按沟通渠道细分流程,有助于了解各渠道的绩效、客户行为和资源需求。
获取途径
Genesys Cloud CX对话详情记录中的标准字段。
示例
语音聊天电子邮件消息
|
|||
|
结束代码
WrapUpCode
|
坐席在交互结束时分配的代码,用于归类交互结果或主题。 | ||
|
说明
结束代码是坐席选择的标签,用于归类客户交互的性质或处理结果。这些代码以结构化数据记录客户联系支持团队的原因。分析结束代码有助于识别常见问题类型、跟踪处理结果并统计特定请求的频率。这些数据有助于开展根因分析并了解服务需求模式。
重要性
归类交互结果,为分析常见问题、解决效果和联系原因提供结构化数据。
获取途径
可在Genesys Cloud CX对话详情记录中找到,具体位于坐席参与者的会话详情中。
示例
密码重置账单争议已解决产品信息咨询已升级至二级支持
|
|||
|
结束时间
EventEndTime
|
表示活动或事件结束时间的时间戳。 | ||
|
说明
此属性记录活动结束的准确时间。结合开始时间,可精确计算每项活动的持续时间。分析活动耗时有助于找出流程中最耗时的步骤,发现低效环节和优化机会。例如,可识别“交互置于保持”耗时过长或“通话后处理”时间过长的情况。
重要性
可精确计算各项活动的持续时间,帮助识别耗时步骤和绩效瓶颈。
获取途径
可在Genesys Cloud CX的事件日志或交互详情中找到,也可根据后续事件的开始时间推算。
示例
2024-05-21T10:02:30Z2024-05-21T10:15:00Z2024-05-21T10:18:45Z
|
|||
|
队列名称
QueueName
|
交互被路由到的队列名称。 | ||
|
说明
此属性用于识别交互在分配给坐席前等待的队列。按队列名称分析数据,是“服务队列瓶颈检测”仪表板的关键。管理者可据此了解不同技能组或服务线的工作量分布、衡量各队列的等待时间,并找出长期人手不足或负荷过重的队列。这些信息有助于优化资源分配、缩短客户等待时间。
重要性
显示服务请求等待分配的位置,帮助您发现瓶颈并分析工作量分布。
获取途径
可在Genesys Cloud CX对话详情记录中找到。每次交互可能经过一个或多个队列。
示例
一级支持-语音账单咨询-聊天技术支持-电子邮件
|
|||
|
CSAT评分
CustomerSatisfactionScore
|
客户在交互结束后填写的满意度调查评分。 | ||
|
说明
客户满意度评分(CSAT)直接反映客户对所获服务的评价。通常会在交互结束后通过调查收集。结合流程数据分析CSAT评分,可以了解流程差异、解决时间或特定坐席如何影响客户满意度。这是评估整体流程成效的重要结果指标。
重要性
直接衡量客户满意度,便于分析流程绩效与客户结果之间的关联。
获取途径
此数据通常来自Genesys Cloud CX质量管理模块,或与Genesys集成的第三方调查工具。
示例
5413
|
|||
|
SLA目标解决时间
SlaTargetResolutionTime
|
服务请求解决时间的合同约定目标。 | ||
|
说明
此属性根据服务级别协议(SLA)规定服务请求的最长解决时间,并作为衡量实际解决时间的基准。它是“SLA合规概览”仪表板和“SLA合规率”KPI的重要数据,可帮助组织对照客户承诺监控绩效,并在可能违约前发现风险。
重要性
为衡量SLA合规情况提供基准,这是服务绩效和合同义务的重要指标。
获取途径
此值可能存储为对话的自定义属性,也可能根据队列、客户类型或请求类型等规则推算。
示例
86400144003600
|
|||
|
对话ID
ConversationId
|
Genesys为整个对话分配的唯一标识符。 | ||
|
说明
对话ID是Genesys Cloud CX中的主要技术键,用于汇总单次客户对话中的所有相关交互、片段和参与者。概念上的“服务请求”用作案例ID,而对话ID则是通过Genesys API获取所有相关数据的底层键。它对于提取数据、关联不同数据集以及验证流程数据至关重要。
重要性
这是Genesys中的主要技术键,对于提取数据、排查问题和关联回源系统至关重要。
获取途径
这是Genesys Cloud CX所有分析和对话API中的主要字段。
示例
d8a7c6b5-e4f3-2109-8765-fedcba098765c7b6a5d4-f3e2-1098-7654-edcbaf987654
|
|||
|
是否符合SLA
IsSlaCompliant
|
标记服务请求是否在SLA目标时间内解决。 | ||
|
说明
此布尔属性表示服务请求是否达到解决时间目标,通过比较“ServiceResolutionTime”和“SlaTargetResolutionTime”计算得出。此标记简化了“SLA合规概览”仪表板中的分析和可视化,也是计算“SLA合规率”KPI的依据。您可以快速筛选并细分符合或未符合SLA的案例,识别SLA违约的常见模式。
重要性
清晰标记每个案例是否符合SLA或已违约,简化SLA绩效分析,并支持对未达标情况进行根因分析。
获取途径
计算字段:如果ServiceResolutionTime <= SlaTargetResolutionTime,则为True,否则为False。
示例
truefalse
|
|||
|
是否重新打开
IsReopened
|
标记已解决的服务请求之后是否重新打开。 | ||
|
说明
此布尔属性用于标记状态已设为已解决或已关闭、之后又重新变为活跃的服务请求。重新打开的案例通常表示初次解决方案无效或不完整,导致客户不满并增加工作量。此属性支持“服务请求重新打开趋势”仪表板和“服务请求重新打开率”KPI。分析这些案例有助于找出解决无效的根本原因。
重要性
揭示解决流程中的问题,指出解决方案质量缺陷,并可能导致返工和糟糕的客户体验。
获取途径
计算字段:检测“服务请求已解决”活动发生后重新激活案例的活动,并据此推导。
示例
truefalse
|
|||
|
是否首次联系解决
IsFirstContactResolution
|
标记服务请求是否在一次交互内解决。 | ||
|
说明
此布尔属性用于识别在首次交互中解决的案例,无需客户后续联系或内部转接。值为“true”表示问题得到理想且高效的解决。此属性是“首次联系解决率”KPI及其对应仪表板的计算依据。分析首次联系未能解决的案例,有助于发现坐席培训、知识库改进或流程调整的机会。
重要性
直接衡量效率和客户满意度,因为首次解决问题是良好服务体验的重要因素。
获取途径
计算字段,根据案例的事件顺序推导。如果案例解决前未发生转接或重新打开等特定活动,则视为首次联系解决(FCR)。
示例
truefalse
|
|||
|
服务解决时间
ServiceResolutionTime
|
从首次客户交互开始到最终解决所经过的总时间。 | ||
|
说明
此指标衡量服务请求从客户首次联系到问题标记为已解决的总时长,是衡量整体流程效率和客户体验的重要绩效指标。此计算属性是“服务请求解决时间”仪表板和“平均服务解决时间”KPI的核心。分析其分布有助于发现处理时间过长的案例和系统性延误。
重要性
这是衡量整体流程效率及其对客户体验影响的重要KPI。
获取途径
计算字段:最终解决活动的时间戳减去首次客户联系活动的时间戳。
示例
90010800172800
|
|||
|
服务请求类型
ServiceRequestType
|
服务请求的分类,例如“咨询”“投诉”或“技术问题”。 | ||
|
说明
此属性根据服务请求的性质或目的进行分类,便于细分分析,了解不同类型请求的处理方式。例如,“投诉”与“一般咨询”的流程和解决时间可能大不相同。在“内部升级分析”等仪表板中,此属性有助于判断某些请求类型是否更常被升级。
重要性
可按请求类型细分流程,比较不同请求的处理方式,并发现特定类型的瓶颈或低效环节。
获取途径
此信息可能来自IVR选项、客户在网页表单中的选择,也可能由坐席指定。在Genesys中,可将其存储为参与者属性或结束代码。
示例
账单咨询技术支持账户管理产品投诉
|
|||
客户服务活动
| 活动 | 说明 | ||
|---|---|---|---|
|
交互已转接
|
表示坐席将交互转接至其他队列或坐席。转接可以是坐席立即断开的盲转,也可以是先与接收方沟通的咨询转接。 | ||
|
重要性
此活动是内部升级率这一关键绩效指标的重要依据。较高的转接率可能意味着需要加强培训、调整路由或简化流程。
获取途径
如果初始坐席参与后,对话详情记录中新增了ACD或坐席参与者,通常即可识别此事件;该变更往往由“transfer”事件触发。
采集
根据参与者会话数据中的转接事件识别。
事件类型
explicit
|
|||
|
交互开始
|
此活动标记客户服务交互的开始,例如来电、聊天或电子邮件。Genesys Cloud CX会在系统创建新的对话对象时明确记录此事件。 | ||
|
重要性
这是服务请求流程的主要开始事件,对于计算总解决时间和了解客户需求模式至关重要。
获取途径
此事件记录在对话详情中,对应对话对象本身的开始时间,通常可在conversationStart时间戳中找到。
采集
系统发起新对话时记录。
事件类型
explicit
|
|||
|
交互断开
|
所有参与者断开连接时,对话结束。此活动标记对话结束,通常也代表服务请求在技术层面已关闭。 | ||
|
重要性
这是交互本身明确的结束事件,对于计算交互总时长至关重要,也常用作请求关闭的替代指标。
获取途径
此信息来自对话详情记录,对应对话对象的结束时间,通常可在conversationEnd时间戳中找到。
采集
所有参与者断开连接、对话结束时记录。
事件类型
explicit
|
|||
|
分配结束代码
|
坐席为交互分配预设的结束代码或处理结果代码,明确标记服务请求的结果,例如“已解决”或“已升级”。 | ||
|
重要性
结束代码是判断请求业务结果的主要依据,对于计算解决率和划分案例以供分析至关重要。
获取途径
这是对话详情记录中的明确事件,通常位于坐席参与者的会话数据中,并记录结束代码及时间戳。
采集
坐席为交互选择结束代码时记录。
事件类型
explicit
|
|||
|
坐席接受交互
|
标记坐席接受已分配的交互并与客户接通的时刻。这是服务请求开始由坐席直接处理的重要节点。 | ||
|
重要性
此活动对于衡量首次联系解决率和坐席处理时间至关重要,也标志着坐席开始处理请求。
获取途径
可在对话详情记录中找到。坐席参与者的状态变为“connected”时会记录相应时间戳。
采集
坐席参与者的状态变为“connected”时记录。
事件类型
explicit
|
|||
|
交互中开始保持
|
坐席在交互过程中将客户置于保持状态时,系统会记录此活动。这是对话中坐席参与者状态的明确变更。 | ||
|
重要性
分析保持的频率和时长,有助于发现流程低效之处,例如坐席经常需要查找信息或向他人咨询。
获取途径
此信息来自对话详情记录中的坐席参与者会话数据。状态变为“held”时会记录时间戳。
采集
坐席参与者的状态变为“held”时记录。
事件类型
explicit
|
|||
|
交互结束保持
|
坐席取消客户的保持状态并恢复对话时会发生此事件。它标记保持时段结束,并作为状态变更记录。 | ||
|
重要性
结合“交互中开始保持”活动,可准确计算总保持时间。这是总处理时间和客户体验的重要组成部分。
获取途径
根据坐席参与者会话数据推断,状态从“held”变回“connected”时即为此事件。
采集
坐席参与者的状态从“held”变为“connected”时记录。
事件类型
explicit
|
|||
|
向坐席发出交互
|
系统向特定坐席发出交互时会发生此事件。系统等待坐席接受或拒绝对话期间,坐席状态会变为“alerting”。 | ||
|
重要性
此活动有助于分析坐席响应速度和路由算法的效果。此后若出现延迟,可能说明坐席未能及时接单。
获取途径
可在对话详情记录中坐席的参与者数据内找到。参与者会话中将显示“alerting”状态及对应时间戳。
采集
路由引擎向坐席发出新交互提醒时记录。
事件类型
explicit
|
|||
|
对话进入队列
|
表示新的交互进入特定队列、等待坐席接听的时刻。这是Genesys路由引擎(ACD)明确记录的事件。 | ||
|
重要性
跟踪此活动对于衡量队列等待时间和识别路由过程中的瓶颈至关重要。从进入队列到分配坐席之间的间隔较长,可能表明人员配置或路由逻辑存在问题。
获取途径
此信息来自对话详情记录,具体查看对话中ACD参与者的“purpose”和“state”。指标数组中队列的“enterTime”表示此事件。
采集
ACD路由引擎将对话放入队列时记录。
事件类型
explicit
|
|||
|
已发送客户满意度调查
|
交互关闭后发送客户满意度(CSAT)调查时会发生此活动。通常,系统会根据预设规则自动触发调查。 | ||
|
重要性
此活动是衡量CSAT调查发送及时性这一关键绩效指标所必需的。及时发送调查有助于在客户仍清楚记得服务体验时收集准确反馈。
获取途径
此信息通常可从Genesys Cloud CX中的调查或质量管理数据获取,并可关联回原始对话ID。
采集
调查模块针对特定对话发送调查时记录。
事件类型
explicit
|
|||
|
服务请求重新打开
|
客户在问题被视为已解决后不久,再次就同一问题联系服务中心的情况。此事件不会被明确记录,而是根据业务逻辑计算得出。 | ||
|
重要性
跟踪重新打开的请求是衡量服务请求重新打开率的关键。这表明初次解决未能奏效,影响客户满意度和运营效率。
获取途径
如果某个客户(客户ID)在上一次交互解决后的预设时间范围内,就相关问题(例如服务请求类型)再次触发“交互开始”事件,即可推断此活动。
采集
将同一客户针对同一问题的新交互与近期关闭的交互关联后计算得出。
事件类型
calculated
|
|||
|
通话后处理开始
|
此活动标记通话后处理(ACW)时段的开始。坐席已与客户断开连接,接下来会处理记录备注或更新系统等任务。 | ||
|
重要性
衡量ACW时长有助于了解坐席效率和总处理时间。ACW时间过长可能表明交互后的处理流程效率低下。
获取途径
此信息来自坐席参与者会话数据。客户参与者断开连接后,坐席状态变为“acw”时会记录此事件。
采集
坐席参与者的状态变为“acw”时记录。
事件类型
explicit
|
|||
|
通话后处理结束
|
此事件标记坐席通话后处理时段的结束。此时,坐席可以开始处理另一项交互。 | ||
|
重要性
结合“通话后处理开始”活动,可准确计算结束处理阶段的时长,帮助分析坐席效率和流程开销。
获取途径
根据坐席状态从“acw”变为可用状态(例如“idle”)推断,并使用该状态变更的时间戳。
采集
根据坐席状态从“acw”变为可用状态推断。
事件类型
inferred
|
|||
数据提取指南
减少重复联系,立即提升客户服务!
轻松提升CSAT,将首次联系解决率提高至80%。
无需信用卡,几分钟即可激活试用。