您的事件管理数据模板
您的事件管理数据模板
- 建议收集的属性
- 流程映射需跟踪的关键活动
- 实用数据提取指南
事件管理属性
| 名称 | 说明 | ||
|---|---|---|---|
|
事件ID
TicketId
|
系统为每个事件工单生成的唯一标识符。 | ||
|
说明
事件ID是Zendesk Support中唯一标识每个事件案例的主键。在流程挖掘中,它作为案例ID,将事件创建到关闭期间的所有相关活动、状态变更和通信关联起来。 在分析中,该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
|
事件生命周期中特定时间点发生的业务活动或事件名称。 | ||
|
说明
此属性描述事件管理流程中的具体步骤或操作,例如“Incident Created”“Ticket Assigned to Agent”或“Incident Resolved”。这些活动来自Zendesk的事件日志或审计轨迹数据,其中记录了系统变更。 在流程挖掘中,这些活动的顺序构成流程图,是所有分析的基础。通过分析活动流转,组织可以发现事件实际经过的路径,识别步骤之间的瓶颈,衡量返工循环(例如重新打开已解决的工单),并检查流程是否符合既定标准。
为什么重要
活动顺序定义了流程,是流程挖掘分析的核心,用于识别低效、偏差和改进机会。
获取位置
来自Zendesk Ticket Audits API中的事件。例如,status字段上的Change事件可以映射为“Status Changed”。
示例
事件已创建工单已分配至代理状态已变更为Pending事件已解决事件已关闭
|
|||
|
源系统
SourceSystem
|
提取事件数据的系统。 | ||
|
说明
此属性用于标识流程数据的来源。在此视图中,该值通常是固定的,例如“Zendesk Support”,表示所有事件和属性均来自该系统。 在整合多个系统数据的环境中,该字段对于区分不同数据源至关重要。它有助于确保数据完整性,并支持按来源分析,例如比较Zendesk与其他ITSM工具中的事件管理流程。
为什么重要
标识数据来源,对于数据治理以及整合多个源系统数据的分析至关重要。
获取位置
在数据转换期间设置的静态值,用于标识数据来源。
示例
Zendesk SupportZendesk
|
|||
|
SLA状态
SlaStatus
|
事件当前的服务级别协议(SLA)状态。 | ||
|
说明
此属性表示事件是否按计划达到既定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
|
分配给事件的优先级,例如“Low”“Normal”“High”或“Urgent”。 | ||
|
说明
事件的优先级决定响应和解决所需的紧迫程度,是支持团队进行工作排序和资源分配的关键因素。 在流程分析中,优先级用于划分事件,以比较不同优先级下的流程和绩效。例如,分析人员可以检查“紧急”事件是否确实比“低”优先级事件解决得更快。优先级还用于监控SLA合规性,因为SLA通常根据优先级设定。“优先级变更率”KPI依赖于对该字段变更的跟踪。
为什么重要
此属性对于分组分析、评估优先级设置效果以及监控不同紧急程度下的SLA合规性至关重要。
获取位置
Zendesk Tickets API的priority字段。变更记录在Ticket Audits API中。
示例
低正常高紧急
|
|||
|
受理代理
Assignee
|
当前负责处理事件的支持代理。 | ||
|
说明
此属性用于标识特定时间点负责事件的代理。受理人的变更属于关键事件,表示工作已从一名人员交接给另一名人员。 分析受理代理有助于了解工作负载分配、个人表现和协作模式。跟踪该字段的变更,对于计算“Average Handoffs per Incident”KPI以及识别事件频繁转交的情况至关重要,因为这可能表明存在知识缺口或路由低效。
为什么重要
标识负责代理,支持工作负载分析和交接跟踪,对于发现流程低效至关重要。
获取位置
Zendesk Tickets API的assignee_id字段。变更记录在Ticket Audits API中。
示例
John SmithJane Doe服务台自动化
|
|||
|
受理组
AssignedGroup
|
当前负责处理事件的支持团队或组。 | ||
|
说明
此属性表示负责事件的团队。事件通常会在不同支持层级或专业组之间流转,例如从“L1 Support”转至“Network Team”。 这是分析流程交接和识别瓶颈的重要维度。通过监控事件在各组之间的流转,分析人员可以衡量团队间依赖关系、计算特定团队的队列等待时间并优化路由规则。它直接支持“Handoffs and Rework Analysis”仪表板。
为什么重要
跟踪团队责任归属,对于分析团队间交接、识别团队特定瓶颈和衡量队列等待时间至关重要。
获取位置
Zendesk Tickets API的group_id字段。变更记录在Ticket Audits API中。
示例
一级支持二级网络团队三级基础设施支持账单
|
|||
|
工单状态
TicketStatus
|
事件发生时事件工单的状态,例如“Open”“Pending”或“Solved”。 | ||
|
说明
此属性反映事件工单在生命周期不同阶段的状态。Zendesk的标准状态包括new、open、pending、on-hold、solved和closed。跟踪该字段的变更,是生成流程挖掘活动的主要方式。 分析工单状态是理解流程的基础。它有助于识别事件在特定状态下停留的时间,例如“Pending”通常表示等待客户回复。该属性也是定义案例完成状态和计算解决时间的关键。
为什么重要
跟踪状态变更是了解流程进展、识别等待时间以及确定事件生命周期起止点的关键。
获取位置
Zendesk Tickets API的status字段。变更记录在Ticket Audits API中。
示例
新建开放待处理已解决已关闭
|
|||
|
报告渠道
Channel
|
最初报告事件的渠道,例如“Email”“Web”或“API”。 | ||
|
说明
此属性记录最终用户或系统创建事件工单所使用的方式。了解报告渠道对于分析事件来源并相应调整支持流程非常重要。 按渠道分析事件可以发现不同模式。例如,通过电话报告的事件,其解决时间可能短于通过电子邮件报告的事件。该信息支持“Incident Throughput Volume”仪表板,并有助于资源规划和渠道优化。
为什么重要
帮助按来源分析事件量和流程表现,支持针对特定渠道改进流程并分配资源。
获取位置
Zendesk Tickets API的via.channel字段。
示例
Web电子邮件API电话
|
|||
|
严重程度
Severity
|
事件对业务造成的影响程度。 | ||
|
说明
严重程度定义事件的业务影响,通常与优先级结合使用,以确定整体紧急程度。在Zendesk中,它通常配置为自定义字段。 分析严重程度有助于了解所处理事件的关键程度。它是“SLA合规监控”和“优先级设置有效性指标”等仪表板的重要数据维度。对比不同严重程度事件的流程,可以发现高严重程度事件是否获得了适当的处理速度和资源。
为什么重要
表示事件的业务影响,支持聚焦最关键的问题进行分析,并确保这些问题得到高效解决。
获取位置
通常为自定义字段。请在Zendesk管理中心检查Ticket Fields配置。
示例
1-严重2-高3-中4-低
|
|||
|
交接次数
HandoffCount
|
事件被重新分配给其他客服或团队的总次数。 | ||
|
说明
此计算指标量化事件责任转移的次数。每当Assignee或AssignedGroup字段发生变化,该案例的计数就增加一次。 交接是事件管理中效率低下和延迟的常见来源。交接次数较多可能表明路由规则不清晰、支持团队存在知识缺口,或流程过于复杂。此指标是“每个事件的平均交接次数”KPI的基础,也是“交接与返工分析”仪表板的关键指标。
为什么重要
量化责任转移造成的流程阻力,帮助定位延长解决时间的路由低效和知识缺口。
获取位置
通过统计事件中AssignedGroup或Assignee字段发生变化的次数计算。
示例
0135
|
|||
|
客户组织
Organization
|
事件请求方所属的组织或公司。 | ||
|
说明
此属性将事件与客户组织关联起来。对于B2B支持环境而言,这一点至关重要,因为不同客户的服务级别和支持流程可能有所不同。 按组织分析事件,可以帮助支持团队监控客户健康度、识别影响特定客户的重复问题,并确保履行合同义务。它也是筛选仪表板和报表、提供以客户为中心的表现视图的重要维度。
为什么重要
支持按客户进行分析,帮助监控服务级别、识别重点客户的趋势并有效管理客户关系。
获取位置
Zendesk Tickets API的organization_id字段。
示例
Global Tech Inc.Innovate SolutionsData Corp
|
|||
|
工单类型
TicketType
|
工单的分类,例如“Incident”、“Problem”、“Question”或“Task”。 | ||
|
说明
此字段根据请求性质对工单进行分类。事件管理流程专门关注类型为“Incident”的工单,即IT服务发生计划外中断或质量下降的情况。 在分析中,此属性主要用作筛选条件,确保流程视图仅包含事件。它也可用于更广泛的ITSM分析,对比事件、问题和服务请求的处理流程。
为什么重要
支持筛选数据,专门聚焦事件,确保流程分析与事件管理生命周期相关。
获取位置
Zendesk Tickets API,字段类型。
示例
事件问题咨询任务
|
|||
|
提交人
Submitter
|
最初报告事件的最终用户或系统。 | ||
|
说明
此属性用于标识创建工单的人员或实体。它不同于请求方,因为代理可能会代表他人创建工单。 在分析中,提交人可用于了解问题的报告者。结合组织数据后,还可以识别特定客户或用户群体是否产生了大量事件,从而指导主动支持或培训工作。
为什么重要
标识事件报告来源,可用于发现与特定用户、部门或自动化系统相关的模式。
获取位置
Zendesk Tickets API的submitter_id字段。
示例
alice.jones@example.combob.williams@example.com系统监控
|
|||
|
是否自动化
IsAutomated
|
布尔标记,用于表示某项活动由自动化系统还是人工客服执行。 | ||
|
说明
此派生属性有助于区分人工用户执行的事件与系统自动化、触发器或API集成执行的事件。通常通过检查事件作者是否为已知系统用户来确定。 了解自动化程度对于现代流程分析至关重要。它有助于评估自动化规则的有效性,识别可自动化的人工任务,并衡量自动化对效率和解决时长的影响。此属性还可用于对比自动化活动与人工活动的流程。
为什么重要
区分人工操作与系统操作,对于分析自动化对流程效率的影响以及发现新的自动化机会至关重要。
获取位置
通过检查事件作者(Ticket Audits API中的author_id)是否对应已知系统用户或自动化用户来派生。
示例
truefalse
|
|||
|
是否首次联系解决
IsFirstContactResolution
|
布尔标记。如果事件由首次分配的客服或团队在没有任何交接的情况下解决,则为true。 | ||
|
说明
首次联系解决(FCR)是衡量支持中心效率和客户满意度的关键指标。此计算属性标记无需重新分配给其他客服或团队即可解决的事件。 通常通过检查工单是否在仍分配给初始客服和团队的情况下达到“Solved”状态来判断。在流程挖掘中,这支持直接计算FCR率,并对比FCR事件与需要升级处理事件的流程路径,从而帮助发现赋能一线支持团队的机会。
为什么重要
直接衡量首次支持触点的效率,并帮助发现将解决环节前移的机会。
获取位置
计算得出的布尔标记。如果工单状态为“solved”或“closed”,且在整个事件生命周期内只有一个唯一的受理人或受理团队,则为True。
示例
truefalse
|
|||
|
标签
Tags
|
应用于事件的标签列表,用于分类和补充上下文。 | ||
|
说明
标签是灵活的标记,可添加到工单中,用于补充上下文、分类或路由。客服人员可以手动添加标签,也可以通过触发器和自动化规则自动添加。 标签是流程挖掘分析的重要数据来源。您可以利用标签创建细分分析,例如筛选与特定产品发布(“launch_q4”)或已知服务中断(“outage_20231027”)相关的事件。这种灵活性支持超越标准工单字段的深入调查。
为什么重要
提供灵活的事件分类和筛选方式,支持基于具体上下文的详细分析,弥补仅使用标准字段的不足。
获取位置
Zendesk Tickets API,字段tags。
示例
VIP用户网络问题中断_20231027账单相关
|
|||
|
根因类别
RootCauseCategory
|
导致事件发生的根本原因所属的高层级类别。 | ||
|
说明
此属性用于分类事件发生的根本原因。它通常在事件生命周期接近结束时采集,作为事后复盘或问题管理流程的一部分,并存储在自定义字段中。 这些数据对于“根因识别准确率”仪表板和“RCA覆盖率”KPI至关重要。按根因分析事件有助于识别重复发生的问题,为实施永久性修复和减少未来事件数量提供依据。这样可以将重点从被动救火转向主动预防问题。
为什么重要
通过分类事件原因,支持主动的问题管理,帮助识别趋势并防止问题再次发生。
获取位置
通常为自定义工单字段。请在Zendesk管理中心检查Ticket Fields配置。
示例
软件缺陷硬件故障用户错误网络中断
|
|||
|
案例持续时间
CaseDuration
|
从事件创建到最终关闭所经过的总时间。 | ||
|
说明
此计算指标表示单个事件端到端的周期时间。计算方式为第一个事件(例如“Incident Created”)与最后一个事件(例如“Incident Closed”)时间戳之差。 案例持续时间是衡量整体流程效率的主要关键绩效指标(KPI)。仪表板广泛使用该指标展示平均周期时间、识别长期未结案例并分析一段时间内的趋势。它从整体上衡量流程处理和解决事件的速度。
为什么重要
这是衡量整体流程速度并识别导致解决时间过长因素的关键KPI。
获取位置
对每个Incident ID,计算最后一个事件与第一个事件时间戳之差。
示例
25920060480086400
|
|||
|
满意度评分
SatisfactionRating
|
事件解决后,最终用户提供的满意度评分。 | ||
|
说明
此属性记录客户对支持体验的反馈,通常在工单解决后通过调查收集。Zendesk中的常见评分为“Good”或“Bad”。 满意度评分虽然不是直接衡量流程效率的指标,但可作为关键结果指标。在流程挖掘中,可以将其与流程变体关联,了解哪些解决路径能带来更高的客户满意度。例如,交接次数较多的事件是否会获得更低评分?
为什么重要
提供关键结果指标,可与流程特征关联,帮助了解流程绩效如何影响用户满意度。
获取位置
Zendesk Ticket Metrics API(/api/v2/ticket_metrics.json),字段satisfaction_rating.score。
示例
良好不良已提供未提供
|
|||
事件管理活动
| 活动 | 说明 | ||
|---|---|---|---|
|
事件已关闭
|
工单永久关闭时,事件生命周期最终结束。在Zendesk中,这通常会在工单解决一段时间后自动发生,并作为最终状态变更记录。 | ||
|
为什么重要
这是流程的最终结束活动。从“Incident Created”到此事件的时间即为总流程时长,可提供端到端的周期时间视图。
获取位置
通过工单审计日志中的“Change”事件获取,该事件中“status”字段的新值变为“closed”。
采集
通过“status”字段变更为“closed”的“Change”事件识别。
事件类型
explicit
|
|||
|
事件已创建
|
新工单在Zendesk中创建时,事件生命周期由此开始。该事件会通过Zendesk工单创建审计日志明确记录,作为每个案例的起点。 | ||
|
为什么重要
这是主要的开始活动。分析该事件与其他事件之间的时间,对于衡量工单的整体生命周期时长和初始响应时间至关重要。
获取位置
这是Zendesk工单审计日志中明确记录的事件。每个新工单都会生成带有相应时间戳的“Create”事件。
采集
直接来自审计日志中的工单创建事件。
事件类型
explicit
|
|||
|
事件已解决
|
当代理实施解决方案并将工单标记为“solved”时,就会达到这一关键里程碑。这是一个明确操作,会作为状态变更记录在工单审计日志中。 | ||
|
为什么重要
这是主要的解决活动,也是衡量解决耗时的关键节点。该事件与“Incident Closed”之间的时间,代表用户确认或自动关闭周期。
获取位置
通过工单审计日志中的“Change”事件获取,该事件中“status”字段的新值变为“solved”。
采集
通过“status”字段变更为“solved”的“Change”事件识别。
事件类型
explicit
|
|||
|
工单已分配至代理
|
当工单分配给特定代理处理时,就会发生此活动。这是工单审计历史中明确记录的事件,表示某位人员已接手负责。 | ||
|
为什么重要
这一里程碑对于衡量首次分配耗时至关重要,也是分析交接、返工和首次联系解决率的基础。
获取位置
当工单审计日志中的“assignee_id”字段被填充或变更时记录。首次分配是计算KPI的重要里程碑。
采集
通过工单审计日志中针对“assignee_id”字段的“Change”事件识别。
事件类型
explicit
|
|||
|
工单已重新分配
|
初始分配后,工单责任从一名代理或一个组转移给另一名代理或另一个组时,就会发生此事件。这是工单审计历史中明确跟踪的事件。 | ||
|
为什么重要
重新分配对于分析交接和返工至关重要。频繁重新分配通常意味着初始路由不准确、问题复杂或流程存在瓶颈。
获取位置
通过工单审计日志识别“assignee_id”或“group_id”字段在首次填充后的“Change”事件。
采集
通过后续针对“assignee_id”或“group_id”字段的“Change”事件识别。
事件类型
explicit
|
|||
|
状态已变更为Open
|
表示代理已开始积极处理事件。通常通过工单“status”字段从“new”变更为“open”来推断,标志着调查和诊断阶段开始。 | ||
|
为什么重要
该事件标志着流程从排队转入主动处理。工单在“new”状态下停留至转为“open”所用的时间,是衡量初始响应时间的重要指标。
获取位置
通过工单审计日志识别“Change”事件进行推断:该事件中“status”字段的新值为“open”,旧值为“new”。
采集
根据状态字段从“new”变更为“open”推断。
事件类型
inferred
|
|||
|
工单已分配至组
|
表示将事件初步路由或分诊至特定支持组。这通常是明确责任归属的第一步,并作为明确的变更事件记录在工单审计历史中。 | ||
|
为什么重要
跟踪组分配情况有助于分析初始分诊效率,并识别工单被路由至正确团队前的延迟。
获取位置
每当工单审计日志中的“group_id”字段被设置或变更时记录。创建后的首次变更即为初始分配。
采集
通过工单审计日志中针对“group_id”字段的“Change”事件识别。
事件类型
explicit
|
|||
|
已发送公开回复
|
表示支持代理向最终用户发送的沟通内容。在Zendesk中,当工单新增公开评论时,会明确记录此事件。 | ||
|
为什么重要
跟踪公开回复有助于了解沟通频率,也是分析用户确认延迟时的重要时间线节点。
获取位置
从工单评论数据中获取。当评论的“public”属性为true时,视为公开评论。
采集
工单新增“public: true”评论时记录此事件。
事件类型
explicit
|
|||
|
已添加内部备注
|
该活动表示内部协作:代理为其他团队成员在工单中添加私密备注。当评论被标记为非公开时,会明确记录此活动。 | ||
|
为什么重要
分析内部备注有助于了解需要协作处理的复杂问题,但数量过多可能表明存在知识缺口或流程低效。
获取位置
从工单评论数据中获取。当评论的“public”属性为false时,视为内部备注。
采集
工单新增“public: false”评论时记录此事件。
事件类型
explicit
|
|||
|
已设置优先级
|
定义事件的优先级,例如Low、Normal、High或Urgent。该信息会作为明确的变更事件记录,并决定工单的紧急程度和所需响应时间。 | ||
|
为什么重要
跟踪优先级的设置时间和方式,对于“Prioritization Effectiveness Metrics”仪表板至关重要,可确保关键问题得到及时处理。
获取位置
通过工单审计日志中“priority”字段的“Change”事件记录。还可以跟踪后续变更,以衡量Priority Change Rate KPI。
采集
通过工单审计日志中针对“priority”字段的“Change”事件识别。
事件类型
explicit
|
|||
|
已违反SLA目标
|
表示工单未达到规定的服务级别协议要求,例如首次回复时间或解决时间。该事件根据SLA策略定义和工单更新时间戳计算得出。 | ||
|
为什么重要
该事件直接支持SLA合规监控。识别违反SLA的时间和原因,是提升服务可靠性与客户信任的基础。
获取位置
这是一个计算得出的事件。可以分析与工单关联的“sla_policy_metrics”数据,并使用每个SLA目标的“breached_at”时间戳推导。
采集
根据工单SLA指标数据中的“breached_at”时间戳推导。
事件类型
calculated
|
|||
|
状态已变更为Pending
|
表示流程暂停,等待请求方回复。该事件通过工单“status”字段变更为“pending”来推断。 | ||
|
为什么重要
该活动对于计算User Confirmation Wait Time至关重要。在此状态下停留时间过长,可能显著拉长整体解决时间,并暴露沟通延迟。
获取位置
通过工单审计日志识别“Change”事件进行推断:该事件中“status”字段的新值为“pending”。
采集
根据状态字段变更为“pending”推断。
事件类型
inferred
|
|||
|
用户满意度已评分
|
表示最终用户为所获得的支持服务提交满意度评分的时间点。这是工单解决后由Zendesk明确记录的事件。 | ||
|
为什么重要
分析满意度评分可以为代理表现和流程有效性提供重要反馈,将流程指标与客户结果联系起来。
获取位置
从与工单关联的满意度评分数据中获取。通常包括评分(“good”或“bad”)以及可选评论。
采集
工单提交满意度评分时记录此事件。
事件类型
explicit
|
|||
提取指南
优化事件管理,立即加快解决速度
将MTTR降低35%,消除重复事件,提升满意度。
无需信用卡,几分钟内即可开始改进