您的客户服务数据模板
您的客户服务数据模板
- 建议收集的属性
- 需要跟踪的关键活动
- 提取指南
客户服务属性
| 名称 | 说明 | ||
|---|---|---|---|
|
开始时间
EventTime
|
表示活动或事件开始时间的时间戳。 | ||
|
说明
该属性提供每项活动发生时的准确日期和时间,对于正确排列事件顺序及开展所有基于时间的分析至关重要。开始时间用于按时间顺序构建流程,也是计算不同活动之间持续时间、等待时间和周期时间的基础。准确的时间戳是可靠流程分析和绩效监控的关键。
为什么重要
该时间戳按时间顺序排列所有活动,从而准确分析流程、持续时间和瓶颈。
获取位置
可在Genesys Cloud CX的事件日志或交互详情中找到,通常与每个记录的系统事件或用户事件相关联。
示例
2024-05-21T10:00:15Z2024-05-21T10:02:30Z2024-05-21T10:15:00Z
|
|||
|
服务请求
ServiceRequest
|
客户服务交互的主要标识符,用于关联所有相关活动。 | ||
|
说明
服务请求通常也称为Ticket或Case,是单个客户咨询或问题的主要标识符。它将从首次联系到最终解决的所有相关事件归入同一个流程实例。按服务请求分析,可以完整、端到端地查看客户旅程和内部处理流程,也是计算总解决时间、首次联系解决率等关键指标的基础。
为什么重要
这是连接所有流程步骤的关键Case ID,可对每次客户交互从开始到结束进行整体分析。
获取位置
这是概念上的案例标识符。在Genesys中,它通常对应Conversation 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的conversation详情记录中找到,与处理特定交互片段的用户相关联。
示例
a1b2c3d4-e5f6-7890-1234-567890abcdeff0e9d8c7-b6a5-4321-fedc-ba0987654321
|
|||
|
坐席姓名
AgentName
|
处理交互或活动的坐席全名。 | ||
|
说明
坐席姓名是与坐席ID对应的、便于阅读的服务代表标识。该属性让管理者和团队负责人更容易理解仪表板和报告。它广泛用于以坐席为中心的分析,以评估绩效、识别培训需求并确保工作量公平分配,无需交叉查询系统ID。
为什么重要
提供易于理解的坐席姓名,便于分析绩效和沟通结果,无需使用技术ID。
获取位置
通过查询AgentId,从Genesys Cloud CX的Users或Directory服务中获取。
示例
John SmithJane DoePeter Jones
|
|||
|
结束代码
WrapUpCode
|
交互结束时由坐席分配的代码,用于对交互结果或主题进行分类。 | ||
|
说明
Wrap-Up Code是坐席选择的标签,用于对客户交互的性质或解决结果进行分类。这些代码提供了客户联系支持团队原因的结构化数据。分析Wrap-Up Code有助于识别常见问题类型、跟踪解决结果,并衡量特定请求的发生频率。这些数据对于根因分析和了解服务需求模式具有重要价值。
为什么重要
对交互结果进行分类,为分析常见问题、解决效果和联系原因提供结构化数据。
获取位置
可在Genesys Cloud CX对话详细记录中获取,具体位于坐席参与者的会话详细信息中。
示例
密码重置账单争议已解决产品信息请求已升级至二级支持
|
|||
|
结束时间
EventEndTime
|
表示活动或事件结束时间的时间戳。 | ||
|
说明
该属性记录活动结束的准确时刻。与开始时间配合使用,可以精确计算每项活动的持续时间。分析活动持续时间有助于识别流程中最耗时的步骤,定位低效环节和优化机会。例如,可以发现“交互进入保持状态”时间过长或“通话后工作”持续时间过长。
为什么重要
支持精确计算单项活动的持续时间,对于识别耗时步骤和绩效瓶颈至关重要。
获取位置
可在Genesys Cloud CX的事件日志或交互详情中找到,也可以根据后续事件的开始时间推导。
示例
2024-05-21T10:02:30Z2024-05-21T10:15:00Z2024-05-21T10:18:45Z
|
|||
|
通信渠道
MediaType
|
交互所使用的通信渠道,例如语音、聊天或电子邮件。 | ||
|
说明
此属性用于指定客户与坐席沟通所使用的媒介。常见渠道包括语音、聊天、电子邮件和社交媒体。正如“通信渠道绩效”仪表板所示,按渠道分析绩效有助于企业了解各渠道的请求量、解决时间和客户满意度。这些洞察对于优化渠道策略和资源分配至关重要。
为什么重要
按通信渠道细分流程,对于了解各渠道的绩效、客户行为和资源需求至关重要。
获取位置
Genesys Cloud CX对话详细记录中的标准字段。
示例
语音聊天电子邮件消息
|
|||
|
队列名称
QueueName
|
交互被路由至的队列名称。 | ||
|
说明
此属性用于标识交互在分配给坐席前等待的具体队列。按队列名称分析数据,对于“服务队列瓶颈检测”仪表板至关重要。它可以帮助管理者了解不同技能组或服务线之间的工作负载分布,衡量各队列的等待时间,并识别长期人手不足或负载过高的队列。这些信息是优化资源分配、缩短客户等待时间的关键。
为什么重要
通过展示服务请求等待分配的位置,帮助识别瓶颈并分析工作负载分布。
获取位置
可在Genesys Cloud CX对话详细记录中获取。每次交互可能经过一个或多个队列。
示例
一级支持-语音账单咨询-聊天技术支持-电子邮件
|
|||
|
CSAT评分
CustomerSatisfactionScore
|
客户在交互后调查中提供的满意度评分。 | ||
|
说明
客户满意度评分,即CSAT,是衡量客户对所接受服务感受的直接指标。通常在交互结束后通过调查收集。结合流程数据分析CSAT评分,可以发现流程差异、解决时间或特定坐席对客户满意度的影响。这是评估整体流程成效的重要结果指标。
为什么重要
直接衡量客户满意度,支持分析流程绩效与客户结果之间的关联。
获取位置
这些数据通常来自Genesys Cloud CX Quality Management模块,或与Genesys集成的第三方调查工具。
示例
5413
|
|||
|
SLA目标解决时间
SlaTargetResolutionTime
|
合同约定的服务请求目标解决时间。 | ||
|
说明
此属性根据服务级别协议(SLA)定义服务请求必须完成解决的最长时间,是衡量实际解决时间的基准。这些数据对于“SLA合规概览”仪表板和“SLA合规率”KPI至关重要,可帮助组织监控对客户承诺的履行情况,并在潜在违约发生前及时识别风险。
为什么重要
为衡量SLA合规性提供基准,是反映服务绩效和合同义务的重要指标。
获取位置
它可能作为对话的自定义属性存储,也可能根据队列、客户类型或请求类型等规则计算得出。
示例
86400144003600
|
|||
|
对话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
|
|||
|
是否符合SLA
IsSlaCompliant
|
用于标识服务请求是否在SLA目标时间内解决的标记。 | ||
|
说明
此布尔属性用于标识服务请求是否达到解决时间目标。它通过比较“ServiceResolutionTime”和“SlaTargetResolutionTime”计算得出。此标记简化了“SLA合规概览”仪表板中的分析和可视化,也是计算“SLA合规率”KPI的基础。您可以据此快速筛选并细分合规与不合规案件,识别SLA违约的常见模式。
为什么重要
通过明确标记每个案件是否合规,简化SLA绩效分析,并支持对失败原因进行根因分析。
获取位置
计算字段:当ServiceResolutionTime <= SlaTargetResolutionTime时为True,否则为False。
示例
truefalse
|
|||
|
是否重新打开
IsReopened
|
用于标识已解决的服务请求之后是否再次打开的标记。 | ||
|
说明
此布尔属性用于标记已设为已解决或已关闭、但之后又重新变为活动状态的服务请求。重新打开的案件通常表明初始解决方案无效或不完整,导致客户不满并增加额外工作。此属性支持“服务请求重新打开趋势”仪表板和“服务请求重新打开率”KPI。分析这些案件有助于识别解决无效的根因。
为什么重要
突出显示解决流程中的失败,指向解决方案质量问题,以及由此产生的返工和较差客户体验。
获取位置
计算字段,通过检测“服务请求已解决”活动发生后重新激活案件的活动得出。
示例
truefalse
|
|||
|
是否首次联系解决
IsFirstContactResolution
|
用于标识服务请求是否在一次交互内解决的标记。 | ||
|
说明
此布尔属性用于识别在首次交互期间解决、无需客户跟进或内部转接的案件。值为“true”表示实现了理想且高效的解决。此属性是“首次联系解决率”KPI及其对应仪表板的基础。分析未能在首次联系时解决的案件特征,可以发现坐席培训、知识库改进或流程调整的机会。
为什么重要
直接衡量效率和客户满意度,因为一次解决问题是带来良好服务体验的关键因素。
获取位置
计算字段,通过分析案件的事件序列得出。如果案件在解决过程中未出现转接或重新打开等特定中间活动,则视为FCR。
示例
truefalse
|
|||
|
服务解决时间
ServiceResolutionTime
|
从首次客户交互开始到最终解决所经过的总时间。 | ||
|
说明
此指标衡量服务请求的总时长,从客户发起联系到问题标记为已解决。它是衡量整体流程效率和客户体验的关键绩效指标。此计算属性是“服务请求解决时间”仪表板和“平均服务解决时间”KPI的核心。分析其分布有助于识别长期未结案件和系统性延迟。
为什么重要
这是衡量整体流程效率及其对客户体验影响的关键KPI。
获取位置
计算字段:最终解决活动的时间戳减去首次客户联系活动的时间戳。
示例
90010800172800
|
|||
|
服务请求类型
ServiceRequestType
|
服务请求的分类,例如“咨询”“投诉”或“技术问题”。 | ||
|
说明
此属性根据服务请求的性质或目的对其进行分类,便于细分分析,了解不同类型请求的处理方式。例如,“投诉”与“一般咨询”的流程路径和解决时间可能存在显著差异。对于“内部升级分析”等仪表板,此维度有助于判断某些请求类型是否更容易被升级。
为什么重要
支持按流程细分,比较不同类型请求的处理方式,并识别特定类型的瓶颈或低效环节。
获取位置
此信息可能通过IVR选项、客户在网页表单中的选择获取,也可能由坐席分配。在Genesys中,它可以存储为参与者属性或Wrap-Up Code。
示例
账单咨询技术支持账户管理产品投诉
|
|||
客户服务活动
| 活动 | 说明 | ||
|---|---|---|---|
|
交互已断开
|
该活动表示conversation结束,即所有参与者均已断开连接。这通常是服务请求交互的技术性关闭节点。 | ||
|
为什么重要
这是交互本身的明确结束事件,对于计算交互总时长至关重要,也常被用作请求关闭的替代标志。
获取位置
该事件取自conversation详情记录,对应conversation对象的结束时间,通常位于conversationEnd时间戳中。
采集
所有参与者断开连接、conversation结束时记录。
事件类型
explicit
|
|||
|
交互已转接
|
表示坐席将交互转接至其他队列或坐席。转接可以是盲转,即坐席立即断开连接;也可以是咨询转接,即先与接收方沟通再完成转接。 | ||
|
为什么重要
该活动是内部升级率KPI的重要依据。较高的转接率可能表明需要加强培训、路由不准确或流程过于复杂。
获取位置
当初始坐席参与后,conversation详情记录中新增ACD或坐席参与者时,可以识别此活动,通常由“transfer”事件触发。
采集
通过参与者会话数据中的转接事件识别。
事件类型
explicit
|
|||
|
交互开始
|
该活动标志着客户服务交互的开始,例如接听来电、发起聊天或接收电子邮件。当系统创建新的conversation对象时,Genesys Cloud CX会明确记录此事件。 | ||
|
为什么重要
这是服务请求流程的主要开始事件,对于计算总解决时间和了解客户来电需求模式至关重要。
获取位置
该事件取自conversation详情记录,对应conversation对象本身的开始时间,通常位于conversationStart时间戳中。
采集
系统发起新conversation时记录。
事件类型
explicit
|
|||
|
分配收尾代码
|
坐席为交互分配预定义的收尾代码或处置代码,明确标记服务请求结果,例如“已解决”或“已升级”。 | ||
|
为什么重要
收尾代码是确定请求业务结果的主要依据,也是计算解决率和划分案例分析范围的重要数据。
获取位置
这是conversation详情记录中的明确事件,通常位于坐席参与者会话数据中。系统会记录收尾代码和时间戳。
采集
坐席为交互选择收尾代码时记录。
事件类型
explicit
|
|||
|
坐席接受交互
|
标志着坐席接受所提供的交互并与客户建立连接的时刻。这是服务请求开始由坐席直接处理的关键节点。 | ||
|
为什么重要
该活动对于衡量首次联系解决率和坐席处理时间至关重要,表示坐席开始处理请求。
获取位置
该事件可在conversation详情记录中找到,表现为坐席参与者状态变为“connected”,并带有相应时间戳。
采集
坐席参与者状态变为“connected”时记录。
事件类型
explicit
|
|||
|
Conversation路由至队列
|
表示新交互被放入指定队列、等待可用坐席的时刻。这是Genesys路由引擎(ACD)明确记录的事件。 | ||
|
为什么重要
跟踪此活动对于衡量队列等待时间和识别路由流程中的瓶颈至关重要。从该活动到坐席分配之间的持续时间较长,通常表明人员配置或路由逻辑存在问题。
获取位置
该事件取自conversation详情记录,具体查看conversation中ACD参与者的“purpose”和“state”。指标数组中队列的“enterTime”表示此事件。
采集
ACD路由引擎将conversation放入队列时记录。
事件类型
explicit
|
|||
|
交互解除保持状态
|
坐席取消客户的保持状态并恢复conversation时发生。该事件标志着保持时段结束,并作为状态变化记录。 | ||
|
为什么重要
与“交互进入保持状态”配对后,该活动可用于精确计算总保持时间,这是整体处理时间和客户体验的重要组成部分。
获取位置
当坐席参与者会话数据中的状态从“held”变回“connected”时生成。
采集
坐席参与者状态从“held”变为“connected”时记录。
事件类型
explicit
|
|||
|
交互进入保持状态
|
坐席在交互过程中将客户置于保持状态时,会记录此活动。这是conversation中坐席参与者的明确状态变化。 | ||
|
为什么重要
分析保持状态的频率和持续时间,可以发现流程低效问题,例如坐席频繁查找信息或咨询他人。
获取位置
该事件取自conversation详情记录中的坐席参与者会话数据。状态变为“held”,并记录时间戳。
采集
坐席参与者状态变为“held”时记录。
事件类型
explicit
|
|||
|
坐席收到交互
|
当系统向特定坐席提供交互时,会发生此事件。坐席状态变为“alerting”,系统等待其接受或拒绝conversation。 | ||
|
为什么重要
该活动有助于分析坐席响应速度和路由算法的有效性。此后的延迟可能表明坐席未能及时接受工作。
获取位置
该事件位于conversation详情记录的坐席参与者数据中。参与者会话将显示状态为“alerting”的指标及相应时间戳。
采集
路由引擎向坐席提示新交互时记录。
事件类型
explicit
|
|||
|
客户满意度调查已发送
|
交互关闭后发送客户满意度(CSAT)调查时,会发生此活动。通常,系统会根据预定义规则自动触发。 | ||
|
为什么重要
该活动是衡量CSAT调查发送及时性KPI的必要依据。及时发送调查,有助于在客户仍对体验记忆清晰时收集准确反馈。
获取位置
该信息通常来自Genesys Cloud CX中的调查或质量管理数据,并可关联回原始conversation ID。
采集
调查模块为特定conversation发送调查时记录。
事件类型
explicit
|
|||
|
服务请求重新打开
|
表示客户在问题被视为解决后不久,因同一问题再次联系服务中心的情况。这不是明确记录的事件,而是根据业务逻辑计算得出。 | ||
|
为什么重要
跟踪重新打开的请求,是衡量服务请求重新打开率的关键。它表明初始解决方案未能有效解决问题,并影响客户满意度和运营效率。
获取位置
通过识别同一客户(Customer ID)在上一次交互解决后的预定义时间窗口内,针对相关问题(例如服务请求类型)产生的新“交互开始”事件来推断。
采集
通过将同一客户和问题的新交互与近期关闭的交互关联计算得出。
事件类型
calculated
|
|||
|
通话后工作开始
|
该活动标志着通话后工作(ACW)时段开始。坐席已与客户断开连接,但进入专用状态,以完成记录备注或更新系统等任务。 | ||
|
为什么重要
衡量ACW持续时间对于了解坐席效率和整体处理时间非常重要。ACW时间过长可能表明交互后的处理流程效率低下。
获取位置
该事件取自坐席参与者会话数据,在客户参与者断开连接后,坐席状态变为“acw”时记录。
采集
坐席参与者状态变为“acw”时记录。
事件类型
explicit
|
|||
|
通话后工作结束
|
标志着坐席通话后工作时段结束。此时,坐席可以继续处理其他交互。 | ||
|
为什么重要
该活动与“通话后工作开始”结合,可精确计算收尾阶段的持续时间,帮助分析坐席生产力和流程开销。
获取位置
当坐席状态从“acw”变为可用状态(例如“idle”)时推断得出,并使用该状态变化的时间戳。
采集
根据坐席状态从“acw”变为可用状态推断。
事件类型
inferred
|
|||
提取指南
终结重复联系:立即提升客户服务!
轻松提升CSAT,实现80%的一次联系解决率。
无需信用卡,几分钟内即可激活试用。