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