数据模板:事件管理
事件管理数据模板
- 建议收集的属性
- 流程需重点跟踪的活动
- 适配您数据系统的数据抽取指南
事件管理属性
| 名称 | 描述 | ||
|---|---|---|---|
|
事件ID
IncidentId
|
每条事件记录的唯一标识符。 | ||
|
描述
Incident ID是每个事件的主键,从创建到关闭对其进行唯一标识。它关联所有相关活动、日志和变更,使我们能够获得该事件生命周期的端到端视图。 在流程挖掘中,该属性至关重要,因为它定义了案例(Case)。所有具有相同Incident ID的事件都被视为同一流程实例的一部分,从而可以重建并分析单个事件的处理过程。
为何重要
这是贯穿事件生命周期、串联所有活动的关键标识符,使端到端流程分析成为可能。
获取方式
这是 'HPD:Help Desk' 表单中的 'Incident Number' 字段(字段ID:1000000161)。
示例
INC000001234567INC000002345678INC000003456789
|
|||
|
事件timestamp
EventTimestamp
|
活动发生的精确日期和时间。 | ||
|
描述
该时间戳记录事件生命周期中某个步骤发生的时间,为从原始数据重建流程提供所需的时间顺序。 事件时间戳对所有基于时间的分析都至关重要,包括计算各活动之间的周期时长、识别事件长时间等待的瓶颈,以及衡量整体解决时长。它是流程分析的时间主干。
为何重要
该时间戳提供事件的时间顺序,这对于计算时长、识别瓶颈以及了解流程时间线至关重要。
获取方式
来自'HPD:Help Desk'表单中的'Last Modified Date'(字段ID:6)或其他指定日期字段;历史事件则来自审计日志的时间戳字段。
示例
2023-10-26T10:00:00Z2023-10-26T10:15:32Z2023-10-27T14:22:05Z
|
|||
|
活动名称
ActivityName
|
事件生命周期中发生的具体事件或任务名称。 | ||
|
描述
该属性描述在某一时间点对事件执行的具体活动,例如'Incident Reported'、'Group Assigned'、'Incident Resolved'。这些活动构成流程图的基础。 分析这些活动的先后顺序与发生频率,可揭示真实的流程走向,识别常见路径,并突出与标准流程的偏差。这对于理解为解决事件所采取的具体行动至关重要。
为何重要
活动定义了流程图中的各个步骤,可用于可视化并分析事件管理工作流。
获取方式
通常来源于 'HPD:Help Desk' 表单中 'Status'(Field ID: 7)与 'Status_Reason' 的变更,或来源于 'HPD:Help Desk Audit Log' 表单。
示例
事件已上报分配到支持组解决方案已实施事件已关闭
|
|||
|
事件状态
IncidentStatus
|
事件在该时间点的当前或历史状态。 | ||
|
描述
该属性表示事件所处的状态,如'New'、'In Progress'、'Pending'、'Resolved'或'Closed'。它提供事件在生命周期中所处阶段的快照。 分析状态变化是理解事件管理流程的基础。可用于定义活动、衡量在不同状态下的停留时间(例如事件处于'Pending'的时长),并识别可能卡住或长时间无进展的事件。
为何重要
跟踪状态变更是理解事件推进情况的关键,也便于衡量其在“Pending”或“In Progress”等特定状态下的停留时长。
获取方式
这是 'HPD:Help Desk' 表单中的 'Status' 字段(字段ID:7)。
示例
新建已分配进行中挂起已解决已结案
|
|||
|
事件类别
IncidentCategory
|
事件分类,通常按层级划分。 | ||
|
描述
事件分类用于以结构化方式对事件进行归类,通常采用多级层次(如一级:硬件,二级:笔记本,三级:电池)。这些数据是路由、报告与趋势分析的基础。 在流程挖掘中,我们会按类别分别分析不同类型的事件。通过比较初始与最终类别,它为“事件分类准确性”仪表板提供支持,并帮助识别“根因趋势”仪表板中的模式。
为何重要
分类使路由更准确,便于开展趋势分析,并可在不同事件类型之间进行绩效对比。
获取方式
这些字段来自'HPD:Help Desk'表单中的'Operational Categorization Tier 1/2/3'。
示例
硬件 > 笔记本 > 电池软件 > 企业应用 > 登录错误网络 > 连接 > Wi‑Fi
|
|||
|
事件解决时间
IncidentResolutionTime
|
从事件首次上报到解决所经历的总时长。 | ||
|
描述
这是一个计算指标,表示从 'Incident Reported' 到 'Incident Resolved' 活动之间的持续时间,是事件管理中最常用、最重要的KPI之一。 该指标直接衡量解决流程的效率。在流程挖掘中,它是核心绩效指标之一,常按事件类别、优先级和团队维度进行分析,以发现改进空间,并跟踪流程变更随时间带来的影响。
为何重要
这是衡量事件管理端到端效率的关键KPI,直接影响用户满意度。
获取方式
对每个Incident ID,以“Incident Resolved”事件的时间戳减去首个事件的时间戳来计算。
示例
2592003600864000
|
|||
|
优先级
Priority
|
事件被设定的优先级,用于决定处理的紧急程度。 | ||
|
描述
优先级通常由影响和紧急程度综合评定,决定事件处理的顺序与速度。常见取值从“Critical”到“Low”。 在流程挖掘中,按优先级分析对性能评估至关重要。它有助于回答“高优先级事件是否满足SLA?”、“低优先级事件是否更易延迟?”等问题。按优先级筛选可将分析聚焦在最关键的业务问题上。
为何重要
该属性是开展细分分析的关键,有助于确保高优先级事件更快得到处理,并满足其对应的服务级别目标。
获取方式
这是 'HPD:Help Desk' 表单中的 'Priority' 字段(字段ID:1000000164)。
示例
严重高中低
|
|||
|
受理人
Assignee
|
被指派处理该事件的具体人员。 | ||
|
描述
Assignee指在某一时点对该事件负责的具体支持人员或技术人员。与Assigned Group相比,它能提供更细粒度的信息。 按处理人(Assignee)维度分析绩效,有助于识别表现优秀的人员、发现需要额外培训的同事,以及发现工作量分配不均衡。也常用于追溯复杂事件中个人采取的具体操作顺序。
为何重要
提供工作量分布与个人绩效的细粒度视图,帮助识别表现突出者以及需要支持的处理人员。
获取方式
这是 'HPD:Help Desk' 表单中的 'Assignee' 字段(字段ID:1000000218)。
示例
Bob Smith爱丽丝·约翰逊Charlie Brown
|
|||
|
指派组
AssignedGroup
|
负责处理该事件的支持组。 | ||
|
描述
该属性标识被指派处理事件的团队或部门,如'Service Desk'、'Network Team'、'Database Administrators'。跟踪指派是理解跨团队工作流转的关键。 该属性可用于分析团队间交接、识别由特定团队引发的瓶颈,并衡量“事件转派率(Incident Reassignment Rate)”。它有助于可视化事件在组织内的流转路径,并突出路由低效或知识缺口所在。
为何重要
记录分配到哪个小组,有助于分析交接、识别反复转派的循环,并定位特定团队内的瓶颈。
获取方式
这是 'HPD:Help Desk' 表单中的 'Assigned Group' 字段(字段ID:1000000217)。
示例
服务台网络运维应用支持二线基础设施服务
|
|||
|
是否SLA超时
IsSlaBreached
|
指示该事件是否在超过 SLA 目标日期后才解决的标志。 | ||
|
描述
如果事件解决用时超过其定义的SLA,该布尔属性为真,为每个事件的SLA表现提供清晰的二元结果。 该标记是构建“事件SLA绩效总览”仪表板并计算“事件SLA合规率”KPI的关键。它便于直接筛选与汇总所有未达标的事件,从而更轻松地分析违约原因。
为何重要
该标记可简化SLA合规性分析,便于筛选所有违约事件并深入调查根因。
获取方式
通过比较“Incident Resolved”事件的时间戳与“SlaTargetDate”计算:若解决的时间戳晚于目标日期,则该标记为true。
示例
truefalse
|
|||
|
是否重新打开
IsReopened
|
指示事件在状态设为 'Resolved' 后是否被重新打开的标志。 | ||
|
描述
如果事件在被标记为 'Resolved' 后又回到活动状态(如 'In Progress'),该布尔属性为真,表明初次修复无效或不完整。 这是对返工的直接度量,可用于计算“事件返工率”KPI。分析重开事件有助于识别修复质量不足、测试不充分或未被妥善处理的重复性问题,并为“返工与升级路径”仪表板提供支持。
为何重要
直接衡量返工与修复质量。高复开率意味着修复无效、流程存在薄弱环节。
获取方式
通过分析单个事件的活动序列计算而得:如果在“Resolution Implemented”之后出现“Incident Reopened”或类似活动,则该标记为true。
示例
truefalse
|
|||
|
服务
Service
|
受该事件影响的业务或技术服务。 | ||
|
描述
该属性将事件关联到配置管理数据库(CMDB)中定义的具体服务,例如 'Email Service'、'VPN Access' 或 'SAP Financials'。 这种关联对于理解事件对业务的影响至关重要。按服务维度分析有助于找出产生大量事件的问题服务,揭示与特定技术相关的反复问题,并支持问题管理中的趋势分析。
为何重要
将事件与业务服务关联对于开展影响分析、识别最容易出问题的服务至关重要。
获取方式
这是 'HPD:Help Desk' 表单中表示受影响配置项(CI)的 'ServiceCI' 或类似字段。
示例
企业邮箱SAP ERP远程访问 VPN人力资源门户
|
|||
|
SLA 目标日期
SlaTargetDate
|
按SLA要求,事件应在此日期时间前解决。 | ||
|
描述
该属性按服务级别协议(SLA)定义存储事件解决的截止时间,通常根据事件优先级与服务时间计算得出。 该时间戳是衡量实际解决时长的基准,用于计算“事件SLA合规率”KPI,并用于构建SLA绩效仪表板,同时支持对临近截止的事件进行提前监控。
为何重要
这是衡量SLA合规性的基准,用于判断事件是否按时解决或是否发生违约。
获取方式
这些数据通常存放于 'SLM:Measurement' 表单,并与事件记录关联,而非 'HPD:Help Desk' 表单上的直接字段。
示例
2023-10-26T14:00:00Z2023-10-27T09:00:00Z2023-11-01T17:00:00Z
|
|||
|
关闭代码
CloseCode
|
在关闭事件时选择的代码,用于标明解决结果。 | ||
|
描述
Close Code用于以结构化方式总结事件是如何被解决的。例如:'Resolved by User'、'No Fault Found'、'Duplicate Incident'、'Permanent Fix Applied'等。 该属性对于分析解决效果和结果非常有价值。它可以帮助识别未真正修复就被关闭的事件,或找出用户经常自助解决的类别,从而提示需要优化知识库文章或自助服务工具。
为何重要
提供关于解决结果的结构化数据,便于评估修复有效性,并识别事件关闭方式的趋势。
获取方式
这通常属于 'HPD:Help Desk' 表单中的解决或关闭相关信息的一部分。
示例
远程解决重复问题用户错误无需处理
|
|||
|
最后数据更新
LastDataUpdate
|
时间戳,表示此事件的数据上次从源系统刷新的时间。 | ||
|
描述
该属性记录最近一次数据提取的日期和时间,用于说明当前分析数据的新鲜度,帮助判断洞察是否足够及时。 掌握最新更新时间对报表和仪表板至关重要,它可以告知用户数据的时效性,并帮助管理对是否包含最新事件活动的预期。
为何重要
用于说明数据的时效性,帮助用户了解流程分析及其洞见的最新程度。
获取方式
该值通常在数据抽取(ETL)过程中生成,并标记在数据集上。
示例
2023-11-01T02:00:00Z2023-11-02T02:00:00Z2023-11-03T02:00:00Z
|
|||
|
影响
Impact
|
衡量该事件对业务流程影响程度的指标。 | ||
|
描述
Impact 用于评估事件对业务的不利影响程度。通常按等级定义,如“广泛/大范围”“显著/大规模”“中等/有限”或“轻微/局部”。 与 Urgency 结合后,Impact 决定事件的 Priority。按影响度进行分析,有助于识别哪些事件对业务扰动最大,而不论技术复杂度高低。这一点对确定流程改进的优先顺序至关重要。
为何重要
用于量化事件对业务的严重程度,这是确定优先级并将分析聚焦高影响问题的关键依据。
获取方式
这是 'HPD:Help Desk' 表单中的 'Impact' 字段(字段ID:1000000163)。
示例
1-广泛/普遍2-重大/大范围3-中等/有限4-轻微/局部
|
|||
|
提交人
Submitter
|
最初上报该事件的人。 | ||
|
描述
Submitter指遇到问题并提交上报的终端用户或客户,与负责处理事件的Assignee不同。 按提交人或其部门分析数据,有助于找出需要更多培训的用户群体,或识别受某类问题影响较多的群体,为事件管理提供以客户为中心的视角。
为何重要
标识上报问题的用户,便于按部门、地区或角色进行分析,发现与特定用户相关的趋势。
获取方式
该信息记录在 'HPD:Help Desk' 表单中的 'Submitter' 字段或其他与客户信息相关的字段里。
示例
John DoeJane SmithPeter Jones
|
|||
|
根因
RootCause
|
导致该事件的根本原因。 | ||
|
描述
根因(Root Cause)是指只要解决就能避免事件复发的根本问题,通常在相关问题(Problem)调查过程中识别。 并非所有事件都会记录根因,但分析该属性对主动问题管理至关重要。它支撑“根因识别率”KPI,并有助于构建跟踪重复性问题趋势的仪表板,引导落地永久性解决方案。
为何重要
定位根因是问题管理的核心,也是减少重复事件量相关分析的基础。
获取方式
该信息可能存放在事件记录的专用 'Root Cause' 字段中,或更常见地位于关联的 'PBI:Problem Investigation' 表单中。
示例
服务器磁盘空间不足网络配置错误2.1 版本的软件缺陷安全证书过期
|
|||
|
渠道
Channel
|
上报事件所使用的方式或渠道。 | ||
|
描述
该属性指定事件的提交方式,例如电话、邮件、自助门户或现场报修,反映事件进入支持流程的入口渠道。 按渠道分析有助于识别最有效的渠道,以及哪些渠道产生的事件更易或更难解决;也可指导自动化或用户培训的投入方向,例如推广能采集更完整初始信息的自助门户。
为何重要
了解提交渠道有助于评估不同受理方式的效率,并为自助服务或自动化的投入提供依据。
获取方式
这是 'HPD:Help Desk' 表单中的 'Reported Source' 字段(字段ID:1000000215)。
示例
电子邮件电话自助服务直接输入
|
|||
|
源系统
SourceSystem
|
提取该事件数据的来源系统。 | ||
|
描述
该属性用于标识数据来源,在采用多套ITSM工具或集成系统的环境中特别有用。它可确认数据来自预期来源,例如某个特定的BMC Helix ITSM实例。 在分析中,它有助于区分生产、开发或遗留系统之间可能存在的流程或数据差异,确保数据血缘清晰可靠。
为何重要
标识数据来源,这对数据校验以及跨多套集成系统的分析管理至关重要。
获取方式
通常在数据抽取、转换与加载(ETL)过程中添加的静态值。
示例
BMCHelixITSM_ProdITSM-EU-InstanceServiceManagement-APAC
|
|||
|
解决方案说明
Resolution
|
用于记录解决该事件所采取步骤的自由文本描述。 | ||
|
描述
该字段包含由人工撰写的最终解决摘要,说明为修复问题、恢复用户服务所采取的措施。 尽管是非结构化文本,但可以通过文本挖掘识别常见解决模式、提取与特定问题相关的关键词,或用于补充根因分析,提供结构化字段常常缺失的定性背景信息。
为何重要
提供关于解决方案的定性细节,可用于文本挖掘,发现结构化数据里看不到的模式。
获取方式
这是 'HPD:Help Desk' 表单中的 'Resolution' 字段(字段ID:1000000156)。
示例
用户的密码已通过 Active Directory 重置。清理了浏览器缓存和Cookie,已解决登录问题。已在 IDF 配线间 3B 重启网络交换机。
|
|||
|
重新分派次数
ReassignmentCount
|
事件被转派到其他支持组的总次数。 | ||
|
描述
该指标统计事件在生命周期内 'AssignedGroup' 字段被更改的次数。次数过高通常意味着初始路由存在问题、首次接触无法解决,或问题复杂需要多个团队参与。 该属性直接支持“Incident Reassignment Rate”KPI 和“Incident Reassignment Cycle Analysis”仪表板,用于量化工单在团队间来回“乒乓”的现象,这会导致显著延迟和流程低效。
为何重要
量化低效分派与交接,帮助识别在团队间反复转派、陷入循环的事件。
获取方式
在事件日志中,统计某个Incident ID的“AssignedGroup”值发生变化的次数来计算。
示例
0135
|
|||
事件管理活动
| 活动 | 描述 | ||
|---|---|---|---|
|
事件已上报
|
该活动标记系统中事件记录的首次创建。它直接取自核心事件管理表单中的创建时间戳。 | ||
|
为何重要
这是事件生命周期的主要起始事件,对于计算整体解决时长与了解事件到达率至关重要。
获取方式
该事件对应在 'HPD:Help Desk' 表单中新建记录。时间戳通常取自 'Submit Date' 或 'Reported Date' 字段。
捕获
来自 HPD:Help Desk 表单上的 'Submit Date' 时间戳。
事件类型
explicit
|
|||
|
事件已关闭
|
这是最终活动,表示在确认已解决或确认期结束后正式关闭事件记录。当状态被设置为 'Closed' 时记录。 | ||
|
为何重要
这是事件全生命周期的最终结束事件。'Resolved' 与 'Closed' 之间的时间通常用于用户确认及行政收尾。
获取方式
该事件对应 'HPD:Help Desk' 表单中 'Status' 字段被设置为 'Closed'。时间戳记录在 'Closed Date' 字段及审计日志中。
捕获
来自 'Closed Date' 时间戳,或状态变更至 'Closed' 的时间。
事件类型
inferred
|
|||
|
事件已解决
|
该活动标记服务台视角下的正式解决(最终关闭之前)。当事件状态设为'Resolved'时记录。 | ||
|
为何重要
这是衡量SLA合规性与解决时长的最重要里程碑,表明用户服务已恢复。
获取方式
该事件对应 'HPD:Help Desk' 表单中 'Status' 字段被设置为 'Resolved'。时间戳记录在 'Last Resolved Date' 字段及审计日志中。
捕获
来自审计日志中状态变更为 'Resolved' 的时间戳。
事件类型
inferred
|
|||
|
分配到支持组
|
该活动标记事件首次被指派至某个支持组开展调查。它通过事件创建后'Assigned Group'字段首次被填充来推断。 | ||
|
为何重要
这是标志主动处理开始的关键里程碑。跟踪首次分派用时对于评估响应速度和初始分流效率至关重要。
获取方式
在审计日志('HPD:HelpDesk_AuditLogSystem')中,捕捉 'HPD:Help Desk' 表单上 'Assigned Group' 字段的首次填充。
捕获
来自首次填充 'Assigned Group' 字段时的时间戳。
事件类型
inferred
|
|||
|
调查已启动
|
表明支持人员已开始实际处理该事件,通常可通过状态从 'Assigned' 变为 'In Progress' 推断。 | ||
|
为何重要
此里程碑标志着从排队等待转入主动诊断。分析从排队到开始调查的等待时间,有助于识别资源瓶颈,并支持“Diagnosis & Investigation Bottlenecks”仪表板。
获取方式
根据 'HPD:Help Desk' 表单上的状态变化推断。当 'Status' 字段变为 'In Progress' 时触发该事件,时间戳取自审计日志。
捕获
根据 HPD:HelpDesk_AuditLogSystem 中状态变为 'In Progress' 的记录推断。
事件类型
inferred
|
|||
|
SLA 违约
|
当事件解决用时超过其SLA目标时触发的计算型事件,通过比较解决时间戳与SLA到期时间得出。 | ||
|
为何重要
该活动是“事件SLA绩效概览”仪表板与“事件SLA达标率”KPI的基础,可直接标记未满足服务承诺的事件。
获取方式
在“HPD:Help Desk”表单上,将“Last Resolved Date”与“Target Date”(SLA到期日)进行比较计算;若事件尚未解决,则可与当前时间对比计算。
捕获
计算事件:当“Last Resolved Date”>“Target Date”时发生。
事件类型
calculated
|
|||
|
事件已分类
|
表示事件已完成运营和产品分类,且已设置优先级。通常根据分类字段的填写或最后一次修改时间来推断。 | ||
|
为何重要
准确、及时的分类对高效路由与报表至关重要。分析此环节可定位初始分诊中的延迟或误判,并为“Incident Categorization Accuracy”仪表板提供支持。
获取方式
在审计日志('HPD:HelpDesk_AuditLogSystem')中跟踪 'Operational Categorization Tier 1-3'、'Product Categorization Tier 1-3' 与 'Priority' 等字段的变更。
捕获
来自创建后对分类或优先级字段最后一次更新的时间戳。
事件类型
inferred
|
|||
|
事件已取消
|
该活动表示终止误建或已不再相关的事件。当事件状态设为'Cancelled'时记录。 | ||
|
为何重要
这是事件的终止状态,与成功解决不同。分析被取消的事件有助于发现事件创建渠道的问题或重复上报的情况。
获取方式
当 'HPD:Help Desk' 表单的 'Status' 字段更新为 'Cancelled' 时推断,时间戳记录在审计日志中。
捕获
根据审计日志中状态变为 'Cancelled' 的记录推断。
事件类型
inferred
|
|||
|
事件已重新打开
|
表示先前标记为已解决的事件因问题未消除而被重新激活。通常根据状态由“Resolved”回到“In Progress”或“Assigned”等活动状态来推断。 | ||
|
为何重要
该活动可直接衡量返工情况及初始方案的有效性。大量重开事件是修复质量不佳的关键信号,并支撑“事件返工率(Incident Rework Rate)”KPI。
获取方式
在审计日志('HPD:HelpDesk_AuditLogSystem')中,通过检测特定 Incident ID 的 'Status' 从 'Resolved' 变为 'In Progress' 或 'Assigned' 来推断。
捕获
根据状态由 'Resolved' 转回为某个活动状态的变化推断。
事件类型
inferred
|
|||
|
已收到用户确认
|
表示用户已主动确认所提供的解决方案已解决其问题。这可能是显式事件,或在关闭前根据备注或相关系统动作推断。 | ||
|
为何重要
跟踪此项比单纯等待自动关闭更能真实反映用户确认流程。它有助于衡量“Average User Confirmation Time”KPI,并识别沟通缺口。
获取方式
这类信息不易可靠地采集。通常可在事件转为 'Closed' 之前,通过工作日志条目或特定的状态原因更新进行推断,可能需要分析 'HPD:WorkLog' 表单。
捕获
根据关闭前的特定工作日志条目或状态原因的更新推断。
事件类型
inferred
|
|||
|
等待客户反馈
|
表示事件因等待用户提供信息或采取行动而暂停推进。通常根据状态变更为“Pending”来推断。 | ||
|
为何重要
该活动有助于区分坐席工作时间与用户等待时间。分析处于该状态的时长,对理解用户响应延迟如何影响整体解决时长至关重要。
获取方式
当 'HPD:Help Desk' 表单的 'Status' 字段更新为 'Pending' 时推断,具体原因通常位于 'Status_Reason' 字段。
捕获
根据 HPD:HelpDesk_AuditLogSystem 中状态变为 'Pending' 的记录推断。
事件类型
inferred
|
|||
|
等待用户确认
|
当已实施解决方案,支持团队等待用户确认修复是否成功时发生。通常对应 'Resolved' 状态,此时会启动自动关闭计时。 | ||
|
为何重要
该活动是“用户确认与验证延迟”仪表板的关键输入。它用于量化从提供修复到获得用户验证之间的延迟,这类延迟会人为拉长事件生命周期。
获取方式
当 'HPD:Help Desk' 表单上的 'Status' 变为 'Resolved' 时进入该状态。持续时间从 'Last Resolved Date' 起算,直至事件被 'Closed' 或 'Reopened'。
捕获
当状态变更为“Resolved”时开始,于状态变更为“Closed”或“In Progress”时结束。
事件类型
inferred
|
|||
|
解决方案已实施
|
该活动表明支持团队已应用修复或变通方案,通常在事件状态变为'Resolved'时推断。 | ||
|
为何重要
这是表明解决方案已交付的关键里程碑,是衡量调查完成后到应用修复所需时间的重要数据点。
获取方式
通常在 'HPD:Help Desk' 表单的 'Status' 被设置为 'Resolved' 时确定,时间戳记录在 'Last Resolved Date' 字段及审计日志中。
捕获
来自 'Last Resolved Date' 时间戳,或状态变更至 'Resolved' 的时间。
事件类型
inferred
|
|||
|
转派至其他小组
|
当事件从一个支持组转派到另一个支持组时,该活动会发生。它通过在初次指派后检测到'Assigned Group'字段的变更来推断。 | ||
|
为何重要
频繁转派通常意味着初始路由不正确或知识库有缺口。跟踪此活动对 'Incident Reassignment Cycle Analysis' 仪表板以及 'Incident Reassignment Rate' KPI 至关重要。
获取方式
在审计日志('HPD:HelpDesk_AuditLogSystem')中,识别 'HPD:Help Desk' 表单上 'Assigned Group' 字段在首次填充后的后续变更来推断。
捕获
识别首次分派后对'Assigned Group'字段的任何变更。
事件类型
inferred
|
|||