您的客户服务数据模板
您的客户服务数据模板
- 建议收集的属性
- 需要跟踪的关键活动
- 提取指南
客户服务属性
| 名称 | 说明 | ||
|---|---|---|---|
|
事件时间
EventTime
|
表示特定活动或事件发生时间的精确时间戳。 | ||
|
说明
事件时间记录活动执行的日期和时间。该时间戳是按时间顺序排列事件,以及计算流程不同步骤之间时长的基础。 在流程挖掘分析中,该属性用于计算所有基于时间的指标,包括周期时间、等待时间和处理时长。分析人员可以借此发现前置延迟较长的活动,从而识别瓶颈,并衡量相对于服务级别协议(SLA)的绩效。准确、一致的时间戳是可靠分析的必要条件。
为什么重要
该时间戳对于正确排列事件顺序,以及计算周期时间、瓶颈等所有绩效指标至关重要。
获取位置
通常对应ServiceNow审计和历史表(例如“sys_audit”)中的“sys_created_on”字段。
示例
2023-10-26T10:00:00Z2023-10-26T10:15:32Z2023-10-27T14:05:11Z
|
|||
|
服务请求
ServiceRequest
|
每个客户服务请求、工单或票据的唯一标识符。 | ||
|
说明
Service Request是连接单个客户问题从创建到关闭期间所有相关活动和事件的主要案例标识符,也是跟踪客户交互端到端旅程的主线。 在流程挖掘中,该属性对于重建顺序流至关重要。每个唯一的Service Request值代表一个流程实例,可用于逐案例分析周期时间、路径和差异。它确保从首次联系到最终解决和关闭的所有步骤,都正确关联到同一客户请求。
为什么重要
这是连接所有流程步骤的关键Case ID,使您能够分析每次客户服务互动的完整生命周期。
获取位置
通常对应ServiceNow CSM中“sn_customerservice_case”表的“number”字段。
示例
CS0010001CS0010045CS0010112
|
|||
|
活动名称
ActivityName
|
服务请求生命周期中发生的特定事件或任务的名称。 | ||
|
说明
活动名称描述客户服务流程中的一个步骤,例如“Service Request Created”“Request Assigned to Agent”或“Solution Proposed”。这些活动从系统日志或表更新中提取,用于构建每个服务请求的事件时间序列。 该属性对于可视化流程图、识别瓶颈和了解工作流转至关重要。通过分析活动的顺序和频率,分析人员可以发现常见流程路径、偏差,以及返工或低效环节。活动定义的粒度会直接影响流程模型能够提供的洞察深度。
为什么重要
该属性构成流程图的骨架,定义需要分析其顺序和持续时间的具体步骤与任务。
获取位置
这是一个概念属性,源自系统审计表(例如“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合规情况至关重要。
获取位置
根据“task_sla”表中的“made_sla”字段计算,或通过比较实际解决时间与计划解决时间得出。
示例
truefalse
|
|||
|
状态
State
|
服务请求在生命周期中的当前状态。 | ||
|
说明
状态属性描述服务请求在任意时间点的运营状态,例如“新建”“处理中”“等待信息”“已解决”或“已关闭”。该字段的变化通常用于定义流程模型中的活动。 分析状态可以从整体上了解案例所处的流程阶段,并识别案例在特定状态中停留的时长,例如“等待信息”可能是造成延迟的重要原因。它还可用于定义“解决至关闭时间”等关键KPI的起点和终点。
为什么重要
表示请求在任意时间点的状态,有助于识别“暂停”或“等待信息”等非生产性状态所耗费的时间。
获取位置
对应“sn_customerservice_case”表中的“state”字段。
示例
新建处理中等待用户信息已解决已关闭
|
|||
|
类别
Category
|
服务请求的主要分类,例如“计费”或“技术问题”。 | ||
|
说明
Category根据客户咨询或问题的性质,对服务请求进行高层分类。通常在请求首次创建时完成分类,并据此将请求路由到正确的分配组。 该属性对于细分流程分析至关重要。通过按Category筛选,分析人员可以比较不同类型请求的顺序流。例如,“Billing”问题的解决流程可能与“Technical Issue”完全不同。这是几乎所有仪表板进行数据切分时都会使用的关键属性。
为什么重要
支持按请求类型拆分分析,揭示某些类别是否更容易出现延迟、升级或SLA违约。
获取位置
对应“sn_customerservice_case”表中的“category”字段。
示例
咨询/帮助订单产品问题账单
|
|||
|
上次数据更新
LastDataUpdate
|
表示数据上次从源系统提取或刷新的时间戳。 | ||
|
说明
此属性记录最近一次提取数据的日期和时间,帮助了解所分析数据的新鲜度,确保用户明确当前查看的是近实时信息还是历史快照。 分析过程中,这是理解数据集时间范围的关键元数据。它有助于正确解读仪表板和KPI,例如明确数据截至上一小时或前一天。
为什么重要
表示数据的新鲜度,这对流程挖掘洞察的相关性和时效性至关重要。
获取位置
此时间戳在数据提取、转换和加载(ETL)过程中生成并添加。
示例
2023-11-20T08:00:00Z
|
|||
|
客户
Customer
|
发起服务请求的客户或公司名称或标识符。 | ||
|
说明
此属性标识服务请求所服务的外部相关方,可以是个人或组织,为每个案例提供客户背景。 在分析中,客户属性支持以客户为中心查看服务流程。您可以据此识别某些客户是否遇到更多问题或更长延迟,并与客户细分、客户价值等其他数据关联,以确定流程改进的优先级。例如,可以检查高价值客户是否获得更快的服务。
为什么重要
将流程关联到具体客户,支持分析重点客户或客户细分的服务水平和问题频率。
获取位置
可能对应“sn_customerservice_case”表中的“caller_id”“opened_for”或“account”字段,这些字段引用用户表或公司表。
示例
John SmithACME CorporationGlobal Tech Inc.
|
|||
|
是否返工
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
|
|||
客户服务活动
| 活动 | 说明 | ||
|---|---|---|---|
|
关闭服务请求
|
这是最后一项活动,标志着服务请求记录正式关闭,通常发生在解决后的确认期结束之后。当工单状态变更为“Closed”且closed_at时间戳被设置时,系统会捕获此事件。 | ||
|
为什么重要
作为流程的最终结束点,此活动对于计算完整工单生命周期至关重要。分析“Resolved”到“Closed”之间的时间,可以揭示管理开销或延迟。
获取位置
根据审计历史推断,当sn_customerservice_case表中的state字段设置为“Closed”时触发。closed_at字段会同时填充。
采集
检测state变更为“Closed”,并使用对应的时间戳。
事件类型
inferred
|
|||
|
创建服务请求
|
此活动标志着客户服务流程的开始,即新工单正式记录到系统中的时刻。当新记录插入sn_customerservice_case表时,系统会明确捕获此事件。 | ||
|
为什么重要
作为每个工单的起点,此活动对于计算端到端周期时间和分析请求接收量至关重要。它是所有后续流程和SLA计时器的触发点。
获取位置
此事件对应于在sn_customerservice_case表中创建记录。时间戳取自sys_created_on字段。
采集
sn_customerservice_case表中的记录创建时间戳(sys_created_on)。
事件类型
explicit
|
|||
|
将请求分配给客服
|
当服务请求被分配给特定客服进行调查和解决时,此活动随之发生。系统通过推断工单记录中assigned_to字段的变更来捕获该活动。 | ||
|
为什么重要
这是衡量初始响应时间和客服工作量分配的关键里程碑。跟踪该字段的重新分配,有助于发现流程低效和客服资源不足造成的潜在瓶颈。
获取位置
根据sn_customerservice_case表的审计历史(sys_audit)推断,跟踪assigned_to字段何时被填充或变更。
采集
检测工单审计日志中assigned_to字段的值变更。
事件类型
inferred
|
|||
|
解决服务请求
|
这是一个关键里程碑,表示客服已完成处理,问题被视为解决。当工单状态变更为“Resolved”且resolved_at时间戳被填充时,系统会捕获此事件。 | ||
|
为什么重要
此活动标志着主动解决流程的结束,对于计算解决周期时间和SLA达标情况至关重要,也是许多效率KPI的主要终点。
获取位置
根据审计历史推断,当sn_customerservice_case表中的state字段设置为“Resolved”时触发。resolved_at字段通常会同时填充。
采集
检测state变更为“Resolved”,并使用对应的时间戳。
事件类型
inferred
|
|||
|
触发内部升级
|
表示将服务请求正式升级至更高层级的支持团队或管理人员处理。该活动可通过分配组变更为更高层级团队,或设置相应标记来推断。 | ||
|
为什么重要
跟踪升级有助于识别流程薄弱环节、一线支持的知识缺口和复杂工单类型。这是衡量流程阻力和客户不满意度的重要指标。
获取位置
可通过审计日志推断:检测assignment_group是否变更为已知的升级团队,或工单记录中的escalation字段是否发生变更。
采集
检测escalation字段变更,或工单是否转移至更高层级的assignment_group。
事件类型
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
|
|||
|
发送客户调查
|
表示工单解决后向客户发送满意度调查。通常在创建调查实例记录并将其与工单关联时捕获此事件。 | ||
|
为什么重要
此活动有助于将流程执行模式与客户反馈关联起来。了解调查何时发送以及是否发送,对于分析反馈闭环的有效性十分重要。
获取位置
这是记录在调查专用表(例如asmt_assessment_instance)中的明确事件,该表包含对源工单记录的引用。
采集
在与工单关联的“asmt_assessment_instance”表中创建记录。
事件类型
explicit
|
|||
|
向客户请求信息
|
当客服需要客户提供更多信息才能继续处理,并将工单置于待处理状态时,此活动随之发生。通常可通过状态变更为“Awaiting User Info”或“On Hold”等值来推断。 | ||
|
为什么重要
此活动对于“客户信息等待时间”分析至关重要。它可以单独识别由外部依赖造成的流程延迟,将其与内部处理时间区分开来。
获取位置
根据sn_customerservice_case表的审计历史推断,当state字段变更为表示等待客户输入的值时触发,例如“Awaiting Info”。
采集
检测state字段变更为指定的“等待客户”值。
事件类型
inferred
|
|||
|
客服开始调查
|
此活动表示客服已开始主动处理服务请求。通常可通过工单状态从“新建”或“已分配”等状态变更为“处理中”来推断。 | ||
|
为什么重要
此事件有助于区分排队时间和实际处理时间。分析分配到开始调查之间的时长,可以发现客服接手新工单时的延迟。
获取位置
根据工单state字段变更为活动处理状态(例如“Work in Progress”)推断。具体状态值可配置,需进行确认。
采集
检测state字段从待处理值变更为活动值,例如从“New”变更为“Work in Progress”。
事件类型
inferred
|
|||
|
提出解决方案
|
此活动标志着客服已找到解决方案,并将其告知客户以供确认。通常可通过状态变更为“Awaiting Acceptance”等值,或出现特定工作备注来推断。 | ||
|
为什么重要
这一里程碑将调查阶段与确认、解决阶段区分开来。分析等待客户确认所花费的时间,可以发现简化工单关闭阶段的机会。
获取位置
根据sn_customerservice_case表的审计日志推断,当state变更为表示已提出解决方案的值时触发,例如“Proposed Solution”。具体值可能因实施方式而异。
采集
检测state字段变更为“Proposed Solution”或“Awaiting Acceptance”等值。
事件类型
inferred
|
|||
|
收到客户提供的信息
|
此活动标志着客户提供所请求信息的时刻,客服可以恢复处理。通常可通过工单状态从“Awaiting User Info”变更回活动状态来推断。 | ||
|
为什么重要
此事件结束客户等待阶段,可精确衡量客户响应时间,并帮助识别延迟时间最长的工单类型或客户。
获取位置
根据sn_customerservice_case表的审计历史推断,当state字段从“Awaiting Info”状态变更回“Work in Progress”等活动状态时触发。
采集
检测state字段从“等待客户”值变更回活动值。
事件类型
inferred
|
|||
|
请求分类与确定优先级
|
表示初始分诊,即对服务请求进行分类并分配优先级,以确定紧急程度和路由。该活动通过工单记录审计日志中category、subcategory或priority字段的变更推断得出。 | ||
|
为什么重要
分析此活动有助于识别工单分诊延迟,确保请求得到正确路由并按紧急程度处理。它会影响首次分配时间和整体解决效率。
获取位置
根据sn_customerservice_case表的审计历史(sys_audit)推断,具体跟踪category和priority字段的首次填充或更新。
采集
检测category或priority字段的首次赋值或值变更。
事件类型
inferred
|
|||
|
重新打开服务请求
|
当已解决的服务请求因问题复发或解决方案无效而恢复为活动状态时,此活动随之发生。系统通过检测状态从“Resolved”变更回“Work in Progress”来推断。 | ||
|
为什么重要
重新打开的工单直接反映解决质量,也是返工的主要原因。分析这些事件对于提高首次联系解决率和客户满意度至关重要。
获取位置
根据sn_customerservice_case表的审计历史推断,识别state字段从“Resolved”变更为活动状态的序列。
采集
检测state从“Resolved”变更为“Work in Progress”等活动值。
事件类型
inferred
|
|||
提取指南
立即释放客户服务效率潜力
提升客户满意度,实现80%的一次联系解决率。
无需信用卡,几分钟即可开始。