客户服务数据模板
客户服务数据模板
- 建议收集的属性
- 需要跟踪的关键活动
- 数据提取指南
客户服务属性
| 名称 | 说明 | ||
|---|---|---|---|
|
事件时间
EventTime
|
表示特定活动或事件发生时间的精确时间戳。 | ||
|
说明
事件时间记录活动执行的日期和时间。此时间戳是按时间顺序排列事件、计算流程不同步骤间时长的基础。 在流程挖掘分析中,此属性用于计算所有基于时间的指标,包括周期时间、等待时间和处理时长。分析人员可以通过查找前置延迟较长的活动来识别瓶颈,也可以据此衡量服务级别协议(SLA)的达成情况。准确且一致的时间戳是可靠分析的必要条件。
重要性
此时间戳对于正确排列事件顺序和计算周期时间、瓶颈等所有绩效指标至关重要。
获取途径
通常对应ServiceNow审计和历史表(例如“sys_audit”)中的“sys_created_on”字段。
示例
2023-10-26T10:00:00Z2023-10-26T10:15:32Z2023-10-27T14:05:11Z
|
|||
|
服务请求
ServiceRequest
|
每个客户服务请求、案例或工单的唯一标识符。 | ||
|
说明
服务请求是主要案例标识符,用于关联同一客户问题从创建到关闭的所有相关活动和事件。它是跟踪客户交互端到端历程的主线。 在流程挖掘中,此属性是还原流程顺序的基础。每个唯一的服务请求值代表一个流程实例,可据此逐案分析周期时间、路径和差异。它确保从首次联系到最终解决和关闭的所有步骤都正确关联到同一客户咨询。
重要性
这是关键的案例ID,用于关联所有流程步骤,从而分析每次客户服务交互的完整生命周期。
获取途径
通常对应ServiceNow CSM中“sn_customerservice_case”表的“number”字段。
示例
CS0010001CS0010045CS0010112
|
|||
|
活动名称
ActivityName
|
客户服务请求生命周期中发生的特定事件或任务的名称。 | ||
|
说明
活动名称用于描述客户服务流程中的步骤,例如“已创建服务请求”“已将请求分配给客服专员”或“已提出解决方案”。这些活动从系统日志或表更新记录中提取,用于按时间顺序构建每个服务请求的事件序列。 此属性对于流程图可视化、识别瓶颈和了解工作流转情况至关重要。通过分析活动的顺序和频率,分析人员可以发现常见流程路径、偏差,以及返工或效率低下的环节。活动定义的粒度会直接影响从流程模型中获得的洞察深度。
重要性
此属性构成流程图的基础,定义了要分析其顺序和持续时间的具体步骤与任务。
获取途径
这是一个概念性属性,可从系统审计表(例如“sys_audit”)中提取,也可通过跟踪“sn_customerservice_case”表中的状态变化和关键字段更新得出。
示例
创建服务请求请求分配给客服人员向客户请求信息服务请求已解决
|
|||
|
优先级
Priority
|
服务请求的优先级,决定其紧急程度。 | ||
|
说明
优先级表示服务请求的重要程度和处理紧迫性,通常根据请求对客户的影响及其紧急程度综合确定。常见取值从严重到低。 在流程挖掘中,优先级是重要的筛选和比较维度。分析人员可以据此检查高优先级请求是否确实比低优先级请求处理得更快,以及某些优先级的请求是否更容易出现SLA违约。这是“服务请求端到端周期时间”仪表板的基础属性。
重要性
按紧急程度划分服务请求,有助于确认严重问题是否比一般问题处理得更快。
获取途径
对应“sn_customerservice_case”表中的“priority”字段。
示例
1 - 严重2 - 高3 - 中4 - 低
|
|||
|
分配组
AssignmentGroup
|
负责处理服务请求的团队或部门。 | ||
|
说明
Assignment Group表示服务请求被分配到的队列或团队。根据问题类型,请求通常会在不同团队之间流转,例如一级支持服务台、专业技术团队或账单部门。 此属性对于分析跨部门交接和识别团队层面的瓶颈至关重要。它有助于直观呈现工作在不同职能部门之间的流转情况,并发现工作负荷过重或需要额外培训的团队。这项分析可直接支持“客服人员交接与重新分配”和“流程”仪表板。
重要性
标识负责工作的团队,这对于分析团队绩效、工作负荷和部门间的流程交接至关重要。
获取途径
对应“sn_customerservice_case”表中的“assignment_group”字段。
示例
服务台账单咨询二级技术支持
|
|||
|
已分配客服专员
AssignedAgent
|
当前负责处理服务请求的客服专员。 | ||
|
说明
此属性标识特定时间点负责服务请求的用户。在案例生命周期中,请求在不同客服专员或专家之间移交时,该值通常会发生变化。 分析已分配客服专员有助于了解工作负荷分布、客服专员绩效和交接情况。您可以据此了解哪些客服专员处理的复杂案例最多、案例重新分配的频率,以及特定客服专员是否对应较长的解决时间或较高的客户满意度。这是“客服专员交接与重新分配”仪表板的重要依据。
重要性
跟踪客服专员的责任归属,便于分析工作负荷、绩效和重新分配频率。频繁重新分配往往意味着流程受阻。
获取途径
对应“sn_customerservice_case”表中的“assigned_to”字段。
示例
Beth AnglinDavid LooAbel Tuter
|
|||
|
是否违反SLA
IsSlaBreached
|
用于指示服务请求是否超出规定服务级别协议(SLA)目标的布尔标记。 | ||
|
说明
此计算属性用于指示服务请求是否在约定时限内解决。通常,解决时间超过SLA目标时值为“True”,否则为“False”。该属性以明确的二元结果呈现每个案例的SLA绩效。 此属性是“SLA遵循情况与违规趋势”仪表板和“SLA遵循率”KPI的重要组成部分。通过直接筛选和统计违反SLA的案例,它简化了分析,帮助您识别哪些请求类型、优先级或团队最容易出现SLA违规。
重要性
明确回答案例是否按时完成,这是衡量和报告SLA合规情况的基础。
获取途径
根据“task_sla”表中的“made_sla”字段计算,或通过比较实际解决时间与计划解决时间得出。
示例
truefalse
|
|||
|
状态
State
|
服务请求在生命周期中的当前状态。 | ||
|
说明
状态属性描述服务请求在任一时间点的运行状态,例如“新建”“处理中”“等待提供信息”“已解决”或“已关闭”。此字段的变化通常用于定义流程模型中的活动。 分析状态可以概览案例在流程中的位置。您可以据此识别案例在特定状态(如“等待提供信息”)停留的时长,这可能是造成延迟的重要原因。状态也有助于确定“解决至关闭时间”等关键KPI的起止点。
重要性
显示请求在任一时间点的状态,有助于识别“暂挂”或“等待提供信息”等非生产性状态所占用的时间。
获取途径
对应“sn_customerservice_case”表中的“state”字段。
示例
新建处理中等待用户提供信息已解决已关闭
|
|||
|
类别
Category
|
服务请求的主要分类,例如“账单”或“技术问题”。 | ||
|
说明
类别根据客户咨询或问题的性质对服务请求进行概括分类。通常在请求创建时完成分类,以便将请求分配给正确的分配组。 此属性对于细分流程分析至关重要。按类别筛选后,分析人员可以比较不同类型请求的流程。例如,“账单”问题的解决流程可能与“技术问题”截然不同。几乎所有仪表板都可以按此关键属性细分数据。
重要性
按请求类型细分分析,有助于发现某些类别是否更容易出现延迟、升级或SLA违约。
获取途径
对应“sn_customerservice_case”表中的“category”字段。
示例
咨询/帮助订单产品问题账单
|
|||
|
客户
Customer
|
发起服务请求的客户或公司的名称或标识符。 | ||
|
说明
此属性标识服务请求所面向的外部相关方,可以是个人或组织,并提供每个案例的客户背景信息。 在分析中,客户属性可用于从客户视角审视服务流程。您可以据此识别哪些客户遇到的问题更多或延迟更长,也可以将其与客户细分、客户价值等其他数据关联,以确定流程改进的优先顺序。例如,可以检查高价值客户是否获得更快的服务。
重要性
将流程关联到具体客户,便于分析重点客户或客户细分群体的服务水平和问题频率。
获取途径
可能对应“sn_customerservice_case”表中的“caller_id”“opened_for”或“account”字段,这些字段引用用户表或公司表。
示例
John SmithACME CorporationGlobal Tech Inc.
|
|||
|
数据上次更新时间
LastDataUpdate
|
表示上次从源系统提取或刷新数据时间的时间戳。 | ||
|
说明
此属性记录最近一次提取数据的日期和时间,帮助了解正在分析的数据是否为近实时信息或历史快照。 在分析过程中,这是了解数据集时间范围的重要元数据。例如,您可以据此判断仪表板和KPI所用数据截至最近一小时或前一天,从而正确解读结果。
重要性
显示数据的新鲜度,这对于确保流程挖掘洞察的相关性和时效性至关重要。
获取途径
此时间戳在数据提取、转换和加载(ETL)过程中生成并添加。
示例
2023-11-20T08:00:00Z
|
|||
|
是否返工
IsRework
|
用于指示是否发生明显返工的布尔标记,例如案例重新打开或重复调查。 | ||
|
说明
此计算属性用于标记存在低效或重复模式的案例。触发标记的逻辑可能包括“服务请求重新打开”等事件,或同一案例中“客服开始调查”后接“提出解决方案”等关键活动序列多次出现。 此标记有助于快速识别问题案例并量化流程中的整体返工情况。它直接支持“返工与重复操作热点”仪表板和“返工率”KPI,让分析人员无需手动查找重复模式,即可聚焦低效问题的成因。
重要性
通过标记存在重复循环或重新打开事件的案例,帮助量化流程低效情况,便于衡量和改善返工。
获取途径
这是一个计算属性。在数据转换过程中,根据业务逻辑识别返工模式并得出结果,例如“ReopenCount”不为零或活动重复出现。
示例
truefalse
|
|||
|
是否首次联系解决
IsFirstContactResolution
|
用于指示请求是否由首次分配的客服解决,且未发生转派或升级的布尔标记。 | ||
|
说明
此计算属性用于识别在首次交互期间或由首位处理案例的客服高效解决的服务请求。逻辑通常会检查是否没有重新分配(“ReassignmentCount”为0)、是否没有“触发内部升级”活动,以及是否没有向客户索取更多信息。 此属性直接衡量一项关键客户服务指标,并支持“首次联系解决率”仪表板和KPI。它便于量化首次联系解决(FCR)绩效,也有助于分析渠道、请求类别等因素如何促进或阻碍首次联系解决。
重要性
直接衡量首次响应的效率。较高的FCR率与运营效率和客户满意度密切相关。
获取途径
这是一个计算属性。在数据转换过程中,根据规则得出结果,例如“ReassignmentCount”为零且没有发生升级活动。
示例
truefalse
|
|||
|
渠道
Channel
|
客户提交服务请求所使用的沟通渠道。 | ||
|
说明
渠道表示客户提交请求的方式,例如“电子邮件”“电话”“门户网站”或“在线聊天”。不同渠道的流程特征和客户预期可能有明显差异。 按渠道分析流程,有助于评估各沟通方式的效果。例如,您可以了解电话提交的请求是否首次联系解决率更高,或电子邮件请求的周期时间是否更长。这直接支持“沟通渠道效果”仪表板。
重要性
有助于评估电话、电子邮件或门户网站等不同客户交互渠道的效率和处理结果。
获取途径
通常对应“sn_customerservice_case”表中的“contact_type”字段。
示例
电话电子邮件自助服务在线聊天
|
|||
|
源系统
SourceSystem
|
提取数据的系统。 | ||
|
说明
此属性标识数据来源,在信息汇集自多个系统的环境中尤为重要。对于此流程视图,该值通常为“ServiceNow CSM”。 在分析中,此属性有助于数据治理和问题排查。如果涉及多个源系统,您可以据此筛选流程,了解流程在特定系统中的运行情况,或比较不同系统中的流程差异。
重要性
提供数据来源的必要背景信息,确保多系统环境中的信息清晰可辨,并有助于数据治理。
获取途径
这是在数据转换过程中添加的静态值,用于标记数据集的来源。
示例
ServiceNow CSM
|
|||
|
解决代码
ResolutionCode
|
表示服务请求最终结果或解决方式的代码。 | ||
|
说明
解决代码是客服专员解决案例时选择的结构化值,用于说明具体解决方式,例如“用户自行解决”“已知错误”“重复请求”或“无需采取行动”。 此属性有助于分析根本原因。通过分析不同解决代码的出现频率,组织可以发现反复出现的问题、知识缺口或产品问题,并据此推动改进,减少某些类型服务请求的数量。
重要性
反映服务请求的处理结果,对于分析根本原因和发现反复出现的问题至关重要。
获取途径
对应“sn_customerservice_case”表中的“close_code”字段或自定义解决代码字段。
示例
已解决(采用临时方案)已解决(永久解决)未解决(客户未响应)由来电者关闭/解决
|
|||
|
重新分配次数
ReassignmentCount
|
服务请求被重新分配给其他客服专员或组的总次数。 | ||
|
说明
每当“assigned_to”或“assignment_group”字段发生变化,此属性的计数就会增加。它简单反映了案例经历的内部转交次数。 重新分配次数直接反映流程受阻情况,是“客服专员交接与重新分配”仪表板和“每个请求的平均客服专员交接次数”KPI的重要输入。重新分配次数较多,通常意味着初始路由不准确、客服专员技能存在缺口,或案例难以分类,这些因素都会延长解决时间。
重要性
通过统计交接次数,直接衡量流程效率低下的程度。次数较多往往与解决时间延长和客户不满相关。
获取途径
这是task表中的标准指标字段“reassignment_count”,sn_customerservice_case表继承自该表。
示例
0135
|
|||
|
重新打开次数
ReopenCount
|
客户重新打开已解决服务请求的次数。 | ||
|
说明
此计数器跟踪案例从“已解决”或“已关闭”状态重新变为“处理中”或“已开启”状态的次数。案例被重新打开,说明最初的解决方案无效或不完整。 此属性是返工和首次解决质量的重要指标。重新打开次数较多,说明解决流程可能存在问题,例如客服专员过早关闭工单,或未能彻底解决客户的根本问题。它是了解所提解决方案有效性的关键指标。
重要性
反映解决失败和返工情况。重新打开次数较多,意味着解决流程质量不佳,也会令客户感到不满。
获取途径
通常会在“sn_customerservice_case”表或相关表中名为“reopen_count”的字段中跟踪此信息。
示例
012
|
|||
客户服务活动
| 活动 | 说明 | ||
|---|---|---|---|
|
创建服务请求
|
此活动标志着客户服务流程的开始,即系统正式记录新案例。向sn_customerservice_case表插入新记录时,系统会明确记录此事件。 | ||
|
重要性
作为每个案例的起点,此活动是计算端到端周期时间和分析请求受理量的基础。它会触发所有后续流程和SLA计时器。
获取途径
此事件对应于在sn_customerservice_case表中创建记录。时间戳取自sys_created_on字段。
采集
sn_customerservice_case表中的记录创建时间戳(sys_created_on)。
事件类型
explicit
|
|||
|
服务请求已关闭
|
这是最后一个活动,标记服务请求记录正式关闭,通常发生在解决后的确认期结束后。案例状态变为“已关闭”且closed_at时间戳已设置时,即可记录此事件。 | ||
|
重要性
作为流程的最终结束点,此活动对于计算案例的完整生命周期至关重要。分析“已解决”到“已关闭”之间的时间,可以发现行政工作造成的额外耗时或延迟。
获取途径
当sn_customerservice_case表审计历史中的state字段设为“已关闭”时,可据此推断。closed_at字段会同时填充。
采集
检测“state”变为“已关闭”,并使用对应的时间戳。
事件类型
inferred
|
|||
|
服务请求已解决
|
这是一个重要里程碑,表示客服专员已完成处理,问题被视为已解决。案例状态变为“已解决”且resolved_at时间戳已填充时,即可记录此事件。 | ||
|
重要性
此活动标志主动解决流程结束,对于计算解决周期时间和SLA达成情况至关重要。它也是许多效率KPI的主要终点。
获取途径
当sn_customerservice_case表审计历史中的state字段设为“已解决”时,可据此推断。resolved_at字段通常也会同时填充。
采集
检测“state”变为“已解决”,并使用对应的时间戳。
事件类型
inferred
|
|||
|
触发内部升级
|
表示将服务请求正式升级至更高级别的支持团队或管理人员处理。可根据分配组变更为更高级别的团队,或某个标记被设置来推断。 | ||
|
重要性
跟踪升级情况有助于发现流程薄弱环节、一线支持的知识缺口以及复杂的案例类型。这是衡量流程阻滞和客户不满的重要指标。
获取途径
可通过审计日志推断:检测“assignment_group”是否变更为已知的升级团队,或案例记录中的“escalation”字段是否发生变化。
采集
检测“escalation”字段是否变化,或是否转至更高级别的“assignment_group”。
事件类型
inferred
|
|||
|
请求分配给客服人员
|
服务请求分配给特定客服人员进行调查和解决时,会发生此活动。系统根据案例记录中assigned_to字段的变更推断并记录此活动。 | ||
|
重要性
这是衡量初次响应时间和客服人员工作量分布的重要节点。追踪此字段的转派情况,有助于发现流程低效和客服人员可用性方面的潜在瓶颈。
获取途径
根据sn_customerservice_case表的审计历史记录(sys_audit)推断,追踪assigned_to字段何时被填入或更改。
采集
检测案例审计日志中“assigned_to”字段的值变更。
事件类型
inferred
|
|||
|
SLA违约
|
表示服务请求未能满足规定的服务级别协议(例如解决时限)的时间点。这是一个计算得出的事件,通过比较解决时间和SLA计划结束时间确定。 | ||
|
重要性
识别SLA违约是合规监控和绩效管理的基础。此事件有助于找出对SLA违约影响最大的流程阶段或案例类型。
获取途径
通过分析与案例相关的task_sla表记录计算得出。如果has_breached字段为true,或actual_elapsed_time超过planned_duration,则视为违约。
采集
检查关联task_sla记录中的“has_breached”标记。
事件类型
calculated
|
|||
|
分配组变更
|
表示案例责任从一个团队转交给另一个团队。通过监控案例记录中assignment_group字段的变更推断此事件。 | ||
|
重要性
追踪分配组变更对于分析部门间交接和识别系统性路由问题至关重要。此活动频繁发生,可能表明责任归属或流程定义不清晰。
获取途径
根据sn_customerservice_case表的审计历史记录(sys_audit)推断,追踪assignment_group字段的变更。
采集
检测案例审计日志中“assignment_group”字段的值变更。
事件类型
inferred
|
|||
|
向客户请求信息
|
客服专员需要客户补充信息才能继续处理,并将案例设为待处理状态时,就会发生此活动。可根据状态变为“等待用户提供信息”或“暂挂”等值来推断。 | ||
|
重要性
此活动对于“等待客户信息时长”分析至关重要。它可以单独识别由外部依赖造成的流程延迟,并将其与内部处理时间区分开来。
获取途径
当sn_customerservice_case表的审计历史中,state字段变为表示等待客户提供信息的值(例如“等待提供信息”)时,可据此推断。
采集
检测“state”字段是否变为指定的“等待客户”状态值。
事件类型
inferred
|
|||
|
客服专员开始调查
|
此活动表示客服专员已开始处理服务请求。通常可根据案例状态从“新建”或“已分配”等变为“处理中”来推断。 | ||
|
重要性
此事件有助于区分排队时间和实际处理时间。分析分配请求到开始调查之间的时长,可以发现客服专员接手新案例是否存在延迟。
获取途径
可根据案例的状态字段变为“处理中”等活动状态来推断。具体状态值可配置,应予以核实。
采集
检测“state”字段从待处理状态变为活动状态,例如从“新建”变为“处理中”。
事件类型
inferred
|
|||
|
已发送客户调查
|
表示案例解决后向客户发送满意度调查。通常在创建调查实例记录并将其关联到案例时记录此事件。 | ||
|
重要性
此活动有助于将流程执行模式与客户反馈联系起来。了解调查是否发送及发送时间,对于分析反馈闭环的有效性十分重要。
获取途径
这是记录在asmt_assessment_instance等调查专用表中的明确事件,其中包含对源案例记录的引用。
采集
在与案例关联的“asmt_assessment_instance”表中创建记录。
事件类型
explicit
|
|||
|
提出解决方案
|
此活动标记客服专员找到解决方案并告知客户、等待客户确认的时间点。通常可根据状态变为“等待接受”等值,或出现特定工作备注来推断。 | ||
|
重要性
此里程碑将调查阶段与确认和解决阶段区分开来。分析等待客户确认所花费的时间,可以发现简化案例收尾环节的机会。
获取途径
当sn_customerservice_case表的审计日志中,state变为表示已提出解决方案的值(例如“已提出解决方案”)时,可据此推断。具体情况可能因实施方式而异。
采集
检测“state”字段是否变为“已提出解决方案”或“等待接受”等值。
事件类型
inferred
|
|||
|
收到客户提供的信息
|
此活动标记客户提供所需信息、客服专员可以恢复处理的时间点。案例状态从“等待用户提供信息”变回活动状态时,可据此推断。 | ||
|
重要性
此事件标志客户等待期结束,有助于准确衡量客户响应时间,并识别哪些案例类型或客户对应的延迟最长。
获取途径
当sn_customerservice_case表的审计历史中,state字段从“等待提供信息”变回“处理中”等活动状态时,可据此推断。
采集
检测“state”字段从“等待客户”状态值变回活动状态值。
事件类型
inferred
|
|||
|
请求分类并确定优先级
|
表示初步分诊过程,即对服务请求进行分类并设置优先级,以确定紧急程度和路由方式。此活动根据案例记录审计日志中类别、子类别或优先级字段的变更推断得出。 | ||
|
重要性
分析此活动有助于发现案例分诊延误,确保请求得到正确路由并按紧急程度处理。它会影响首次分配所需时间和整体解决效率。
获取途径
根据sn_customerservice_case表的审计历史记录(sys_audit)推断,具体追踪类别和优先级字段的初始填入或更新。
采集
检测“category”或“priority”字段首次设置值或值发生变化的情况。
事件类型
inferred
|
|||
|
重新打开服务请求
|
已解决的服务请求因问题再次出现或解决方案无效而恢复为活动状态时,就会发生此情况。可通过检测状态从“已解决”变回“处理中”来推断。 | ||
|
重要性
重新打开的案例直接反映解决质量,也是返工的主要原因。分析此类事件对于提高首次联系解决率和客户满意度至关重要。
获取途径
可通过sn_customerservice_case表的审计历史推断:识别state字段从“已解决”变为活动状态的记录序列。
采集
检测“state”是否从“已解决”变为“处理中”等活动状态值。
事件类型
inferred
|
|||
数据提取指南
立即提升客户服务效率
提升客户满意度,实现80%的首次联系解决率。
无需信用卡,几分钟即可开始。