您的服务请求管理 Data 模板
您的服务请求管理 Data 模板
- 全面分析的推荐属性
- 需追踪的关键服务请求活动
- Zendesk Support 数据提取指南
服务请求管理属性
| 名称 | 描述 | ||
|---|---|---|---|
|
开始时间
EventTimestamp
|
活动发生的精确日期和时间。 | ||
|
描述
Event Timestamp(或开始时间)记录了活动发生的准确时刻。例如,它记录了指派坐席、发送公开回复或工单状态更改为“已解决”的时间。这些时间数据源自每张 Zendesk 工单的审计日志。 该属性对于任何基于时间的分析都至关重要。它用于按时间顺序排列事件、计算活动间的持续时间、衡量等待时间以及分析整体 case 周期。它是识别瓶颈以及对照 SLA 等时间目标评估绩效的基础。
为何重要
此 timestamp 按时间顺序排列 events,对于所有持续时间、性能和瓶颈分析都至关重要。
获取方式
Zendesk Ticket Audits API,每个审计 event 的 'created_at' 字段。
示例
2023-10-26T10:00:00Z2023-10-26T10:15:30Z2023-10-27T14:20:10Z
|
|||
|
服务请求 ID
ServiceRequestId
|
Zendesk 内每个服务请求工单的唯一标识符。 | ||
|
描述
Service Request ID(在 Zendesk 中通常称为工单 ID)是每个 case 的主键。它将从请求创建到关闭期间的所有相关 Activities、评论和状态变更联系在一起。这实现了对单个请求生命周期的完整端到端追踪。 在 Process Mining 分析中,此属性是基础。它定义了 case,从而能够重建流程流向、识别变体并计算 cycle time 等 case 级指标。数据集中的每个 event 都必须与 Service Request ID 相关联,以了解其在整体流程中的背景。
为何重要
这是核心的 case 标识符,它连接了服务请求历程中的所有 events,使得分析端到端流程成为可能。
获取方式
Zendesk Tickets API,字段 'id'。
示例
102451024610247
|
|||
|
活动
ActivityName
|
服务请求中发生的业务 activity 或 event 的名称。 | ||
|
描述
Activity 代表服务请求生命周期中一个独立的步骤或 event,例如“服务请求已创建”、“请求已分配给坐席”或“服务请求已解决”。这些 Activities 源自 Zendesk 工单审计日志中记录的变更,该日志追踪对状态、受理人、优先级等字段的修改以及评论的添加。 分析 Activities 是 Process Mining 的核心。它能实现流程图的可视化、识别步骤间的瓶颈并分析返工循环。通过了解 Activities 的顺序和频率,企业可以识别低效环节并找到流程改进的机会。
为何重要
此属性定义了流程中的步骤,实现了流程图的可视化,并支持对流程流向、变体和一致性的分析。
获取方式
这在概念上源自 Zendesk Ticket Audits API 中记录的 events。例如,'status' 字段从 'new' 更改为 'open' 可以映射到诸如“请求已分拣”之类的 activity。
示例
服务请求已创建坐席已重新分配服务请求已解决
|
|||
|
最后数据更新
LastDataUpdate
|
用于指示数据上次从源系统刷新的时间戳。 | ||
|
描述
此属性记录了从 Zendesk Support 进行最新 data 提取的日期和时间。它提供了有关被分析 data 新鲜度的背景,确保用户了解流程视图的时效性。 对于持续监控和仪表板展示,此信息至关重要。它允许分析师和业务用户了解他们查看的是近乎实时的 data 还是前期快照,这会影响其结论的有效性。
为何重要
提供关于数据新鲜度的关键背景信息,让用户了解分析结果的实时程度。
获取方式
这是一个在进行 data 提取时生成并标记在数据集上的元数据字段。
示例
2023-10-27T08:00:00Z
|
|||
|
源系统
SourceSystem
|
指明数据的来源系统。 | ||
|
描述
此属性指定服务请求 data 的来源。对于此流程视图,其值始终为 'Zendesk Support',将其标识为所有服务管理活动的记录系统。 在具有多个集成系统的环境中,此字段对于 data 血缘和故障排除至关重要。它确保分析正确限定在预期系统范围内,并有助于在合并来自各种来源的 data 时进行区分。
为何重要
识别数据的来源系统,确保数据血缘并在合并多个系统的数据时防止混淆。
获取方式
这是一个在 data 提取和转换过程中添加的静态值('Zendesk Support')。
示例
Zendesk Support
|
|||
|
工单标签
TicketTags
|
应用于服务请求的标签列表,用于分类和路由。 | ||
|
描述
Tags(标签)是灵活的标识,可由坐席手动添加或通过业务规则自动添加到工单中。它们用于为工单添加特定的背景或分类,而这些内容可能无法被“类型”或“优先级”等标准字段涵盖。 对于 Process Mining 分析而言,Tags 是极其通用的属性。它们可用于过滤非常具体的场景、追踪自定义 workflow 或识别根源。例如,“VIP”标签可用于分析关键客户的流程,而“product_bug”标签可用于追踪缺陷报告的生命周期。
为何重要
提供了一种灵活的数据切片方式,允许对特定子流程或未在其他字段中抓取的工单属性进行深入分析。
获取方式
Zendesk Tickets API,字段 'tags'。这是一个字符串数组。
示例
销售咨询账单问题功能需求vip_客户
|
|||
|
指派团队
AssignedTeam
|
分配给服务请求的支持团队或组。 | ||
|
描述
此属性指示支持组织内的哪个团队或小组负责该服务请求。在 Zendesk 中,这些被称为“组”。工单通常先分配给一个组,然后再由单个坐席接手。 按分配团队进行分析对于了解团队层级的绩效和工作负载至关重要。它有助于回答哪些团队处理哪些类型的请求、其平均解决时间以及其 SLA 遵守率等问题。这是 Agent & Team Performance dashboard 的一个主要维度。
为何重要
支持分析团队绩效、工作量平衡以及不同支持小组之间的路由效率。
获取方式
Zendesk Groups API,通过联接 Tickets API 响应中的 'group_id'。
示例
一线支持技术支持账单
|
|||
|
服务类型
ServiceType
|
服务请求的类别或类型(例如:事件、问题、故障、任务)。 | ||
|
描述
Service Type 用于对服务请求的性质进行归类。Zendesk 使用 'type' 字段来区分不同类型的支持互动。这种初始分类有助于将工单路由到正确的团队并应用相应的流程。 此属性对于过滤和对比至关重要。它允许分析师检查不同类型请求的流程流向,这些请求通常具有截然不同的解决路径和 SLA。这是 Agent & Team Performance dashboard 的关键维度,用于查看谁最擅长处理特定的请求类型。
为何重要
对请求进行分类,以便对不同流程(如事故与咨询,其路径各不相同)进行独立分析。
获取方式
Zendesk Tickets API,字段 'type'。
示例
询问事件问题任务
|
|||
|
经办人姓名
AgentName
|
event 发生时分配给该服务请求的坐席姓名。 | ||
|
描述
此属性标识负责处理服务请求的支持坐席。在工单的整个生命周期中,分配的坐席可能会多次更改,此字段记录了每个步骤的负责人。 坐席姓名对于绩效分析至关重要。它允许对 data 进行过滤和细分,以评估工作负载分布、每个坐席的解决时间以及重新分配的频率。这有助于构建 Agent & Team Performance dashboard 并了解个人对整体流程效率的贡献。
为何重要
此属性对于分析坐席绩效、工作负载分布以及重新分配对解决时间的影响至关重要。
获取方式
Zendesk Users API,通过联接 Tickets API 响应中的 'assignee_id'。
示例
Jane Doe约翰·史密斯Emily Jones
|
|||
|
请求优先级
RequestPriority
|
分配给服务请求的优先级,例如低、普通、高或紧急。 | ||
|
描述
请求优先级是一种指示服务请求紧急程度的分类。该级别通常决定了工单的目标解决时间和适用的 SLA 政策。优先级最初可由系统或用户设置,坐席也可在工单生命周期内进行更改。 该属性对于细分和根源分析至关重要。它有助于分析高优先级工单是否比低优先级工单解决得更快,并且是“服务请求升级趋势”和“SLA 达成情况”仪表板中的关键因素。
为何重要
允许按紧急程度对请求进行细分,这对于分析 SLA 合规性和确保及时处理关键问题至关重要。
获取方式
Zendesk Tickets API,字段 'priority'。
示例
低普通高紧急
|
|||
|
请求渠道
RequestChannel
|
提交服务请求的渠道(例如:电子邮件、Web 表单、电话)。 | ||
|
描述
此属性标识服务请求的提交来源。Zendesk 记录了工单的创建方式,无论是通过电子邮件、Web 门户、API 集成、聊天还是其他渠道。这提供了有关客户交互方式的背景信息。 请求渠道是一个强大的分析维度。它支持“请求渠道效率”dashboard,允许比较不同渠道的解决时间、满意度评分和返工率。这可以帮助企业优化支持渠道,并将用户引导至最高效的渠道。
为何重要
有助于分析不同客户支持渠道的效率和结果,从而实现针对性改进。
获取方式
Zendesk Tickets API,对象 'via' 及其 'channel' 属性。
示例
网页emailapichat
|
|||
|
请求状态
RequestStatus
|
event 发生时服务请求的状态(例如:新建、开启、挂起)。 | ||
|
描述
请求状态代表工单在特定时间点所处的状态。Zendesk 拥有多个标准状态,如新建、开启、待定、挂起、已解决和已关闭,这些状态标记了请求在整个生命周期中的进度。该字段的变化是创建事件日志中活动的主要触发因素。 分析在不同状态下花费的时间是瓶颈分析的核心部分。它有助于识别工单停滞的位置,例如在“待定”或“挂起”状态下耗时过长。了解状态转换也是发现返工循环的关键。
为何重要
追踪状态是了解请求进度以及识别在等待或活跃状态下花费了多少时间的基础。
获取方式
Zendesk Tickets API,字段 'status'。
示例
新建未结挂起已解决已结案
|
|||
|
SLA 策略名称
SlaPolicyName
|
应用于该请求的 Service Level Agreement (SLA) 策略名称。 | ||
|
描述
此属性标识了规定服务请求目标响应和解决时间的特定 SLA 策略。策略通常由请求的优先级、类型或客户的订阅级别等因素决定。 了解已应用的 SLA 策略对于“SLA 遵守与违规分析”dashboard 至关重要。它提供了评估绩效所需的背景,因为不同的策略会有不同的目标。这有助于公平准确地评估工单是否达到了其特定的服务水平目标。
为何重要
通过识别请求是根据哪一组目标衡量的,为 SLA 分析提供背景,从而实现准确的合规性报告。
获取方式
Zendesk Ticket Metrics API。SLA data 通常与工单的指标相关联。
示例
紧急 - 1 小时响应标准 - 24 小时解决高级客户 SLA
|
|||
|
坐席重新分配次数
AgentReassignmentCount
|
请求从一个坐席重新分配给另一个坐席的总次数。 | ||
|
描述
此属性是一个计数器,每当工单上的 'assignee_id' 字段更改时就会递增。单个工单的高重新分配次数可能表明存在各种流程问题,例如初始路由错误、坐席知识匮乏或请求过于复杂,单个坐席无法处理。 这是衡量流程效率的关键指标,直接支持“坐席重新分配率”KPI。分析具有高重新分配次数的 cases 可以发现改进路由规则、坐席培训或知识库资源的机会,从而确保工单能更快地到达正确的人手中。
为何重要
有助于量化内部交接并识别流程摩擦,因为高频率的重新分配往往会导致延迟和低效。
获取方式
通过计算 Zendesk Ticket Audits API 中每张工单“assignee_id”变化的次数得出。
示例
013
|
|||
|
是否为首次联系解决
IsFirstContactResolution
|
一个标记,用于指示请求是否由第一位指派的客服人员解决,且未经历重新指派或请求者的二次回复。 | ||
|
描述
首次联系解决 (FCR) 是衡量客户问题是否在单次互动中得到解决的关键指标。这个计算属性是一个布尔标记,如果工单由第一位指派的坐席解决,且没有经历任何重新分配且坐席仅回复过一次,则为 true。 该属性直接支持“首次联系解决率”这一 KPI。分析 FCR case 的特征可以为卓越流程提供蓝图。相反,分析未能实现 FCR 的 case 可以揭示提升坐席培训、改进知识库文章或优化初始分拣的机会。
为何重要
衡量单次接触即可高效解决问题的能力,这是提升客户满意度和运营效率的强大动力。
获取方式
这是一个复杂的计算属性。它需要分析工单的 event log,以检查坐席重新分配情况以及坐席的公开回复次数。
示例
truefalse
|
|||
|
是否发生SLA违约
IsSlaBreached
|
一个标记,用于指示该服务请求是否违反了任何 SLA 目标。 | ||
|
描述
此属性是一个布尔值或分类标志,显示工单的 SLA 结果。它可以指示“已达标”、“已违规”或“活跃中”等状态。这是通过将实际响应或解决时间与应用的 SLA 策略中定义的目标进行比较来确定的。 这是“SLA 遵守与违规分析”dashboard 的关键属性。它可以轻松统计并将合规与不合规工单可视化。进一步的分析随后可以侧重于违规工单的流程特征,以识别根源,例如漫长的等待时间或过多的重新分配。
为何重要
直接衡量相对于服务水平承诺的绩效,这是服务质量和客户满意度的关键指标。
获取方式
源自 Zendesk Ticket Metrics API,该 API 提供每张工单的 SLA 状态信息。
示例
已达成已超期在职
|
|||
|
是否返工
IsRework
|
一个标记,如果服务请求在解决后被重新开启,则为 true。 | ||
|
描述
此布尔标志用于识别经历了返工的 cases。如果服务请求的状态从“已解决”变回开启状态,通常被视为返工,这表明初始解决方案不足,客户不得不跟进同一问题。 此属性对于计算“服务请求返工率”KPI 和进行“返工与重新开启 Activity 分析”dashboard 至关重要。通过标记返工 cases,分析师可以隔离这些低效的流程流向,发现重新开启的根源,并努力提高首次解决率。
为何重要
识别解决并非最终结果的流程失败,突出直接影响客户满意度的质量和效率问题。
获取方式
通过分析 Zendesk Ticket Audits API 中工单的状态序列计算得出。从“已解决”到“开启”的状态转换表示存在返工。
示例
truefalse
|
|||
|
服务请求周期时间
ServiceRequestCycleTime
|
从创建服务请求到最终解决的总时长。 | ||
|
描述
此计算指标衡量服务请求的端到端处理时间。通常计算为“服务请求已解决”activity 与“服务请求已创建”activity 之间的时间差。这是任何支持流程中最重要的核心 KPI 之一。 此属性直接支持“平均服务请求周期时间”KPI 和“端到端周期时间”dashboard。通过在请求类型或优先级等不同维度上分析此指标,有助于识别哪些因素对整体效率的影响最大。
为何重要
这是衡量整体流程效率和客户体验的主要 KPI,显示了交付解决方案所需的时间。
获取方式
计算方式为 case 的第一个和最后一个(解决)事件时间戳之差。
示例
259200s (3 天)86400s (1 天)3600s (1 小时)
|
|||
|
满意度评分
SatisfactionRating
|
工单解决后请求者提供的满意度分数。 | ||
|
描述
此属性捕获客户对支持体验的反馈,通常在工单标记为已解决后通过调查收集。常见的评分包括“好”或“差”,有时还带有评论。 满意度评分是一项关键的结果指标。将流程模式与满意度分数关联起来,可以揭示哪些流程行为会导致客户满意或不满。例如,分析可能显示高重新分配率或长解决时间与负面满意度评分强烈相关。
为何重要
在流程执行与客户结果之间建立直接联系,有助于识别哪些流程行为能驱动客户满意度。
获取方式
Zendesk Tickets API,字段 'satisfaction_rating.score' 或 'satisfaction_rating.reason'。
示例
良好差评已提供
|
|||
|
结束时间
EndTime
|
activity 完成的精确日期和时间。 | ||
|
描述
End Time(结束时间)标志着一个 activity 的完成。对于 Zendesk 中的许多 events 来说,持续时间是瞬间的,因此结束时间与开始时间相同。然而,对于基于状态的 Activities(如“请求处理暂停”),结束时间将是工单解除暂停的时间。 此属性对于计算特定 Activities 的持续时间至关重要,而这正是瓶颈分析的关键。通过比较 activity 的开始时间和结束时间,可以直接测量其处理时间,从而帮助精准定位哪些步骤最耗时。
为何重要
支持计算单个活动的持续时间,这对于识别流程瓶颈和衡量步骤级效率至关重要。
获取方式
对于离散 events,这通常与 StartTime 相同。对于状态持续时间,它是下一个改变状态的 event 的 timestamp。
示例
2023-10-26T10:00:00Z2023-10-26T10:15:30Z2023-10-27T14:20:10Z
|
|||
|
请求者姓名
RequestorName
|
提交服务请求的终端用户或客户的姓名。 | ||
|
描述
此属性标识发起服务请求的个人。将请求与特定客户联系起来,可以提供以用户为中心的支持流程视图。 在流程分析中,请求者可用于分析特定客户或客户群的模式。例如,可以调查某些客户是否经历了更长的解决时间或更高的返工率,这可能表明他们使用的产品或服务存在问题。
为何重要
将流程与客户关联,从而能够分析特定客户的问题、重复请求及满意度水平。
获取方式
Zendesk Users API,通过联接 Tickets API 响应中的 'requester_id'。
示例
爱丽丝·约翰逊鲍勃·威廉姆斯Charlie Brown
|
|||
|
请求者组织
RequestorOrganization
|
请求者所属的组织或公司。 | ||
|
描述
此属性将服务请求与特定的客户组织联系起来。这在 B2B 支持场景中尤为相关,因为服务水平协议和支持合同通常是在组织层级定义的。 按组织分析 data 可以提供支持绩效的公司级视图。它可以帮助识别产生大量工单、经历重复性问题或满意度评分较低的组织。这对于大客户管理和识别更广泛的客户健康趋势非常有价值。
为何重要
支持按公司对请求进行分组,从而进行 B2B 服务分析,这对于在组织层面管理客户关系和 SLA 至关重要。
获取方式
Zendesk Organizations API,通过联接 Tickets API 响应中的 'organization_id'。
示例
Acme CorporationGlobal Tech Inc.创新解决方案
|
|||
服务请求管理 Activities
| 活动 | 描述 | ||
|---|---|---|---|
|
SLA目标超时
|
此 activity 标志着服务请求未能达到预定义 SLA 目标(如首次回复时间或解决时间)的时间点。当目标未达成时,Zendesk 会将其记录为显式 event。 | ||
|
为何重要
这是合规监控的一个关键 event,也是 SLA 遵守率 KPI 的重要输入。它精准指出了未能履行服务承诺的情况。
获取方式
从 Zendesk 工单事件或审计日志中的“SLABreach”事件抓取。该事件会指明违反了哪项 SLA 指标。
捕获
通过工单数据中明确的“SLABreach”事件识别。
事件类型
explicit
|
|||
|
已发送公开回复
|
此 activity 标志着坐席发送给请求者的任何沟通。这在 Zendesk 工单 data 中被捕获为显式的“评论”event,其中 'public' 属性为 true。 | ||
|
为何重要
这些 events 对于分析沟通频率、测量坐席响应时间以及识别解决问题所需的互动次数至关重要。
获取方式
这是工单 data 中的一个显式“评论”event。event 详情包含一个 'public: true' 属性,以便与内部备注区分开来。
捕获
从“public”标记设为 true 的工单“Comment”事件中抓取。
事件类型
explicit
|
|||
|
服务请求已关闭
|
代表服务请求的最终永久关闭。工单在处于“已解决”状态一段时间后会自动转入“已关闭”状态,且无法再重新开启。 | ||
|
为何重要
此 activity 标志着服务请求流程的最终结束。它为计算完整的 case 时长提供了最终终点。
获取方式
从工单审计日志中“status”字段的“Change”事件推断,其中新值为“已关闭”。
捕获
从审计日志中状态变为“已关闭”的“Change”事件中推断。
事件类型
inferred
|
|||
|
服务请求已创建
|
标志着服务请求生命周期的开始,即请求者通过任何渠道提交新工单时。这在 Zendesk 工单审计日志中被记录为“Create”事件,为流程提供了明确的开始时间。 | ||
|
为何重要
此 activity 是每个服务请求的主要启动 event,对于计算端到端周期时间和分析请求接收量至关重要。
获取方式
这在 Zendesk 工单审计日志中记录为“创建”event 类型。此 event 的 timestamp 即为服务请求工单的创建时间。
捕获
直接从工单审计日志中的“Create”事件抓取。
事件类型
explicit
|
|||
|
服务请求已解决
|
此 activity 标志着坐席已提供解决方案并将工单状态更改为“已解决”。从坐席的角度来看,该请求已被视为完成,但请求者仍可以重新开启。 | ||
|
为何重要
这是一个重要的里程碑,标志着坐席主动工作的结束。达到这一状态所需的时间是衡量解决效率的主要指标。
获取方式
从工单审计日志中“status”字段 graves 的“Change”事件推断,其中新值为“已解决”。
捕获
从审计日志中状态变为“已解决”的“Change”事件中推断。
事件类型
inferred
|
|||
|
服务请求已重新开启
|
当请求者回复一个处于“已解决”状态的请求时发生,其状态会自动变回“开启”。这表示所提议的解决方案并不充分。 | ||
|
为何重要
此 activity 是返工的主要指标。分析其频率有助于衡量解决质量并识别导致客户不满的原因。
获取方式
从工单审计日志中“status”字段的“Change”事件推断,其中原值为“已解决”,新值为“开启”。
捕获
从状态由“已解决”转为“开启”中推断。
事件类型
inferred
|
|||
|
请求已分派给座席
|
当服务请求首次分配给特定坐席时,会发生此 activity。这是从工单审计日志中的“变更”event 推断出来的,其中 'assignee_id' 字段从空值或组 ID 被填充。 | ||
|
为何重要
这标志着坐席开始主动工作,对于衡量初始响应时间、首次分配延迟以及坐席工作负载分布至关重要。
获取方式
从工单审计日志中“assignee_id”字段第一个设置了特定用户 ID 的“Change”事件中推断。
捕获
从第一个将“assignee_id”字段设置为具体坐席的变更事件中推断。
事件类型
inferred
|
|||
|
SLA 目标已应用
|
代表服务请求工单应用服务水平协议 (SLA) 政策的时刻。当工单属性匹配激活的 SLA 政策条件时,该事件会被明确记录。 | ||
|
为何重要
追踪 SLA 何时被应用对于监控合规性、分析潜在违规以及了解不同请求类型的预期服务时间线至关重要。
获取方式
从 Zendesk 工单事件或审计日志中的“SLAPolicyApplied”事件抓取。该事件会指明匹配了哪项政策。
捕获
通过工单数据中明确的“SLAPolicyApplied”事件识别。
事件类型
explicit
|
|||
|
优先级已变更
|
指示服务请求的优先级(如“低”、“普通”、“高”或“紧急”)已更新。这在工单审计日志中被记录为“priority”字段的“Change”事件。 | ||
|
为何重要
分析优先级变化有助于识别随时间推移紧急程度增加的请求,并评估优先级管理是否有效。
获取方式
在 Zendesk 工单审计日志中被记录为“priority”字段的“Change”事件,显示原值和新值。
捕获
从审计日志中“priority”字段的“Change”事件中推断。
事件类型
inferred
|
|||
|
坐席已重新分配
|
代表服务请求的所有权从一名坐席移交给另一名坐席。这是根据初次分配后“assignee_id”字段发生的任何后续“Change”事件推断出来的。 | ||
|
为何重要
追踪重新分配是计算坐席重新分配率 KPI 的关键,有助于识别流程低效、路由错误或知识缺口。
获取方式
从工单审计日志中“assignee_id”字段的“Change”事件中推断,不包括工单的第一次分配事件。
捕获
从“assignee_id”字段的第二次及后续“Change”事件中推断。
事件类型
inferred
|
|||
|
已添加内部笔记
|
客服人员在服务请求中添加了内部备注或评论,仅其他客服可见。这被记录为“Comment”事件,且“public”属性为 false。 | ||
|
为何重要
追踪内部备注可以深入了解坐席或团队之间的协作,这可能是延迟的来源,也可能是高效解决问题的关键。
获取方式
这是工单 data 中的一个显式“评论”event。event 详情包含一个 'public: false' 属性,表明它是一条内部备注。
捕获
从“public”标记设为 false 的工单“Comment”事件中抓取。
事件类型
explicit
|
|||
|
请求已升级
|
代表服务请求正式升级到更高级的支持层级、不同团队或管理层。这通常是根据工单分配组的变化或用于追踪升级的自定义字段的变化推断出来的。 | ||
|
为何重要
监控升级情况有助于识别复杂请求、一线坐席的培训需求,以及需要更高级别干预的系统性问题。
获取方式
这不属于标准 event。必须从 'group_id' 字段变更为升级组的“变更”event 中推断,或从用于升级追踪的自定义工单字段的变更中推断。
捕获
从“group_id”的变化或自定义“升级”字段推断。
事件类型
inferred
|
|||
|
请求已挂起
|
当服务请求的状态更改为“挂起”时,会发生此 activity,通常表示坐席正在等待请求者或第三方的消息。这是从状态变更 event 中推断出来的。 | ||
|
为何重要
这有助于隔离和测量支持团队直接控制之外的等待时间,从而更准确地反映坐席的处理时间。
获取方式
从工单审计日志中“status”字段的“Change”事件推断,其中新值为“挂起”。
捕获
从审计日志中状态变为“挂起”的“Change”事件中推断。
事件类型
inferred
|
|||