客户服务数据模板
客户服务数据模板
这是适用于客户服务的通用流程挖掘数据模板。使用针对具体系统的模板,可获取更有针对性的指导。
选择具体系统- 用于一致分析的标准化数据字段
- 用于准确绘制流程图的关键活动
- 适用于各类系统的基础结构
客户服务属性
| 名称 | 说明 | ||
|---|---|---|---|
| 事件时间 EventTime | 记录特定活动或事件发生的准确日期和时间的时间戳。 | ||
| 说明 事件时间也称开始时间,用于记录活动发生的时刻。日志中的每个事件,从服务请求创建到最终关闭,都会标记相应的时间戳。这些时间数据对于按时间顺序排列事件至关重要。 服务请求对应的一系列时间戳,可帮助流程挖掘工具还原实际发生的流程路径。事件时间是所有时间分析的基础,可用于计算活动间隔、衡量案例总解决时间、识别瓶颈,以及检查是否符合服务级别协议(SLA)。 重要性 此时间戳用于排列事件顺序,并支持各类时长分析,例如计算解决时间和识别瓶颈。 获取途径 可在事件日志或审计跟踪表中找到,通常与活动名称一同记录。字段名称可能是“创建日期”“事件日期”或“时间戳”。 示例 2023-10-26T10:00:00Z2023-10-26T10:15:30Z2023-10-27T14:05:00Z | |||
| 服务请求ID ServiceRequestId | 用于唯一标识单个客户咨询或问题的编号。此ID将所有相关活动关联到同一个案例。 | ||
| 说明 服务请求ID是主键,用于唯一标识每个客户案例,从创建到最终解决全程不变。它作为案例标识符,将与特定客户问题相关的所有事件、沟通和操作汇集到一条完整时间线上。 在流程挖掘中,此属性是还原每个服务请求端到端历程的基础。分析人员将每项活动与特定服务请求ID关联后,即可查看流程路径、发现偏差并准确衡量案例耗时。以案例为中心的流程视图对于了解绩效和发现改进机会至关重要。 重要性 这是必不可少的案例标识符。没有它,您就无法追踪单个客户问题在流程中的处理历程。 获取途径 通常位于客户服务管理系统中案例、工单或事件记录的标题区域或主表中。 示例 SR-2023-00123CASE009876TKT-554321INC0123456 | |||
| 活动 Activity | 在某个服务请求的客户服务流程中发生的特定业务事件、任务或步骤的名称。 | ||
| 说明 活动表示服务请求生命周期中的一个独立步骤或事件。例如“服务请求已创建”“请求已分配”“已提出解决方案”和“请求已关闭”。每项活动都关联到特定服务请求,并带有记录发生时间的时间戳。 此属性对于构建流程图至关重要,它以可视化方式呈现客户服务工作流。分析活动的顺序和频率,有助于发现服务请求的实际处理路径,包括常见工作流、瓶颈、偏差和返工循环。它是流程挖掘分析的基础。 重要性 此属性定义流程图中的步骤,是了解实际工作内容及其顺序的关键。 获取途径 通常从客户服务系统的事件日志、状态变更表或审计跟踪记录中提取。 示例 请求已创建分派请求发送首次回复解决请求 | |||
| 数据最近更新时间 LastDataUpdate | 记录上次从源系统刷新数据的时间戳。 | ||
| 说明 数据最近更新时间属性记录最近一次数据提取或刷新的日期和时间。此元数据对于了解待分析数据的新鲜度和管理数据管道至关重要。 此属性可让业务用户和分析人员了解分析所用数据的时效性,帮助安排数据刷新,并确保决策依据的数据及时满足需求。监控持续进行的流程时,了解最近更新时间对于正确解读未关闭案例的当前状态至关重要。 重要性 反映数据的新鲜度,确保分析和业务决策基于及时、相关的信息。 获取途径 此时间戳通常在数据提取(ETL)过程中生成并添加。 示例 2023-10-27T02:00:00Z2023-10-28T02:00:00Z2023-10-29T02:00:00Z | |||
| 源系统 SourceSystem | 提取数据的记录系统,可用于追踪数据来源。 | ||
| 说明 源系统属性用于标识客户服务数据的来源应用或平台,例如ServiceNow、Salesforce、Zendesk或内部定制系统。在整合多个系统的数据时,此字段对于数据治理和可追溯性至关重要。 虽然它通常不直接用于标准流程路径分析,但能提供重要背景信息,帮助了解不同系统在数据质量或流程执行方面可能存在的差异。它也有助于验证数据、排查数据提取问题和管理数据集成管道。 重要性 标识数据来源,对于多系统环境中的数据治理、问题排查和分析至关重要。 获取途径 此字段通常在数据提取(ETL)过程中添加,源系统的数据表中可能没有该字段。 示例 Salesforce Service CloudZendesk SupportServiceNow CSM | |||
| 优先级 Priority | 分配给服务请求的优先级,例如“低”“中”“高”或“紧急”。 | ||
| 说明 优先级属性表示服务请求的紧急程度,通常会影响处理时限。优先级一般根据客户所报告问题的业务影响和严重程度确定。SLA通常与优先级挂钩。 在流程分析中,优先级是重要的筛选和比较维度。分析人员可以检查高优先级请求是否确实比低优先级请求解决得更快,并验证优先级规则是否得到执行,以及资源分配是否符合业务重点。比较不同优先级请求的流程路径,还能发现处理严重问题时的低效环节。 重要性 可用于分析紧急请求是否得到更快处理,并验证资源分配是否符合业务需求。 获取途径 这是大多数客户服务系统中案例或工单表单的标准字段。 示例 低中高紧急 | |||
| 分配群组 AssignedGroup | 负责处理服务请求的团队、部门或队列。 | ||
| 说明 分配群组用于标识在特定时间点负责某项服务请求的团队或职能部门,例如“一线支持”“账单部门”或“技术支持团队”。服务请求在处理过程中通常会在不同群组之间流转。 分析分配群组对于了解团队协作和交接情况至关重要。它有助于发现哪些团队工作负荷过重、群组间的瓶颈出现在哪里,以及不同类型的请求在组织中的处理路径。这些信息对于优化团队架构、资源分配和路由规则十分重要。 重要性 可用于分析团队绩效、工作量分配,以及部门间交接造成的延误。 获取途径 位于案例或工单记录中,字段名称通常为“分配群组”“团队”或“队列”。 示例 一线支持账单咨询技术升级处理硬件支持 | |||
| 客户满意度 CustomerSatisfaction | 服务请求解决后,客户提供的满意度分数或评级。 | ||
| 说明 客户满意度是重要的结果指标,用于衡量客户对所获服务的评价。通常通过解决问题后的调查问卷收集,评分方式可以是1到5等数字量表,也可以是“良好”“一般”或“较差”等类别。 此属性对于将流程绩效与业务结果联系起来至关重要。分析人员将满意度评分与流程指标关联后,可以发现哪些流程行为会带来满意或不满。例如,分析可能显示,多次重新分配或解决时间过长的案例,往往会得到较低的满意度评分。这为优先呈现对客户体验影响最大的流程改进机会提供了清晰的数据依据。 重要性 直接衡量客户对服务质量的评价,将流程效率与业务结果联系起来。 获取途径 通常存储在单独的调查问卷回复表中,并可与服务请求记录关联。 示例 5413 | |||
| 客服人员 Agent | 负责某项活动的客服人员或用户的姓名或唯一标识符。 | ||
| 说明 客服人员属性用于标识执行特定活动或当前负责某项服务请求的员工。该属性可以是唯一ID、电子邮件地址或全名。 此属性支持个人层面的绩效和工作量分析。管理者可以查看工作分配情况,比较客服人员在解决时间或客户满意度等指标上的表现,并发现培训机会。它对于分析客服人员之间的交接也至关重要,因为交接可能导致延误并令客户不满。 重要性 此属性对于分析客服人员的工作量、绩效以及人员交接的影响至关重要。 获取途径 通常可在案例分配历史表、事件日志中找到,也可能是案例或工单主记录中的字段。 示例 John Smithagent.jane@example.comuser_1138Sarah Doe | |||
| 是否已升级处理 IsEscalated | 用于标记服务请求是否已升级至更高级别的支持团队或管理层。 | ||
| 说明 是否已升级处理属性是一个布尔标记(true或false),用于标明服务请求是否已正式升级。问题超出当前支持级别的处理能力、未能在规定时间内解决,或客户极度不满时,通常会进行升级处理。 此属性对于升级分析至关重要。组织可据此计算升级率,这是一项关键绩效指标。分析升级案例的流程路径,有助于企业发现升级的根本原因,例如一线支持技能不足、流程不清晰或产品问题。减少升级处理通常是重要目标,因为升级会增加成本,也可能损害客户满意度。 重要性 有助于识别升级处理的频率和根本原因,并发现提升首次联系解决率的机会。 获取途径 这通常是案例或工单记录中的复选框或标记字段,也可以通过检测“升级处理”活动推导得出。 示例 truefalse | |||
| 沟通渠道 CommunicationChannel | 发起服务请求或进行沟通的渠道,例如“电子邮件”“电话”或“聊天”。 | ||
| 说明 沟通渠道用于标识客户与服务台互动所使用的方式。常见渠道包括电子邮件、电话、Web门户、聊天和社交媒体。渠道会影响客户预期和解决流程的复杂程度。 按沟通渠道分析流程,可以发现显著的绩效差异。例如,电话提交的请求可能解决得更快,但比通过Web门户提交的请求更耗费客服人员资源。这类分析有助于组织优化渠道策略、有效分配资源,并针对不同沟通方式调整服务体验。 重要性 揭示不同沟通渠道对解决时间、客服人员投入和整体流程效率的影响。 获取途径 通常是案例或工单记录中的标准字段,用于标明请求的创建渠道。 示例 电子邮件电话聊天Web门户社交媒体 | |||
| 结束时间 EndTime | 记录活动完成时间的时间戳,用于计算单项活动的持续时间。 | ||
| 说明 结束时间属性标记活动的完成时刻。事件时间记录开始时刻,结束时间则提供计算特定任务耗时所需的另一个时间点。并非所有事件都有明确的结束时间,但对于客服人员调查或客户通话等活动,这项信息很有价值。 分析时,结束时间与事件时间的差值就是活动处理时间。这是瓶颈分析的基础,有助于找出流程中最耗时的步骤。了解活动时长有助于规划资源、评估绩效并发现简化运营的机会。 重要性 此属性是计算单项活动时长的关键,对于识别瓶颈和衡量效率至关重要。 获取途径 通常与开始时间一同记录在事件日志或审计跟踪表中。如果没有结束时间,可根据后续事件的开始时间推算。 示例 2023-10-26T10:30:00Z2023-10-26T11:00:45Z2023-10-27T16:20:00Z | |||
| 请求状态 RequestStatus | 服务请求当前或历史状态,例如“打开”“待处理”“已解决”或“已关闭”。 | ||
| 说明 请求状态表示服务请求在生命周期特定阶段的状态。随着处理进展,状态会发生变化,例如从“新建”变为“处理中”,再变为“等待客户”,最后变为“已解决”。状态变更序列通常构成流程模型中的活动基础。 分析状态变更是了解流程路径的主要方式之一。它有助于识别请求在特定状态(如“待处理”)停留的时间,从而发现对外部相关方的依赖。状态也用于区分未关闭和已关闭案例,这是报告当前待处理案例量和解决率的基础。 重要性 跟踪请求所处的生命周期阶段,帮助识别等待状态的耗时并定义流程活动。 获取途径 案例或工单记录中的核心字段。状态变更通常记录在审计历史表中。 示例 新建处理中等待客户已解决已关闭 | |||
| 请求类型 RequestType | 服务请求的分类,例如“问题咨询”“事件”“故障”或“功能请求”。 | ||
| 说明 请求类型用于对客户问题或咨询进行高层级分类,帮助细分服务请求,了解支持团队面临的不同需求。常见类型包括技术问题、账单咨询、信息请求或投诉。 此属性对于分析很有价值,可用于筛选和比较不同类型请求的处理流程。例如,“账单咨询”的解决流程可能比“技术事件”简单、快速得多。了解这些差异有助于制定合适的SLA、设计高效工作流并有效分配资源。 重要性 按类型细分请求对于了解不同流程路径,并针对具体问题制定改进措施至关重要。 获取途径 这是案例或工单表单中的标准字段,名称通常为“类型”“类别”或“分类”。 示例 事件问题咨询故障功能请求 | |||
| SLA目标时间 SlaTargetTime | 根据合同约定或目标要求解决服务请求的日期和时间。 | ||
| 说明 SLA目标时间表示根据适用的服务级别协议(SLA),服务请求预期解决的截止时间。此目标通常取决于请求的优先级、类型或客户合同级别,可以存储为具体时间戳,也可以存储为从创建时间起算的时长。 此属性是SLA一致性分析的基础。将实际解决时间与SLA目标时间进行比较,组织即可计算SLA达成率。流程挖掘还可以进一步细分分析,显示哪些类型的请求或流程步骤最容易导致SLA违约,从而有针对性地改进,履行服务承诺。 重要性 此属性对于衡量SLA达成情况至关重要,而SLA达成情况是客户服务组织的关键KPI。 获取途径 通常根据系统中定义的SLA政策计算,并存储在案例或工单记录中。 示例 2023-10-28T10:00:00Z2023-11-01T17:00:00Z2023-10-26T14:00:00Z | |||
| 产品 Product | 客户请求所涉及的产品或服务。 | ||
| 说明 产品属性用于指定客户请求涉及的具体产品、服务或功能,以便按业务领域对服务请求进行分类。 按产品分析服务请求对于根因分析和产品改进至关重要。某个产品的工单数量较多,可能意味着存在质量问题、缺陷或易用性问题。这些数据可为产品开发和工程团队提供有价值的反馈,帮助他们优先处理修复和改进事项,从而减少支持工作量并改善客户体验。 重要性 将服务请求与具体产品关联,为产品改进和根因分析提供重要反馈。 获取途径 通常是案例或工单表单中的字段,可关联产品目录,也可以手动填写。 示例 Alpha-100打印机企业套件v2.5移动应用账单平台 | |||
| 客户 Customer | 发起服务请求的客户或公司的名称或唯一标识符。 | ||
| 说明 客户属性用于标识与服务请求相关的外部客户,可以是个人或组织。借助此属性,可以汇总并分析特定客户的所有服务交互。 以客户为中心的视角对于了解整体客户体验至关重要。按客户筛选数据进行分析,企业可以发现请求量较大的客户,这可能意味着产品存在问题或客户需要更多培训。此属性还有助于跟踪重要客户的服务历史,确保其获得预期水平的支持。 重要性 提供以客户为中心的流程视图,帮助发现特定客户的常见问题并管理重要客户。 获取途径 案例或工单记录中的标准字段,关联CRM中的联系人或客户对象。 示例 ABC CorporationGlobal Tech Inc.Jane DoeACCT-00123 | |||
客户服务活动
| 活动 | 说明 | ||
|---|---|---|---|
| 关闭请求 | 这是最后一项活动,表示服务请求已完成永久性行政关闭。此后,请求即视为完成,无需采取进一步行动。 | ||
| 重要性 此活动标志着流程生命周期的正式结束。从解决到关闭之间的时间,可以反映自动关闭或最终审核等流程政策。 获取途径 根据状态明确变更为“已关闭”记录。许多系统都有专门的“关闭时间”时间戳。 采集 使用“关闭时间”时间戳,或状态变更为“已关闭”时的时间戳。 事件类型 explicit | |||
| 分派请求 | 将服务请求首次分派给特定客服人员或团队处理。这是关键步骤,标志着请求从队列进入实际处理环节。 | ||
| 重要性 此活动对于跟踪客服人员工作量、衡量首次分派所需时间,以及识别分派流程中的瓶颈至关重要。 获取途径 从服务请求记录审计日志或历史记录中的“负责人”或“分配给”字段变更获取。 采集 识别客服人员或团队负责人字段首次填入或变更的事件。 事件类型 explicit | |||
| 创建服务请求 | 客户请求正式登记时,客户服务流程随之开始。当源系统生成新的案例、工单或交互记录时,系统会记录此事件。 | ||
| 重要性 这是流程的主要开始事件,对于衡量整个生命周期时长和分析一段时间内的请求量至关重要。 获取途径 通常从服务管理系统中主案例或工单记录的创建时间戳获取。 采集 使用主案例、工单或事件记录的创建时间戳。 事件类型 explicit | |||
| 升级请求 | 将服务请求正式升级至更高级别的支持团队、其他部门或管理层。通常在初始客服人员无法解决问题时发生。 | ||
| 重要性 升级处理是衡量流程复杂程度、客服人员能力和首次联系解决情况的重要指标。分析升级路径有助于优化支持体系。 获取途径 可以通过升级规则引擎记录的明确事件识别,也可以根据请求重新分派给指定升级团队或人员来推断。 采集 使用专用的升级标记或时间戳,或检测分派对象是否变更为已知的升级团队。 事件类型 explicit | |||
| 解决请求 | 客服人员完成处理并认为客户问题已解决时,会到达这一关键节点。请求状态变为“已解决”或“已处理”。 | ||
| 重要性 这是衡量解决时间的主要事件,标志着支持团队完成主动处理,也是服务生命周期中的关键节点。 获取途径 根据状态明确变更为“已解决”或“已处理”获取。大多数系统会记录专门的解决时间戳。 采集 使用“解决时间”时间戳,或状态变更为“已解决”时的时间戳。 事件类型 explicit | |||
| 重新分派请求 | 初次分派后,服务请求的处理责任从一名客服人员或团队转交给另一名客服人员或团队。这代表支持流程中的一次交接。 | ||
| 重要性 跟踪重新分派对于分析流程碎片化和识别不必要的交接至关重要。频繁重新分派可能意味着分派规则存在问题或知识不足。 获取途径 监控初次分派后“负责人”“分配给”或“分派组”字段的后续变更,据此推断。 采集 识别首次分派后负责人或分派组字段的所有变更。 事件类型 inferred | |||
| 重新打开请求 | 此前已解决的服务请求恢复为活动状态时,就会发生此事件。通常是因为客户反馈问题尚未解决或再次出现。 | ||
| 重要性 重新打开的请求直接反映返工情况,也是首次联系解决失败的重要指标。分析这些事件对于提升解决方案质量至关重要。 获取途径 通常是一个明确事件:收到客户的新回复后,系统自动将状态从“已解决”改回“未解决”。 采集 检测状态从“已解决”或“已关闭”变回“未解决”或“处理中”的变更。 事件类型 explicit | |||
| SLA违约 | 服务请求未能满足既定服务级别协议时发生,例如未能达到首次响应时间或解决时间要求。这是对业务影响重大的事件。 | ||
| 重要性 此活动直接衡量服务级别表现和合规情况。分析违约发生的时间和原因,对于流程改进和管理客户预期至关重要。 获取途径 这是一个计算得出的事件,通过将活动时间戳与服务合同或策略引擎中预设的SLA目标进行比较得出。 采集 比较开始和结束活动之间的时间差与既定SLA目标。如果持续时间超出目标,则记录违约事件。 事件类型 calculated | |||
| 发送满意度调查 | 通常在服务请求解决后由自动化规则触发,向客户发送满意度调查,并由此开始收集反馈。 | ||
| 重要性 此活动为客户反馈指标提供背景信息,有助于分析调查回复率和反馈请求的发送时间。 获取途径 从自动化日志、外发邮件记录,或与服务请求关联的专用调查记录中获取。 采集 识别调查对象的创建,或与满意度调查相关的外发消息。 事件类型 explicit | |||
| 发送首次回复 | 请求创建后,客服人员首次直接向客户发送非自动化消息。此活动是客户互动的重要节点。 | ||
| 重要性 此活动对于衡量和监控“首次响应时间”SLA至关重要,反映支持团队响应客户问题的速度。 获取途径 系统的SLA引擎通常会记录带时间戳的明确事件。也可以从案例时间线中查找客服人员首次向外发送的公开消息,据此推断。 采集 如果有专用的“首次响应时间”时间戳,请直接使用;否则,查找客服人员首次向外发送消息的时间戳。 事件类型 explicit | |||
| 向客户索取信息 | 客服人员需要客户提供更多信息才能继续处理,并将请求设为待处理状态时,就会发生此活动。这会暂停内部流程或SLA计时器。 | ||
| 重要性 此活动是了解客户相关延误的关键。跟踪该状态的持续时间,有助于区分客服人员工作时间和客户等待时间。 获取途径 通常根据状态变更推断,例如变为“待处理”“暂停”或“等待客户信息”。 采集 在案例历史记录中识别状态变更为“待处理”或“等待客户回复”的事件。 事件类型 inferred | |||
| 客服人员开始调查 | 表示客服人员已开始主动处理服务请求。此活动不同于请求分派,代表诊断或解决工作正式开始。 | ||
| 重要性 有助于区分等待时间和实际工作时间。分析此活动可以发现分派后到实际开始处理之间的延误。 获取途径 通常根据服务请求的状态变更推断,例如从“新建”或“已分派”变为“处理中”或“正在处理”。 采集 识别分派后首次变更为“处理中”等活动状态的事件。 事件类型 inferred | |||
| 提出解决方案 | 客服人员制定解决方案并告知客户。此活动可能早于正式解决,尤其是在需要客户确认的情况下。 | ||
| 重要性 这一概念性步骤有助于区分寻找解决方案所需的时间和等待客户接受方案所需的时间,从而更细致地了解问题解决阶段。 获取途径 通常根据包含解决方案详情的外发消息,或状态变更为“等待接受”或“已提供解决方案”来推断。 采集 识别包含“解决方案”等关键词的外发消息,或表示已提出解决方案的状态变更。 事件类型 inferred | |||
| 收到客户提供的信息 | 客户提供所需信息后,客服人员即可继续处理。此事件通常会使请求从待处理状态恢复为活动状态。 | ||
| 重要性 此事件标志着客户等待阶段结束。分析此事件与“向客户索取信息”活动之间的时间,可以了解客户响应时间。 获取途径 可根据客户发来的消息,或状态从“待处理”自动变回“未解决”或“处理中”来推断。 采集 检测客户发来的消息,或状态从“待处理”变为“活动”的变更。 事件类型 inferred | |||
| 收到客户满意度反馈 | 客户提交满意度调查回复时发生此事件。评分或评论等反馈会记录在对应的服务请求中。 | ||
| 重要性 此事件将流程执行情况与客户感知的服务质量直接关联起来。结合流程分析满意度评分,有助于找出导致体验不佳的步骤。 获取途径 客户提交回复并将其关联到原服务请求时,可从调查模块中获取。 采集 使用客户满意度调查回复的提交时间戳。 事件类型 explicit | |||
| 添加内部评论 | 客服人员在服务请求中添加仅供内部查看的备注或评论,以便与其他客服人员或团队协作,客户无法看到这些内容。 | ||
| 重要性 这些事件反映内部协作、知识共享或升级准备情况。内部备注频繁出现,可能意味着案例复杂或存在知识缺口。 获取途径 从服务请求的活动流或沟通日志中获取,并筛选标记为“内部”或“私密”的评论。 采集 筛选案例评论或活动日志,查找标记为仅供内部查看的条目。 事件类型 explicit | |||
| 请求分类 | 根据类型、类别或优先级对服务请求进行分类。此步骤通常由客服人员或自动化规则执行,用于确定紧急程度和分派方式。 | ||
| 重要性 分析分类变更有助于评估分诊效果、发现返工和分派错误,也能帮助了解服务请求的复杂程度和性质。 获取途径 通常根据审计日志或历史记录推断,查看服务请求记录中“类别”“类型”或“优先级”等字段的变更。 采集 检测案例历史记录中分类、优先级或类型字段的变更。 事件类型 inferred | |||
数据提取指南
不同系统的数据提取方式各不相同。详细说明请
立即提升客户服务水平
发现瓶颈、提升客服效率,让客户获得更好的服务体验。
无需信用卡,几分钟即可开始。