您的客户服务数据模板
您的客户服务数据模板
- 建议收集的属性
- 需要追踪的关键活动
- 提取指南
客户服务属性
| 名称 | 描述 | ||
|---|---|---|---|
|
Event 时间
EventTime
|
指示特定活动或事件发生的精确时间戳。 | ||
|
描述
Event Time 记录了执行活动的日期和时间。此 timestamp 是按时间顺序排列 event 以及计算流程中不同步骤之间时长的基础。 在流程挖掘分析中,此属性用于计算所有基于时间的指标,包括周期时间、等待时间和处理时长。它允许分析师通过发现前面存在长时间延迟的活动来识别瓶颈,并对照服务水平协议 (SLA) 衡量绩效。准确且一致的 timestamp 是进行可靠分析的必要前提。
为何重要
此时间戳对于正确排列事件顺序以及计算所有性能指标(如周期时间和瓶颈)至关重要。
获取方式
这通常对应于 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 - 低
|
|||
|
指派处理人
AssignedAgent
|
当前负责处理该服务请求的个人座席人员。 | ||
|
描述
此属性标识在特定时间点负责服务请求的用户。随着请求在不同座席或专家之间交接,该属性在案例生命周期中经常发生变化。 分析负责座席是了解工作量分布、座席绩效和交接情况的关键。它有助于回答诸如哪些座席处理最复杂的案例、案例转派的频率如何,以及某些座席是否与较长的解决时间或较高的客户满意度相关联。这对于“座席交接与转派”仪表板至关重要。
为何重要
追踪座席职责,支持对工作量、绩效和转派频率进行分析,转派频率通常预示着流程中存在阻力。
获取方式
这对应于 sn_customerservice_case 表上的 assigned_to 字段。
示例
Beth AnglinDavid LooAbel Tuter
|
|||
|
指派组
AssignmentGroup
|
负责该服务请求的团队或部门。 | ||
|
描述
分配组代表服务请求所属的队列或团队。根据问题的性质,请求通常会在不同的组之间路由,例如一级支持服务台、专业技术团队或财务部门。 此属性对于分析部门间的交接和识别团队级别的瓶颈至关重要。它有助于可视化工作在不同职能区域之间的流转情况,并能突出显示工作过载或需要额外培训的小组。这直接为“座席交接与转派”和“流程流转”仪表板提供支持。
为何重要
识别负责工作的团队,这对于分析团队绩效、工作量以及部门间的流程交接至关重要。
获取方式
这对应于 sn_customerservice_case 表上的 assignment_group 字段。
示例
服务台账单查询二线技术支持
|
|||
|
是否发生SLA违约
IsSlaBreached
|
一个布尔标识,指示服务请求是否超出了定义的服务水平协议 (SLA) 目标。 | ||
|
描述
此计算属性指示服务请求是否在约定的时间范围内解决。如果解决时间超过了 SLA 目标,通常为 True,否则为 False。这为每个案例的 SLA 绩效提供了明确的二元结果。 此属性对于“SLA 达成与违规趋势”仪表板和“SLA 达成率”KPI 至关重要。它通过允许直接过滤和统计违规案例来简化分析,从而轻松识别哪些类型的请求、优先级或团队与 SLA 违规关联度最高。
为何重要
针对案例是否按期完成提供明确的“是”或“否”答案,这是衡量和报告 SLA 合规性的基础。
获取方式
根据
示例
truefalse
|
|||
|
状态
State
|
服务请求在其生命周期中的当前状态。 | ||
|
描述
状态属性描述了服务请求在任何时间点的运营状态,如“新建”、“处理中”、“等待信息”、“已解决”或“已关闭”。该字段的变更通常用于定义流程模型中的活动。 分析状态可以提供案例在流程中所处位置的高层级视图。它用于识别案例在特定状态(如“等待信息”)下停留的时长,这可能是导致延迟的主要原因。它还有助于定义关键 KPI(如“从解决到关闭的时间”)的起点和终点。
为何重要
指示请求在任何时间的当前状态,有助于识别在“挂起”或“等待信息”等非生产性状态上花费的时间。
获取方式
这对应于 sn_customerservice_case 表上的 state 字段。
示例
新建进行中等待用户提供信息已解决已结案
|
|||
|
类别
Category
|
服务请求的主要分类,如“账单”或“技术问题”。 | ||
|
描述
类别根据客户咨询或问题的性质为服务请求提供高层级的归类。这种分类通常在请求首次创建时完成,并有助于将其路由到正确的分配组。 此属性对于细分流程分析至关重要。通过对类别进行过滤,分析人员可以比较不同类型请求的流程流向。例如,“账单”问题的解决流程可能与“技术问题”截然不同。这是几乎所有仪表板用于切片数据的关键属性。
为何重要
支持按请求类型细分分析,揭示某些特定类别是否更容易出现延迟、升级或 SLA 违规。
获取方式
这对应于 sn_customerservice_case 表上的 category 字段。
示例
咨询 / 帮助订单产品问题账单
|
|||
|
最后数据更新
LastDataUpdate
|
指示数据上次从源系统提取或刷新的时间戳。 | ||
|
描述
此属性记录最近一次数据提取的日期和时间。它提供了所分析数据的新鲜度背景,确保用户清楚自己查看的是近乎实时的新息还是历史快照。 在分析过程中,这是理解数据集时间窗口的关键元数据。它有助于用户正确解读仪表板和 KPI,例如,了解数据截至最后一小时或前一天是有效的。
为何重要
指示 data 的新鲜度,这对于流程挖掘洞察的相关性和及时性至关重要。
获取方式
此时间戳在数据提取、转换与加载(ETL)过程中生成并添加。
示例
2023-11-20T08:00:00Z
|
|||
|
处理时间
ProcessingTime
|
在一项活动上实际投入工作的时间长度。 | ||
|
描述
处理时间(也称为活跃时间或服务时间)衡量一项活动从开始到结束的持续时长。它代表座席或系统主动执行任务的时间,而非任务之间的等待时间。 在流程挖掘中,该指标对于区分增值时间和非增值等待时间至关重要。分析处理时间有助于识别哪些特定任务最耗时,以及哪里存在自动化或培训空间以提高效率。它是瓶颈分析的基础指标。
为何重要
衡量某项活动的实际工作时间,有助于在流程中区分增值时间与无效的等待时间。
获取方式
这是一个计算属性,通常通过活动的结束时间 (EndTime) 与开始时间 (StartTime) 之差得出。
示例
PT15MPT2H30MP1D
|
|||
|
客户
Customer
|
发起服务请求的客户或公司的名称或标识符。 | ||
|
描述
此属性标识服务请求所针对的外部利益相关者(个人或组织)。它为每个案例提供客户背景信息。 在分析中,客户属性支持以客户为中心的视角审视服务流程。它可以用来识别某些客户是否遇到了更多问题或更长的延迟,并可以与其他客户数据(如细分或价值)结合,以优先开展流程改进工作。例如,可以检查高价值客户是否获得了更快的服务。
为何重要
将流程关联至特定客户,从而能够针对大客户或特定客户群分析服务水平和问题发生频率。
获取方式
这可能是 sn_customerservice_case 表上的 caller_id、opened_for 或 account 字段,它们引用了用户或公司表。
示例
约翰·史密斯ACME 公司Global Tech Inc.
|
|||
|
是否为首问负责解决
IsFirstContactResolution
|
一个布尔标识,指示请求是否由第一位分派的坐席解决,且未经过任何转移或升级。 | ||
|
描述
此计算属性用于识别在首次互动中或由首位处理案例的座席高效解决的服务请求。其逻辑通常检查如下条件:转派次数为零 (ReassignmentCount 为 0)、无“触发内部升级”活动,且未向客户请求更多信息。 此属性直接衡量关键的客户服务指标,并为“首问负责解决率”仪表板和 KPI 提供支持。它能轻松量化 FCR 绩效,并有助于分析促成或阻碍实现首问负责解决的因素(如渠道或请求类别)。
为何重要
直接衡量初步响应的效率。高 FCR 率与运营效率和高客户满意度紧密相关。
获取方式
这是一个计算属性。它是在数据转换过程中根据规则派生出来的,例如“转派计数”为零且未发生升级活动。
示例
truefalse
|
|||
|
是否返工
IsRework
|
一个布尔标识,指示是否发生了明显的 rework,例如重新开启的 case 或重复调查。 | ||
|
描述
这是一个计算属性,用于标记呈现低效或重复模式的案例。该标记的触发逻辑可能由“服务请求已重开”等事件激发,或者当同一案例中多次出现关键活动序列(如“座席开始调查”后紧跟“已提出解决方案”)时触发。 此标记对于快速识别问题案例和量化流程中的整体返工水平非常有价值。它直接支持“返工与重复热点”仪表板和“返工率”KPI,使分析人员能够专注于导致低效的动因,而无需手动识别重复模式。
为何重要
通过标记具有重复循环或重新开启 event 的 case,帮助量化流程低效程度,从而轻松衡量并针对性解决 rework 问题。
获取方式
这是一个计算属性。它是在数据转换过程中通过应用业务逻辑派生出来的,该逻辑可检测返工模式,例如非零的“重开次数”或重复活动。
示例
truefalse
|
|||
|
渠道
Channel
|
发起服务请求时使用的沟通渠道。 | ||
|
描述
渠道表示客户提交请求的方式,例如“电子邮件”、“电话”、“门户网站”或“聊天”。不同的渠道可能具有显著不同的流程特征和客户期望。 按渠道分析流程有助于评估每种沟通方式的有效性。例如,它可以揭示通过“电话”提交的请求是否具有更高的首问负责解决率,或者“电子邮件”请求是否往往具有更长的周期时间。这直接为“沟通渠道有效性”仪表板提供支持。
为何重要
有助于确定不同客户互动渠道(如电话、电子邮件或 Web 门户)的效率和结果。
获取方式
这通常对应于 sn_customerservice_case 表上的 contact_type 字段。
示例
电话电子邮件自助服务聊天
|
|||
|
源系统
SourceSystem
|
数据提取来源系统。 | ||
|
描述
此属性标识数据的来源,这在从多个系统汇总信息的环境中尤为重要。对于此流程视图,该值将始终为“ServiceNow CSM”。 在分析中,这有助于数据治理和故障排除。当涉及多个源系统时,它允许过滤流程以了解其在特定系统中的运行方式,或比较不同系统之间的流程差异。
为何重要
提供关于数据来源的关键背景信息,确保多系统环境下的清晰度并辅助数据治理。
获取方式
这是在数据转换过程中添加的静态值,用于标记数据集的来源。
示例
ServiceNow CSM
|
|||
|
解决代码
ResolutionCode
|
一个指示最终结果或服务请求如何解决的代码。 | ||
|
描述
解决代码是座席在解决案例时选择的结构化值。它提供了关于解决方案的具体细节,如“由用户解决”、“已知错误”、“重复请求”或“无需采取行动”。 此属性对于根本原因分析非常有价值。通过分析不同解决代码的频率,企业可以识别重复性问题、知识欠缺或产品缺陷。这些信息随后可用于推动改进,从而减少某些类型服务请求的数量。
为何重要
提供有关服务请求结果的洞察,这对于根本原因分析和识别重复性问题至关重要。
获取方式
这对应于 sn_customerservice_case 表上的 close_code 或自定义解决代码字段。
示例
已解决(临时方案)已永久解决未解决(客户无响应)由呼叫者关闭/解决
|
|||
|
重开次数
ReopenCount
|
已解决的服务请求被客户重新开启的次数。 | ||
|
描述
此计数器追踪案例从“已解决”或“已关闭”状态变回“处理中”或“开启”状态的次数。重开案例表明初始解决方案无效或不彻底。 此属性是衡量返工和初次解决质量的重要指标。高重开次数意味着解决流程存在问题,例如座席过早关闭工单或未完全解决客户的底层问题。它是理解所提解决方案有效性的关键指标。
为何重要
指示解决失败和 rework。大量重新开启 case 标志着解决过程质量低下,并会导致客户沮丧。
获取方式
这通常在 sn_customerservice_case 表或相关表中的 reopen_count 字段进行追踪。
示例
012
|
|||
|
重新分配次数
ReassignmentCount
|
服务请求被转派给不同座席或小组的总次数。 | ||
|
描述
此属性是一个计数器,每当 assigned_to 或 assignment_group 字段发生变化时就会递增。它为案例经历的内部流转量提供了一个简单的衡量指标。 转派计数是衡量流程阻力的直接指标,也是“座席交接与转派”仪表板和“单个请求平均座席交接次数”KPI 的关键输入。高转派计数通常表明初始路由存在问题、座席技能欠缺或案例难以分类,所有这些都会导致解决时间延长。
为何重要
通过计算交接次数直接衡量流程的低效程度。高频率的交接通常与更长的解决时间和客户不满相关联。
获取方式
这是 task 表上的标准指标字段 reassignment_count,sn_customerservice_case 表继承自该表。
示例
0135
|
|||
客户服务活动
| 活动 | 描述 | ||
|---|---|---|---|
|
服务请求已关闭
|
这是最后一项活动,标志着服务请求记录的正式关闭,通常发生在解决后的确认期之后。当案例状态变为“已关闭”且设置了 closed_at 时间戳时捕获。 | ||
|
为何重要
作为流程的最终终点,此活动对于计算完整的 case 生命周期至关重要。分析“已解决”和“已关闭”之间的时间可以揭示行政开销或延迟。
获取方式
通过审计历史推断,即当
捕获
检测
事件类型
inferred
|
|||
|
服务请求已创建
|
此活动标志着客户服务流程的开始,即新案例正式在系统中记录。当一条新记录插入到 sn_customerservice_case 表时,该事件会被明确捕获。 | ||
|
为何重要
作为每个 case 的起点,此活动对于计算端到端周期时间和分析请求受理量至关重要。它是所有后续流程和 SLA 计时器的触发点。
获取方式
此事件对应于在 sn_customerservice_case 表中创建记录。时间戳取自 sys_created_on 字段。
捕获
sn_customerservice_case 表中的记录创建时间戳 (sys_created_on)。
事件类型
explicit
|
|||
|
服务请求已解决
|
这是一个关键里程碑,表示座席已完成处理且问题被视为已解决。当案例状态变更为“已解决”且填充了 resolved_at 时间戳时,该事件将被捕获。 | ||
|
为何重要
此活动标志着主动解决流程的结束,对于计算解决周期时间和 SLA 达成率至关重要。它是许多效率 KPI 的主要终点。
获取方式
通过审计历史推断,即当
捕获
检测
事件类型
inferred
|
|||
|
触发内部升级流程
|
代表将服务请求正式升级到更高级别的支持或管理层进行处理。这可以从分配组变更为更高级别团队或特定标记位的设置来推断。 | ||
|
为何重要
追踪升级情况有助于识别流程薄弱环节、一线支持的知识缺口以及复杂的案例类型。这是流程阻力和客户不满的关键指标。
获取方式
可以通过在审计日志中检测到
捕获
检测
事件类型
inferred
|
|||
|
请求已分派给座席
|
当服务请求被分派给特定座席进行调查和解决时发生此活动。它通过推断案例记录中 assigned_to 字段的变更来捕获。 | ||
|
为何重要
这是衡量初始响应时间和座席工作量分布的关键里程碑。追踪此字段的转派情况可以突出流程低效环节以及座席可用性方面的潜在瓶颈。
获取方式
通过追踪
捕获
在 case 的审计日志中检测
事件类型
inferred
|
|||
|
SLA 违约
|
代表服务请求未能满足预设服务水平协议(如解决时间)的时刻。这是一个计算得出的事件,通过对比实际解决时间与 SLA 计划结束时间得出。 | ||
|
为何重要
识别 SLA 违规是合规监控和绩效管理的基础。此 event 有助于找准哪些流程阶段或 case 类型是导致 SLA 违规的主要原因。
获取方式
通过分析 task_sla 表中与 case 相关的记录计算得出。如果
捕获
检查关联
事件类型
calculated
|
|||
|
向客户请求资料
|
当座席需要客户提供更多信息才能继续处理,并将案例置于挂起状态时触发。这通常通过状态变更为“等待用户信息”或“挂起”来推断。 | ||
|
为何重要
此活动对于“客户信息等待时间”分析至关重要。它能分离出由外部依赖项引起的流程延迟,将其与内部处理时间区分开来。
获取方式
通过
捕获
检测
事件类型
inferred
|
|||
|
坐席开始调查
|
此活动表示座席已开始主动处理服务请求。通常在案例状态从“新建”或“已分派”变为“处理中”时推断得出。 | ||
|
为何重要
此事件有助于区分排队时间与实际处理时间。分析从分派到开始调查之间的时间间隔,可以揭示座席在承接新案例时的延迟情况。
获取方式
根据案例的状态字段变更为活跃工作状态(如“处理中”)来推断。具体的各种状态值可进行配置并应加以核实。
捕获
检测
事件类型
inferred
|
|||
|
客户调查已发送
|
代表在案例解决后发送客户满意度调查。该事件通常在创建调查实例记录并与案例关联时捕获。 | ||
|
为何重要
此活动有助于将流程执行模式与客户反馈相关联。了解调查问卷发送的时间和情况对于分析反馈闭环的有效性非常重要。
获取方式
这是一个明确记录在特定调查表(如 asmt_assessment_instance)中的事件,其中包含对源案例记录的引用。
捕获
在关联至该案例的 'asmt_assessment_instance' 表中创建记录。
事件类型
explicit
|
|||
|
已提出解决方案
|
此活动标志着座席已确定解决方案并将其传达给客户以待确认。通常根据状态变更为“等待接受”或特定的工作备注条目来推断。 | ||
|
为何重要
此里程碑将调查阶段与确认及解决阶段区分开来。分析等待客户确认所花费的时间,可以发现简化案例关闭阶段的改进机会。
获取方式
当
捕获
检测
事件类型
inferred
|
|||
|
指派组已变更
|
指示 case 的责任已从一个团队转移到另一个团队。此 event 是通过监控 case 记录中 `assignment_group` 字段的更改推断出来的。 | ||
|
为何重要
追踪分配组的变更对于分析部门间的交接和识别系统性路由问题至关重要。此活动的高频发生可能表明职责归属或流程定义不清晰。
获取方式
通过追踪
捕获
在 case 的审计日志中检测
事件类型
inferred
|
|||
|
收到客户提供的资料
|
此活动标志着客户提供所请求信息的时刻,使座席能够恢复工作。当案例状态从“等待用户信息”变回活跃状态时,即可推断出该活动。 | ||
|
为何重要
此事件结束了客户等待期,从而能够精确衡量客户响应时间。它有助于识别哪些案例类型或客户与最长的延迟相关联。
获取方式
通过
捕获
检测
事件类型
inferred
|
|||
|
服务请求已重新开启
|
当已解决的服务请求因问题再次发生或解决方案无效而返回活跃状态时触发。这可以通过检测到状态从“已解决”变回“处理中”来推断。 | ||
|
为何重要
重开案例是直接衡量解决质量的指标,也是返工的主要诱因。分析这些事件对于提高首问负责解决率和客户满意度至关重要。
获取方式
通过识别
捕获
检测
事件类型
inferred
|
|||
|
请求已完成分类和定级
|
代表初始的分拣阶段,在此阶段对服务请求进行分类并分配优先级,以确定其紧迫性和路由。这可以从案例记录审计日志中类别、子类别或优先级字段的变更来推断。 | ||
|
为何重要
分析此活动有助于识别 case 分拣过程中的延迟,确保请求得到正确路由并按紧急程度处理。它会影响首次分配的时间和整体解决效率。
获取方式
通过追踪
捕获
检测
事件类型
inferred
|
|||