服务请求管理数据模板
服务请求管理数据模板
- 建议收集的属性
- 需要跟踪的关键活动
- 数据提取指南
服务请求管理属性
| 名称 | 说明 | ||
|---|---|---|---|
|
事件时间
EventTime
|
活动发生的准确时间戳。 | ||
|
说明
事件时间记录服务请求中某项活动的日期和时间。此时间戳对于正确排列事件顺序和计算事件间隔至关重要。 在流程挖掘中,此属性用于排列每个案例中的活动,也是所有时间分析的基础。它可用于计算周期时间、活动间等待时间,以及服务级别协议(SLA)的达成情况。准确的时间戳对于发现瓶颈和了解流程绩效至关重要。
重要性
此时间戳用于按时间顺序排列事件,也是周期时间分析和瓶颈识别等绩效分析的基础。
获取途径
对应Freshservice中活动或审计日志条目的创建时间戳。
示例
2023-10-26T10:00:00Z2023-10-26T11:35:10Z2023-10-27T14:20:05Z
|
|||
|
服务请求ID
ServiceRequestId
|
每个服务请求的唯一标识符。 | ||
|
说明
服务请求ID是Freshservice为每个新登记的服务请求分配的唯一编号或代码。它是跟踪请求完整生命周期的主键,涵盖从创建到关闭的全过程。 在流程挖掘中,该ID至关重要,因为它充当案例ID。状态变更、客服专员分配和备注等相关事件都通过此标识符关联起来。分析每个服务请求ID的处理过程,可以完整呈现端到端流程,识别常见路径,并发现影响个别案例的偏差或瓶颈。
重要性
这是关联所有相关事件的关键案例ID,可用于追踪单个服务请求的端到端处理过程。
获取途径
这是Freshservice工单对象中的主要字段,在界面中可见,也可通过Freshservice API获取。
示例
SR-12943SR-13501SR-14011
|
|||
|
活动名称
ActivityName
|
服务请求在特定时间发生的事件或任务名称。 | ||
|
说明
活动名称用于描述服务请求生命周期中的具体步骤或事件。这些活动从系统审计日志、状态变更或用户执行的具体操作中提取,例如“请求已分配给客服专员”“已添加备注”或“服务请求已解决”。 此属性对于构建流程图至关重要,流程图可直观呈现服务请求的处理流程。通过分析不同活动的顺序和频率,组织可以了解实际流程、发现步骤间的瓶颈、衡量活动耗时,并识别不符合规范或效率低下的流程变体。
重要性
此属性定义流程图中的步骤,用于呈现和分析服务请求工作流。
获取途径
根据Freshservice工单关联的“activities”或“audits”生成。通常需要通过转换逻辑,将系统事件映射为便于业务理解的活动名称。
示例
创建服务请求将请求分配给服务人员解决服务请求关闭服务请求
|
|||
|
上次数据更新时间
LastDataUpdate
|
指示数据上次从源系统刷新时间的时间戳。 | ||
|
说明
此属性记录数据集上次从Freshservice提取或更新的日期和时间,说明所分析数据的时效性。 开展流程分析时,了解数据是否最新至关重要。此时间戳可帮助您判断当前查看的信息是否为最新数据,这对于及时做出运营决策以及信任分析结果都很重要。
重要性
显示数据的时效性,确保分析和决策基于最新信息。
获取途径
此值在数据提取和转换(ETL)过程中生成并写入数据集。
示例
2024-05-21T02:00:00Z2024-05-20T02:00:00Z
|
|||
|
源系统
SourceSystem
|
标识数据提取自哪个系统。 | ||
|
说明
此属性指定流程数据的来源系统,本例中为Freshservice。在整合多个系统的数据以全面了解流程时,此属性尤其有用。 即使只分析单个系统,添加此属性看似多余,但这有助于支持未来扩展和数据治理。它能明确数据来源,并帮助管理数据集成流程。
重要性
确保数据来源清晰且可追溯,这对于整合多个系统的数据或开展数据治理至关重要。
获取途径
通常在数据提取和转换(ETL)过程中添加为固定值。
示例
FreshserviceFreshservice-API-v2
|
|||
|
优先级
Priority
|
服务请求的优先级,例如低、中、高或紧急。 | ||
|
说明
优先级表示服务请求的重要程度和紧急程度,通常决定目标解决时间和资源分配。优先级可根据规则自动设置,也可由客服专员手动设置。 在流程挖掘中,优先级是重要的分析维度。您可以按优先级对请求分组,比较高优先级和低优先级请求的流程及绩效。这对于SLA达成情况分析,以及了解分诊阶段是否及时、有效地确定优先级至关重要。
重要性
对于分析SLA达成情况,以及了解请求是否根据业务影响进行分诊和处理至关重要。
获取途径
可在Freshservice工单对象的“priority”字段中获取。
示例
低中高紧急
|
|||
|
已分配团队
AssignedTeam
|
负责处理服务请求的支持团队或小组。 | ||
|
说明
此属性表示负责处理服务请求的职能小组或团队,例如“IT二线支持”或“硬件采购”。请求可能会先分配给团队,再由具体客服专员接手。 按已分配团队分析,有助于了解团队层面的绩效和工作量,并发现特定职能领域的瓶颈。这对于评估不同团队处理请求的效率,以及优化支持组织的资源分配至关重要。
重要性
支持在团队或小组层面分析绩效和工作量,有助于管理资源并发现职能领域的瓶颈。
获取途径
可在Freshservice工单对象的“group”字段中获取。
示例
服务台网络运营应用支持
|
|||
|
已分配客服专员
AssignedAgent
|
当前负责处理服务请求的客服专员姓名。 | ||
|
说明
此属性用于标识在特定时间负责处理服务请求的客服专员。请求生命周期中,负责人可能会发生变化。 分析已分配客服专员的数据,有助于了解客服专员的绩效和工作量分布。您可以据此计算每位客服专员的平均解决时间、活跃请求数和重新分配率等KPI,从而识别表现突出的客服专员、可能需要额外培训的人员,以及工作量分配不均的情况。
重要性
可用于分析客服专员的工作量和绩效,以及重新分配对解决时间的影响。
获取途径
可在Freshservice工单对象的“agent”或“responder”字段中获取。
示例
Alice JohnsonRobert Smith未分配
|
|||
|
服务类型
ServiceType
|
所请求服务的具体类型或类别。 | ||
|
说明
服务类型根据所需服务对请求进行分类,例如“新硬件申请”“软件访问权限”或“重置密码”。这通常与用户选择的服务目录项目相关联。 此属性可用于按服务请求类型分组,比较不同服务的流程和绩效。它对于计算“每种服务类型的平均活动数”等KPI至关重要,有助于识别复杂度或资源需求较高的服务。分析结果可用于推动特定服务类型的流程简化和自动化。
重要性
支持比较不同请求类别的流程和复杂度,帮助发现需要标准化或自动化的领域。
获取途径
根据Freshservice的配置,此属性通常对应工单对象中的“category”“item”或自定义字段。
示例
新员工入职软件许可证申请VPN访问权限
|
|||
|
状态
Status
|
服务请求在生命周期中的当前状态。 | ||
|
说明
“状态”字段表示服务请求在特定时间点所处的状态,例如“开启”“待处理”“已解决”或“已关闭”。状态变更通常是流程挖掘中活动数据的主要来源。 分析状态有助于了解流程进展,以及请求在各状态中停留的时间。例如,“待处理”状态持续时间过长,可能意味着请求正在等待请求者提供信息或外部供应商处理。此属性对于定义不同流程阶段的起点和终点也很重要。
重要性
为每个事件提供重要背景信息,并帮助衡量请求在“开启”或“待处理”等状态中的停留时间,以便发现延误。
获取途径
可在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
|
适用于该请求的服务级别协议(SLA)策略名称。 | ||
|
说明
此属性用于标识适用于服务请求的具体SLA策略,该策略规定了目标响应时间和解决时间。策略通常根据优先级、服务类型或请求者所属群组等因素制定。 了解所应用的SLA策略,对于使用SLA达成与超时分析仪表板至关重要。它有助于准确衡量实际绩效是否达到既定目标,并分析哪些策略最常超时。分析结果可用于评估流程绩效,或判断SLA目标本身是否合理。
重要性
标识衡量请求时所依据的具体服务目标,是准确报告SLA达成情况的必要信息。
获取途径
此信息属于工单关联的SLA数据,可能需要查询特定的SLA相关API端点或字段。
示例
高优先级事件-4小时标准请求-3天VIP支持-1小时
|
|||
|
是否返工
IsRework
|
用于标记请求是否涉及返工活动的布尔值。 | ||
|
说明
如果服务请求经历了表明需要返工的活动,此计算标记将设为真。例如,解决后重新开启(“服务请求已重新开启”)、多次重新分配,或多次向用户索取信息(“已向请求者索取信息”)。 此属性简化了流程低效情况的分析。您可以轻松筛选出涉及返工的案例,并将其流程图和周期时间与“顺畅”案例进行比较。此属性直接支持“服务请求返工分析”仪表板,并有助于量化交接效率低下或初始信息不完整造成的影响。
重要性
便于标记和分析涉及低效循环或重复步骤的案例,帮助量化质量不佳带来的成本。
获取途径
在数据转换过程中,根据每个“ServiceRequestId”的活动顺序应用业务逻辑计算得出。
示例
truefalse
|
|||
|
是否违反SLA
IsSlaBreached
|
用于标记服务请求是否超出解决SLA目标的布尔值。 | ||
|
说明
此计算属性是一个简单的真或假标记,用于指示服务请求是否在SLA截止时间之后关闭。该值通过比较“服务请求已关闭”或“服务请求已解决”的时间戳与“SlaDueDate”得出。 此属性简化了SLA达成情况仪表板中的分析和可视化。您可以轻松筛选和汇总数据,计算整体SLA达成率KPI。按此标记分组,有助于快速筛选并分析超时请求与按时解决请求的流程特征。
重要性
通过提供清晰的标记,简化SLA达成情况分析,便于筛选和汇总未达到目标的请求。
获取途径
这是一个计算字段,在数据转换过程中通过比较最终解决时间戳与“SlaDueDate”字段得出。
示例
truefalse
|
|||
|
渠道
Channel
|
提交服务请求的方式或渠道。 | ||
|
说明
渠道表示服务请求的提交方式,例如通过自助服务门户、电子邮件、电话或聊天提交。此信息有助于了解用户偏好和各渠道的效率。 按渠道分析流程可以发现重要信息。例如,通过门户提交的请求可能比通过电子邮件提交的请求信息更完整、解决速度更快;电子邮件请求则可能需要多次沟通。此类分析有助于推广更高效的渠道。
重要性
有助于分析提交渠道是否会影响流程效率、解决时间或所需返工量。
获取途径
可在Freshservice工单对象的“source”字段中获取。
示例
电子邮件门户电话聊天
|
|||
|
结束时间
EndTime
|
活动完成的准确时间戳。 | ||
|
说明
结束时间表示活动完成时的时间戳。在Freshservice中,许多事件的开始时间和结束时间相同,因此属于瞬时事件。但对于基于状态的活动,结束时间则是下一次状态变更的时间戳。 此属性对于计算活动持续时间和活动间的等待时间至关重要。用结束时间减去开始时间,即可得出特定任务的处理时间。这有助于识别最耗时、最需要优化的活动。
重要性
支持计算活动持续时间,这是识别瓶颈和衡量各步骤处理时间的基础。
获取途径
Freshservice日志中没有直接对应的字段。需要根据某个服务请求的事件顺序,使用后续事件的时间戳推算。
示例
2023-10-26T10:05:15Z2023-10-26T14:00:20Z2023-10-28T09:30:00Z
|
|||
|
请求者
Requestor
|
提交服务请求的用户。 | ||
|
说明
此属性用于标识发起服务请求的个人,通常是员工。它有助于了解谁在使用服务台,以及他们的需求。 请求者并非流程分析的主要维度,但按请求者或其所属部门分析可以发现规律。例如,某个部门可能经常提交信息不完整的请求,说明需要开展针对性培训。对于客户体验分析,此属性也很重要。
重要性
提供发起请求的用户信息,支持按个人、部门或地点分析请求模式。
获取途径
可在Freshservice工单对象的“requester”字段中获取。
示例
John DoeJane Smith服务账户
|
|||
|
请求者部门
RequestorDepartment
|
请求者所属的部门。 | ||
|
说明
此属性指定提交服务请求的用户所属部门,例如“销售”“财务”或“人力资源”。此信息通常来自系统中的用户资料。 按部门分析流程绩效是常见需求,有助于发现某些部门的解决时间是否更长,或是否有独特的流程需求。分析结果可用于指导资源分配、培训计划或部门专属服务的设计。
重要性
支持按业务单元细分流程,帮助发现部门特有的问题或绩效差异。
获取途径
此信息关联至请求者的用户资料,可能来自Freshservice中的默认“department”字段或自定义用户字段。
示例
财务市场营销信息技术
|
|||
|
重新分配次数
ReassignmentCount
|
服务请求被重新分配给其他客服专员或团队的总次数。 | ||
|
说明
此计算属性统计每个服务请求中“请求已重新分配”或类似活动的发生次数。重新分配次数过多,通常说明初步分诊存在问题、技能路由不准确或工作量分配不均。 此属性直接支持“客服专员绩效与工作量分布”仪表板,以及“每个请求的客服专员平均重新分配次数”KPI。分析此指标有助于发现导致工单在不同人员间流转的流程问题。这类问题会延长解决时间,也会让客服专员和请求者感到沮丧。
重要性
衡量路由效率低下和流程阻滞程度。次数过多说明初步分诊或客服专员工作量存在问题,可能导致延误。
获取途径
在数据转换过程中,统计每个“ServiceRequestId”对应的特定分配变更活动即可计算得出。
示例
013
|
|||
服务请求管理活动
| 活动 | 说明 | ||
|---|---|---|---|
|
SLA目标未达成
|
当服务请求的解决时间超过规定的服务级别协议(SLA)目标时,即触发此计算事件。这不是系统直接记录的事件,而是通过比较解决时间和SLA截止时间得出的。 | ||
|
重要性
此指标直接衡量服务表现是否达到承诺,是管理层关注的重要KPI。它有助于找出最可能无法按时完成的请求类型或优先级。
获取途径
比较“已解决”时间戳与“SLA截止时间”时间戳后计算得出。如果解决时间晚于截止时间,则触发此事件。
采集
比较解决时间戳与SLA截止时间戳。如果resolved_at > sla_due_by,则创建此事件。
事件类型
calculated
|
|||
|
关闭服务请求
|
这是最后一项活动,标志着服务请求生命周期结束。通常工单在“已解决”状态保持一段设定时间且未重新打开后,会自动关闭。 | ||
|
重要性
此事件标志着流程实例正式结束。从“已解决”到“已关闭”的时间,是请求者确认处理结果的期限。
获取途径
根据工单状态变更记录推断,对应状态变为“已关闭”时的时间戳。
采集
记录工单状态变为“已关闭”时的时间戳。
事件类型
inferred
|
|||
|
创建服务请求
|
此活动标志着服务请求生命周期的开始,即新请求正式录入Freshservice。系统会在生成新工单记录时明确记录此事件。新工单可能来自服务目录、电子邮件或其他渠道,并获得唯一的服务请求ID。 | ||
|
重要性
这是流程的主要开始事件。分析此活动与后续活动之间的时间,是衡量整体周期时间和发现初始处理延误的基础。
获取途径
Freshservice会明确记录此事件。您可以在工单的活动日志或审计记录中找到它,通常对应工单创建时间戳。
采集
使用Freshservice工单数据中的工单创建时间戳。
事件类型
explicit
|
|||
|
将请求分配给服务人员
|
标记服务请求分配给具体服务人员处理的时间点。这是一个重要里程碑,可通过跟踪工单的“已分配服务人员”或“负责人”字段变更来推断。 | ||
|
重要性
此活动对于分析服务人员工作量和发现分配流程中的瓶颈至关重要。从创建到分配的时间是重要的绩效指标。
获取途径
通过监控工单活动日志或字段审计记录中“服务人员”或“受理人”字段的变更来推断。
采集
记录“已分配服务人员”字段首次填入内容或其值发生变更时的时间戳。
事件类型
inferred
|
|||
|
联系外部供应商
|
此活动标志着工单已转交外部供应商或第三方处理。可根据状态变为“等待供应商处理”或“等待第三方”等情况推断。 | ||
|
重要性
与供应商协作可能造成明显延误。跟踪此活动对于衡量供应商表现及其对服务请求整体周期时间的影响至关重要。
获取途径
根据工单状态变更历史推断。查找专门用于跟踪外部供应商依赖情况的状态。
采集
检测工单状态字段是否变为表示等待第三方处理的值。
事件类型
inferred
|
|||
|
解决服务请求
|
此关键里程碑标志着服务人员已提供解决方案并认为工作完成。可根据工单状态变为“已解决”来推断。 | ||
|
重要性
此活动表示主动处理阶段结束。从开始到此时的时长是衡量服务人员和流程效率的重要指标,也是计算SLA的依据。
获取途径
根据工单状态变更历史推断,对应状态首次设为“已解决”时的时间戳。
采集
记录工单状态首次变为“已解决”时的时间戳。
事件类型
inferred
|
|||
|
向请求者索取信息
|
表示受理请求的服务人员需要请求者补充信息,处理因此暂停。可根据工单状态变为“待处理”或“等待客户回复”来推断。 | ||
|
重要性
此活动揭示了常见的延误和返工原因。分析其发生频率,有助于改进请求模板和初始数据收集。
获取途径
根据工单状态变更历史推断。查找状态变为“等待客户回复”或“等待补充信息”等情况。
采集
检测工单状态字段是否变为表示等待用户提供信息的值。
事件类型
inferred
|
|||
|
完成内部审核
|
表示拟议的解决方案或请求处理需要经过内部审核或审批后才能继续。可根据状态变为“待审批”或“内部审核”等情况推断。 | ||
|
重要性
内部审核可能成为瓶颈,尤其是在复杂或影响较大的服务请求中。衡量审核时长有助于简化审批工作流。
获取途径
根据工单状态变更历史推断。工作流中需要使用“等待内部审批”等特定状态。
采集
检测工单状态字段是否变为表示内部审核或审批的值。
事件类型
inferred
|
|||
|
完成请求分流
|
表示对新建服务请求进行初步评估和分类。通常可根据首次设置优先级或将请求分配给某个组来推断此活动,表明请求已完成审核并进入队列。 | ||
|
重要性
跟踪分流情况有助于衡量初始响应团队的效率。此阶段的延误会显著影响整体解决时间和SLA达成率。
获取途径
根据活动日志推断。可通过请求创建后首次发生的“设置优先级”或“分配组”事件的时间戳识别此活动。
采集
找出优先级字段或分配组字段发生变更的最早时间戳。
事件类型
inferred
|
|||
|
添加备注
|
表示服务人员或请求者在服务请求中添加的任何公开或私密备注。此事件会明确记录在工单对话或活动日志中。 | ||
|
重要性
分析备注的频率和时间,有助于了解沟通模式、协作效率以及流程中的疑问点。
获取途径
Freshservice会在工单对话历史中明确记录此活动。每条备注都包含时间戳和作者信息。
采集
从工单对话或评论日志中提取每条记录。
事件类型
explicit
|
|||
|
设置请求优先级
|
当服务请求被设置为低、中或高等优先级时,即发生此活动。可通过检测工单历史记录中“优先级”字段的变更来推断。 | ||
|
重要性
设置优先级对于资源分配和达到SLA目标至关重要。分析此活动有助于确认请求是否得到及时、准确的评估。
获取途径
根据Freshservice工单的字段变更历史推断。查找“优先级”字段的更新,并记录变更时间戳。
采集
检测“优先级”字段从空值或先前值发生的变更,并记录时间戳。
事件类型
inferred
|
|||
|
请求者提供信息
|
请求者提供所需信息后,服务人员即可恢复处理。通常可根据工单状态从“待处理”自动变回“未解决”来推断。 | ||
|
重要性
此活动标志着信息请求环节的结束。分析从索取信息到收到信息之间的时长,对于优化等待时间至关重要。
获取途径
根据状态从“待处理”变回“未解决”或“处理中”来推断,通常由请求者回复触发。
采集
检测工单状态是否从待处理变为未解决。
事件类型
inferred
|
|||
|
请求者确认解决结果
|
此活动表示请求者明确确认所提供的解决方案令人满意。可根据正向调查回复或工单关闭前的特定评论来推断。 | ||
|
重要性
确认结果可直接反映解决方案的质量。即使请求没有重新打开,确认率偏低也可能说明解决方案未能充分满足用户需求。
获取途径
此活动难以直接捕获,可能需要自定义配置。可根据关联工单的客户满意度调查回复,或是否添加特定标签来推断。
采集
需要分析满意度调查或解决后添加的标签等相关数据。
事件类型
inferred
|
|||
|
重新分配请求
|
此活动记录初次分配后服务人员或组的任何变更。可通过检测“已分配服务人员”或“已分配组”字段的后续更新来推断。 | ||
|
重要性
频繁重新分配可能说明初始分流、服务人员技能匹配或工作量平衡存在问题。此活动对于服务人员重新分配次数KPI和返工分析至关重要。
获取途径
根据工单字段变更历史推断。首次设置值后,每次更新“已分配服务人员”或“已分配组”字段时,都会记录此事件。
采集
首次分配后,检测“已分配服务人员”或“已分配组”字段的任何变更。
事件类型
inferred
|
|||
|
重新打开服务请求
|
请求者表示问题在标记为“已解决”后仍然存在,导致工单重新变为未解决状态时,即发生此活动。可根据状态从“已解决”变回“未解决”或“处理中”来推断。 | ||
|
重要性
请求重新打开,通常说明首次联系解决率偏低、客户不满意。跟踪这一返工循环对于提升解决方案质量至关重要。
获取途径
根据活动日志中的工单状态变更历史推断。这是状态从“已解决”直接变为“未解决”的情况。
采集
检测状态是否从已解决变为未解决。
事件类型
inferred
|
|||
数据提取指南
立即提升Freshservice服务请求效率
减少处理延迟和用户不满,实现70%的自动化。
无需信用卡,几分钟即可完成设置。