您的客户服务数据模板
您的客户服务数据模板
- 建议收集的属性
- 需要跟踪的关键活动
- 提取指南
客户服务属性
| 名称 | 说明 | ||
|---|---|---|---|
|
服务请求
ServiceRequest
|
客户服务Case或工单的唯一标识符,用于关联所有相关活动。 | ||
|
说明
Service Request通常也称为Ticket或Case,是主要标识符,用于关联与单个客户咨询或问题相关的所有活动。在Salesforce Service Cloud中,它对应Case Number。 此属性对于重建每次客户互动的端到端历程至关重要。它允许流程挖掘工具将“Case Created”“Agent Investigates Issue”和“Case Resolved”等所有相关事件归入同一个流程实例,从开始到结束实现整体分析。
为什么重要
它是流程挖掘的基础构件,将属于同一客户问题的所有事件连接成一个完整的流程实例。
获取位置
SalesforceCase对象,字段:CaseNumber
示例
000010240000105800001193
|
|||
|
事件时间
EventTime
|
表示活动发生时间的精确时间戳。 | ||
|
说明
Event Time记录特定活动在系统中的发生日期和时间,为整个流程提供时间背景,从而支持计算持续时间、等待时间和周期时间。 在分析中,该时间戳用于按时间顺序排列每个Service Request的事件,是流程发现的基础。它对于性能类KPI至关重要,例如衡量“Case Created”到“Initial Acknowledgment Sent”之间的时间,或计算总解决时间。
为什么重要
此时间戳对于了解流程时间线、计算性能指标和识别活动之间的延迟至关重要。
获取位置
根据与具体事件对应的各种日期字段推导,例如Case对象中的CreatedDate,或CaseHistory记录中的CreatedDate。
示例
2023-04-15T10:00:00Z2023-04-15T11:23:14Z2023-04-16T09:05:30Z
|
|||
|
最后更新时间
LastDataUpdateTime
|
表示该流程数据最近一次刷新的时间戳。 | ||
|
说明
此属性记录源系统最近一次数据提取或更新的时间戳。它是适用于整个数据集而非单个事件的元数据字段。 它主要用于告知用户当前分析数据的新鲜度。这对于确保洞察和决策基于当前且相关的信息至关重要,也有助于管理用户对数据时效性的预期。
为什么重要
它确保数据新鲜度透明可见,让用户了解分析所依据的数据有多新。
获取位置
通常在数据提取、转换和加载(ETL)过程中生成并存储。
示例
2023-10-27T04:00:00Z
|
|||
|
活动名称
ActivityName
|
客户服务流程中发生的特定业务事件或步骤的名称。 | ||
|
说明
该属性描述服务请求生命周期中的单个步骤或里程碑。活动是流程图中的节点,代表坐席、自动化系统或客户执行的操作。 分析“案例已创建”“已触发内部升级”和“案例已关闭”等活动的顺序和频率,是流程挖掘的核心工作。通过分析,您可以发现实际顺序流、识别瓶颈,并发现偏离标准操作规程的情况。
为什么重要
活动定义流程步骤,其顺序构成流程图及后续所有分析的基础。
获取位置
通常由多个字段共同推导,例如Case对象中的状态变化(Status字段),或CaseHistory、EmailMessage对象中的记录。
示例
Case已创建Case已分配给客服已向客户提出解决方案Case已关闭
|
|||
|
源系统
SourceSystemName
|
流程数据的来源系统。 | ||
|
说明
此属性标识生成数据的源应用,在此场景中为Salesforce Service Cloud。在整合多个系统的数据以获得完整流程视图的环境中,它尤其有用。 即使只分析单个系统,此属性也能提供有关数据来源的重要背景。它有助于数据治理、问题排查,并确保分析基于正确的数据集。
为什么重要
它提供有关数据来源的重要背景,对于数据治理以及可能整合多个系统数据的分析至关重要。
获取位置
通常在数据提取和转换过程中添加静态值,用于标记数据集来源。
示例
Salesforce Service CloudSFSC
|
|||
|
Case优先级
CasePriority
|
分配给服务请求的优先级,例如High、Medium或Low。 | ||
|
说明
Case Priority是用于确定服务请求紧急程度的标准分类。根据Service Level Agreement(SLA),该标记通常决定目标响应时间和解决时间。 基于优先级分析流程表现,对于评估优先级策略的有效性至关重要。它有助于判断高优先级案件是否确实得到更快解决并达到严格的SLA目标,直接支持Case Prioritization and Impact仪表板。
为什么重要
它支持分析流程是否有效优先处理紧急案件,并根据案件重要性满足不同服务级别。
获取位置
SalesforceCase对象,字段:Priority
示例
高中低
|
|||
|
Case状态
CaseStatus
|
服务请求在生命周期中的当前状态,例如New、In Progress或Closed。 | ||
|
说明
Case Status表示服务请求的当前状态。状态变化通常是识别流程活动的主要来源。例如,从“New”变为“Working”可以映射为“Agent Investigates Issue”活动。 分析Case的最终状态有助于了解解决结果,也可用于筛选打开或关闭的Case,并识别可能在某一状态停留过久的案件。
为什么重要
它提供有关Case当前状态和结果的洞察,状态变化也常用于推导活动顺序。
获取位置
SalesforceCase对象,字段:Status
示例
新建处理中等待客户已关闭
|
|||
|
Case类型
CaseType
|
服务请求的分类,例如Question、Problem或Feature Request。 | ||
|
说明
Case Type是用于分类客户咨询或问题性质的类别属性。它支持对服务请求进行细分,了解不同类型问题的处理方式。 基于Case Type分析流程,可能发现某些请求类型遵循不同路径、解决时间更长或需要更多交接。这些洞察有助于针对特定工作类别定制并改进流程。
为什么重要
它支持细分流程,了解不同类型请求是否采用不同处理方式,并识别需要专项改进的环节。
获取位置
SalesforceCase对象,字段:Type
示例
故障功能请求问题
|
|||
|
SLA状态
SlaStatus
|
表示Case是否在SLA目标时间内解决。 | ||
|
说明
此属性根据每个已解决Case是否遵守既定Service Level Agreement进行分类。计算方式是将实际解决时间戳与“SLA Target Resolution Time”进行比较。 作为SLA Adherence Rate KPI的直接输入,此属性简化了绩效监控。您可以快速筛选和分析所有不合规的Case,识别SLA违约的常见根因,例如特定Case类型、产品或流程瓶颈。
为什么重要
按Case提供清晰的二元SLA合规结果,是绩效监控和延迟根因分析的基础。
获取位置
在数据转换层中,将“Case Resolved”时间戳与“SlaTargetResolutionTime”属性进行比较后计算。
示例
已满足已违反
|
|||
|
SLA目标解决时间
SlaTargetResolutionTime
|
根据SLA,服务请求应完成解决的目标日期和时间。 | ||
|
说明
此属性定义解决Case的服务级别协议(SLA)截止时间。通常根据Case优先级、类型和客户级别等因素确定。Salesforce可以通过entitlement和milestone功能自动计算该时间。 此时间戳对于衡量SLA遵循情况至关重要。通过比较实际解决时间与目标时间,组织可以计算SLA遵循率KPI,并识别有SLA违约风险的案件,直接支持Case SLA Adherence仪表板。
为什么重要
它提供衡量实际表现的基准,对于计算SLA合规率和识别风险案件至关重要。
获取位置
该信息通常存储在Case Milestone对象的SlaExitDate字段中,该对象属于Salesforce的Entitlement Management功能。
示例
2023-04-16T17:00:00Z2023-04-18T09:00:00Z2023-05-01T12:00:00Z
|
|||
|
已分配客服
AssignedAgent
|
当前负责处理服务请求的用户或队列。 | ||
|
说明
此属性标识在特定时间点负责处理服务请求的客服个人或团队。在Salesforce中,通常对应Case Owner。 跟踪此属性的变化,是分析客服表现、工作量分配和交接情况的基础。它有助于回答以下问题:Case被重新分配了多少次?哪些客服处理最复杂的案件?团队工作量是否均衡?这是Agent Handoffs和Workload Distribution仪表板的关键属性。
为什么重要
它对于分析客服工作量、表现和交接频率至关重要,而这些因素会直接影响效率和解决时间。
获取位置
SalesforceCase对象,字段:OwnerId。此字段包含User或Queue的ID。
示例
Sarah JonesDavid Chen二级支持队列
|
|||
|
是否首次联系解决
IsFirstContactResolution
|
用于标识Case是否在首次与客户互动时解决的标记。 | ||
|
说明
此布尔属性用于识别无需客户首次联系后跟进即可解决的服务请求。判定逻辑通常需要分析活动的顺序和时间。 较高的首次联系解决率(FCR)是客户服务流程高效且有效的重要信号。此计算属性是First Contact Resolution Rate KPI的基础。分析首次联系未解决的Case,可以发现改进客服培训、知识库内容和流程设计的机会。
为什么重要
直接衡量服务效率和客户满意度的关键方面,帮助识别高效解决问题的驱动因素。
获取位置
在数据转换期间,通过分析指定Case的事件日志计算。常见规则是检查“Case Resolved”是否早于任何“Information Requested From Customer”或后续客户联系活动。
示例
truefalse
|
|||
|
沟通渠道
CommunicationChannel
|
发起服务请求的渠道,例如电子邮件、电话或网页。 | ||
|
说明
此属性指定客户提交服务请求所使用的沟通方式。在Salesforce中,通常记录在Case Origin字段中。 了解沟通渠道是优化资源配置和提升服务效率的关键。通过按渠道分析解决时间和流程路径,组织可以识别不同问题类型最适合的渠道,从而支持Communication Channel Efficiency仪表板。
为什么重要
它支持比较不同客户联系渠道的表现,帮助优化渠道策略和资源配置。
获取位置
SalesforceCase对象,字段:Origin
示例
电子邮件电话Web聊天
|
|||
|
结束时间
EndTime
|
表示活动完成时间的时间戳。 | ||
|
说明
End Time表示活动完成的时间。与Start Time结合后,可以精确计算活动处理时间。在Salesforce中,许多事件是瞬时发生的,因此Start Time和End Time相同。 但对于持续时间较长的活动,单独记录End Time对于准确衡量任务耗时至关重要。它直接支持性能分析,帮助区分主动处理时间和步骤之间的空闲等待时间。
为什么重要
它支持计算活动的实际持续时间,对于分析客服表现和识别耗时步骤至关重要。
获取位置
对于瞬时事件,它通常与StartTime相同。对于具有持续时间的活动,必须从表示完成时间的特定字段获取,可能需要自定义配置。
示例
2023-04-15T10:00:00Z2023-04-15T11:55:00Z2023-04-16T14:20:00Z
|
|||
|
Case主题
CaseSubject
|
对客户问题或请求的简要概述或标题。 | ||
|
说明
Case主题提供了对服务请求的简洁自由文本概述,通常是电子邮件主题,或由客服人员或客户填写的标题。 虽然主题不是可直接用于流程分析的结构化字段,但其中包含丰富的上下文信息。结合文本挖掘技术,您可以对Case进行分类、识别新出现的问题,或为定量流程分析补充定性背景。
为什么重要
快速提供Case的高层背景信息,便于下钻分析,也可用于文本挖掘。
获取位置
Salesforce Case对象,字段:Subject
示例
无法登录门户关于账单的疑问报表仪表板功能请求
|
|||
|
客户名称
CustomerName
|
与服务请求关联的客户或账户名称。 | ||
|
说明
此属性用于标识发起服务请求的客户。在Salesforce中,该客户可能是Contact(个人)或Account(公司)。 从客户视角分析流程,可以获得有价值的洞察。例如,您可以识别哪些客户遇到的问题更多,或解决时间更长。这些信息有助于制定客户关系管理策略,并发现主动支持的机会。
为什么重要
支持以客户为中心进行分析,帮助识别特定客户或客户群体的模式和绩效差异。
获取位置
Salesforce Case对象,字段:ContactId或AccountId,分别关联Contact和Account对象。
示例
Global Tech Inc.Emily WhiteInnovate Solutions
|
|||
|
客服转交次数
AgentHandoffCount
|
Case从一名客服人员或队列重新分配给另一名客服人员或队列的次数。 | ||
|
说明
此指标量化服务请求在解决前经历的重新分配次数。计算方式是在单个Case的生命周期内,统计“AssignedAgent”属性发生的不同变更次数。 此属性是Average Agent Handoffs per Case KPI的基础,并显示在Agent Handoffs and Rework Patterns仪表板中。转交次数较多通常意味着流程效率低、责任归属不清或知识存在缺口,进而导致解决时间延长和客户不满。
为什么重要
量化流程中的内部摩擦,因为过多转交是造成延迟和客户不满的常见原因。
获取位置
在数据转换期间按Case粒度计算:统计每个“ServiceRequest”的“AssignedAgent”字段唯一值数量,再减一。
示例
0135
|
|||
|
是否已升级
IsEscalated
|
用于标识Case是否已升级的标记。 | ||
|
说明
此布尔属性用于标识服务请求是否经历过升级。在Salesforce中,可以通过标准IsEscalated字段进行跟踪,该字段会根据Escalation Rules自动设置。 此标记是Internal Escalation Analysis仪表板和Internal Escalation Rate KPI的直接输入。它支持快速筛选和汇总所有已升级的Case,帮助量化升级频率,并分析其对整体解决时间和流程复杂度的影响。
为什么重要
直接衡量Case升级情况,这是反映流程摩擦、复杂度或客服知识缺口的重要指标。
获取位置
Salesforce Case对象,字段:IsEscalated
示例
truefalse
|
|||
|
是否返工
IsRework
|
用于标识Case是否涉及返工或回到之前阶段的标记。 | ||
|
说明
此布尔属性用于标记存在返工模式的Case,例如关闭后重新打开,或在“Agent Investigates”和“Solution Proposed”之间反复循环。识别返工需要分析活动顺序,以发现不理想的循环。 此属性直接支持Rework Rate KPI以及Agent Handoffs and Rework Patterns仪表板。定位存在返工的Case后,分析人员可以调查根因,例如解决方案不足或信息收集不完整,并采取纠正措施。
为什么重要
突出显示流程低效和资源浪费,支持针对频繁重复活动开展分析。
获取位置
在数据转换期间通过分析活动序列计算。例如,同一Case中出现“Case Closed”→“Case Reopened”或“Solution Proposed”→“Agent Investigates Issue”的序列,即标记为返工。
示例
truefalse
|
|||
|
涉及的产品
ProductInvolved
|
客户请求所涉及的具体产品或服务。 | ||
|
说明
此属性将服务请求关联到具体产品或服务。在Salesforce中,通常通过查找Product对象进行管理。 按产品细分流程数据对于产品质量分析至关重要。它可以帮助识别哪些产品产生的支持请求最多、存在哪些问题,以及不同产品线的解决流程是否存在差异。这些信息是产品开发团队的重要反馈。
为什么重要
支持基于产品的流程分析,帮助发现特定产品的质量问题或支持缺口。
获取位置
Salesforce Case对象,字段:ProductId。这是一个标准但可选的查找字段。
示例
Alpha CRM SuiteBeta Analytics ToolGamma Data Connector
|
|||
客户服务活动
| 活动 | 说明 | ||
|---|---|---|---|
|
Case已关闭
|
此活动表示服务请求生命周期最终且确定的结束。Case关闭后,除非重新打开,否则不应再进行后续处理。 | ||
|
为什么重要
作为终止事件,此活动为计算Case完整持续时间提供最终终点。“Resolved”到“Closed”之间的时间也可以揭示关闭流程中的低效环节。
获取位置
根据Case对象IsClosed字段变为true的时间戳推断。ClosedDate字段也会在此时填充。
采集
IsClosed字段变为true并记录在CaseHistory中的时间戳。
事件类型
inferred
|
|||
|
Case已分配给客服
|
标志着服务请求被分配给特定客服或队列处理的时点。这是流程中的基础步骤,通过Case所有者字段的变化捕获。 | ||
|
为什么重要
此活动对于跟踪客服工作量、分配延迟和交接频率至关重要,也是分析客服表现和识别分配流程瓶颈的基础。
获取位置
根据Case对象OwnerId字段的变化推断。该变化的时间戳记录在CaseHistory对象中。
采集
识别OwnerId字段首次更新的时间戳。
事件类型
inferred
|
|||
|
Case已创建
|
当新的服务请求或Case在Salesforce中登记时,此活动标志着客户服务流程正式开始。系统会在Case对象创建新记录时明确捕获该事件,并记录精确时间戳。 | ||
|
为什么重要
作为主要的开始事件,此活动对于计算Case的完整生命周期和解决时间至关重要。它为衡量SLA表现和了解案件量提供基准。
获取位置
此事件对应Case对象的记录创建事件。时间戳记录在标准CreatedDate字段中。
采集
直接取自Case记录的创建时间戳。
事件类型
explicit
|
|||
|
Case已解决
|
此关键里程碑表示客服已完成解决客户问题所需的工作。Case现等待最终关闭,经过一段时间后可能自动关闭。 | ||
|
为什么重要
这是衡量解决时间的主要终点,也是计算SLA遵循情况的关键。它标志着Case主动处理阶段结束。
获取位置
当CaseHistory对象中的Status字段变为“Resolved”时推断。此时IsClosed字段可能仍为false。
采集
CaseStatus变为“Resolved”的时间戳。
事件类型
inferred
|
|||
|
SLA里程碑已违反
|
当首次响应或解决时间等服务承诺未达成时,此事件会被触发。Salesforce通过entitlement流程和里程碑记录跟踪此事件。 | ||
|
为什么重要
此活动对于SLA遵循分析和合规监控至关重要。它直接标示未达到客户期望的案件,支持有针对性的流程改进。
获取位置
从CaseMilestone对象中获取。当里程碑记录的IsViolated字段被设为true时生成事件。
采集
事件时间是CaseMilestone记录中IsViolated标记变为true的时间戳。
事件类型
explicit
|
|||
|
已触发内部升级
|
当Case需要更高级别的支持或专业知识并被正式升级时,此活动发生。它可以由Salesforce升级规则明确捕获,也可以根据字段变化推断。 | ||
|
为什么重要
分析升级情况有助于识别复杂案件类型、一线客服的培训需求和系统性问题。这是衡量流程摩擦及其对解决时间影响的重要指标。
获取位置
可以从CaseEscalation记录中明确获取。更常见的方式是根据CaseHistory推断,例如复选框字段“IsEscalated”被设为true。
采集
“IsEscalated”字段变为true的时间戳。
事件类型
inferred
|
|||
|
Case已分类并确定优先级
|
当Case被标记类型、类别和优先级时,此活动发生。通常由分诊团队或自动化规则完成,并根据相关Case字段的变化推断。 | ||
|
为什么重要
分类是了解案件分布和路由效果的关键。分析此步骤有助于优化工作量分配,确保高优先级案件得到及时处理。
获取位置
根据CaseHistory对象推断,跟踪Priority、Type或其他分类字段首次被填充,或从默认值发生变化的时间。
采集
跟踪CaseHistory中Priority或Type等字段的更新。
事件类型
inferred
|
|||
|
Case已重新分配
|
表示Case在首次分配后从一名客服或一个队列转交给另一名客服或另一个队列。根据后续Case所有者字段的变化推断。 | ||
|
为什么重要
频繁重新分配可能表明初始路由不准确、流程效率低下或知识存在缺口,进而导致延迟和糟糕的客户体验。此活动有助于量化客服交接。
获取位置
根据首次分配后CaseHistory对象中OwnerId字段的任何变化推断。
采集
识别首次更新之后OwnerId字段的所有更新。
事件类型
inferred
|
|||
|
Case已重新打开
|
当之前已解决或关闭的Case因问题再次出现或解决方案无效而重新激活时发生。这是返工的重要指标。 | ||
|
为什么重要
重新打开的Case通常表明解决质量较低或首次联系解决失败。分析其频率和根本原因,对于提升服务质量至关重要。
获取位置
当CaseHistory对象中的IsClosed字段从true变为false,或Status从关闭或已解决状态恢复为打开状态时推断。
采集
Status或IsClosed字段从终止状态变为活动状态的时间戳。
事件类型
inferred
|
|||
|
客服开始调查问题
|
表示客服主动诊断并了解客户问题的阶段。这不是一个明确记录的事件,而是根据Case状态从新建或打开变为处理中来推断。 | ||
|
为什么重要
了解调查阶段的持续时间,有助于识别服务请求中的复杂问题,以及客服可能需要更多培训或资源支持的环节。它可以区分主动处理时间和等待时间。
获取位置
当CaseHistory对象中的Status字段更新为表示主动处理的值,例如“In Progress”或“Working”时推断。
采集
CaseStatus变更为“处理中”状态的时间戳。
事件类型
inferred
|
|||
|
已发送初次确认
|
表示发送给客户的首次沟通消息,用于确认已收到其服务请求。通常,这是由Case创建规则触发的自动邮件,通过识别首条出站通信推断得出。 | ||
|
为什么重要
跟踪此活动对于衡量初次响应时间并确保及时告知客户至关重要。它有助于分析“Initial Acknowledgment Latency”KPI,改善客户沟通。
获取位置
根据与Case关联的首条出站EmailMessage记录的时间戳推断。也可以根据自动化规则触发的自定义字段更新推断。
采集
识别与Case关联的首条出站EmailMessage时间戳。
事件类型
inferred
|
|||
|
已发送满意度调查
|
表示发送客户满意度(CSAT)或净推荐值(NPS)调查。通常在Case解决或关闭后自动执行。 | ||
|
为什么重要
虽然不属于核心解决流程,但此活动对于了解反馈闭环十分重要。分析其时间和频率,有助于持续收集客户声音。
获取位置
根据与Case关联且匹配调查模板的出站EmailMessage记录推断。也可以根据创建SurveyInvitation记录来捕获。
采集
识别出站调查邮件或SurveyInvitation记录的创建。
事件类型
inferred
|
|||
|
已向客户提出解决方案
|
表示客服向客户提供潜在解决方案的时点。这是一个概念性步骤,通常根据出站通信或特定状态变化推断。 | ||
|
为什么重要
跟踪此里程碑有助于衡量从调查到提出解决方案所需的时间。如果客户不接受该方案,它也可能标志着确认循环的开始。
获取位置
根据包含特定关键词的出站EmailMessage,或CaseHistory对象中状态变为“Solution Provided”来推断。
采集
状态变更或出站通信事件的时间戳。
事件类型
inferred
|
|||
|
已向客户请求信息
|
当客服需要客户提供更多信息才能继续处理Case时,此活动发生。通常根据Case状态变为“等待客户”来推断。 | ||
|
为什么重要
此活动标志着等待时间开始,而等待不受客服控制。单独识别这段时间,对于准确衡量内部流程效率和客服表现至关重要。
获取位置
当CaseHistory对象中的Status字段更新为“Waiting on Customer Response”或“Pending”等值时推断。
采集
CaseStatus变更为“等待”状态的时间戳。
事件类型
inferred
|
|||
|
已收到客户提供的信息
|
当客户提供所需信息时,此活动标志着客户等待时间结束。通常根据收到入站通信后Case状态恢复为活动状态来推断。 | ||
|
为什么重要
跟踪此事件对于了解客户响应时间及其对Case完整生命周期的影响至关重要。它表示客服恢复主动处理。
获取位置
根据与Case关联的入站EmailMessage时间戳推断,或根据CaseHistory对象中状态从“Waiting on Customer”变回“In Progress”来推断。
采集
入站邮件或状态从“等待”变更的时间戳。
事件类型
inferred
|
|||
提取指南
立即释放客户服务效率
实现80%的首次联系解决率,提升CSAT评分。
无需信用卡