客户服务数据模板
客户服务数据模板
- 建议收集的属性
- 需要跟踪的关键活动
- Microsoft Dynamics 365客户服务数据提取指南
客户服务属性
| 名称 | 说明 | ||
|---|---|---|---|
|
服务请求
ServiceRequest
|
客户服务请求的唯一标识,也称为案例或工单。 | ||
|
说明
服务请求是主要标识符,用于关联与单个客户咨询或问题相关的所有活动。在流程挖掘中,它充当案例ID,确保从创建到关闭的每次客户互动都有完整、一致的视图。按服务请求分析,可追踪端到端处理过程、衡量解决时长,并发现类似案例的规律。
重要性
这是关键的案例ID,可将所有相关事件关联到同一个流程实例,从而支持端到端流程分析。
获取途径
这是Microsoft Dynamics 365 Customer Service中Case(incident)实体的主键。
示例
CAS-01024-F3B4V6SR-2023-00589TKT-4815162342
|
|||
|
上次数据更新
LastDataUpdate
|
上次从源系统刷新或提取数据的时间戳。 | ||
|
说明
此属性表示上次从Microsoft Dynamics 365提取数据的时间,有助于了解所分析数据的新鲜度,也是报告和监控的必要信息。用户查看仪表板和分析结果时,可据此判断数据的时效性。
重要性
让用户了解数据的更新时间,这对于依据流程分析及时、准确地制定业务决策至关重要。
获取途径
此值在提取数据时生成并写入数据集。
示例
2023-10-27T08:00:00Z
|
|||
|
开始时间
EventTime
|
表示活动发生时间的时间戳。 | ||
|
说明
此属性记录特定活动发生的准确日期和时间,对于正确排列事件顺序以及开展所有基于时间的分析至关重要,包括计算周期时间、持续时间和活动间的等待时间。时间戳准确且一致,是确保流程挖掘分析可靠的关键。
重要性
此时间戳可按时间顺序排列事件,并支持所有基于时长的计算,这些计算对于绩效分析和发现瓶颈至关重要。
获取途径
对应于Case(incident)实体或相关活动实体(例如Email、Task、Phone Call)中的“createdon”或“modifiedon”等字段。
示例
2023-04-15T10:00:00Z2023-05-20T14:35:10Z2023-06-01T09:12:45Z
|
|||
|
活动
ActivityName
|
服务请求在某个时间点发生的具体业务事件名称。 | ||
|
说明
此属性描述客户服务流程中的单个步骤或状态变更,例如“创建案例”“客服人员调查问题”或“解决案例”。这些活动构成流程图的基础,可用于展示和分析流程。每项活动与时间戳结合后,便形成定义流程顺序的事件。
重要性
活动定义了流程中的各个步骤。分析活动的顺序和频率,是了解流程、发现偏差和识别瓶颈的基础。
获取途径
通常通过将状态变更(statuscode)或相关实体(如Task、Email或Phone Call)中的特定事件映射为标准化活动名称来得出。
示例
创建案例客服人员调查问题向客户提出解决方案关闭案例
|
|||
|
源系统
SourceSystem
|
标识提取数据的源系统。 | ||
|
说明
此属性指定事件数据的来源。对于此流程,该属性始终标识Microsoft Dynamics 365 Customer Service为数据源。在包含多个系统的环境中,此字段对于区分数据来源和确保数据沿袭至关重要。
重要性
清晰呈现数据沿袭,这对于数据治理和排查数据不一致问题至关重要,尤其是在分析来自多个系统的数据时。
获取途径
通常在数据提取和转换过程中添加静态值,用于标记数据集的来源。
示例
Microsoft Dynamics 365客户服务
|
|||
|
SLA目标解决时间
SlaTargetResolutionTime
|
合同约定的服务请求解决时限。 | ||
|
说明
此属性指定有效服务级别协议(SLA)要求的服务请求解决时限,是衡量实际绩效的基准。此值对于SLA达成情况监控仪表板和计算SLA达成率KPI至关重要,可帮助发现流程未能履行服务承诺的环节。
重要性
这是衡量服务绩效是否达到承诺的主要基准,可直接用于分析SLA达成情况和违约情况。
获取途径
此值由Dynamics 365中的SLA配置确定,并通过SLA KPI Instances与案例关联。
示例
2592008640014400
|
|||
|
优先级
Priority
|
分配给服务请求的优先级,用于表示其紧急程度。 | ||
|
说明
此属性定义服务请求的紧急程度,通常分为低、普通、高或紧急。优先级用于确定案例的处理顺序,通常也决定SLA目标。分析优先级对流程、资源分配和解决时长的影响,是确保紧急问题得到及时处理的关键。
重要性
有助于了解高优先级请求是否处理得更快并达到目标,以及优先级如何影响整体流程绩效。
获取途径
对应于Case(incident)实体中的“Priority”(prioritycode)字段。
示例
低普通高
|
|||
|
客户名称
CustomerName
|
与服务请求关联的客户或账户名称。 | ||
|
说明
此属性用于识别发起服务请求的客户。以客户为中心分析流程,有助于了解哪些客户提交的请求最多、解决时间最长,或问题最复杂。这对于管理客户关系和改进面向特定客户的服务至关重要。
重要性
支持按客户分析,发现规律、改进重点客户服务,并了解客户旅程。
获取途径
这是Case(incident)实体中的“Customer”(customerid)查找字段,可指向Account或Contact记录。
示例
Global Tech Inc.Jane DoeInnovate Solutions
|
|||
|
客服人员姓名
AgentName
|
负责该活动的客服人员或用户的姓名。 | ||
|
说明
此属性用于识别执行活动的具体客服人员或系统用户,例如从队列中领取项目或解决案例的人员。它对于分析客服人员绩效、工作量分布和资源分配至关重要。按客服人员追踪活动,组织可以发现表现突出的人员、培训需求和工作量失衡问题。
重要性
支持分析个人和团队绩效、平衡工作量,并发现辅导机会,从而提升整体服务质量。
获取途径
对应于Case(incident)实体中的“Owner”(ownerid)字段,该字段关联到System User(systemuser)实体。
示例
Alice SmithBob Johnson系统
|
|||
|
服务请求类型
ServiceRequestType
|
服务请求的主要类别或分类。 | ||
|
说明
此属性根据服务请求的性质对其分类,例如“账单咨询”“技术支持”或“产品反馈”。按类型细分流程分析,有助于了解不同类型请求的处理方式。分析结果可能显示,某些类别的解决时间更长、升级率更高,或遵循不同的流程路径。
重要性
按类型细分流程,有助于发现特定类型的瓶颈、资源需求和改进机会,从而优化路由和处理策略。
获取途径
此信息通常存储在Case(incident)实体的“Subject”(subjectid)字段或自定义类别字段中。
示例
账单咨询技术支持产品反馈账户管理
|
|||
|
渠道
Channel
|
发起服务请求时使用的沟通渠道。 | ||
|
说明
此属性用于识别客户互动的来源,例如电话、电子邮件、Web门户或聊天。不同渠道的流程、客户预期和解决难度往往各不相同。按渠道分析流程,有助于优化相应工作流和资源分配。
重要性
帮助了解不同客户联系渠道对流程效率、解决时长和客户满意度的影响。
获取途径
对应于Case(incident)实体中的“Case Origin”(caseorigincode)字段。
示例
电话电子邮件Web聊天
|
|||
|
状态原因
StatusReason
|
提供服务请求当前状态的详细原因。 | ||
|
说明
案例可能处于“活跃”或“已解决”等概括性状态,而状态原因则提供更具体的信息,例如“已提供信息”或“问题已解决”。此属性对于了解案例在生命周期中的进展及其原因至关重要。例如,它可以区分成功解决的案例和客户取消的案例,这对于准确分析结果十分重要。
重要性
详细呈现案例结果及状态变更原因,从而更准确地分析解决路径和根本原因。
获取途径
对应于Case(incident)实体中的“Status Reason”(statuscode)字段。
示例
处理中暂停处理问题已解决已提供信息
|
|||
|
客户满意度评分
CustomerSatisfactionScore
|
客户在案例解决后提供的满意度评分。 | ||
|
说明
此属性记录客户满意度(CSAT)调查中的数值或类别评分,通常在服务请求关闭后收集。它直接反映客户对服务质量的评价。这些数据对于“客户满意度趋势”仪表板和“解决后平均CSAT评分”KPI至关重要,可将流程绩效与客户体验联系起来。
重要性
直接衡量客户满意度,帮助组织将流程表现与客户评价联系起来,并据此推动改进。
获取途径
此数据通常来自相关调查实体(如Customer Voice),并关联回Case(incident)实体。
示例
5341
|
|||
|
所属团队
OwnerTeam
|
当前负责该服务请求的团队。 | ||
|
说明
此属性用于识别负责服务请求的团队。请求可以由单个客服人员或团队(队列)负责。按团队分析对于了解团队绩效、不同支持层级或专业团队之间的工作量分布,以及发现团队间的流程差异至关重要。
重要性
支持在团队层面分析绩效,对于有效管理支持层级和专业团队至关重要。
获取途径
当Case(incident)实体的“负责人”(ownerid)字段指向Team记录而非System User时,此属性由该字段得出。
示例
一级支持账单部门技术专家团队
|
|||
|
是否已升级
IsEscalated
|
用于标记服务请求是否已升级的标志。 | ||
|
说明
此布尔属性用于标记服务请求是否经过升级。当一线支持无法解决问题,需要更高级别的团队或专家介入时,就会发生升级。跟踪此标志对于“内部升级路径”仪表板和“内部升级率”KPI至关重要,有助于找出升级的根本原因以及初级支持层级的不足。
重要性
直接衡量升级频率,揭示首次联系解决方面的问题,并指出需要改进流程或客服人员技能的领域。
获取途径
对应Case(incident)实体中的“是否已升级”(isescalated)字段。
示例
truefalse
|
|||
|
是否返工
IsRework
|
用于标记案例是否包含返工活动的计算字段。 | ||
|
说明
此布尔标志用于识别包含返工循环或重复活动的案例,例如多次出现“向客户请求信息”事件,或解决后出现“案例重新激活”事件。系统通过分析活动顺序,识别表明效率低下或首次未能正确解决问题的模式并计算此属性。它是“返工与重复联系分析”仪表板的关键数据。
重要性
帮助量化并定位流程低效之处,让分析人员能够聚焦重复工作和资源浪费的根本原因。
获取途径
通过流程挖掘分析检测特定活动顺序(例如,已解决→重新激活)或案例中的重复活动来计算。
示例
truefalse
|
|||
|
是否违反SLA
IsSlaBreached
|
用于标记服务请求是否超出SLA目标的计算字段。 | ||
|
说明
此布尔标志通过比较服务请求的实际解决时间与“SLA目标解决时间”得出。实际用时超过目标时,标志设为true。此属性是“SLA合规监控”仪表板和“SLA达标率”KPI计算的基础,可清晰标记每个案例的SLA绩效是否达标。
重要性
清晰标记每个案例是否达到SLA要求,便于筛选、汇总和分析超时的根本原因。
获取途径
通过比较“ServiceRequestCycleTime”和“SlaTargetResolutionTime”计算得出。
示例
truefalse
|
|||
|
是否首次联系解决
IsFirstContactResolution
|
用于标记请求是否在首次联系时解决。 | ||
|
说明
此计算属性用于识别无需客户后续联系,且未因明显延误而重新分配客服人员便得到解决的服务请求。具体判定逻辑可能较复杂,通常会检查周期时间是否较短,以及首次互动后是否没有重新打开案例或客户再次咨询等活动。此属性是“首次联系解决率”KPI的基础。
重要性
这是衡量服务效率和客户满意度的关键指标,可反映问题能否快速、彻底地解决。
获取途径
根据每个案例事件日志中的活动顺序和时间计算得出。
示例
truefalse
|
|||
|
涉及的产品
ProductInvolved
|
与客户服务请求相关的产品。 | ||
|
说明
此属性用于识别客户问题涉及的具体产品或服务。按产品细分服务流程,有助于发现某些产品是否引发更多支持请求、问题是否更复杂,或是否需要客服人员具备专门技能。这些分析有助于改进产品和规划资源。
重要性
支持按产品分析流程,以发现反复出现的产品问题、完善支持文档并有效分配专家资源。
获取途径
对应Case(incident)实体中的“产品”(productid)查找字段。
示例
Alpha-100打印机Zeta CRM软件Omega数据套餐
|
|||
|
知识文章ID
KnowledgeArticleId
|
与服务请求关联的知识库文章标识符。 | ||
|
说明
此属性记录在解决服务请求期间使用或关联的知识文章ID,可直接衡量客服人员利用知识库解决客户问题的情况。这些数据对于“知识文章使用情况”仪表板及相应KPI至关重要,有助于评估知识库的价值和完整性。
重要性
跟踪知识库的使用情况,帮助了解客服人员是否利用现有资源更快、更一致地解决问题。
获取途径
此信息可在Case(incident)实体与Knowledge Article(knowledgearticle)实体之间的关系中找到。
示例
KA-01337KA-02048
|
|||
客户服务活动
| 活动 | 说明 | ||
|---|---|---|---|
|
SLA计时器启动
|
表示案例的服务级别协议(SLA)计时器已激活,开始根据“首次响应截止时间”或“解决截止时间”等服务指标计时。这是由Dynamics 365 SLA引擎管理的明确事件。 | ||
|
重要性
此活动是监控SLA达成情况、了解服务承诺从何时开始计时的基础,可直接用于分析服务目标是否达成。
获取途径
记录在与“Incident”实体关联的“SLA KPI Instance”实体中。相关SLA KPI Instance记录的“createdon”时间戳即为开始时间。
采集
使用与案例关联的“SLA KPI Instance”记录的创建时间戳。
事件类型
explicit
|
|||
|
关闭案例
|
这是对案例记录进行的最终管理性关闭,可能与问题解决同时发生,也可能稍后进行。案例状态变更为“已关闭”时会记录此活动。 | ||
|
重要性
这表示系统中流程生命周期的最终结束。“已解决”到“已关闭”之间的时长可能反映管理开销或完成记录归档的延误。
获取途径
通过“Incident”实体中“statecode”字段变更为“已取消”(2)或自定义关闭状态来记录。时间戳可在审计历史中查看。
采集
追踪“statecode”变更为最终结束状态(例如Canceled/Closed)时的时间戳。
事件类型
explicit
|
|||
|
分配案例
|
此活动表示将案例分配给特定队列或用户处理。系统会明确记录案例负责人的变更,并可通过系统审计日志进行追踪。 | ||
|
重要性
追踪分配情况对于分析工作量分布、发现分配环节的延误以及了解路由效率至关重要。借此可以了解案例多快能转到合适的团队或人员手中。
获取途径
通过追踪“Incident”实体中“ownerid”字段的变更来记录。变更时间戳可在审计历史日志中查看。
采集
从审计日志中提取带时间戳的“ownerid”字段变更记录。
事件类型
explicit
|
|||
|
创建案例
|
此活动标志着客户服务流程的开始,即系统中创建新的案例记录。该事件会被明确记录:首次保存“Incident”实体记录时,系统会记录具体时间戳。 | ||
|
重要性
作为主要开始事件,此活动对于计算案例的整体生命周期时长和了解案例量趋势至关重要,也是后续流程分析的基准。
获取途径
此事件取自每条新记录中“Incident”(案例)实体的“createdon”时间戳。
采集
使用Incident记录的“createdon”时间戳。
事件类型
explicit
|
|||
|
升级案例
|
表示将案例正式升级至更高级别的支持团队或其他团队。用户可通过明确操作,将案例重新分配给指定的升级队列或用户。 | ||
|
重要性
监控升级情况对于“内部升级率”这一KPI至关重要,也有助于找出一线支持无法解决问题的根本原因,从而发现流程薄弱环节和培训机会。
获取途径
可根据“ownerid”字段变更为指定的升级队列或团队来推断,也可通过将案例标记为已升级的自定义操作明确记录。
采集
识别“ownerid”变更为已知升级队列时的时间戳。
事件类型
inferred
|
|||
|
解决案例
|
这是一个关键里程碑,表示客服人员认为客户的问题已得到处理。这是Dynamics 365中的明确操作,会创建与案例关联的“Case Resolution”活动记录。 | ||
|
重要性
作为主要的成功结束事件,此活动对于计算解决时长和成功率至关重要,也是几乎所有客户服务KPI的重要组成部分。
获取途径
此事件对应于创建“Resolution”(Case Resolution)活动记录。该记录中的“actualend”时间戳即为问题解决时间。
采集
使用关联的“Resolution”活动记录中的“actualend”或“createdon”时间戳。
事件类型
explicit
|
|||
|
发送满意度调查
|
表示已向客户发送满意度调查,通常在案例解决后自动触发。一般通过外发邮件或Customer Voice调查活动记录此事件。 | ||
|
重要性
此活动将运营流程与客户体验结果联系起来,可结合案例经过的流程路径分析客户满意度评分。
获取途径
可根据包含调查链接的外发“Email”活动记录,或与案例关联的“Customer Voice survey invite”活动记录来推断。
采集
使用调查相关活动记录的创建时间戳。
事件类型
inferred
|
|||
|
向客户提出解决方案
|
此活动表示客服人员已制定解决方案并告知客户。通常可根据案例时间线中发出的邮件,或状态变更为“等待客户确认”来推断。 | ||
|
重要性
此里程碑标志着流程从调查转入解决。分析提出方案到客户确认之间的时长,有助于发现客户响应延迟或方案本身的问题。
获取途径
可根据与案例关联的外发“Email”活动记录的时间戳,或状态码变更为解决前状态来推断。
采集
使用外发邮件活动的时间戳,或状态变更为“已提出解决方案”时的时间戳。
事件类型
inferred
|
|||
|
向客户索取信息
|
当客服人员需要客户提供更多信息才能继续处理时,会出现此活动。通常可根据案例状态变为“等待”状态,或案例时间线中发出一封邮件来推断。 | ||
|
重要性
此活动对于衡量客户相关延误和了解“等待客户信息时间”这一KPI至关重要,有助于单独分析流程中等待外部信息的时长。
获取途径
可根据“Incident”实体中“statuscode”字段变更为“暂停处理”等值来推断,原因可能为“等待客户”。使用此状态变更的时间戳。
采集
追踪“statuscode”变更为指定“等待客户”状态时的时间戳。
事件类型
inferred
|
|||
|
客服人员调查问题
|
表示客服人员正在了解并诊断客户的问题。这是推断得出的活动,通常通过客服人员将知识文章关联到案例来识别,表明已进行相关调查。 | ||
|
重要性
追踪此活动有助于衡量知识资源的使用情况及其对解决时长的影响,并了解客服人员是否在利用现有工具高效解决问题。
获取途径
根据“IncidentKnowledgeBaseRecord”实体中新建的记录推断,该记录用于将知识文章关联到案例。使用此记录的创建时间戳。
采集
使用知识文章与Incident关联时的时间戳。
事件类型
inferred
|
|||
|
客服人员领取队列项目
|
客服人员主动从共享队列中领取案例并开始处理时,会触发此事件。这是用户主动执行的操作,与系统将案例分配到队列不同。 | ||
|
重要性
此活动有助于衡量案例在队列中等待客服人员开始处理的实际时长,是发现队列瓶颈和了解客服人员主动性的关键。
获取途径
当用户更新与案例关联的“QueueItem”实体中的“workedbyid”字段,或案例负责人从队列变更为用户时,系统会记录此事件。
采集
确定“QueueItem”中“workedbyid”字段被填入值时的时间戳。
事件类型
explicit
|
|||
|
更改案例分类
|
客服人员在案例创建后修改其类别或主题时,会触发此事件。系统会通过审计功能明确追踪此变更。 | ||
|
重要性
追踪重新分类情况对于“服务请求重新分类率”这一KPI至关重要。频繁重新分类可能表明初始分流存在问题,导致路由错误和延误。
获取途径
从“Incident”实体的审计历史中获取,具体追踪“subjectid”字段或其他自定义分类字段的变更。
采集
从审计日志中提取带时间戳的“subjectid”字段变更记录。
事件类型
explicit
|
|||
|
重新激活案例
|
已解决的案例被自动或手动重新打开时,会触发此活动。通常是因为客户回复,或表示问题尚未解决。这是系统的标准行为,会将案例状态从“已解决”改回“活跃”。 | ||
|
重要性
此活动对于发现返工和分析“首次联系解决率”至关重要。重新激活次数较多,可能表明初次提供的解决方案不完整或效果不佳。
获取途径
通过“Incident”实体中“statecode”字段从“已解决”(1)变回“活跃”(0)来记录。此变更的时间戳会保存在审计历史中。
采集
在审计日志中追踪“statecode”从Resolved变更为Active时的时间戳。
事件类型
explicit
|
|||
数据提取指南
优化客户服务:提升首次联系解决率,立即降低成本
识别瓶颈,将首次联系解决率提升至80%,让客户更满意。
无需信用卡,几分钟即可完成设置。