您的客户服务数据模板
您的客户服务数据模板
- 建议采集的属性
- 客户服务流程中需要跟踪的关键活动
- Zendesk Support数据提取指南
客户服务属性
| 名称 | 说明 | ||
|---|---|---|---|
|
开始时间
StartTime
|
表示活动或事件开始时间的时间戳。 | ||
|
说明
开始时间(即事件时间戳)记录特定活动发生的准确日期和时间。例如,记录客户评论添加、客服人员分配或工单状态改为“Resolved”的时间。 此时间戳是流程挖掘的基础,用于确定事件的先后顺序、计算活动间隔时长、衡量SLA表现并了解服务流程的时间变化。
重要性
此时间戳对于排列事件顺序、计算时长和分析服务请求流程的时间线至关重要。
获取途径
Zendesk Ticket Audits API中每个审计记录的
示例
2023-04-15T10:00:00Z2023-04-15T10:05:14Z2023-04-16T14:30:00Z
|
|||
|
服务请求
ServiceRequest
|
每个客户服务请求的唯一标识,也称为工单或案例。 | ||
|
说明
服务请求是主要案例标识,用于关联从创建到最终解决的单个客户咨询或问题的所有活动。每次交互、更新或内部操作都与此唯一ID关联。 在流程挖掘中,按服务请求对事件进行分组分析,可以完整呈现客户服务的端到端历程。这是计算解决总时间、识别流程偏差和了解每个客户问题生命周期的基础。
重要性
这是必需的案例ID,用于关联所有流程步骤,从而还原并分析每个客户服务历程。
获取途径
Zendesk Tickets API的
示例
102451287415332
|
|||
|
数据最近更新时间
LastDataUpdate
|
源系统最近一次刷新或提取数据的时间戳。 | ||
|
说明
此属性表示上次从Zendesk Support更新数据集的时间,可帮助您了解所分析数据的新旧程度。 分析人员和业务用户需要了解最近更新时间,才能判断当前查看的流程信息是否为最新数据。此信息有助于管理对数据时效性的预期,也是报告和监控的重要依据。
重要性
明确数据的时效性,帮助用户了解流程分析反映的是哪个时间点的数据。
获取途径
这是在数据提取过程中生成并存储的元数据字段,用于记录提取任务的时间戳。
示例
2023-10-27T02:00:00Z
|
|||
|
活动名称
ActivityName
|
服务请求生命周期中发生的具体事件或任务名称。 | ||
|
说明
活动名称用于描述客户服务流程中的单个步骤或节点,例如“服务请求已创建”“请求已分配给客服人员”或“服务请求已解决”。这些事件均带有时间戳,共同构成每个服务请求的操作顺序。 此属性对于可视化流程、发现流程变体以及分析事件的频率和顺序至关重要。它能帮助分析人员了解实际执行的操作,并识别常见路径、瓶颈以及偏离标准过程的情况。
重要性
此属性定义流程步骤,可用于绘制流程图并分析流程路径和变体。
获取途径
从记录变更和操作的Zendesk工单审计日志或事件流中提取。
示例
服务请求已创建请求已分配给客服人员客服人员已发送首条公开回复服务请求已解决
|
|||
|
源系统
SourceSystem
|
提取数据的记录系统。 | ||
|
说明
此属性指定服务请求数据的来源系统,本例中为Zendesk Support。整合多个系统的数据时,它有助于数据治理和追溯数据来源。 分析时,此属性可确保数据正确归属其来源,对于维护数据完整性和了解流程背景十分重要,尤其是在涉及多个系统的环境中。
重要性
标识数据来源,对于数据治理以及在集成环境中区分流程数据至关重要。
获取途径
这是数据提取过程中添加的静态值,用于标记数据来源。
示例
Zendesk Support
|
|||
|
SLA目标解决时间
SlaTargetResolutionTime
|
根据SLA策略,预期解决服务请求所需的目标时长。 | ||
|
说明
此属性定义服务级别协议(SLA)规定的工单解决时限。目标时限通常会根据请求的优先级、类型或客户服务计划等因素动态变化。 这是“SLA合规绩效”仪表板的基础属性,用作衡量实际解决时间的基准。将实际表现与目标进行比较,有助于量化服务交付质量,并确保履行对客户的合同义务。
重要性
定义对客户的服务承诺,并作为衡量按时完成情况和SLA合规情况的基准。
获取途径
根据应用于工单的SLA策略计算。可通过Zendesk Ticket Metrics API获取此信息。
示例
144002880086400
|
|||
|
优先级
Priority
|
分配给服务请求的优先级,例如“Low”“Normal”“High”或“Urgent”。 | ||
|
说明
优先级表示服务请求的紧急程度,通常会影响其在队列中的位置和目标解决时间。它有助于客服人员优先处理最紧急的问题。 此属性对于绩效和SLA分析至关重要。“服务请求解决时间分析”仪表板会按优先级细分数据,帮助您了解高优先级请求是否比低优先级请求处理得更快,以及资源配置是否符合业务需求。
重要性
用于表示请求的紧急程度,这对分析SLA合规情况并确保严重问题得到及时处理至关重要。
获取途径
Zendesk Tickets API中的
示例
低普通高紧急
|
|||
|
已分配的客服人员
AssignedAgent
|
负责处理服务请求的客服人员姓名或ID。 | ||
|
说明
此属性用于标识特定时间点负责某项活动或服务请求的客服人员。如果请求被重新分配,负责人可能会在生命周期内发生变化。 按已分配的客服人员进行分析,有助于了解工作量、绩效和效率。此属性支持“客服人员工作量与效率”仪表板,可比较不同客服人员的处理时长和案例数量,帮助发现辅导机会并平衡工作量。
重要性
跟踪执行操作的客服人员,以便分析个人绩效、工作量分配和资源配置。
获取途径
Zendesk Tickets API的
示例
John SmithJane DoeSupportBot
|
|||
|
是否违反SLA
IsSlaBreached
|
用于标记服务请求的解决时间是否超过SLA目标的布尔值。 | ||
|
说明
此计算属性是一个简单的真/假标记,用于表示服务请求是否未能满足规定的解决时限。该标记通过比较实际解决时长与SLA目标时限得出。 此标记简化了SLA合规分析,是“SLA合规绩效”仪表板和“SLA合规率”KPI的核心数据点,可快速汇总并直观展示达到或未达到服务目标的请求数量。
重要性
为每个案例提供明确的SLA绩效结果,简化合规监控与报告。
获取途径
在数据转换期间,将总解决时间与SlaTargetResolutionTime进行比较后计算得出。
示例
truefalse
|
|||
|
服务请求类型
ServiceRequestType
|
服务请求的分类,例如“Question”“Incident”“Problem”或“Task”。 | ||
|
说明
此属性根据服务请求的性质对其进行分类。通常在创建请求或初步分流时设置,有助于确定适当的工作流和优先级。 按服务请求类型细分数据是分析的基础。您可以比较不同问题类型的解决时间、升级率和流程路径,例如查看“服务请求解决时间分析”和“内部升级率及原因”仪表板。这有助于发现某些类型的请求是否更难处理或处理效率更低。
重要性
对请求进行分类,以便比较和分析不同问题类型的绩效,为有针对性的流程改进提供依据。
获取途径
Zendesk Tickets API的
示例
问题事件问题Task
|
|||
|
沟通渠道
CommunicationChannel
|
提交服务请求或进行沟通的渠道。 | ||
|
说明
此属性用于标识所使用的沟通方式,例如电子邮件、网页表单、聊天或电话,反映客户与服务台的互动方式。 了解各渠道的使用情况有助于规划资源并改善客户体验。“沟通渠道使用概览”仪表板会分析这些数据,查看哪些渠道最常用,以及某些渠道是否与更长的解决时间或不同的流程路径相关。这些信息有助于确定应在哪些方面投入资源,以改进服务或实现自动化。
重要性
展示客户与客服人员的互动情况,便于分析各渠道的效率及其对流程和客户体验的影响。
获取途径
Zendesk Tickets API中的
示例
网页电子邮件API聊天
|
|||
|
产品或服务类别
ProductServiceCategory
|
客户请求所涉及的具体产品、服务或功能。 | ||
|
说明
此属性根据产品或服务领域对服务请求进行分类,提供更详细的背景信息。分类通常由客服人员手动设置,也可以根据请求内容自动设置。 此分类对“请求分类准确率”和“调查周期时间细分”仪表板至关重要。它有助于深入分析哪些产品引发的支持请求最多、哪些请求最难解决,以及初始分类是否与最终解决方案相符,从而改进请求分派和客服培训。
重要性
将请求关联到具体业务领域、产品或服务,便于针对问题领域及其对流程的影响开展分析。
获取途径
通常是Zendesk中的自定义工单字段。具体字段名称取决于Zendesk的配置。
示例
移动应用订阅管理API集成硬件
|
|||
|
信息请求次数
InformationRequestCount
|
针对单个服务请求向客户索取信息的总次数。 | ||
|
说明
此计算指标统计每个服务请求中“向客户索取信息”活动的发生次数。次数较多可能说明客服人员没有在一开始收集所有必要信息。 此属性用于“重复索取信息分析”仪表板。跟踪该次数有助于发现流程低效之处和需要加强客服培训的领域。减少索取信息的次数,可以显著缩短解决时间并改善客户体验。
重要性
量化与客户反复沟通的情况,揭示导致解决时间延长、客户体验下降的低效环节。
获取途径
统计每个服务请求中ActivityName为“Information Requested From Customer”的事件数量后计算得出。
示例
013
|
|||
|
客服团队
AgentGroup
|
负责处理服务请求的支持组或团队。 | ||
|
说明
此属性表示负责处理服务请求的客服团队。请求通常会根据技能、产品领域或语言分配给特定团队。 按客服团队分析,有助于了解团队层面的绩效、工作量分布以及团队间的升级模式。与分析单个客服人员相比,这种分析视角更全面,也有助于发现特定部门或职能中的系统性问题。
重要性
记录团队责任归属,便于分析团队绩效、团队间交接情况,以及不同支持层级或专业领域的资源分配。
获取途径
Zendesk Tickets API中的
示例
一线支持技术支持账单
|
|||
|
是否重新打开
IsReopened
|
用于标记服务请求在标记为已解决后是否重新打开的布尔值。 | ||
|
说明
如果服务请求在此前已标记为已解决或已关闭,之后又转回打开状态,此属性就会标记为真。这表明最初的解决方案未能解决问题。 此标记对跟踪返工和首次联系解决失败至关重要。它直接支持“服务请求重新打开趋势”仪表板和“服务请求重新打开率”KPI,便于统计和分析需要进一步处理的案例,而这些案例往往反映了更深层的问题。
重要性
识别返工和未能解决的问题,帮助衡量所提供解决方案的质量与效果。
获取途径
在数据转换期间,检查工单状态是否从“已解决”或“已关闭”变为“打开”后计算得出。
示例
truefalse
|
|||
|
满意度评分
SatisfactionRating
|
服务请求解决后客户给出的满意度评分。 | ||
|
说明
此属性记录客户对服务体验的反馈,通常在工单解决后通过调查收集。常见评分包括“良好”“差”或数字评分。 这是衡量客户感受的直接指标,也是重要的结果指标,可用于计算“客户感受评分”KPI。将满意度评分与解决时间、客服人员处理次数等流程数据结合分析,可以发现哪些流程行为能带来更好的客户体验。
重要性
直接衡量客户对所提供服务的反馈,将流程绩效与客户体验结果联系起来。
获取途径
Zendesk Tickets API中的
示例
良好差已邀请评价
|
|||
|
结束时间
EndTime
|
表示活动或事件完成时间的时间戳。 | ||
|
说明
结束时间表示活动完成的时间。在许多事件日志结构中,下一项活动的开始时间可作为当前活动的结束时间。对于“客服人员调查问题”等基于状态的活动,结束时间表示该状态结束的时间。 此属性对于准确计算活动时长至关重要,是绩效分析的核心内容。它有助于发现耗时最长的步骤,并为详细的瓶颈分析和资源效率计算提供依据。
重要性
用于计算活动时长,对于发现瓶颈和衡量绩效至关重要。
获取途径
通常根据同一服务请求的后续事件顺序,取下一事件的StartTime作为结束时间。
示例
2023-04-15T10:05:14Z2023-04-15T11:20:30Z2023-04-16T15:00:00Z
|
|||
|
解决代码
ResolutionCode
|
用于说明请求最终解决或关闭原因的代码或类别。 | ||
|
说明
解决代码以结构化方式记录服务请求的处理结果,例如“客服人员已解决”“重复请求”“无需处理”或“已知问题”。相比简单的“已关闭”状态,它能提供更多背景信息。 此属性对根因分析尤其有价值。在“服务请求重新打开趋势”仪表板中,按解决代码分析重新打开率,可以发现某些解决方案是否效果不佳,导致客户再次联系支持团队。
重要性
帮助了解服务请求的处理结果,为根因分析以及查明请求重新打开的原因提供重要信息。
获取途径
通常是Zendesk中的自定义工单字段。具体字段名称取决于Zendesk的配置。
示例
首次联系即解决升级至二线支持等待客户回复产品缺陷
|
|||
客户服务活动
| 活动 | 说明 | ||
|---|---|---|---|
|
已向客户索取信息
|
客服人员需要客户提供更多信息才能继续处理,并将工单状态改为“pending”时,会发生此活动。此状态变更明确表示流程正在等待外部人员回复。 | ||
|
重要性
此活动反映了流程对客户的依赖,并会暂停内部SLA计时。同一工单频繁或反复出现此情况,可能说明初次收集信息不完整,导致解决时间延长。
获取途径
这是Zendesk Ticket Audits API中明确记录的状态变更事件。“status”字段变为“pending”时,系统会记录此事件。
采集
在Ticket Audits中查找工单状态被设为“pending”的“Change”事件。
事件类型
explicit
|
|||
|
服务请求已关闭
|
这是最后一项活动,标志着服务请求永久关闭。通常,工单标记为“solved”后经过一段设定时间,且客户没有新回复,系统便会自动关闭工单。 | ||
|
重要性
作为最终结束事件,它标志着工单生命周期结束。从“solved”到“closed”的时间段是工单可能重新打开的窗口;“closed”事件则确认解决方案已被接受。
获取途径
当“status”字段被设为“closed”时,Zendesk Ticket Audits API会明确记录此状态变更。
采集
在Ticket Audits中查找工单状态被设为“closed”的“Change”事件。
事件类型
explicit
|
|||
|
服务请求已创建
|
此活动标志着客户服务流程的开始:客户通过电子邮件、网页表单或聊天等渠道提交请求后,Zendesk会生成新工单。系统会在创建时记录此事件,并附上唯一工单ID和时间戳。 | ||
|
重要性
作为主要开始事件,它是计算案例总时长和分析一段时间内请求量的基础。它也为衡量首次响应时间和总解决时间等关键绩效指标提供基准。
获取途径
这是Zendesk Ticket Audits API中明确记录的事件,对应工单的“Create”事件,并提供初始创建时间戳。
采集
从Ticket Audits日志中的工单创建事件获取。
事件类型
explicit
|
|||
|
服务请求已解决
|
客服人员为客户提供解决方案后,会将服务请求标记为“solved”。这只是临时状态,工单在永久关闭前仍可能因客户回复而重新打开。 | ||
|
重要性
这是衡量解决时间和客服人员效率的主要节点。它表示客服人员认为工作已完成,也为工单重新打开时分析返工情况提供依据。
获取途径
当“status”字段被设为“solved”时,Zendesk Ticket Audits API会明确记录此状态变更。
采集
在Ticket Audits中查找工单状态被设为“solved”的“Change”事件。
事件类型
explicit
|
|||
|
服务请求已重新打开
|
客户回复状态为“solved”的工单时,会发生此活动。Zendesk会自动将状态改回“open”,表示问题尚未完全解决。 | ||
|
重要性
工单重新打开是首次联系解决失败和解决方案质量不佳的重要指标。分析工单重新打开的频率和原因,有助于发现改进客服人员培训和解决流程的方向。
获取途径
这是Ticket Audits API中明确记录的状态变更:当“status”从“solved”变回“open”时,系统会记录此事件。
采集
跟踪状态从“solved”变为“open”的“Change”事件。
事件类型
explicit
|
|||
|
请求已分配给客服人员
|
此事件表示服务请求已分配给特定客服人员处理。分配可以根据路由规则自动完成,也可以由团队负责人或客服人员手动完成。 | ||
|
重要性
分配是明确责任归属和管理工作量的重要节点。分析分配耗时和重新分配模式,可以发现初步分流和任务分配流程中的瓶颈。
获取途径
这是Zendesk Ticket Audits API中明确记录的“Change”事件,每当“assignee_id”字段被填写或更改时都会记录。
采集
跟踪Ticket Audits日志中“assignee_id”字段的变更。
事件类型
explicit
|
|||
|
SLA未达标
|
此活动标志着服务请求未能达到预先设定的服务级别协议要求,例如首次回复时间或解决时间。系统会根据工单活动时间戳与SLA政策进行比较,计算此事件。 | ||
|
重要性
SLA未达标会直接影响客户满意度和合同合规。分析其发生时间和原因,对于发现系统性延误、资源短缺或不切实际的绩效目标至关重要。
获取途径
数据可来自Zendesk Ticket Metrics API,该接口会存储SLA未达标时间戳(“breached_at”)。也可以将工单事件时间戳与设定的SLA规则进行比较后计算得出。
采集
使用Ticket Metrics API中的“breached_at”时间戳,或将解决时间与SLA政策规定的时限进行比较后计算。
事件类型
calculated
|
|||
|
客户已回复
|
客户回复工单时会触发此事件,通常发生在工单处于“pending”状态时。Zendesk会自动将工单状态从“pending”改回“open”,表示客服人员可以继续处理。 | ||
|
重要性
此活动标志着等待时间结束,并触发流程继续进行。分析客户的回复耗时,有助于了解客服人员的请求是否清晰。
获取途径
此事件对应最终用户发布的新公开评论,并会在Ticket Audits API中触发从“pending”到“open”的明确状态变更。
采集
跟踪状态从“pending”变为“open”的“Change”事件,或识别最终用户发布的新公开评论。
事件类型
explicit
|
|||
|
客服人员已发送首条公开回复
|
此活动标志着客服人员首次向客户发送公开评论,与自动确认消息不同。它是衡量客服人员开始处理客户问题的重要指标。 | ||
|
重要性
这是衡量“First Reply Time”SLA的关键节点,也是服务响应速度的重要指标。它标志着沟通从自动回复转为由人工主动调查和提供支持。
获取途径
在Ticket Comments数据流中,找到由人工客服人员(而非自动化系统用户)发布的第一条公开评论即可识别。
采集
扫描工单评论,筛选客服人员发布的公开评论,并选取时间戳最早的一条。
事件类型
inferred
|
|||
|
已发送满意度调查
|
指自动向客户发送客户满意度(CSAT)调查的时间点。通常在工单标记为已解决后不久发送。 | ||
|
重要性
此活动启动客户反馈流程。了解调查何时发送以及是否发送,有助于结合背景解读满意度评分,并衡量反馈计划的成效。
获取途径
可根据自动化日志或工单新增的特定标签推断。Ticket Audits API中的“satisfaction_rating”部分也会记录调查发送时间。
采集
查找“csat_sent”等标签,或使用满意度评分调查发出的时间戳。
事件类型
inferred
|
|||
|
已发送首次确认
|
指发送给客户的自动首次回复,用于确认已收到请求。通常由Zendesk触发器在工单创建后立即发送模板邮件通知。 | ||
|
重要性
跟踪此活动对于衡量首次响应速度和管理客户预期至关重要。从请求创建到发送确认的时间,是影响客户满意度的一项关键指标。
获取途径
如果工单的第一条公开评论由自动化用户发布,或在工单创建后几秒内发布,可据此推断此活动。您可以分析Ticket Comments数据流来识别。
采集
找出工单创建后由自动化或触发器立即发布的第一条公开评论。
事件类型
inferred
|
|||
|
已收到满意度评分
|
客户提交满意度调查回复时会发生此事件,回复中包含“Good”或“Bad”等评分。评分及相关评论会记录在工单中。 | ||
|
重要性
客户直接反馈对于衡量服务质量和客户感受非常重要。结合流程分析这些评分,有助于了解特定活动或客服人员与结果之间的关联。
获取途径
当“satisfaction_rating”字段记录了客户评分和评论时,Ticket Audits API会将其作为“Change”事件记录。
采集
筛选Ticket Audit日志,查找“satisfaction_rating”字段的变更。
事件类型
explicit
|
|||
|
已触发内部升级
|
指将服务请求转交给其他内部团队或更高级别的支持团队。通常可根据工单的分配组发生变更来推断。 | ||
|
重要性
跟踪升级有助于发现流程薄弱环节、一线支持的知识缺口以及复杂的请求类型。升级率偏高可能意味着需要加强培训或完善流程文档。
获取途径
可根据Ticket Audits API中的“Change”事件推断:当“group_id”字段发生变更时,即表示团队之间进行了交接。
采集
监控Ticket Audits日志中“group_id”字段的变更。
事件类型
inferred
|
|||
|
请求已分类并确定优先级
|
客服人员或自动化设置或更新工单字段(如类型、类别和优先级)时,会发生此活动。此步骤会作为变更事件记录在工单历史中。 | ||
|
重要性
正确分类并确定优先级,对于高效分派和资源配置至关重要。分析此活动有助于评估初步分流是否准确,以及它对解决时间的影响。
获取途径
可从Zendesk Ticket Audits API中的“Change”事件获取。查找“priority”“type”或分类相关自定义字段的首次更新即可识别。
采集
筛选Ticket Audit日志,查找工单创建后关键分类字段的首个“Change”事件。
事件类型
explicit
|
|||
数据提取指南
消除客户服务瓶颈,立即提升CSAT
减少重复联系,实现80%的首次联系解决率(FCR),提升客户满意度。
无需信用卡