数据模板:事件管理
事件管理数据模板
- 建议收集的属性
- 需要追踪的关键活动
- 提取指南
事件管理属性
| 名称 | 描述 | ||
|---|---|---|---|
|
事件ID
IncidentId
|
每条事件记录的唯一标识符,用作跟踪整个事件生命周期的主键。 | ||
|
描述
事件ID是事件管理分析的基石。它作为唯一标识,将所有相关活动、时间戳与属性变更串联为一条完整的轨迹。 在流程挖掘中,每条事件日志都会关联一个事件ID,从而可以重建每起事件的端到端流程。这对于计算周期时长、分析流程变体以及定位单个事件的瓶颈至关重要。没有唯一标识,就无法区分不同事件,也无法分析其从上报到解决的路径。
为何重要
它为每个事件提供唯一标识,使其从创建到关闭的端到端跟踪与分析成为可能。
获取方式
这是工单的主标识符,可通过Freshservice Tickets API在工单对象的'id'字段获取。
示例
INC-10234INC-10235INC-10236
|
|||
|
事件timestamp
EventTimestamp
|
活动或事件发生的精确日期和时间。 | ||
|
描述
事件时间戳(或开始时间)标记某个活动发生的准确时刻。事件从创建到关闭的每个活动,都有对应的时间戳。 该属性是所有基于时间的流程挖掘分析的关键,用于按时间顺序排列事件、计算活动间的持续时长、衡量单个事件的整体周期时长,并分析等待时间。它也是构建用于跟踪SLA表现、交接延迟与整体解决时长的仪表板的基础。
为何重要
它提供事件的时间顺序,这对计算时长、分析周期时间以及理解流程绩效至关重要。
获取方式
该值来自Freshservice中的多个时间戳字段,如'created_at'、'updated_at',以及工单会话或审计日志中的时间戳。
示例
2023-10-26T10:00:00Z2023-10-26T10:05:14Z2023-10-27T14:30:00Z
|
|||
|
最后数据更新
LastDataUpdate
|
指示该流程数据上次刷新或抽取时间的时间戳。 | ||
|
描述
该属性提供最近一次从源系统更新整个数据集的时间戳。它是适用于整个数据集的元数据字段,但为保持一致,常在事件级别一并提供。 在分析中,该信息对于判断数据的时效性以及仪表板与KPI所覆盖的时间窗口至关重要。它能增强用户对洞察时效性的信心,并帮助判断最新事件是否已纳入分析。
为何重要
它向用户说明数据的更新时点,确保其理解分析覆盖的时间范围。
获取方式
这是在数据抽取(ETL)过程中生成的元数据时间戳。
示例
2023-11-01T02:00:00Z2023-11-02T02:00:00Z
|
|||
|
活动名称
ActivityName
|
在事件生命周期的某个时间点发生的具体业务活动或事件的名称。 | ||
|
描述
“活动名称”用于描述事件管理流程中的单一步骤或事件,例如“事件分配给小组”“状态变更为待处理”或“事件已解决”。这些活动来自事件数据随时间发生的变更。 该属性是流程挖掘的基石,它定义了已发现流程图中的节点。通过分析这些活动的先后顺序与出现频率,组织可以可视化真实的事件解决流程,识别常见路径,发现偏离标准流程的行为,并定位诸如频繁转派等返工环路。
为何重要
它定义流程图中的步骤,便于可视化并分析事件解决流程、瓶颈与偏差。
获取方式
该属性并非Freshservice的直接字段,而是由工单属性的变化推导而来,例如状态、优先级、工程师/组分配以及备注的新增。
示例
事件已报告事件已分派至组已添加解决备注事件已解决
|
|||
|
源系统
SourceSystem
|
数据提取所依据的系统,通常为Freshservice。 | ||
|
描述
该属性用于标识数据的来源。本场景中通常固定为Freshservice;但在需要合并多系统数据以获得全局流程视图的环境中,此字段至关重要。 纳入“来源系统”属性是数据治理与可追溯性的最佳实践。它确保数据来源清晰,有助于数据校验、问题排查,并为将来将其他服务管理或运营系统纳入流程挖掘项目奠定基础。
为何重要
它通过清晰标识事件管理数据的来源,确保数据的可追溯性与治理规范。
获取方式
这通常是在数据转换(ETL)过程中添加的静态值,用于标记数据集。
示例
FreshserviceFreshservice-EUFreshservice-PROD
|
|||
|
事件严重性
IncidentSeverity
|
事件的严重性级别,用于指示其对业务的影响程度。 | ||
|
描述
事件严重性用于衡量事件对业务的影响,通常分为 Low、Medium、High、Critical。虽然与优先级相关,但严重性关注的是影响,而优先级关注的是紧迫性。最终优先级往往由严重性与影响程度共同决定。 按严重性进行分析有助于评估组织处理高业务影响事件的能力。仪表板会据此细分解决时间和 SLA 表现,确保最具影响的问题在整个生命周期内获得恰当的关注与资源。
为何重要
它衡量事件对业务的影响,便于围绕影响最大的问题开展缓解分析。
获取方式
这是Freshservice的默认字段,可通过Tickets API中的'impact'获取,取值为数值。
示例
低中高
|
|||
|
事件优先级
IncidentPriority
|
事件的优先级,用于决定响应与解决的紧急程度。 | ||
|
描述
事件优先级是决定处理速度与关注度的关键字段,通常分为 Low、Medium、High、Urgent,并且常与 SLA 目标挂钩。 在流程挖掘中,优先级是过滤与分析的核心维度。它支持对比高优先级与低优先级事件的解决流程,确保关键问题被高效处理。仪表板通常会按优先级细分诸如周期时长和 SLA 表现等指标,为支持经理提供可执行的洞察。
为何重要
它有助于优先聚焦最关键的事件,对评估SLA达标情况与资源分配至关重要。
获取方式
在 Freshservice Tickets API 中对应 'priority' 字段。取值为数字(例如 1 表示低,4 表示紧急)。
示例
低中高紧急
|
|||
|
事件状态
IncidentStatus
|
事件在其生命周期中的当前状态,例如新建、待处理、已解决或已关闭。 | ||
|
描述
事件状态表明事件当前所处阶段。状态变化是构成已发现流程图的关键事件,例如从“进行中”变为“待处理”,或从“已解决”变为“已关闭”。 该属性是理解事件全程轨迹的基础。分析各状态的停留时长有助于识别瓶颈,例如事件在“待处理”状态下因等待用户回复而耗时过长。它也对确定周期时长的起止点至关重要。
为何重要
它跟踪事件的全生命周期进展,并帮助识别常见延迟的阶段。
获取方式
在 Freshservice Tickets API 中对应 'status' 字段。取值为数字。
示例
未结进行中挂起已解决已结案
|
|||
|
事件类别
IncidentCategory
|
用于对事件进行分类,例如硬件、软件或网络。 | ||
|
描述
事件类别用于按上报问题的类型对事件进行层级分类。这种层级化分类有助于将事件路由到正确的团队,对趋势分析也至关重要。 该属性用于“Incident Categorization Accuracy”仪表板,用于分析初始误分类是否因反复转派而拉长了解决时间。通过按类别对事件分组,组织可以识别重复性问题,了解主要支持投入的方向,并据此制定改进举措。
为何重要
它支持分析事件趋势,并帮助判断是否因分类错误导致解决延误。
获取方式
这是Freshservice中的默认字段,但可自定义。在Tickets API中对应'category',相关字段包括'sub_category'和'item_category'。
示例
硬件软件网络问题账户访问
|
|||
|
指派坐席
AssignedAgent
|
当前被指派处理该事件的支持坐席姓名或ID。 | ||
|
描述
“指派坐席”用于标识在某一时点对该事件负责的服务台人员。该属性的变化代表事件所有权在坐席之间的转移。 此属性对绩效分析至关重要,可用于仪表板跟踪坐席工作负载、单个坐席的平均解决时长以及首次联系解决率。同时也可用于分析坐席之间的交接,这往往是延迟与低效的来源。通过跟踪坐席指派情况,管理者能识别培训需求,并表彰高绩效成员。
为何重要
它支持分析坐席绩效、工作量分布,以及坐席交接对解决时长的影响。
获取方式
在 Freshservice Tickets API 中对应 'responder_id' 字段。可与 Agents API 关联以获取坐席姓名。
示例
John DoeJane SmithSupportBot
|
|||
|
指派组
AssignedGroup
|
当前被指派处理该事件的支持组或团队。 | ||
|
描述
“指派组”表示哪个团队负责该事件,例如“一线支持”“网络团队”或“数据库管理员”。该属性的变化意味着在不同职能团队之间的升级或转派。 分析指派组对于理解交接与转派中的延迟至关重要。流程挖掘可将事件在各小组间的流转可视化,突出常见的升级路径,并衡量事件在各小组等待处理的时间,从而识别组织层面的瓶颈,寻找优化跨团队协作的机会。
为何重要
它跟踪哪个团队负责,这对分析交接、升级与跨团队延迟至关重要。
获取方式
在 Freshservice Tickets API 中对应 'group_id' 字段。可与 Groups API 关联以获取组名。
示例
服务台网络运维基础设施支持
|
|||
|
解决 SLA 目标时间
ResolutionSlaTargetTime
|
按SLA策略,该事件应完成解决的时间戳。 | ||
|
描述
该属性存储作为事件解决截止时间的具体日期与时间。该目标由应用于工单的SLA策略决定,通常取决于优先级等因素。 该目标时间用于计算《SLA达标率》KPI并驱动《SLA绩效仪表板》。通过将实际解决时间戳与该目标进行对比,可判断事件是否按时解决或已违反SLA,这是衡量服务级别合规性的基础。
为何重要
它提供解决截止时间,用于计算SLA合规性并识别存在风险的事件。
获取方式
在 Freshservice Tickets API 中对应 'fr_due_by'(首次响应)与 'due_by'(解决)字段。
示例
2023-10-26T14:00:00Z2023-10-27T09:00:00Z2023-11-05T17:00:00Z
|
|||
|
上报渠道
ReportingChannel
|
上报事件所用的方式或渠道,例如邮件、门户或电话。 | ||
|
描述
上报渠道(也称来源)用于标识事件是如何进入支持系统的。常见渠道包括邮件、自助服务门户、电话或聊天。 分析该属性有助于评估各上报渠道的效率。《上报渠道效率》仪表板会按渠道对比事件量与平均解决时长,从而判断哪些方式更高效、哪些需要优化。例如,通过门户上报的事件由于一开始就包含更结构化的信息,通常能更快解决。
为何重要
它帮助识别最高效的上报渠道,并挖掘优化事件受理流程的机会。
获取方式
在 Freshservice Tickets API 中对应 'source' 字段。取值为数字。
示例
电子邮件门户电话聊天
|
|||
|
已提供临时解决方案
WorkaroundProvided
|
一个标记,用于指示在最终解决前是否向用户提供了临时方案。 | ||
|
描述
该布尔属性指示在制定永久方案期间,是否实施了临时修复或变通方案以降低事件影响。通常通过复选框或特定状态进行跟踪。 在流程挖掘中,该属性支撑《临时方案有效性指标》仪表板。它可对比有/无临时方案的事件解决时长,帮助评估临时修复是否有效降低业务中断,并从用户视角促进更快的整体解决。
为何重要
它用于评估临时解决方案在降低事件影响、缩短用户感知的解决时间方面的效果。
获取方式
这通常是自定义布尔(复选框)字段,需在Freshservice的'Ticket Fields'配置中确认是否存在。
示例
truefalse
|
|||
|
是否发生SLA违约
IsSlaBreached
|
一个计算字段,若事件未在其定义的 SLA 目标时限内解决,则为 true。 | ||
|
描述
该布尔属性为计算指标,用于指示事件的解决时间是否超过其SLA目标。通过将实际解决时间戳与ResolutionSlaTargetTime对比得出。 此标记直接用于《SLA达标率》KPI和《SLA绩效仪表板》。以明确的二元结果简化分析,便于聚合与趋势洞察,并可快速识别未达服务承诺的事件数量与占比。
为何重要
它直接衡量每个事件的SLA合规情况,便于计算整体达标率并定位问题环节。
获取方式
这是一个计算字段,在数据转换过程中通过比较'Incident Resolved'的时间戳与'ResolutionSlaTargetTime'字段得出。
示例
truefalse
|
|||
|
是否重新打开
IsReopened
|
一个计算字段,若事件在解决或关闭后被重新打开,则为 true。 | ||
|
描述
该布尔属性为计算得出的标记,用于识别被重新打开的事件:当事件达到“Resolved”或“Closed”状态后,又被改回开放或进行中,则置为true。 此标记用于计算《事件重开率》KPI并支撑《重复事件》仪表板。重开率偏高通常意味着首解质量不足、根因分析不完整或过早关闭。分析这些案例有助于提升修复质量与可持续性。
为何重要
它识别解决流程中的失败案例,突出初次修复无效并导致返工的事件。
获取方式
这是基于事件日志中活动顺序计算的字段。若出现'Incident Reopened'这类活动,或同一Incident ID先为关闭状态后又出现打开状态,则为true。
示例
truefalse
|
|||
|
根因
RootCause
|
调查后为该事件识别出的根本原因。 | ||
|
描述
“根因”属性用于记录导致事件发生的根本问题。该信息通常由支持工程师在处理过程中或完成后填写,属于RCA(根因分析)的一部分。 此属性是《重复事件与根因》仪表板和《根因分析完成率》KPI的关键依据。通过分析常见根因,组织可从被动修复转向主动问题管理,实施永久性方案,预防后续事件并减少重复问题。
为何重要
它助力前瞻性问题管理,帮助识别并消除重复发生事件的根因。
获取方式
在Freshservice中,这通常是自定义字段,因为默认功能有限。请在'Ticket Fields'配置中查看是否有名为'Root Cause'或类似的字段。
示例
软件缺陷网络配置错误用户培训问题硬件故障
|
|||
|
解决周期时长
ResolutionCycleTime
|
从事件首次上报到被解决所经历的总时长。 | ||
|
描述
解决周期时长是为每个事件计算的关键绩效指标,衡量从用户视角看,事件从首次上报到确认解决所经历的总时长。 该计算指标是“事件解决周期时长”仪表板的基础,用于评估整体流程效率,并常按优先级、类别、坐席等维度进行分析。找出周期时间异常偏长的事件,有助于定位系统性延误与低效环节。
为何重要
它是衡量流程绩效的核心指标,直接反映从开始到完成的事件解决时长。
获取方式
这是一个计算指标,是'Incident Resolved'与'Incident Reported'活动之间的时间差。
示例
259200000864000003600000
|
|||
|
请求者部门
RequestersDepartment
|
报障用户所属的部门。 | ||
|
描述
该属性用于标识请求人所属的业务部门,如“销售”“财务”或“IT”。此信息通常来自Freshservice中的用户档案。 按请求人部门进行分析,可识别某些业务单元是否受到过度影响,或是否存在部门特有的问题。它为理解事件的业务影响提供重要背景,并帮助优先处理影响关键部门的修复。
为何重要
它提供业务上下文,支持分析事件趋势及其对特定部门的影响。
获取方式
该信息与工单的请求人关联。可通过Requesters API端点,使用工单中的requester_id获取,再读取department_id及名称。
示例
销售市场营销财务人力资源
|
|||
|
转派次数
HandoffCount
|
事件在不同坐席或小组之间被转派的次数。 | ||
|
描述
转派次数是一项计算指标,用于量化事件在整个生命周期中被重新指派的次数。每当 'AssignedAgent' 或 'AssignedGroup' 属性发生变更,该计数加一。 较高的转派次数通常意味着流程低效、初始路由不当,或坐席技能不足。该指标直接支撑“事件转派次数”KPI 与“转派与流转延迟分析”仪表板,帮助识别因过度转移而导致延误的事件或流程路径。
为何重要
它量化返工与转派,帮助识别因路由错误或知识缺口导致的低效。
获取方式
这是一个计算指标,通过统计单个事件全生命周期内'AssignedAgent'或'AssignedGroup'字段的唯一值数量或变更次数得到。
示例
0125
|
|||
事件管理活动
| 活动 | 描述 | ||
|---|---|---|---|
|
事件已关闭
|
表示事件记录被最终、正式关闭。一般会在进入“Resolved”状态一段时间后自动完成,或由坐席手动关闭。该事件标志着事件生命周期的结束。 | ||
|
为何重要
该活动是流程的最终结束点。到达此事件的总用时代表完整的事件生命周期时长,包含用户确认等等待时段。
获取方式
当活动日志显示 'Status' 字段更新为 'Closed' 时进行推断。
捕获
使用活动日志中状态变更为'Closed'的记录时间戳。
事件类型
inferred
|
|||
|
事件已分派至组
|
表示事件首次被指派到某个支持小组。可由路由规则自动完成,或由派单员手动执行。系统通过审计日志中首次填充“Group”字段来捕捉该活动。 | ||
|
为何重要
跟踪分派情况是衡量首次响应时间、识别派单流程瓶颈的关键,也有助于评估事件路由到正确团队的效率。
获取方式
根据事件活动日志中首次填写或修改 'Group' 字段的记录进行推断。
捕获
找出该事件首次填充 'Group' 字段的时间戳。
事件类型
inferred
|
|||
|
事件已报告
|
表示在Freshservice中新建了一条事件记录。这是事件生命周期的起点,通常由终端用户通过门户或电子邮件提交,或由服务台坐席代为创建工单。该事件会以创建时间戳明确记录。 | ||
|
为何重要
该活动是整个流程的主要起点。分析从此事件到解决的用时,是衡量整体周期时长与SLA达标的基础。
获取方式
取自事件表的创建时间戳。Freshservice 会为每个新工单显式记录该时间。
捕获
使用主事件记录中的'Created at'时间戳。
事件类型
explicit
|
|||
|
事件已解决
|
表示坐席已实施修复并认为事件已解决。当事件状态变更为 'Resolved' 时记录该节点。在Freshservice中,这是停止SLA计时的关键里程碑。 | ||
|
为何重要
这是衡量解决用时(TTR)的关键里程碑。'Resolved'与'Closed'之间的时段有助于分析用户确认延迟和自动关闭策略的影响。
获取方式
当活动日志显示 'Status' 字段更新为 'Resolved' 时进行推断。
捕获
使用活动日志中状态变更为'Resolved'的记录时间戳。
事件类型
inferred
|
|||
|
事件已设定优先级
|
当事件的优先级被设定或更新时触发。优先级决定紧急程度及 SLA 目标。系统通过监控事件历史中“Priority”字段的变更来记录。 | ||
|
为何重要
优先级设置错误或滞后可能导致SLA违约和资源配置低效。分析该活动有助于确保关键事件能被立即处理。
获取方式
依据活动日志对 'Priority' 字段的所有更新记录进行推断。
捕获
使用审计日志中设置或变更'Priority'字段时对应的时间戳。
事件类型
inferred
|
|||
|
已添加解决备注
|
当坐席通过添加解决备注来记录事件的处理方案时触发。在 Freshservice 中,这是在状态切换为“Resolved”之前的独立操作;该操作及其内容都会被明确记录。 | ||
|
为何重要
该事件表示已找到解决方案。从此时点到'Incident Resolved'状态之间的时间可反映内部评审或文档整理的耗时。
获取方式
取自向事件添加解决备注时的时间戳,该时间会记录在会话历史中。
捕获
在事件会话日志中找到 'Resolution Note' 记录的时间戳。
事件类型
explicit
|
|||
|
状态变更为进行中
|
该活动标记事件正式进入调查与处理阶段。当支持工程师将事件状态更改为“In Progress”时即被记录。这属于工单活动历史中的标准状态变更。 | ||
|
为何重要
该里程碑有助于区分等待时间与实际工作时间。分析事件处于'In Progress'的时长,是理解解决工作量的关键。
获取方式
当活动日志显示 'Status' 字段更新为 'In Progress' 时进行推断。
捕获
在活动日志中过滤状态变为 'In Progress' 的记录,并使用其时间戳。
事件类型
inferred
|
|||
|
事件已指派坐席
|
该活动标记将事件指派给某位具体支持工程师,意味着个人负责该工单。指派记录会写入工单活动历史,包含被指派的工程师及时间。 | ||
|
为何重要
这有助于分析支持工程师的工作量、绩效,以及工单在分配到组后被个人接单所需的时间。此信息对工程师绩效类仪表板至关重要。
获取方式
可通过事件活动日志或审计日志中对'Agent'字段的变更进行追踪。
捕获
识别与 'Agent' 字段变更对应的时间戳。
事件类型
inferred
|
|||
|
事件已重新分派
|
表示该事件从一个坐席或支持组转交给另一个,意味着解决流程发生了交接。此事件通过在初次分派后检测对 'Agent' 或 'Group' 字段的后续更改来推断。 | ||
|
为何重要
频繁的转派(交接)通常意味着流程低效、知识缺口或初始路由不正确。分析此类事件有助于识别并减少由此造成的延误。
获取方式
在首次分派之后,跟踪 'Agent' 或 'Group' 字段的任何变更来进行推断。
捕获
在工单审计历史中检测 'Agent' 或 'Group' 字段的变更。
事件类型
inferred
|
|||
|
事件已重新打开
|
当已标记为“Resolved”的事件被重新打开时触发,通常因用户对解决方案有异议。系统根据状态从“Resolved”变回到“Open”或“In Progress”等开放状态来判断。 | ||
|
为何重要
高复开率通常意味着解决质量欠佳或修复不完整。这是评估返工与坐席绩效的关键指标。
获取方式
当活动日志检测到状态从 'Resolved' 变更为活动状态时进行推断。
捕获
在活动日志中过滤 'Status' 从 'Resolved' 变更为 'Open' 或 'In Progress' 的记录。
事件类型
inferred
|
|||
|
已提供临时解决方案
|
该活动表示已向用户提供临时解决方案或变通方案,以降低事件影响。捕获此活动通常需要特定系统配置,如专用复选框、特定备注类型,或对支持工程师备注进行关键词识别。 | ||
|
为何重要
用于分析临时方案在降低业务影响方面的有效性及其与最终解决时间的关系,并支撑《临时方案有效性指标》仪表板。
获取方式
这通常不是一个显式事件。可通过标记包含'workaround'关键词的备注进行推断,或在使用了自定义'Workaround Provided'复选框且其变更被记录时进行推断。
捕获
通过自定义字段的变更或对坐席备注的关键词分析来推断。
事件类型
inferred
|
|||
|
已超出SLA目标
|
这是一个计算得出的事件:当事件已用时间超过为响应或解决设定的SLA目标时触发。Freshservice会在内部跟踪SLA状态,可通过将时间戳与SLA策略对比来推导出该事件。 | ||
|
为何重要
用于直接衡量对服务级别承诺的合规性。找出违约发生的时间与原因,是构建 SLA 绩效仪表板并推动持续改进的基础。
获取方式
通过将解决或响应的时间戳与 SLA 目标到期时间对比计算。Freshservice 通常会将工单标记为 'SLA Violated'。
捕获
通过比较 'Resolved at' 时间戳与 'Due by' 时间戳,或在 'SLA Status' 字段变更为 'Violated' 时即可判定。
事件类型
calculated
|
|||
|
状态变更为待处理
|
表示解决流程被暂时搁置,通常因为等待用户或第三方的信息。系统根据状态切换到任意“Pending”状态来判断。该状态下的时间通常不计入 SLA 计算。 | ||
|
为何重要
识别事件在等待状态下的耗时,对理解外部依赖与延误至关重要。这有助于区分坐席的实际工作时间与等待时间。
获取方式
当活动日志显示 'Status' 字段更新为 'Pending' 或 'Awaiting User Response' 等值时进行推断。
捕获
在活动日志中过滤状态变更为任意等待状态的记录,并使用对应的时间戳。
事件类型
inferred
|
|||
|
首次响应已发送
|
该活动表示事件上报后,支持工程师首次与用户沟通,形式可以是公开备注或直接回复。Freshservice会为所有工程师的沟通打上时间戳。 | ||
|
为何重要
达成首次响应SLA是影响客户满意度的关键KPI。该活动用于衡量与分析坐席响应新事件的速度。
获取方式
在事件会话日志中找到坐席添加的首条公开备注或回复的时间戳即可识别。
捕获
在事件会话历史中筛选坐席首次提交的记录,并取最早时间戳。
事件类型
explicit
|
|||