您的客户服务数据模板
您的客户服务数据模板
这是适用于客户服务的通用流程挖掘数据模板。如需更具体的指导,请使用系统专用模板。
选择具体系统- 标准化数据字段,确保分析一致
- 关键活动,支持准确的流程映射
- 适用于各种系统的基础结构
客户服务属性
| 名称 | 说明 | ||
|---|---|---|---|
| 事件时间 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 | 用于标识服务请求是否已升级至更高层级支持团队或管理层的标记。 | ||
| 说明 Is Escalated属性是一个布尔标志(true或false),用于标记服务请求是否已正式升级。通常在问题超出当前支持层级的处理能力、未能在规定时间内解决,或客户非常不满意时,才会进行升级。 该属性对于升级分析至关重要。借助它,组织可以计算升级率这一关键绩效指标。通过分析已升级案例的流程路径,企业可以识别升级的根本原因,例如一线支持人员技能不足、流程不清晰或产品问题。减少升级通常是重要目标,因为升级成本高,也可能降低客户满意度。 为什么重要 帮助识别升级的频率和根因,发现提升首次接触解决率的机会。 获取位置 通常是案例或工单记录中的复选框或标记字段,也可以通过检测“升级”活动推导。 示例 truefalse | |||
| 沟通渠道 CommunicationChannel | 服务请求发起或沟通所使用的渠道,例如“电子邮件”“电话”或“聊天”。 | ||
| 说明 沟通渠道用于标识客户与服务台互动所使用的媒介。常见渠道包括电子邮件、电话、门户网站、聊天和社交媒体。渠道可能影响客户预期和解决流程的复杂程度。 按沟通渠道分析流程,可以发现明显的绩效差异。例如,与通过门户网站提交的请求相比,电话请求可能解决更快,但需要客服人员投入更多资源。这类分析有助于优化渠道策略、有效分配资源,并针对不同沟通方式调整服务体验。 为什么重要 揭示不同沟通渠道对解决时间、客服人员投入和整体流程效率的影响。 获取位置 通常作为案例或工单记录中的标准字段,用于说明请求的创建方式。 示例 电子邮件电话聊天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合规情况的基础指标,也是客户服务组织的重要KPI。 获取位置 通常根据系统中定义的SLA策略计算,并存储在案例或工单记录中。 示例 2023-10-28T10:00:00Z2023-11-01T17:00:00Z2023-10-26T14:00:00Z | |||
| 产品 Product | 客户请求所涉及的产品或服务。 | ||
| 说明 产品属性用于指定客户请求所涉及的具体产品、服务或功能,从而可以按业务领域对服务请求进行分类。 按产品分析服务请求对于根因分析和产品改进至关重要。某一产品的工单数量较多,可能表明存在质量问题、缺陷或易用性问题。这些数据可以为产品开发和工程团队提供有价值的反馈,帮助其优先修复和改进相关问题,减少支持工作量并改善客户体验。 为什么重要 将服务请求与具体产品关联,为产品改进和根因分析提供重要反馈。 获取位置 通常是案例或工单表单中的字段,可关联产品目录,也可以手动输入。 示例 Alpha-100 PrinterEnterprise Suite v2.5Mobile AppBilling Platform | |||
| 客户 Customer | 发起服务请求的客户或公司名称或唯一标识符。 | ||
| 说明 客户属性用于标识与服务请求相关的外部客户,可以是个人或组织。借助该属性,可以汇总和分析特定客户的所有服务互动。 以客户为中心的视图对于了解整体客户体验至关重要。按客户筛选分析数据,企业可以识别提交大量请求的客户,这可能意味着产品存在问题或客户需要更好的培训。该属性还有助于跟踪重点客户的服务历史,确保其获得预期水平的支持。 为什么重要 支持以客户为中心查看流程,帮助识别特定客户的高频问题并管理重点客户。 获取位置 案例或工单记录中的标准字段,关联CRM中的联系人或客户账户对象。 示例 ABC CorporationGlobal Tech Inc.Jane DoeACCT-00123 | |||
客户服务活动
| 活动 | 说明 | ||
|---|---|---|---|
| 服务请求已创建 | 标志着客户服务流程的开始,即客户请求被正式记录的时刻。当源系统生成新的案例、工单或交互记录时,系统会捕获此事件。 | ||
| 为什么重要 这是流程的主要开始事件,对于衡量完整生命周期时长和分析一段时间内的请求量至关重要。 获取位置 通常从服务管理系统中主要案例或工单记录的创建时间戳获取。 采集 使用主要案例、工单或事件实体的创建时间戳。 事件类型 explicit | |||
| 请求已关闭 | 这是最后一项活动,表示服务请求已完成永久性的管理关闭。此后,请求被视为完成,不再需要进一步处理。 | ||
| 为什么重要 此活动标志着流程生命周期的最终结束。解决与关闭之间的时间,可以揭示自动关闭或最终审核等流程策略。 获取位置 从状态明确变更为“已关闭”获取。许多系统提供专用的“关闭时间”时间戳。 采集 使用“关闭时间”时间戳,或使用状态变更为“已关闭”时的时间戳。 事件类型 explicit | |||
| 请求已分配 | 表示首次将服务请求分配给特定客服人员或团队处理。这是一个关键步骤,意味着请求从队列进入活跃工作流。 | ||
| 为什么重要 此活动对于跟踪客服工作负载、衡量首次分配耗时,以及识别调度流程中的瓶颈至关重要。 获取位置 从服务请求记录审计日志或历史记录中“所有者”或“分配给”字段的变更获取。 采集 识别客服人员或团队所有者字段首次填充或发生变更的事件。 事件类型 explicit | |||
| 请求已升级 | 表示将服务请求正式升级至更高层级的支持团队、其他部门或管理层。当初始客服人员无法解决问题时,通常会发生此情况。 | ||
| 为什么重要 升级是衡量流程复杂度、客服能力和首次联系解决失败情况的重要指标。分析升级路径有助于优化支持体系。 获取位置 可以是升级规则引擎生成的明确事件,也可以根据请求重新分配至指定升级团队或用户来推断。 采集 使用专用的升级标记或时间戳,或检测分配是否变更为已知的升级团队。 事件类型 explicit | |||
| 请求已解决 | 这是一个关键里程碑,表示客服人员已完成工作,并认为客户问题已经得到处理。请求状态变更为“已解决”或“已处理”。 | ||
| 为什么重要 这是衡量解决时间的主要事件,表示支持团队完成主动处理工作,是服务生命周期中的关键里程碑。 获取位置 从状态明确变更为“已解决”或“已处理”获取。大多数系统都会记录专用的解决时间戳。 采集 使用“解决时间”时间戳,或使用状态变更为“已解决”时的时间戳。 事件类型 explicit | |||
| 请求已重新分配 | 表示首次分配后,服务请求的责任从一名客服人员或一个团队转移给另一名客服人员或另一个团队。这代表支持流程中的一次交接。 | ||
| 为什么重要 跟踪重新分配对于分析流程碎片化和识别不必要的交接至关重要。频繁重新分配可能说明路由问题或知识缺口。 获取位置 通过监控首次分配后“所有者”“分配给”或“分配组”字段的后续变更来推断。 采集 识别首次分配后所有者或分配组字段的所有变更。 事件类型 inferred | |||
| 请求已重新打开 | 当之前已解决的服务请求重新回到活跃状态时发生。通常是因为客户反馈问题未解决或再次出现。 | ||
| 为什么重要 重新打开的请求可以直接衡量返工,也是首次联系解决失败的重要指标。分析这些事件对于提升解决方案质量至关重要。 获取位置 通常是一个明确事件:系统收到客户新回复后,自动将状态从“已解决”变更回“已打开”。 采集 检测状态是否从“已解决”或“已关闭”重新变更为“已打开”或“处理中”。 事件类型 explicit | |||
| SLA已违约 | 表示服务请求未能满足既定服务级别协议的时刻,例如首次响应时间或解决时间要求。这是对业务至关重要的事件。 | ||
| 为什么重要 此活动直接衡量服务级别绩效和合规情况。分析违约发生的时间和原因,对于流程改进和管理客户期望至关重要。 获取位置 这是一个计算得出的事件,通过将活动时间戳与服务合同或策略引擎中预先定义的SLA目标进行比较来确定。 采集 将开始活动与结束活动之间的时间差同定义的SLA目标进行比较。如果时长超过目标,则记录违约事件。 事件类型 calculated | |||
| 客服人员开始调查 | 表示客服人员已主动开始处理服务请求。这不同于请求分配,代表诊断或解决工作的开始。 | ||
| 为什么重要 有助于区分等待时间和实际工作时间。分析此活动可以发现请求分配后到实际开始处理之间的延迟。 获取位置 通常根据服务请求状态变更推断,例如从“新建”或“已分配”变更为“处理中”或“工作进行中”。 采集 识别分配后首次变更为活跃“处理中”状态的事件。 事件类型 inferred | |||
| 已向客户请求信息 | 当客服人员需要客户提供更多信息才能继续处理,并将请求置于待处理状态时发生。此时内部流程或SLA计时器会暂停。 | ||
| 为什么重要 此活动是了解客户相关延迟的关键。跟踪该状态的持续时间,有助于区分客服工作时间和客户等待时间。 获取位置 通常根据状态变更推断,例如变更为“待处理”“暂挂”或“等待客户信息”。 采集 在案例历史记录中识别变更为“待处理”或“等待客户”的状态。 事件类型 inferred | |||
| 已提出解决方案 | 表示客服人员已制定解决方案并告知客户。尤其是在需要客户确认时,此活动可能早于正式解决。 | ||
| 为什么重要 这一概念步骤有助于区分寻找解决方案所需的时间与等待客户接受方案所花的时间,更细致地呈现解决阶段。 获取位置 通常根据包含解决详情的出站沟通消息,或状态变更为“等待接受”或“已提供解决方案”来推断。 采集 识别包含“解决方案”等关键词的出站消息,或识别表示已提出解决方案的状态变更。 事件类型 inferred | |||
| 已收到客户信息 | 标志着客户提供所请求信息的时刻,客服人员可以恢复处理。此事件通常会将请求从待处理状态重新置于活跃状态。 | ||
| 为什么重要 此事件结束客户等待阶段。分析该事件与“已向客户请求信息”活动之间的时间,可以了解客户响应时长。 获取位置 根据客户发来的入站沟通消息,或状态从“待处理”自动变更回“已打开”或“处理中”来推断。 采集 检测客户入站消息,或检测状态从“待处理”变更为“活跃”状态。 事件类型 inferred | |||
| 已收到客户满意度反馈 | 当客户提交满意度调查回复时发生。评分或评论等反馈会记录在对应的服务请求中。 | ||
| 为什么重要 将流程执行与客户感知的服务质量直接关联起来。在流程背景下分析满意度评分,有助于识别导致不佳体验的步骤。 获取位置 从调查模块中获取客户提交的回复,并将其与原始服务请求关联。 采集 使用客户满意度调查回复的提交时间戳。 事件类型 explicit | |||
| 已添加内部评论 | 客服人员向服务请求添加私人备注或评论,用于与其他客服人员或团队开展内部协作。客户无法看到此内容。 | ||
| 为什么重要 这些事件表示内部协作、知识共享或升级准备。内部备注频繁出现,可能说明案例复杂或存在知识缺口。 获取位置 从服务请求的活动流或沟通日志中获取,并筛选标记为“内部”或“私人”的评论。 采集 筛选案例评论或活动日志,查找标记为仅限内部查看的条目。 事件类型 explicit | |||
| 满意度调查已发送 | 表示发送客户满意度调查,通常由自动化规则在服务请求解决后触发,并由此启动反馈收集流程。 | ||
| 为什么重要 此活动为客户反馈指标提供背景,有助于分析调查响应率和反馈请求的发送时间。 获取位置 从自动化日志、出站邮件记录,或与服务请求关联的专用调查实例记录中获取。 采集 识别调查对象的创建,或识别与满意度调查相关的出站沟通。 事件类型 explicit | |||
| 请求已分类 | 表示按类型、类别或优先级对服务请求进行分类。此步骤通常由客服人员或自动化规则执行,用于确定紧急程度和路由。 | ||
| 为什么重要 分析分类变更有助于识别分诊效果、返工和路由错误的请求,也可以帮助了解服务请求的复杂程度和性质。 获取位置 通常从审计日志中推断,审计日志记录服务请求中“类别”“类型”或“优先级”等字段的变更。 采集 在案例历史记录中检测分类、优先级或类型字段的变更。 事件类型 inferred | |||
| 首次响应已发送 | 表示请求创建后,客服人员首次向客户发送直接的非自动化沟通消息。这是客户互动的重要里程碑。 | ||
| 为什么重要 此活动对于衡量和监控“首次响应时间”SLA至关重要,反映支持团队响应客户问题的速度。 获取位置 通常是系统SLA引擎中带时间戳的明确事件,也可以通过查找案例时间线中客服人员首次发出的公开消息来推断。 采集 如果系统提供专用的“首次响应时间”时间戳,请使用该时间戳;否则查找客服人员首次发出消息的时间戳。 事件类型 explicit | |||
数据提取指南
立即提升客户服务水平
发现瓶颈、提升客服人员效率,让客户满意。
无需信用卡,几分钟即可开始。