您的事件管理数据模板

Zendesk Support
您的事件管理数据模板

您的事件管理数据模板

此模板概述了有效分析事件管理流程所需的核心数据,包括建议收集的关键属性、需要跟踪的重要活动,以及从Zendesk Support提取数据的实用指南。借助此模板,您可以为流程挖掘项目准备完整、可靠的数据集。
  • 建议收集的属性
  • 流程映射需要跟踪的关键活动
  • 实用的数据提取指南
刚接触事件日志?了解 如何创建流程挖掘事件日志.

事件管理属性

建议将以下数据字段纳入事件日志,以便全面分析事件管理流程。
5 必填 7 建议填写 11 选填
名称 说明
事件ID
TicketId
系统为每张事件工单生成的唯一标识符。
说明

事件ID是Zendesk Support中用于唯一标识每个事件案例的主键。在流程挖掘中,它用作CaseId,将事件创建到关闭期间的所有相关活动、状态变更和沟通记录关联起来。

分析时,此ID对于还原每起事件的端到端处理过程至关重要。它可以汇总事件数据,跟踪单个案例的解决总时长、交接次数和服务级别协议达成情况。按此ID对事件分组后,分析人员可以查看流程路径、识别常见处理方式,并发现偏离标准流程的情况。

重要性

这是将所有事件关联到单起事件的关键标识符,可用于追踪完整生命周期并准确分析流程绩效。

获取途径

Zendesk Tickets API(/api/v2/tickets/{id}),字段id。

示例
19428230113521941055
事件时间戳
EventTimestamp
活动发生的准确日期和时间。
说明

此时间戳记录事件生命周期中某项活动发生的准确时刻,例如添加评论或更改状态的时间,并确定案例中所有活动的先后顺序。

此属性是基于时间的流程挖掘分析的基础。它可用于计算活动间的周期时间、识别等待时间、衡量案例总时长,以及分析不同时段的流程绩效。准确的时间戳对于创建按时间展示案例流转情况的动态流程图,以及构建跟踪平均解决时间等KPI的绩效仪表板都至关重要。

重要性

时间戳为所有活动提供时间顺序信息,可用于计算时长、识别瓶颈并分析流程绩效随时间的变化。

获取途径

Zendesk Ticket Audits API(/api/v2/tickets/{ticket_id}/audits),每条审计事件的字段created_at。

示例
2023-04-15T10:00:00Z2023-04-15T10:05:12Z2023-04-16T14:30:00Z
数据上次更新时间
LastDataUpdate
表示此流程数据上次刷新的时间戳。
说明

此属性记录从源系统最近一次提取或更新数据的日期和时间。通常,每次刷新后,整个数据集都会使用同一个值。

这项信息对于数据治理和流程挖掘分析的使用者都很重要。它能说明数据的新鲜度,帮助分析人员判断当前查看的信息是否为最新数据。监控运营绩效并依据分析结果及时决策时,这一点尤为重要。

重要性

提供数据新鲜度的重要信息,让使用者了解分析所依据的数据有多新,以及数据上次提取的时间。

获取途径

数据刷新完成后,由ETL/数据管道流程生成的时间戳。

示例
2023-10-27T08:00:00Z2023-10-28T08:00:00Z
活动
ActivityName
事件生命周期中特定时点发生的业务活动或事件名称。
说明

此属性描述事件管理流程中的具体步骤或操作,例如“事件已创建”“工单已分配给客服人员”或“事件已解决”。这些活动根据Zendesk事件日志或审计记录中的系统变更生成。

在流程挖掘中,这些活动的顺序构成流程图,是所有分析的基础。通过分析活动路径,组织可以发现事件的实际处理方式、识别步骤间的瓶颈、衡量返工循环(例如重新打开已解决的工单),并检查流程是否符合既定标准。

重要性

活动顺序构成流程路径,是流程挖掘分析的核心,可用于识别低效环节、偏差和改进机会。

获取途径

根据Zendesk Ticket Audits API中的事件生成。例如,可将status字段的“变更”事件映射为“状态已更改”。

示例
事件已创建工单已分配给客服人员状态已更改为“待处理”事件已解决事件已关闭
源系统
SourceSystem
提取事件数据的系统。
说明

此属性标识流程数据的来源。在此视图中,该值为固定值,例如“Zendesk Support”,表示所有事件和属性均来自该系统。

在整合多个系统数据的环境中,此字段对于区分不同数据源至关重要。它有助于确保数据完整性,并支持按来源开展分析,例如比较Zendesk与其他ITSM工具中的事件管理流程。

重要性

标识数据来源,对于数据治理以及整合多个源系统数据的分析至关重要。

获取途径

在数据转换期间设置的固定值,用于标识数据来源。

示例
Zendesk SupportZendesk
SLA状态
SlaStatus
事件当前的服务级别协议(SLA)状态。
说明

此属性表示事件是否有望达到既定SLA目标、是否已超出目标,或SLA计时器是否已暂停。Zendesk会根据配置的策略自动跟踪SLA指标。

此属性是“SLA合规监控”仪表板的重要组成部分,可直接衡量服务承诺的履行情况。分析SLA超标的时间和原因,有助于组织发现流程薄弱环节并提升服务可靠性。此属性可直接用于“事件SLA达成率”KPI。

重要性

直接衡量服务承诺的履行情况,支持分析SLA超标问题并主动监控,以改善合规表现。

获取途径

Zendesk Ticket Metrics API(/api/v2/ticket_metrics.json),根据sla_policy、breached_at等字段计算得出。

示例
活跃已暂停已超标已完成
事件结束时间
EventEndTime
表示活动完成时间的时间戳。
说明

事件结束时间表示一项活动的结束。在事件日志数据中,某项活动的结束时间通常根据同一案例中顺序流的下一项活动的开始时间推算。案例中最后一项活动的结束时间可能与其开始时间相同。

此属性对于计算单项活动的持续时间(ProcessingTime)和活动间的等待时间至关重要。这些信息是瓶颈分析的基础,能帮助分析人员了解每个步骤耗时多久,以及案例在步骤开始前闲置了多长时间。

重要性

支持计算活动持续时间和等待时间,是开展详细瓶颈分析、识别流程延误的基础。

获取途径

根据同一案例中后续事件的开始时间计算。最后一个事件的结束时间可以与其开始时间或案例关闭时间相同。

示例
2023-04-15T10:05:12Z2023-04-16T14:30:00Z2023-04-16T18:00:00Z
优先级
TicketPriority
分配给事件的优先级,例如“低”“普通”“高”或“紧急”。
说明

事件优先级决定响应和解决问题所需的紧迫程度,是支持团队安排工作优先级和分配资源的重要依据。

在流程分析中,优先级可用于划分事件,以比较其流程和绩效。例如,分析人员可以检查“紧急”事件是否确实比“低”优先级事件解决得更快。优先级也用于监控SLA合规情况,因为SLA通常按优先级设定。“优先级变更率”KPI依赖对此字段变化的跟踪。

重要性

此属性对于划分分析范围、评估优先级设置效果,以及监控不同紧急程度下的SLA合规情况至关重要。

获取途径

Zendesk Tickets API中的priority字段。变更记录在Ticket Audits API中。

示例
低普通高紧急
工单状态
TicketStatus
事件发生时工单的状态,例如“打开”“待处理”或“已解决”。
说明

此属性反映事件生命周期不同阶段的工单状态。Zendesk的标准状态包括新建、打开、待处理、暂停、已解决和已关闭。跟踪此字段的变更,是生成流程挖掘活动的主要方式之一。

分析工单状态是了解流程的基础。它有助于识别事件在特定状态下停留的时长,例如“待处理”通常表示正在等待客户回复。此属性对于确定案例何时完成以及计算解决时间也很重要。

重要性

跟踪状态变化有助于了解流程进展、识别等待时间,并确定事件生命周期的起点和终点。

获取途径

Zendesk Tickets API中的status字段。状态变化记录在Ticket Audits API中。

示例
新建打开待处理已解决已关闭
报告渠道
Channel
最初报告事件所用的渠道,例如“电子邮件”“网页”或“API”。
说明

此属性记录最终用户或系统创建事件工单时使用的方式。了解报告渠道有助于分析事件来源,并据此调整支持流程。

按渠道分析事件可以发现不同的规律。例如,通过电话报告的事件可能比通过电子邮件报告的事件解决得更快。这些信息可用于“事件处理量”仪表板,并支持资源规划和渠道优化。

重要性

按来源分析事件数量和流程绩效,支持针对不同渠道改进流程并分配资源。

获取途径

Zendesk Tickets API中的via.channel字段。

示例
网页电子邮件API电话
指派团队
AssignedGroup
当前负责处理事件的支持团队或小组。
说明

此属性表示负责处理事件的团队。事件通常会在不同支持层级或专业小组之间流转,例如从“L1支持”转至“网络团队”。

这是分析流程移交和识别瓶颈的重要维度。通过监控事件在各小组间的流转,分析人员可以衡量团队间的依赖关系、计算特定团队的排队时间,并优化分派规则。此属性可直接用于“移交与返工分析”仪表板。

重要性

跟踪团队责任归属,有助于分析团队间的移交、识别团队特有的瓶颈并衡量排队时间。

获取途径

Zendesk Tickets API中的group_id字段。变更记录在Ticket Audits API中。

示例
L1支持L2网络团队L3基础设施账单
指派客服
Assignee
当前负责处理事件的客服人员。
说明

此属性用于标识特定时间负责处理事件的客服人员。负责人变更是重要事件,意味着工作从一人移交给另一人。

分析指派客服有助于了解工作量分布、个人绩效和协作模式。跟踪此字段的变化对于计算“每个事件的平均移交次数”KPI,以及识别事件频繁转手的情况至关重要。这类情况可能表明存在知识缺口或分派效率低下。

重要性

标识负责处理事件的客服人员,便于分析工作量和跟踪移交情况,从而发现流程低效之处。

获取途径

Zendesk Tickets API中的assignee_id字段。变更记录在Ticket Audits API中。

示例
John SmithJane Doe服务台自动化
严重程度
Severity
事件对业务造成的影响程度。
说明

严重程度用于界定事件对业务的影响,通常与优先级结合使用,以确定整体紧急程度。在Zendesk中,这通常通过自定义字段配置。

分析严重程度有助于了解正在处理的事件有多紧急。它是“SLA合规监控”和“优先级设置效果指标”等仪表板的重要数据维度。比较不同严重程度事件的流程,可以发现高严重程度事件是否得到了适当的响应速度和资源支持。

重要性

表示事件对业务的影响,便于重点分析严重问题,并确保问题得到高效解决。

获取途径

这通常是自定义字段。请在Zendesk管理中心查看工单字段配置。

示例
1 - 严重2 - 高3 - 中4 - 低
客户组织
Organization
事件请求人所属的组织或公司。
说明

此属性将事件与客户组织关联起来。对于B2B支持环境而言,这一点至关重要,因为不同客户的服务级别和支持流程可能有所不同。

按组织分析事件,可以帮助支持团队监控客户状况、识别影响特定客户的重复问题,并确保履行合同义务。它也是筛选仪表板和报告的重要维度,可用于从客户视角查看绩效。

重要性

支持针对客户开展分析,帮助监控服务级别、识别重点客户的趋势,并有效管理客户关系。

获取途径

Zendesk Tickets API中的organization_id字段。

示例
Global Tech Inc.Innovate SolutionsData Corp
工单类型
TicketType
工单的分类,例如“事件”“问题”“咨询”或“任务”。
说明

此字段根据请求性质对工单进行分类。事件管理流程专门关注类型为“事件”的工单,即IT服务发生意外中断或质量下降的情况。

在分析中,此属性主要用作筛选条件,确保流程视图仅包含事件。它也可用于更广泛的ITSM分析,比较事件、问题或服务请求的处理流程。

重要性

筛选数据以专门分析事件,确保流程分析与事件管理生命周期相关。

获取途径

Zendesk Tickets API中的type字段。

示例
事件问题咨询任务
提交人
Submitter
最初报告事件的最终用户或系统。
说明

此属性用于标识创建工单的人员或实体。它与请求人不同,因为客服人员可能会代他人创建工单。

分析提交人有助于了解问题由谁报告。结合组织数据,还可以识别哪些客户或用户群体遇到大量事件,从而指导主动支持或培训工作。

重要性

标识事件报告的来源,可用于分析特定用户、部门或自动化系统相关的规律。

获取途径

Zendesk Tickets API中的submitter_id字段。

示例
alice.jones@example.combob.williams@example.com系统监控器
是否自动化
IsAutomated
用于标记活动由自动化系统还是人工客服执行的布尔值。
说明

此派生属性有助于区分人工用户执行的事件与系统自动化、触发器或API集成执行的事件。通常通过检查事件作者是否为已知系统用户来确定。

了解自动化程度对于现代流程分析至关重要。它有助于评估自动化规则的效果、发现可自动化的人工任务,并衡量自动化对效率和解决时间的影响。此属性还可用于比较自动化活动与人工活动的流程。

重要性

区分人工操作和系统操作,这对于分析自动化对流程效率的影响以及发现新的自动化机会至关重要。

获取途径

检查事件作者(Ticket Audits API中的author_id)是否对应已知系统用户或自动化用户后得出。

示例
truefalse
是否首次联系解决
IsFirstContactResolution
如果事件由最初指派的客服人员或团队解决,且期间没有发生移交,则此布尔值为真。
说明

首次联系解决率(FCR)是衡量支持中心效率和客户满意度的重要指标。此计算属性用于标记未转派给其他客服人员或团队便已解决的事件。

通常通过检查工单是否在仍由最初指派的客服人员和团队负责时达到“已解决”状态来判断。在流程挖掘中,这有助于直接计算FCR,并比较首次联系解决事件与需要升级处理事件的流程路径,从而发现提升一线支持能力的机会。

重要性

直接衡量首次支持接触的效率,并帮助发现提前解决问题的机会。

获取途径

计算得出的布尔值。如果工单状态为“已解决”或“已关闭”,且整个事件生命周期中只有一名唯一的指派客服人员或一个指派团队,则为真。

示例
truefalse
标签
Tags
用于分类和补充事件背景信息的一组标签。
说明

标签是灵活的标记,可添加到工单中以补充背景信息、辅助分类或分派。客服人员可以手动添加,也可以通过触发器和自动化规则自动添加。

标签是流程挖掘分析的重要数据来源。您可以用它们创建更细致的分析分组,例如筛选与特定产品发布(“launch_q4”)或已知服务中断(“outage_20231027”)相关的事件。这种灵活性支持超越标准工单字段的深入分析。

重要性

灵活分类和筛选事件,支持基于具体背景开展详细分析,弥补标准字段的不足。

获取途径

Zendesk Tickets API中的tags字段。

示例
vip_usernetwork_issueoutage_20231027billing_related
根本原因类别
RootCauseCategory
事件根本原因所属的上层类别。
说明

此属性用于对事件发生的根本原因进行分类。通常在事件生命周期接近结束时记录,例如在事后复盘或问题管理过程中,并存储在自定义字段中。

这些数据对于“根本原因识别准确率”仪表板和“根本原因分析覆盖率”KPI至关重要。按根本原因分析事件有助于发现重复问题,指导团队实施永久性修复并减少未来事件数量,从而将工作重点从被动应急转向主动预防问题。

重要性

通过对事件原因分类,支持主动的问题管理,帮助发现趋势并预防问题再次发生。

获取途径

这通常是自定义工单字段。请在Zendesk管理中心查看工单字段配置。

示例
软件缺陷硬件故障用户操作错误网络中断
案例持续时间
CaseDuration
从事件创建到最终关闭所经过的总时间。
说明

此计算指标表示单个事件端到端的周期时间,计算方法是用第一个事件(例如“事件已创建”)的时间戳减去最后一个事件(例如“事件已关闭”)的时间戳。

案例持续时间是衡量整体流程效率的核心关键绩效指标(KPI)。仪表板常用它展示平均周期时间、识别处理时间过长的案例并分析趋势。它从整体上衡量流程处理和解决事件的速度。

重要性

这是衡量整体流程速度并识别导致解决时间过长因素的重要KPI。

获取途径

对每个事件ID,计算最后一个事件与第一个事件的时间戳之差。

示例
25920060480086400
满意度评分
SatisfactionRating
事件解决后,最终用户提供的满意度评分。
说明

此属性记录客户对支持体验的反馈,通常在工单解决后通过调查收集。Zendesk常见的评分为“良好”或“不满意”。

满意度评分虽不能直接衡量流程效率,却是重要的结果指标。在流程挖掘中,可以将其与流程变体关联,了解哪些解决路径能带来更高的客户满意度。例如,移交次数较多的事件是否会得到较低评分?

重要性

提供重要的结果指标,可与流程特征关联分析,了解流程绩效如何影响用户满意度。

获取途径

Zendesk Ticket Metrics API(/api/v2/ticket_metrics.json)中的satisfaction_rating.score字段。

示例
良好不满意已提供未提供
移交次数
HandoffCount
事件转派给其他客服人员或团队的总次数。
说明

此计算指标用于量化事件责任转交的次数。案例中Assignee或AssignedGroup字段每变更一次,计数就增加一次。

移交是事件管理中常见的低效和延误来源。移交次数过多可能表明分派规则不明确、支持团队存在知识缺口,或流程过于复杂。此指标是“每个事件的平均移交次数”KPI的计算依据,也是“移交与返工分析”仪表板的重要指标。

重要性

量化责任转交造成的流程阻力,帮助定位分派效率低下和知识缺口,从而缩短解决时间。

获取途径

统计事件中AssignedGroup或Assignee字段的变更次数。

示例
0135
必填 建议填写 选填

事件管理活动

建议在事件日志中记录以下关键流程步骤和里程碑,以便准确发现并分析流程。
6 建议填写 7 选填
活动 说明
事件已关闭
工单永久关闭时,事件生命周期随之结束。在Zendesk中,工单通常会在解决一段时间后自动关闭,并作为最终状态变更记录。
重要性

这是流程的最终结束活动。从“事件已创建”到此事件的总时长即为流程总时长,可用于全面衡量周期时间。

获取途径

根据工单审计日志中的“变更”事件记录:当“status”字段的新值变为“closed”时,即表示工单已关闭。

采集

根据“status”字段变为“closed”的“变更”事件识别。

事件类型 explicit
事件已创建
在Zendesk中创建新工单时,事件生命周期由此开始。Zendesk工单创建审计日志会明确记录此事件,作为每个案例的起点。
重要性

这是主要的开始活动。分析此事件与其他事件之间的时间间隔,对于衡量工单的整体生命周期和首次响应时间至关重要。

获取途径

Zendesk工单审计日志会明确记录此事件。每个新工单都会生成带有相应时间戳的“创建”事件。

采集

直接取自审计日志中的工单创建事件。

事件类型 explicit
事件已解决
客服人员实施解决方案并将工单标记为“solved”时,即到达这一关键节点。工单审计日志会将此操作明确记录为状态变更。
重要性

这是主要的解决活动,也是衡量解决时间的关键节点。此事件与“事件已关闭”之间的时间,代表等待用户确认或系统自动关闭的时长。

获取途径

根据工单审计日志中的“变更”事件记录:当“status”字段的新值变为“solved”时,即表示事件已解决。

采集

根据“status”字段变为“solved”的“变更”事件识别。

事件类型 explicit
工单已分配给客服人员
工单分配给特定客服人员处理时,会发生此活动。工单审计历史会明确记录此事件,表示某位人员已接手处理。
重要性

这一关键节点对于衡量首次分配所需时间至关重要,也是分析交接、返工和首次联系解决率的基础。

获取途径

当工单审计日志中的“assignee_id”字段被填写或更改时,即会记录此事件。首次分配是计算KPI的重要节点。

采集

根据工单审计日志中“assignee_id”字段的“变更”事件识别。

事件类型 explicit
工单已重新分配
初次分配后,工单责任转交给其他客服人员或支持组时,即会发生此事件。工单审计历史会明确记录此变更。
重要性

重新分配对于分析交接和返工至关重要。频繁重新分配通常意味着初始路由不准确、问题复杂或流程存在瓶颈。

获取途径

工单首次分配后,如果审计日志中“assignee_id”或“group_id”字段出现“变更”事件,即会记录此事件。

采集

根据后续发生的“assignee_id”或“group_id”字段“变更”事件识别。

事件类型 explicit
状态已更改为“打开”
表示客服人员已开始主动处理事件。通常根据工单“status”字段从“new”变为“open”推断,标志着调查和诊断阶段开始。
重要性

此事件标志着工单从排队转为主动处理。工单从“new”状态变为“open”之前所用的时间,是衡量首次响应时间的重要指标。

获取途径

通过工单审计日志推断:识别“status”字段新值为“open”、旧值为“new”的“变更”事件。

采集

根据状态字段从“new”变为“open”推断。

事件类型 inferred
SLA目标未达成
表示工单未能达到既定服务级别协议目标,例如首次回复时间或解决时间。此事件根据SLA策略定义和工单更新时间计算。
重要性

此事件可直接用于监控SLA达成情况。找出未达标的时间和原因,是提升服务可靠性和客户信任的关键。

获取途径

这是一个计算得出的事件。可分析工单关联的“sla_policy_metrics”数据,并使用每个SLA目标的“breached_at”时间戳推导此事件。

采集

根据工单SLA指标数据中的“breached_at”时间戳推导。

事件类型 calculated
工单已分配至组
表示事件首次被路由或分流至特定支持组。这通常是分配处理责任的第一步,并作为明确的变更事件记录在工单审计历史中。
重要性

跟踪组分配情况有助于分析初始分流效率,并找出工单转至正确团队前的延误。

获取途径

当工单审计日志中的“group_id”字段被设置或更改时,即会记录此事件。创建后首次发生的此类变更即为初始分配。

采集

根据工单审计日志中“group_id”字段的“变更”事件识别。

事件类型 explicit
已发送公开回复
表示支持人员向最终用户发送了消息。每当工单添加公开评论时,Zendesk都会明确记录此事件。
重要性

跟踪公开回复有助于了解沟通频率;分析用户确认延误时,这也是时间线中的重要信息。

获取途径

根据工单评论数据记录。当评论的“public”属性为true时,即视为公开评论。

采集

工单新增“public: true”评论时记录此事件。

事件类型 explicit
已提交用户满意度评分
表示最终用户对所获支持服务进行满意度评分。工单解决后,Zendesk会明确记录此事件。
重要性

分析满意度评分可为客服人员表现和流程有效性提供重要反馈,并将流程指标与客户结果联系起来。

获取途径

根据工单关联的满意度评分数据记录。通常包括评分(“良好”或“较差”)和可选评论。

采集

工单提交满意度评分时记录此事件。

事件类型 explicit
已添加内部备注
此活动表示内部协作,即客服人员为其他团队成员在工单中添加私人备注。当评论标记为非公开时,系统会明确记录此活动。
重要性

分析内部备注有助于了解需要协作处理的复杂问题;但备注过多也可能表明存在知识缺口或流程低效。

获取途径

根据工单评论数据记录。当评论的“public”属性为false时,即视为内部备注。

采集

工单新增“public: false”评论时记录此事件。

事件类型 explicit
已设置优先级
确定事件的优先级,例如低、普通、高或紧急。系统会将其记录为明确的变更事件,用于决定工单的紧急程度和所需响应时间。
重要性

跟踪优先级的设置时间和方式,对于“优先级有效性指标”仪表板至关重要,可确保及时处理严重问题。

获取途径

根据工单审计日志中“priority”字段的“变更”事件记录。还可以跟踪后续变更,以衡量优先级变更率KPI。

采集

根据工单审计日志中“priority”字段的“变更”事件识别。

事件类型 explicit
状态已更改为“待处理”
表示流程暂停,正在等待请求者回复。根据工单“status”字段变为“pending”推断此事件。
重要性

此活动对于计算用户确认等待时间至关重要。在此状态停留过久会显著延长整体解决时间,并反映沟通延误。

获取途径

通过工单审计日志推断:识别“status”字段新值为“pending”的“变更”事件。

采集

根据状态字段变为“pending”推断。

事件类型 inferred
建议填写 选填

数据提取指南

如何从Zendesk Support获取数据

准备好开始了吗?

使用此模板简化数据准备工作,深入了解事件管理绩效。立即开始优化流程。

优化事件管理,更快解决问题

将MTTR缩短35%,减少重复事件,提升满意度。

开始免费试用

无需信用卡,几分钟即可开始改进