您的服务请求管理数据模板
您的服务请求管理数据模板
- 建议收集的属性
- 需要跟踪的关键活动
- 提取指南
服务请求管理属性
| 名称 | 说明 | ||
|---|---|---|---|
|
事件时间
EventTime
|
活动发生时的精确时间戳。 | ||
|
说明
Event Time记录服务请求中特定活动的日期和时间。此时间戳是正确排列事件顺序和计算事件间时长的基础。 在流程挖掘中,此属性用于排列每个案例中的活动,也是所有基于时间的分析的基础。它用于计算周期时间、活动间等待时间以及服务级别协议(SLA)的遵循情况。准确的时间戳对于识别瓶颈和了解流程绩效至关重要。
为什么重要
此时间戳按时间顺序排列事件,是所有绩效分析的基础,包括周期时间计算和瓶颈识别。
获取位置
对应Freshservice中活动或审计日志条目的创建时间戳。
示例
2023-10-26T10:00:00Z2023-10-26T11:35:10Z2023-10-27T14:20:05Z
|
|||
|
服务请求ID
ServiceRequestId
|
每个服务请求的唯一标识符。 | ||
|
说明
Service Request ID是Freshservice中为每个新记录的服务请求分配的唯一编号或代码。它作为跟踪请求从创建到关闭整个生命周期的主键。 在流程挖掘中,此ID至关重要,因为它充当Case ID。状态变更、处理人员分配和备注等所有相关事件,都通过此标识符关联。分析每个Service Request ID的完整历程,可以端到端地呈现流程,识别常见路径,并发现影响单个案例的偏差或瓶颈。
为什么重要
这是连接所有相关事件的必要Case ID,可追踪单个服务请求的端到端历程。
获取位置
这是Freshservice工单对象中的主字段,可在用户界面中查看,也可通过Freshservice API获取。
示例
SR-12943SR-13501SR-14011
|
|||
|
活动名称
ActivityName
|
服务请求在特定时间点发生的事件或任务名称。 | ||
|
说明
Activity Name描述服务请求生命周期中的具体步骤或事件。这些活动从系统审计日志、状态变更或用户执行的特定操作中提取,例如“Request Assigned to Agent”“Note Added”或“Service Request Resolved”。 此属性对于构建流程图至关重要,流程图以可视化方式呈现服务请求流转。通过分析不同活动的顺序和频率,组织可以了解实际流程,识别步骤之间的瓶颈,衡量活动时长,并发现不合规或低效的流程变体。
为什么重要
此属性定义流程图中的步骤,用于可视化和分析服务请求工作流。
获取位置
根据Freshservice工单关联的“activities”或“audits”生成。通常需要通过转换逻辑,将系统事件映射为便于业务理解的活动名称。
示例
服务请求已创建请求已分配给处理人员服务请求已解决服务请求已关闭
|
|||
|
数据最后更新时间
LastDataUpdate
|
表示数据最近一次从源系统刷新时间的时间戳。 | ||
|
说明
此属性记录数据集最近一次从Freshservice提取或更新的日期和时间,帮助说明所分析数据的新鲜度。 对于任何流程分析,了解数据的新鲜度都至关重要。此时间戳有助于用户判断当前查看的是否为最新信息,这对于及时作出运营决策以及信任分析所得洞察不可或缺。
为什么重要
帮助用户了解数据的新鲜度,确保分析和决策基于最新信息。
获取位置
此值在数据提取和转换(ETL)过程中生成并写入数据集。
示例
2024-05-21T02:00:00Z2024-05-20T02:00:00Z
|
|||
|
源系统
SourceSystem
|
标识数据提取自哪个系统。 | ||
|
说明
此属性指定流程数据的来源系统,本例中为Freshservice。在整合多个系统的数据以获得完整流程视图时,该属性尤其有用。 在单系统分析中,它可能看似多余,但为支持未来扩展和数据治理,建议保留此属性。它有助于明确数据来源,并管理数据集成管道。
为什么重要
确保数据来源清晰且可追溯,这在整合多个系统的数据或开展数据治理时至关重要。
获取位置
通常在数据提取和转换(ETL)过程中添加为静态值。
示例
FreshserviceFreshservice-API-v2
|
|||
|
优先级
Priority
|
服务请求的优先级,例如Low、Medium、High或Urgent。 | ||
|
说明
Priority表示服务请求的重要性和紧急程度,通常决定目标解决时间及分配的资源。优先级可以根据规则自动设置,也可以由处理人员手动设置。 在流程挖掘中,Priority是重要的分析维度。它用于对请求分组,比较高优先级和低优先级请求的流程和绩效。这对于SLA合规性分析,以及了解分诊阶段是否及时、有效地完成优先级设置至关重要。
为什么重要
对于SLA合规性分析,以及了解请求是否根据业务影响完成分诊和处理至关重要。
获取位置
可在Freshservice工单对象的“priority”字段中获取。
示例
低中高紧急
|
|||
|
分配的团队
AssignedTeam
|
负责处理服务请求的支持团队或组。 | ||
|
说明
此属性表示负责服务请求的职能组或团队,例如“IT Support Level 2”或“Hardware Procurement”。请求可能先分配给团队,再由具体处理人员接手。 按Assigned Team分析有助于了解团队层面的绩效和工作量,并识别特定职能领域的瓶颈。这对于评估不同团队处理请求的效率,以及优化支持组织内的资源分配至关重要。
为什么重要
支持在团队或组层面分析绩效和工作量,对于资源管理和识别职能瓶颈至关重要。
获取位置
可在Freshservice工单对象的“group”字段中获取。
示例
服务台网络运营应用支持
|
|||
|
分配的处理人员
AssignedAgent
|
当前负责服务请求的处理人员姓名。 | ||
|
说明
此属性标识在特定时间点负责处理服务请求的支持人员。请求生命周期内,处理人员可能发生变化。 分析Assigned Agent是了解处理人员绩效和工作量分配的关键。它支持计算每位处理人员的平均解决时间、活跃请求数和重新分配率等KPI,有助于识别高绩效人员、需要额外培训的人员以及工作量分配不均衡的问题。
为什么重要
支持分析处理人员的工作量、绩效,以及重新分配对解决时间的影响。
获取位置
可在Freshservice工单对象的“agent”或“responder”字段中获取。
示例
Alice JohnsonRobert Smith未分配
|
|||
|
服务类型
ServiceType
|
所请求服务的具体类型或类别。 | ||
|
说明
Service Type根据所需服务类型对请求进行分类,例如“New Hardware Request”“Software Access”或“Password Reset”。它通常与用户选择的服务目录项目相关联。 此属性支持按服务请求类型分组,比较不同服务的流程和绩效。它对于计算“Average Activity Count per Service Type”等KPI至关重要,有助于识别复杂度或资源投入较高的服务。相关分析可以推动特定服务类型的流程简化和自动化。
为什么重要
支持比较不同请求类别的流程和复杂度,帮助识别适合标准化或自动化的领域。
获取位置
根据配置不同,通常对应Freshservice工单对象中的“category”“item”或自定义字段。
示例
新员工入职软件许可证申请VPN访问
|
|||
|
状态
Status
|
服务请求在生命周期中的当前状态。 | ||
|
说明
“状态”字段表示服务请求在某个时间点所处的状态,例如“打开”“待处理”“已解决”或“已关闭”。状态变更通常是流程挖掘中活动的主要来源。 分析“状态”可以为流程提供背景信息,并帮助了解请求在特定状态下停留的时间。例如,“待处理”状态持续时间过长,可能表明请求正在等待请求人提供信息或外部供应商反馈。这是定义不同流程阶段起点和终点的关键属性。
为什么重要
为每个事件提供关键背景,并帮助衡量请求在“Open”或“Pending”等不同状态中的停留时间,从而识别延迟。
获取位置
可在Freshservice工单对象的“status”字段中获取。
示例
已打开待处理已解决已关闭
|
|||
|
SLA到期时间
SlaDueDate
|
根据SLA,该服务请求预计完成解决的时间戳。 | ||
|
说明
此属性指定适用SLA政策规定的服务请求解决期限。这是一个计算得出的时间戳,基于请求创建时间、优先级以及SLA中定义的工作时间计算得出。 这是监控实时绩效和开展事后SLA合规分析的关键数据点。通过将实际解决时间与SlaDueDate进行比较,可以判定请求是否“已达标”或“已违约”。它是计算SLA合规率KPI的基础。
为什么重要
这是解决请求的目标期限,也是判断服务请求是否满足或违反SLA的计算依据。
获取位置
这是Freshservice中的计算字段,在工单上显示为“截止时间”。可通过API获取。
示例
2023-10-28T17:00:00Z2023-11-01T09:00:00Z
|
|||
|
SLA策略名称
SlaPolicyName
|
应用于请求的Service Level Agreement(SLA)策略名称。 | ||
|
说明
此属性标识管理服务请求目标响应时间和解决时间的具体SLA策略。策略通常基于优先级、服务类型或请求人所属组等因素制定。 了解所应用的SLA策略,对于SLA Compliance & Breach Analysis仪表板至关重要。它支持准确衡量绩效是否达到既定目标,并分析哪些策略最常被违反。这有助于组织重新评估流程绩效或SLA目标本身的可行性。
为什么重要
标识请求所对应的具体服务目标,是准确报告SLA合规情况的基础。
获取位置
此信息属于与工单关联的SLA数据,可能需要查询特定的SLA相关API端点或字段。
示例
高优先级事件,4小时标准请求,3天VIP支持,1小时
|
|||
|
是否返工
IsRework
|
用于标识请求是否包含返工活动的布尔标记。 | ||
|
说明
如果服务请求经历了表明返工的特定活动,此计算标记将设为true。例如,解决后重新打开(“Service Request Reopened”)、多次重新分配,或反复向用户请求信息(“Information Requested from Requestor”)。 此属性简化了流程低效分析。您可以据此筛选出包含返工的案例,并将其流程图和周期时间与“干净”案例进行比较。它直接支持“Service Request Rework Analysis”仪表板,并帮助量化低效交接或初始信息不完整造成的影响。
为什么重要
以简单方式标记和分析包含低效循环或重复步骤的案例,帮助量化质量不佳带来的成本。
获取位置
在数据转换过程中,根据每个“ServiceRequestId”的活动序列应用业务逻辑计算得出。
示例
truefalse
|
|||
|
是否违反SLA
IsSlaBreached
|
用于标识服务请求是否超过解决SLA目标的布尔标记。 | ||
|
说明
此计算属性是一个简单的true或false标记,用于表示服务请求是否在SLA到期时间之后关闭。它通过比较“Service Request Closed”或“Service Request Resolved”时间戳与“SlaDueDate”得出。 此属性简化了SLA合规仪表板中的分析和可视化。您可以据此轻松筛选和聚合数据,计算整体SLA合规率KPI。按此标记分段,有助于快速识别并分析违反SLA的请求与按时解决请求之间的流程特征差异。
为什么重要
通过提供清晰的筛选和聚合标记,简化SLA合规分析,帮助识别未达到目标的请求。
获取位置
这是一个计算字段,在数据转换过程中通过比较最终解决时间戳与“SlaDueDate”字段得出。
示例
truefalse
|
|||
|
渠道
Channel
|
提交服务请求所使用的方式或渠道。 | ||
|
说明
Channel表示服务请求的创建方式,例如自助服务门户、电子邮件、电话或聊天。此信息有助于了解用户偏好和渠道效率。 按渠道分析流程可以发现重要洞察。例如,通过门户提交的请求可能比通过电子邮件提交的请求信息更完整、解决更快,而电子邮件请求可能需要更多来回沟通。此类分析可以指导组织推广更高效的渠道。
为什么重要
帮助分析提交渠道是否影响流程效率、解决时间或所需返工量。
获取位置
可在Freshservice工单对象的“source”字段中获取。
示例
电子邮件门户电话聊天
|
|||
|
结束时间
EndTime
|
活动完成时的精确时间戳。 | ||
|
说明
结束时间表示活动完成的时间戳。在Freshservice中,许多事件的开始时间和结束时间相同,因此属于时间点事件。但对于基于状态的活动,结束时间应为下一次状态变更的时间戳。 此属性对于计算活动持续时间及活动之间的等待时间至关重要。用EndTime减去StartTime,即可确定特定Task的处理时间。这对于识别耗时最长、最需要优化的活动非常重要。
为什么重要
支持计算活动持续时间,这是识别瓶颈和衡量各步骤处理时间的基础。
获取位置
这不是Freshservice日志中的直接字段。需要在数据转换过程中,使用同一服务请求后续事件的时间戳推导得出。
示例
2023-10-26T10:05:15Z2023-10-26T14:00:20Z2023-10-28T09:30:00Z
|
|||
|
请求人
Requestor
|
提交服务请求的用户。 | ||
|
说明
该属性用于标识发起服务请求的个人,通常是员工。它可以帮助了解谁在使用服务台,以及对方的需求是什么。 虽然请求人或其所属部门不一定是流程分析的主要维度,但按请求人或部门进行分析可以发现规律。例如,分析可能显示某个部门经常提交信息不完整的请求,说明需要开展有针对性的培训。对于任何关注客户体验的分析,这一属性也十分重要。
为什么重要
提供发起请求用户的背景信息,支持按个人、部门或地点分析请求模式。
获取位置
可在Freshservice工单对象的“requester”字段中获取。
示例
John DoeJane Smith服务账户
|
|||
|
请求人所属部门
RequestorDepartment
|
请求人所属的部门。 | ||
|
说明
此属性指定提交服务请求用户所属的组织部门,例如“Sales”“Finance”或“Human Resources”。此信息通常来自系统中的用户档案。 按部门分析流程绩效是常见需求。它可以揭示某些部门是否面临更长的解决时间,或是否存在独特的流程需求。这些洞察可以指导资源分配、培训计划或部门专属服务的创建。
为什么重要
支持按业务部门细分流程,帮助识别部门特有的问题或绩效差异。
获取位置
此信息通过请求人的用户档案关联。它可能位于Freshservice的默认“department”字段或自定义用户字段中。
示例
财务市场营销信息技术
|
|||
|
重新分配次数
ReassignmentCount
|
服务请求被重新分配给其他Agent或团队的总次数。 | ||
|
说明
这是一个计算属性,用于统计每个服务请求中“Request Reassigned”或类似活动的发生次数。重新分配次数较高,通常表明初始分诊、基于技能的路由或工作负载分配存在问题。 此属性直接支持“Agent Performance & Workload Distribution”仪表板和“Avg Agent Reassignment Count/Request”KPI。分析这一指标有助于组织识别导致工单反复转交的流程缺陷,而这会延长解决时间,并使Agent和请求人都感到不满。
为什么重要
衡量路由效率低下和流程摩擦程度。次数较高通常表示初始分诊或Agent工作负载存在问题,从而导致延迟。
获取位置
在数据转换过程中,按每个“ServiceRequestId”统计特定分配变更活动的次数。
示例
013
|
|||
服务请求管理活动
| 活动 | 说明 | ||
|---|---|---|---|
|
已联系外部供应商
|
标志着工单被移交给外部供应商或第三方解决。通常可根据状态变更为“Pending Vendor”或“Awaiting Third Party”等特定状态来推断。 | ||
|
为什么重要
引入供应商可能造成显著延迟。跟踪此活动对于衡量供应商绩效及其对整体服务请求周期时间的影响至关重要。
获取位置
根据工单状态变更历史推断。查找专门用于跟踪外部供应商依赖关系的状态。
采集
检测工单状态字段何时变更为表示等待第三方处理的值。
事件类型
inferred
|
|||
|
已超出SLA目标
|
当解决服务请求所需时间超过规定的Service Level Agreement(SLA)目标时,会产生此计算事件。它不是直接的系统事件,而是通过比较解决时间与SLA到期时间推导得出。 | ||
|
为什么重要
此指标直接衡量服务表现是否达到承诺,是管理层关注的关键KPI。它有助于识别最容易未达标的请求类型或优先级。
获取位置
通过比较“Resolved”时间戳与“SLA Due By”时间戳计算。如果解决时间更晚,则触发此事件。
采集
比较解决时间戳与SLA到期时间戳。如果resolved_at > sla_due_by,则创建此事件。
事件类型
calculated
|
|||
|
服务请求已关闭
|
这是最后一个活动,标志着服务请求生命周期结束。工单在“Resolved”状态保持一段时间且未重新打开后,通常会自动关闭。 | ||
|
为什么重要
此事件标志着流程实例的最终结束。“Resolved”到“Closed”之间的时间代表请求人的确认窗口。
获取位置
根据工单状态变更历史推断。对应状态变更为“Closed”时的时间戳。
采集
记录工单状态变更为“Closed”时的时间戳。
事件类型
inferred
|
|||
|
服务请求已创建
|
当新请求正式录入Freshservice时,此活动标志着服务请求生命周期的开始。系统会在通过服务目录、电子邮件或其他渠道生成新工单记录时明确记录此事件,并创建唯一的Service Request ID。 | ||
|
为什么重要
这是流程的主要开始事件。分析此活动与其他活动之间的时间,是衡量整体周期时间和识别初始处理延迟的基础。
获取位置
Freshservice会明确记录此事件。通常可在工单的活动日志或审计轨迹中找到,对应工单创建时间戳。
采集
使用Freshservice工单数据中的工单创建时间戳。
事件类型
explicit
|
|||
|
服务请求已解决
|
当处理人员提供解决方案并认为工作完成时,此关键里程碑随之发生。通常可根据工单状态变更为“Resolved”来推断。 | ||
|
为什么重要
此活动标志着主动处理阶段结束。到达此节点所需的时长,是衡量处理人员和流程效率的关键指标,也是SLA计算的基础。
获取位置
根据工单状态变更历史推断。对应状态首次设置为“Resolved”时的时间戳。
采集
记录工单状态首次变更为“Resolved”时的时间戳。
事件类型
inferred
|
|||
|
请求已分配给处理人员
|
标志着服务请求被分配给特定处理人员负责处理。此关键里程碑可通过跟踪工单“Assigned Agent”或“Owner”字段的变更来推断。 | ||
|
为什么重要
此活动对于分析处理人员工作量和识别分配流程中的瓶颈至关重要。从创建到分配之间的时间是关键绩效指标。
获取位置
通过监控工单活动日志或字段审计轨迹中“Agent”或“Assignee”字段的变更来推断。
采集
记录“Assigned Agent”字段被填充或其值发生变更时的时间戳。
事件类型
inferred
|
|||
|
已向请求人索取信息
|
表示负责的处理人员需要请求人提供更多信息,流程因此暂停。通常可根据工单状态变更为“Pending”或“Awaiting Customer”来推断。 | ||
|
为什么重要
此活动揭示了常见的延迟和返工来源。分析其发生频率,有助于发现改进请求模板和初始数据收集的机会。
获取位置
根据工单状态变更历史推断。查找变更为“Pending Customer Response”或“Awaiting Information”等状态的记录。
采集
检测工单状态字段何时变更为表示等待用户输入的值。
事件类型
inferred
|
|||
|
已完成内部审核
|
表示拟议解决方案或请求交付在继续之前需要内部审核或批准。通常可根据状态变更为“Pending Approval”或“Internal Review”等状态来推断。 | ||
|
为什么重要
内部审核可能成为瓶颈,尤其是在复杂或影响范围较大的服务请求中。衡量此阶段的时长有助于简化审批工作流。
获取位置
根据工单状态变更历史推断。工作流中需要使用“Pending Internal Approval”等特定状态。
采集
检测工单状态字段何时变更为表示内部审核或批准的值。
事件类型
inferred
|
|||
|
已添加备注
|
表示处理人员或请求人向服务请求添加的任何公开或私密备注。这是工单对话或活动日志中明确记录的事件。 | ||
|
为什么重要
分析备注的频率和时间,可以揭示沟通模式、协作效率以及流程中的疑点。
获取位置
Freshservice会在工单对话历史中明确记录。每条备注都包含时间戳和作者。
采集
提取工单对话或评论日志中的每条记录。
事件类型
explicit
|
|||
|
服务请求已重新打开
|
当请求人表示问题在标记为“Resolved”后仍然存在,工单会回到开放状态。通常可根据状态从“Resolved”变更回“Open”或“In Progress”来推断。 | ||
|
为什么重要
重新打开的请求通常表明首次联系解决率较低或客户不满意。跟踪这一返工循环对于提升解决方案质量至关重要。
获取位置
根据活动日志中的工单状态变更历史推断。这是从“Resolved”直接变更为“Open”的状态转换。
采集
检测状态何时从已解决状态变更为开放状态。
事件类型
inferred
|
|||
|
请求人已提供信息
|
当请求人回复所需信息后,处理人员即可恢复工作。通常可根据工单状态从“Pending”自动变更回“Open”来推断。 | ||
|
为什么重要
此活动标志着信息请求闭环。从索取信息到提供信息之间的时长,是需要分析和优化的关键等待时间。
获取位置
根据状态从“Pending”变更回“Open”或“In Progress”来推断,通常由请求人的回复触发。
采集
检测工单状态何时从待处理状态变更为开放状态。
事件类型
inferred
|
|||
|
请求人已确认解决方案
|
表示请求人明确确认所提供的解决方案令人满意。可根据正向调查回复或工单关闭前的特定评论来推断。 | ||
|
为什么重要
确认结果能够直接反馈解决质量。即使请求未重新打开,较低的确认率也可能表明解决方案未完全满足用户需求。
获取位置
此事件难以直接捕获,可能需要自定义配置。可根据与工单关联的客户满意度调查回复,或应用特定标签来推断。
采集
需要分析满意度调查或解决后应用的标签等相关数据。
事件类型
inferred
|
|||
|
请求已分诊
|
表示对新创建服务请求进行初步评估和分类。通常可根据首次设置优先级或将请求分配给某个组来推断此活动,这说明请求已完成审核并进入队列。 | ||
|
为什么重要
跟踪分诊有助于衡量初始响应团队的效率。此阶段的延迟可能显著影响整体解决时间和SLA合规性。
获取位置
根据活动日志推断。可识别创建后首次发生的“Priority Set”或“Group Assigned”事件的时间戳。
采集
确定优先级字段变更或分配组字段变更中最早的时间戳。
事件类型
inferred
|
|||
|
请求已设置优先级
|
当服务请求被分配Low、Medium或High等优先级时,此活动随之发生。可通过检测工单历史记录中的“Priority”字段变更来推断。 | ||
|
为什么重要
优先级设置对于资源分配和确保达到SLA目标至关重要。分析此活动有助于确认请求是否得到及时、准确的评估。
获取位置
根据Freshservice中的工单字段变更历史推断。查找“Priority”字段的更新,并记录变更时间戳。
采集
检测“Priority”字段从null或原值发生的变更,并记录时间戳。
事件类型
inferred
|
|||
|
请求已重新分配
|
记录初次分配后处理人员或组的任何变更。可通过检测“Assigned Agent”或“Assigned Group”字段的后续更新来推断。 | ||
|
为什么重要
频繁重新分配可能表明初始分诊、处理人员技能匹配或工作量平衡存在问题。此活动对于Agent Reassignment Count KPI和返工分析十分重要。
获取位置
根据工单字段变更历史推断。首次设置初始值后,每次更新“Assigned Agent”或“Assigned Group”字段时都会记录此事件。
采集
检测首次分配后“Assigned Agent”或“Assigned Group”字段的任何变更。
事件类型
inferred
|
|||
提取指南
立即提升Freshservice服务请求效率
告别处理缓慢和用户不满,实现70%的自动化。
无需信用卡,几分钟即可完成设置。