您的客户服务数据模板
您的客户服务数据模板
- 建议收集的属性
- 需要追踪的关键活动
- Microsoft Dynamics 365 Customer Service 数据提取指南
客户服务属性
| 名称 | 描述 | ||
|---|---|---|---|
|
服务请求
ServiceRequest
|
客户服务请求的唯一标识符,也称为“案例”或“工单”。 | ||
|
描述
“服务请求 (Service Request)”作为主标识符,关联了与单个客户咨询或问题相关的所有活动。在流程挖掘中,它充当“Case ID”,确保从创建到关闭的每次客户交互视图完整且一致。按服务请求进行分析,可以追踪端到端旅程、衡量解决时间并识别同类案例中的模式。
为何重要
这是关键的 Case ID,它将所有相关事件连接成一个流程实例,使端到端流程分析成为可能。
获取方式
这是 Microsoft Dynamics 365 客户服务中“Case (incident)”实体的主键。
示例
CAS-01024-F3B4V6SR-2023-00589TKT-4815162342
|
|||
|
最后数据更新
LastDataUpdate
|
从源系统进行最后一次数据刷新或提取的时间戳。 | ||
|
描述
此属性指明数据最后一次从 Microsoft Dynamics 365 提取的时间。它用于展示数据的时效性,确保用户在查看仪表板和分析结果时了解数据的及时性。
为何重要
告知用户数据的时效性,这对于基于流程分析做出及时、准确的业务决策至关重要。
获取方式
此值在数据提取时生成并标记到数据集中。
示例
2023-10-27T08:00:00Z
|
|||
|
开始时间
EventTime
|
活动发生的时间戳。 | ||
|
描述
此属性记录活动发生的精确日期和时间。它是对事件进行排序以及进行所有时间维度分析(如计算周期、时长、等待时间)的基础。准确且一致的时间戳是流程挖掘分析完整性的关键。
为何重要
此时间戳按时间顺序排列事件,并支持所有基于时长的计算,这对于性能分析和瓶颈识别至关重要。
获取方式
对应“Case (incident)”实体或相关活动实体(如邮件、任务、电话)上的“createdon”或“modifiedon”等字段。
示例
2023-04-15T10:00:00Z2023-05-20T14:35:10Z2023-06-01T09:12:45Z
|
|||
|
活动
ActivityName
|
在特定时间点发生的服务请求业务事件名称。 | ||
|
描述
此属性描述客户服务流程中的单个步骤或状态变更,例如“案例已创建”、“客服已调查问题”或“案例已解决”。这些活动构成了流程图的骨架。每个活动与时间戳结合,共同定义了流程的先后顺序。
为何重要
“活动”定义了流程中的步骤。分析活动的顺序和频率是理解流程流、识别偏差以及寻找瓶颈的基础。
获取方式
通常通过将“statuscode”的状态变更,或来自相关实体(如任务、邮件、电话)的特定事件映射到标准化的活动名称来得出。
示例
案件创建坐席已调查问题已向客户提供方案案件已结案
|
|||
|
源系统
SourceSystem
|
标识数据的来源系统。 | ||
|
描述
此属性指定事件数据的来源。在本流程中,它将统一标识为 Microsoft Dynamics 365 Customer Service。在多系统环境中,此字段对于区分数据源和确保数据血缘至关重要。
为何重要
提供清晰的数据血缘,这对于数据治理以及排查数据不一致问题至关重要,尤其是在多系统混合分析中。
获取方式
这通常是在 data 提取和 transformation 过程中添加的静态值,用于标记 dataset 的来源。
示例
Microsoft Dynamics 365 Customer Service
|
|||
|
SLA 目标解决时间
SlaTargetResolutionTime
|
合同约定的服务请求解决目标时间。 | ||
|
描述
此属性指定 SLA 约定的解决目标时长。它是衡量实际绩效的基准。该值对于“SLA 合规性监控”仪表板和计算“SLA 合规率”KPI 至关重要,能够指出流程中未达标的环节。
为何重要
这是衡量服务绩效是否达标的主要基准,直接支持 SLA 合规性和违规分析。
获取方式
该值由 Dynamics 365 中的 SLA 配置决定,并通过 SLA KPI 实例与案例关联。
示例
2592008640014400
|
|||
|
优先级
Priority
|
分配给服务请求的优先级,代表其紧急程度。 | ||
|
描述
此属性定义服务请求的紧急程度(低、中、高、紧急)。优先级决定了案例处理的先后顺序,并通常与 SLA 目标挂钩。分析优先级对流程流向、资源分配和解决时间的影响,是确保关键问题得到及时处理的关键。
为何重要
有助于了解高优先级请求是否处理得更快并达到目标,以及优先级水平如何影响整体流程表现。
获取方式
对应“Case (incident)”实体上的“Priority (prioritycode)”字段。
示例
低普通高
|
|||
|
客户名称
CustomerName
|
与服务请求相关的客户或账户名称。 | ||
|
描述
此属性识别发起请求的客户,支持从以客户为中心的视角分析流程。通过分析,您可以发现哪些客户提交请求最频繁、经历的解决时间最长或遇到的问题最复杂,从而优化客户关系管理。
为何重要
支持客户层级的分析,以识别模式、改进大客户服务并深入了解客户旅程。
获取方式
这是“Case (incident)”实体上的“Customer (customerid)”查找字段,可指向“Account (账户)”或“Contact (联系人)”记录。
示例
Global Tech Inc.Jane Doe创新解决方案
|
|||
|
服务请求类型
ServiceRequestType
|
服务请求的主要类别或分类。 | ||
|
描述
此属性根据请求性质(如“账单查询”、“技术支持”或“产品反馈”)对服务请求进行分类。它是细分流程分析的基础。通过类型分析,可以发现某些类别是否具有更长的解决时间、更高的升级率或遵循不同的流程路径。
为何重要
支持按流程分段,以揭示特定类型的瓶颈、资源需求和改进机会,助力优化路由和处理策略。
获取方式
此信息通常存储在“Case (incident)”实体上的“Subject (subjectid)”字段或自定义类别字段中。
示例
账单咨询技术支持产品反馈账户管理
|
|||
|
渠道
Channel
|
发起服务请求的沟通渠道。 | ||
|
描述
此属性识别客户交互的来源(如电话、邮件、门户或聊天)。不同渠道通常对应不同的流程流向和客户预期。按渠道分析流程有助于优化特定渠道的工作流和资源分配。
为何重要
洞察不同的客户接触渠道如何影响流程效率、解决时间以及客户满意度。
获取方式
对应“Case (incident)”实体上的“Case Origin (caseorigincode)”字段。
示例
电话电子邮件Web聊天
|
|||
|
状态原因
StatusReason
|
为服务请求的当前状态提供更详尽的原因描述。 | ||
|
描述
虽然案例只有“活动中”或“已解决”等宏观状态,但“状态原因 (Status Reason)”提供了更具体的语境,如“已提供信息”或“问题已解决”。此属性对于理解案例生命周期的细微差别至关重要,例如区分成功解决与客户取消的案例,这对准确的结果分析非常关键。
为何重要
提供案例结果及状态变更原因的细颗粒度见解,支持对解决路径和根因进行更精确的分析。
获取方式
对应“Case (incident)”实体上的“Status Reason (statuscode)”字段。
示例
进行中暂停问题已解决提供信息
|
|||
|
经办人姓名
AgentName
|
负责该活动的客服人员或用户名称。 | ||
|
描述
此属性识别执行活动的特定客服或系统用户。它对于分析人员绩效、工作负载分布和资源分配至关重要。通过人员维度的追踪,企业可以发现优秀典型、识别培训需求并纠正负载不均。
为何重要
支持分析个人和团队表现,有助于平衡工作量,并识别辅导机会以提升整体服务质量。
获取方式
对应于案例 (incident) 实体上的“负责人” (ownerid) 字段,该字段链接到系统用户 (systemuser) 实体。
示例
Alice SmithBob Johnson系统
|
|||
|
CSAT 评分
CustomerSatisfactionScore
|
案例解决后客户提供的满意度评分。 | ||
|
描述
此属性包含客户满意度 (CSAT) 调查的评分。它是客户对服务质量感知的直接体现。此数据对于“客户满意度趋势”仪表板和“平均解决后 CSAT 评分”KPI 至关重要,它将流程绩效与客户体验直接挂钩。
为何重要
直接衡量客户满意度,使企业能够将流程行为与客户情绪相关联,从而驱动持续改进。
获取方式
这通常源自相关的调查实体(如 Customer Voice),并链接回“Case (incident)”实体。
示例
5341
|
|||
|
所属团队
OwnerTeam
|
当前负责该服务请求的团队。 | ||
|
描述
此属性识别负责服务请求的团队。按团队分析对于理解团队级绩效、不同支持层级间的负载分布以及识别团队间的流程差异至关重要。
为何重要
支持团队层级的性能分析,这对于有效管理各级支持和专业小组至关重要。
获取方式
当负责人是团队记录而非系统用户时,从案例 (incident) 实体上的“负责人” (ownerid) 字段派生。
示例
一线支持财务部技术专家
|
|||
|
是否升级
IsEscalated
|
指示服务请求是否已升级的标识。 | ||
|
描述
此布尔属性指示服务请求是否经历了升级。升级发生在初级支持无法解决问题,需要高级团队介入时。追踪此标识有助于分析内部升级路径和升级率,从而识别一线支持的薄弱环节和升级根因。
为何重要
直接衡量升级发生的频率,突显首次联系解决率方面的问题,并指向需要改进流程或坐席技能的领域。
获取方式
对应“Case (incident)”实体上的“Is Escalated (isescalated)”字段。
示例
truefalse
|
|||
|
是否发生SLA违约
IsSlaBreached
|
计算得出的标识,指示服务请求是否超出了其 SLA 目标。 | ||
|
描述
此布尔标识通过对比实际解决时间与“SLA 目标解决时间”得出。若实际时间超过目标,则设为 true。它是“SLA 合规性监控”仪表板和计算“SLA 合规率”的基础,为每个案例提供清晰的合规判定。
为何重要
为每个案例提供明确的 SLA 达成或失败结果,便于筛选、汇总并分析违规根因。
获取方式
通过对比 'ServiceRequestCycleTime' 与 'SlaTargetResolutionTime' 计算得出。
示例
truefalse
|
|||
|
是否返工
IsRework
|
计算得出的标识,指示案例是否涉及返工活动。 | ||
|
描述
此布尔标识用于识别包含返工循环或重复活动的案例(如多次请求客户信息或解决后重新激活)。它通过分析活动序列中的低效模式来计算,是“返工与重复联络分析”仪表板的核心属性。
为何重要
有助于量化并隔离流程中的低效环节,使分析师能够专注于重复工作和精力浪费的根本原因。
获取方式
通过流程挖掘分析,检测案例中特定的活动序列(例如:已解决 -> 重新激活)或重复活动计算得出。
示例
truefalse
|
|||
|
是否首次联系解决
IsFirstContactResolution
|
指示请求是否在首次联系时解决的标识。 | ||
|
描述
此计算属性识别那些在没有后续客户交互或重大延迟(如重新分配人员)的情况下解决的请求。它是“首次解决率 (FCR)”KPI 的基础。
为何重要
这是衡量服务效率和客户满意度的关键指标,体现了快速且彻底解决问题的能力。
获取方式
根据每个案例事件日志中活动的顺序和时间计算得出。
示例
truefalse
|
|||
|
服务请求周期时间
ServiceRequestCycleTime
|
从服务请求创建到解决所经历的总时长。 | ||
|
描述
此计算指标衡量每个服务请求的端到端时长,即“案例创建”与“案例解决”之间的时间差。它是评估整体流程效率的核心 KPI,有助于锁定异常耗时的案例并识别系统性延迟。
为何重要
这是一个核心流程绩效指标,直接衡量端到端解决流程的效率,有助于识别长期未结案例。
获取方式
通过为每个案例 ID 减去第一个事件与最后一个解决事件的时间戳之差计算得出。
示例
1728006048003600
|
|||
|
涉及产品
ProductInvolved
|
与客户服务请求关联的产品。 | ||
|
描述
此属性识别与客户问题相关的特定产品或服务,支持基于产品的流程细分分析。这有助于发现哪些产品产生的请求更多、问题更复杂,从而指导产品改进和资源规划。
为何重要
支持针对特定产品的流程分析,以识别重复出现的产品问题、改进支持文档并有效分配专家资源。
获取方式
对应“Case (incident)”实体上的“Product (productid)”查找字段。
示例
Alpha-100 打印机Zeta CRM 软件Omega 数据方案
|
|||
|
知识文章 ID
KnowledgeArticleId
|
关联至服务请求的知识库文章 ID。 | ||
|
描述
此属性记录解决服务请求期间使用或关联的知识文章 ID。它能直接衡量客服利用知识库解决问题的效率。此数据是“知识文章利用率”仪表板和相关 KPI 的核心,有助于评估知识库的价值和完整性。
为何重要
追踪知识库使用情况,有助于了解客服是否利用现有资源来更快速、更一致地解决问题。
获取方式
此信息存在于“Case (incident)”与“Knowledge Article (knowledgearticle)”实体的关联关系中。
示例
KA-02048KA-02048
|
|||
客户服务活动
| 活动 | 描述 | ||
|---|---|---|---|
|
SLA 计时器已启动
|
表示案例的服务级别协议 (SLA) 计时器已激活,该计时器开始根据定义的指标(如“首次响应时间”或“解决时间”)追踪时长。这是由 Dynamics 365 SLA 引擎管理的显式事件。 | ||
|
为何重要
此活动是监控 SLA 合规性的基础,有助于明确服务承诺的计时起点。它直接支持分析服务目标是否达成。
获取方式
记录在与“Incident (事件)”实体相关的“SLA KPI Instance (SLA KPI 实例)”实体中。相关 SLA KPI 实例记录的“createdon”时间戳即为起点。
捕获
使用与案例关联的“SLA KPI Instance”记录的创建时间戳。
事件类型
explicit
|
|||
|
案件创建
|
此活动标志着客户服务流程的开始,即在系统中创建新案例记录。创建是一个明确的事件,当“Incident (事件)”实体记录首次保存时,系统会记录特定的时间戳。 | ||
|
为何重要
作为最主要的开始事件,此活动对于计算整个案例生命周期时长和了解案例数量趋势至关重要。它是后续所有流程分析的基础。
获取方式
此事件取自每个新“Incident (案例)”记录的“createdon”时间戳。
捕获
使用 Incident 记录的“createdon”时间戳。
事件类型
explicit
|
|||
|
案件已结案
|
这是案例记录在行政管理上的最终关闭,可能与解决同时发生,也可能在之后。此活动通过案例状态变更为“已关闭”来捕获。 | ||
|
为何重要
这代表系统中流程生命周期的终点。“已解决”与“已关闭”之间的时间间隔可以反映行政开销或记录归档的延迟。
获取方式
通过 'Incident' 实体上 'statecode' 字段变为“已取消”(2) 或自定义关闭状态来捕获。时间戳可从审核历史记录中获取。
捕获
追踪“statecode”变更为最终终止状态(如“已取消”/“已关闭”)时的时间戳。
事件类型
explicit
|
|||
|
案例已分配
|
此活动代表将案例分配给特定队列或用户处理。系统会记录案例负责人的变更,并可通过系统审计日志进行追踪。 | ||
|
为何重要
追踪分配情况对于分析负载分布、识别分配延迟以及理解路由效率至关重要。它有助于回答“案例多快能路由给正确的人”这一问题。
获取方式
通过追踪 'Incident' 实体上 'ownerid' 字段的变更来捕获。变更的时间戳可从审核历史日志中获取。
捕获
从审核日志中提取 'ownerid' 字段带时间戳的变更记录。
事件类型
explicit
|
|||
|
案例已升级
|
代表将案例正式升级到更高级别的支持团队或其他团队。这可以是明确的用户操作,即将案例重新分配给指定的升级队列或用户。 | ||
|
为何重要
监控升级情况对于“内部升级率”KPI 至关重要,有助于识别一线支持无法解决的问题根因,并揭示流程薄弱环节及培训机会。
获取方式
通过 'ownerid' 字段变更为指定的升级队列或团队来推断。也可以是显式将案例标记为已升级的自定义操作。
捕获
识别 'ownerid' 变更为已知升级队列的带时间戳记录。
事件类型
inferred
|
|||
|
案例已解决
|
这是一个关键里程碑,代表客服认为客户问题已得到处理。这是 Dynamics 365 中的明确操作,会创建一个链接到案例的“Case Resolution (案例解决)”活动记录。 | ||
|
为何重要
作为最主要的基于成功的结束事件,此活动对于计算解决时间和成功率不可或缺。它是几乎所有客户服务 KPI 的核心组成部分。
获取方式
此事件对应“Resolution (案例解决)”活动记录的创建。该记录上的“actualend”时间戳即为解决时间。
捕获
使用相关“Resolution”活动记录中的“actualend”或“createdon”时间戳。
事件类型
explicit
|
|||
|
向客户请求信息
|
此活动标志着客服需要客户提供更多信息才能继续。通常通过案例状态变更为“等待中”或从案例时间线发送外发邮件来推断。 | ||
|
为何重要
这对于衡量由于客户原因导致的延迟以及分析“等待客户信息时长”KPI 至关重要,有助于隔离等待外部输入的流程时间。
获取方式
可以通过 'Incident' 实体上 'statuscode' 字段的变更(例如变为“挂起”,原因为“等待客户”)来推断。使用此状态变更的时间戳。
捕获
追踪“statuscode”变更为指定的“等待客户”状态时的时间戳。
事件类型
inferred
|
|||
|
坐席已调查问题
|
代表客服人员正在积极理解并诊断客户问题。这是一种推断性活动,通常通过客服在案例中关联“知识文章”来识别,表明已进行相关研究。 | ||
|
为何重要
追踪此项有助于衡量知识资源的利用率及其对解决时间的影响。它可以洞察客服是否有效地利用现有工具来解决问题。
获取方式
通过在 'IncidentKnowledgeBaseRecord' 实体中创建记录来推断,该实体将知识库文章链接到案例。使用该记录创建的时间戳。
捕获
使用知识文章与 Incident 关联时的时间戳。
事件类型
inferred
|
|||
|
客服人员已提取队列项目
|
此事件发生在客服主动从共享队列中提取案例开始处理时。这是用户的刻意操作,不同于系统自动将案例分配到队列。 | ||
|
为何重要
此活动有助于衡量案例在客服开始处理前在队列中等待的实际时间。它是识别队列瓶颈和评估客服主动性的关键。
获取方式
当用户更新与案例关联的“QueueItem”实体上的“workedbyid”字段,或者案例负责人从队列更改为用户时进行追踪。
捕获
识别 QueueItem 上的 'workedbyid' 字段被填充的时间戳。
事件类型
explicit
|
|||
|
已向客户提供方案
|
此活动表示客服已制定解决方案并告知客户。通常根据案例时间线发送的外发邮件或状态变更为“等待客户确认”来推断。 | ||
|
为何重要
此里程碑标志着从调查阶段转向解决阶段。分析从提出方案到确认方案之间的时间,可以揭示客户响应延迟或方案本身的问题。
获取方式
可以通过与案例相关的外发“电子邮件”活动记录的时间戳,或状态代码变更为预解决状态来推断。
捕获
使用外发邮件活动或状态变更为“Solution Proposed”时的时间戳。
事件类型
inferred
|
|||
|
案例分类已变更
|
此事件发生在客服在案例创建后修改分类或主题时。这是由系统审计功能追踪的明确变更。 | ||
|
为何重要
追踪重新分类对于“服务请求重新分类率”KPI 至关重要。高频的分类变更说明初始分流存在问题,会导致错误的路由和延误。
获取方式
从 'Incident' 实体的审核历史记录中捕获,特别是通过追踪 'subjectid' 字段或其他自定义分类字段的变更。
捕获
从审核日志中提取 'subjectid' 字段带时间戳的变更记录。
事件类型
explicit
|
|||
|
案例重新激活
|
发生在之前已解决的案例被自动或手动重新开启时(通常由于客户回复或反馈问题未解决)。这是系统标准行为,会将案例状态从“已解决”恢复为“活动中”。 | ||
|
为何重要
此活动对于识别返工和分析“首次解决率 (FCR)”至关重要。大量的重新激活意味着初始解决方案不完整或无效。
获取方式
通过 'Incident' 实体上 'statecode' 字段从“已解决”(1) 变回“活动”(0) 来捕获。该变更的时间戳记录在审核历史记录中。
捕获
在审计日志中追踪“statecode”从“已解决”变回“活动”的时间戳。
事件类型
explicit
|
|||
|
满意度调查已发送
|
标记客户满意度调查的发送。通常在案例解决后自动触发,并作为外发电子邮件或 Customer Voice 调查活动被系统捕获。 | ||
|
为何重要
此活动将运营流程与客户体验结果联系起来。它支持根据案例所经历的流程路径来分析满意度得分。
获取方式
通过创建包含调查链接的外发“电子邮件”活动,或通过与案例相关的“Customer Voice 调查邀请”活动记录来推断。
捕获
使用调查相关活动记录的创建时间戳。
事件类型
inferred
|
|||