您的客户服务 data 模板
您的客户服务 data 模板
- 建议收集的属性
- 需要追踪的关键活动
- 提取指南
客户服务属性
| 名称 | 描述 | ||
|---|---|---|---|
|
服务请求
ServiceRequest
|
客户服务 case 或工单的唯一标识符,链接所有相关 activity。 | ||
|
描述
服务请求(通常称为工单或 Case)作为主要标识符,将与单个客户查询或问题相关的所有 activity 联系起来。在 Salesforce Service Cloud 中,这对应于 Case 编号。 此属性对于重建每次客户互动的端到端旅程至关重要。它允许 Process Mining 工具将所有相关 event(如“Case 已创建”、“客服人员调查问题”和“Case 已解决”)分组到单个流程实例中,从而实现从头到尾的整体分析。
为何重要
它是 Process Mining 的基础构建模块,因为它将属于同一客户问题的所有 event 连接成一个完整的流程实例。
获取方式
Salesforce Case 对象,字段:CaseNumber
示例
000010240000105800001193
|
|||
|
Event 时间
EventTime
|
指示 activity 发生时间的精确 timestamp。 | ||
|
描述
Event Time 捕获了系统中记录特定活动的日期和时间。它为整个流程提供了时间背景,从而允许计算持续时间、等待时间和周期时间。 在分析中,此 timestamp 用于按时间顺序为每个服务请求排列 event,构成了流程发现的基础。它对于绩效相关的 KPI 至关重要,例如衡量“Case 已创建”与“初始确认已发送”之间的时间,或计算总解决时间。
为何重要
此 timestamp 对于理解流程时间线、计算绩效指标以及识别 activity 间的延迟至关重要。
获取方式
派生自对应特定 event 的各种日期字段,如 Case 对象上的 CreatedDate 或 CaseHistory 记录上的 CreatedDate。
示例
2023-04-15T10:00:00Z2023-04-15T11:23:14Z2023-04-16T09:05:30Z
|
|||
|
最后数据更新
LastDataUpdateTime
|
指示此流程数据最后一次刷新的 timestamp。 | ||
|
描述
此属性记录从源系统进行最后一次 data 提取或更新的 timestamp。这是一个元数据字段,适用于整个数据集而非单个 event。 其主要用途是告知用户所分析 data 的新鲜度。这对于确保洞察和决策基于最新且相关的信息至关重要,并有助于管理对数据及时性的预期。
为何重要
它确保了 data 新鲜度的透明度,让用户了解当前分析的实时程度。
获取方式
此值通常在 data 提取、转换和加载 (ETL) 过程中生成并存储。
示例
2023-10-27T04:00:00Z
|
|||
|
活动名称
ActivityName
|
客户服务流程中发生的特定业务 event 或步骤的名称。 | ||
|
描述
此属性描述了服务请求生命周期中的单个步骤或里程碑。Activity 是流程图中的节点,代表客服人员、自动化系统或客户采取的操作。 分析“Case 已创建”、“触发内部升级”和“Case 已关闭”等 activity 的顺序和频率是 Process Mining 的核心。它有助于揭示实际流程,识别瓶颈,并发现偏离标准作业程序的情况。
为何重要
活动定义了流程的步骤,它们的顺序构成了流程图及所有后续分析的基础。
获取方式
通常由多个字段组合推导得出,例如 Case 对象的状态变更(Status 字段)或 CaseHistory、EmailMessage 对象中的记录。
示例
案件创建Case 已分配至代理已向客户建议解决方案案件已结案
|
|||
|
源系统
SourceSystemName
|
流程 data 来源的系统。 | ||
|
描述
此属性标识生成 data 的源应用程序,在本场景中为 Salesforce Service Cloud。在需要整合多个系统 data 以获得全景流程视图的环境中,它特别有用。 即使是分析单个系统,此属性也能提供关于 data 来源的关键背景信息。它有助于数据治理、故障排除,并确保分析基于正确的数据集。
为何重要
它提供了关于 data 来源的关键背景信息,这对于 data 治理以及整合多个系统 data 进行的分析至关重要。
获取方式
这通常是在 data 提取和 transformation 过程中添加的静态值,用于标记 dataset 的来源。
示例
Salesforce Service CloudSFSC
|
|||
|
Case 优先级
CasePriority
|
分配给服务请求的优先级,如高、中或低。 | ||
|
描述
Case 优先级是用于确定服务请求紧急程度的标准分类。这一指定通常根据服务级别协议 (SLA) 决定目标响应和解决时间。 基于优先级分析流程绩效对于评估优先级策略的有效性至关重要。它有助于确定高优先级 case 是否确实得到了更快解决并达到了其严格的 SLA 目标,从而直接为 Case 优先级与影响 dashboard 提供支持。
为何重要
它支持分析流程是否有效地优先处理紧急 case,并根据 case 的重要程度满足不同的服务水平。
获取方式
Salesforce Case 对象,字段:Priority
示例
高中低
|
|||
|
Case 解决时间
CaseResolutionTime
|
从 case 创建到解决所经过的总时间。 | ||
|
描述
此指标衡量服务请求的总时长,从“Case 已创建”到“Case 已解决”的 timestamp。它是任何客户服务流程最基本的 KPI 之一。 此计算属性直接支持平均 Case 解决时间 KPI,是“Case SLA 达成与解决”仪表板的核心指标。它提供了对整体流程效率和客户体验的清晰衡量。跨不同维度(如 case 类型或优先级)分析此指标有助于定位改进领域。
为何重要
这是衡量整体流程效率的主要 KPI,对于理解客户的端到端体验至关重要。
获取方式
在 data 转换期间,通过计算每个服务请求从“Case 已创建”活动到“Case 已解决”活动的 timestamp 之间的时间差来计算。
示例
25920000086400000604800000
|
|||
|
SLA 状态
SlaStatus
|
指示 case 是否在其 SLA 目标内解决。 | ||
|
描述
此属性根据已解决 case 对定义的服务水平协议 (SLA) 的遵守情况进行分类。通过比较实际解决 timestamp 与“SLA 目标解决时间”计算得出。 作为 SLA 达成率 KPI 的直接输入,此属性简化了绩效监控。它支持对所有违规 case 进行快速过滤和分析,以识别 SLA 违约的共同根源,例如特定 case 类型、产品或流程瓶颈。
为何重要
它为每个 case 的 SLA 合规性提供清晰的二元结果,这是进行绩效监控和延迟根因分析的基础。
获取方式
在 data 转换层中,通过将“Case 已解决”的 timestamp 与“SlaTargetResolutionTime”属性进行对比来计算。
示例
已达成已违反
|
|||
|
SLA 目标解决时间
SlaTargetResolutionTime
|
根据 SLA,服务请求应被解决的目标日期和时间。 | ||
|
描述
此属性定义了解决 case 的服务水平协议 (SLA) 截止日期。通常根据 case 优先级、类型和客户层级等因素确定。Salesforce 可以利用其权利和里程碑功能自动计算此项。 此 timestamp 对于衡量 SLA 达成情况至关重要。通过将实际解决时间与此目标进行对比,企业可以计算 SLA 达成率 KPI,并识别有 SLA 违约风险的 case,直接为“Case SLA 达成”仪表板提供支持。
为何重要
它提供了衡量实际绩效的基准,对于计算 SLA 合规性和识别有风险的 case 至关重要。
获取方式
这通常存储在 Case Milestone 对象的 SlaExitDate 字段中,该对象是 Salesforce 权利管理功能的一部分。
示例
2023-04-16T17:00:00Z2023-04-18T09:00:00Z2023-05-01T12:00:00Z
|
|||
|
指派处理人
AssignedAgent
|
当前分配了该服务请求的用户或队列。 | ||
|
描述
此属性标识在给定时间点负责处理服务请求的特定客服人员或团队。在 Salesforce 中,这通常是 Case 所有者。 追踪此属性的变更对于分析客服人员绩效、工作负载分配和交接至关重要。它有助于回答诸如 case 被重新分配了多少次、哪些客服处理最复杂的 case,以及团队间的工作负载是否平衡等问题。这是“客服人员交接和工作负载分配”仪表板的关键属性。
为何重要
这对于分析客服人员的工作负载、绩效以及交接频率至关重要,这些因素直接影响效率和解决时间。
获取方式
Salesforce Case 对象,字段:OwnerId。此字段包含用户或队列的 ID。
示例
Sarah Jones陈大卫二级支持队列
|
|||
|
是否为首次联系解决
IsFirstContactResolution
|
指示 case 是否在与客户的首次互动中解决的标记。 | ||
|
描述
此布尔属性标识在首次客户联系后无需任何后续跟进即可解决的服务请求。判定逻辑通常涉及分析 activity 的顺序和时间点。 高首次联系解决率 (FCR) 是高效客户服务流程的有力指标。此计算属性是 FCR 率 KPI 的基础。分析未在首次联系中解决的 case 可以发现改进客服人员培训、知识库内容和流程设计的机会。
为何重要
它直接衡量了服务效率和客户满意度的关键方面,有助于找出推动有效解决问题的核心因素。
获取方式
在 data 转换期间,通过分析特定 case 的 event log 进行计算。通用规则是检查“Case 已解决”是否发生在任何“向客户请求信息”或后续客户联系活动之前。
示例
truefalse
|
|||
|
案件状态
CaseStatus
|
服务请求在其生命周期中的当前状态,如新建、进行中或已关闭。 | ||
|
描述
Case 状态表示服务请求的当前处境。状态变更通常是识别流程中 activity 的主要来源,例如从“新建”变为“处理中”可以映射到“客服人员调查问题”这一 activity。 分析 case 的最终状态有助于了解解决结果。它还用于过滤开启或关闭的 case,并识别可能在特定状态停留过久的 case。
为何重要
它提供了关于 case 当前状态和结果的洞察,状态变更通常用于推导 activity 的顺序。
获取方式
Salesforce Case 对象,字段:Status
示例
新建处理中等待客户已结案
|
|||
|
案例类型
CaseType
|
服务请求的分类,如咨询、问题或功能需求。 | ||
|
描述
Case 类型是一个类别属性,有助于对客户咨询或问题的性质进行分类。这允许对服务请求进行细分,以了解不同类型的问题是如何处理的。 基于 Case 类型分析流程可以发现,某些类型的请求会遵循不同的路径,解决时间更长,或者需要更多的交接。这一洞察对于为特定工作类别定制和改进流程非常有价值。
为何重要
它支持流程细分,以了解不同类型的请求是否得到了差异化处理,并识别需要专门改进的领域。
获取方式
Salesforce Case 对象,字段:Type
示例
问题功能请求咨询
|
|||
|
沟通渠道
CommunicationChannel
|
发起服务请求的渠道,如邮件、电话或网页。 | ||
|
描述
此属性指定客户提交服务请求时使用的沟通方式。在 Salesforce 中,这通常记录在 Case Origin 字段中。 了解沟通渠道是优化资源分配和提高服务效率的关键。通过按渠道分析解决时间和流程,企业可以识别哪些渠道对处理不同类型的问题最有效,从而为“沟通渠道效率”仪表板提供支持。
为何重要
它支持对不同客户联系渠道的绩效进行比较,有助于优化渠道策略和资源配置。
获取方式
Salesforce Case 对象,字段:Origin
示例
电子邮件电话Web聊天
|
|||
|
结束时间
EndTime
|
指示活动完成时的时间戳。 | ||
|
描述
结束时间代表 activity 的完成时间。结合开始时间,可以精确计算 activity 处理时间。对于 Salesforce 中的许多 event 来说,动作是瞬间完成的,这意味着开始时间和结束时间相同。 然而,对于长时间运行的 activity,拥有明确的结束时间对于准确衡量任务耗时至关重要。它通过区分主动处理时间与步骤间的空闲等待时间,直接支持绩效分析。
为何重要
它支持计算 activity 的真实持续时间,这对于分析客服人员绩效和识别耗时步骤至关重要。
获取方式
对于瞬时 event,这通常与 StartTime 相同。对于具有持续时间的 activity,它必须来源于指示完成的特定字段,这可能需要自定义配置。
示例
2023-04-15T10:00:00Z2023-04-15T11:55:00Z2023-04-16T14:20:00Z
|
|||
|
Case 主题
CaseSubject
|
客户问题或请求的简要摘要或标题。 | ||
|
描述
Case 主题提供了服务请求的简明文字摘要。通常是邮件主题行或由客服人员及客户输入的标题。 虽然这不是用于直接流程分析的结构化字段,但主题行包含丰富的背景信息。它可以配合文本挖掘技术对 case 进行分类、识别新出现的问题,或为定量流程分析添加定性背景。
为何重要
它提供了关于 case 的快速、高层级背景信息,有助于下钻分析,并可用于文本挖掘。
获取方式
Salesforce Case 对象,字段:Subject
示例
无法登录门户关于账单明细的咨询报表 dashboard 的功能请求
|
|||
|
代理交接计数
AgentHandoffCount
|
case 从一个客服人员或队列重新分配到另一个的次数。 | ||
|
描述
此指标量化了服务请求在解决前经历的重新分配次数。通过计算单个 case 生命周期内“分配客服人员”属性的不同变更次数来得出。 此属性是“每 Case 平均客服人员交接次数”KPI 的基础,并在“客服人员交接和返工模式”仪表板中可视化。高交接次数通常预示着流程低效、权责不明或知识缺口,这些都会导致解决时间延长并引起客户不满。
为何重要
它量化了流程中的内部摩擦,因为过多的交接是导致延迟和客户不满的常见原因。
获取方式
在 data 转换期间,通过计算每个“ServiceRequest”中“AssignedAgent”字段的唯一值数量减 1,在 case 级别进行计算。
示例
0135
|
|||
|
客户名称
CustomerName
|
与服务请求关联的客户或账户名称。 | ||
|
描述
此属性标识发起服务请求的客户。在 Salesforce 中,这可以是联系人(个人)或账户(公司)。 从客户视角分析流程可以提供宝贵的洞察。例如,它可以帮助识别某些客户是否遇到更多问题或更长的解决时间。这可以为客户关系管理策略提供依据,并突出主动支持的机会。
为何重要
它支持以客户为中心的分析,有助于识别特定客户或客户群体的模式和绩效差异。
获取方式
Salesforce Case 对象,字段:ContactId 或 AccountId,分别链接到联系人和账户对象。
示例
Global Tech Inc.Emily White创新解决方案
|
|||
|
是否升级
IsEscalated
|
指示 case 是否已升级的标记。 | ||
|
描述
此布尔属性指示服务请求是否经历过升级。在 Salesforce 中,可以通过标准 IsEscalated 字段追踪,该字段根据升级规则自动设置。 此标志是“内部升级分析”仪表板和内部升级率 KPI 的直接输入。它支持对所有升级 case 进行便捷过滤和聚合,有助于量化其频率并分析其对整体解决时间和流程复杂度的影响。
为何重要
它直接衡量 case 升级情况,这是反映流程摩擦、复杂性或客服人员知识缺口的关键指标。
获取方式
Salesforce Case 对象,字段:IsEscalated
示例
truefalse
|
|||
|
是否返工
IsRework
|
指示 case 是否涉及返工或循环回前一阶段的标记。 | ||
|
描述
此布尔属性标记表现出返工模式的 case,例如关闭后重新开启,或在“客服人员调查”与“建议方案”之间反复循环。识别返工的逻辑需要分析 activity 序列中是否存在异常循环。 此属性直接支持返工率 KPI 以及“客服人员交接和返工模式”仪表板。精准定位存在返工的 case 让分析师能够调查根源(可能包括方案不当或信息采集不全),并采取纠正措施。
为何重要
它突出了流程效率低下和精力浪费的问题,从而可以对频繁重复的 activity 进行针对性分析。
获取方式
在 data 转换期间,通过分析活动序列进行计算。例如,同一 case 内出现如“Case 已关闭” -> “Case 已重新打开”或“方案已提出” -> “代理调查问题”之类的序列,则会被标记为返工。
示例
truefalse
|
|||
|
涉及产品
ProductInvolved
|
客户请求所涉及的具体产品或服务。 | ||
|
描述
此属性将服务请求链接到特定的产品或服务。在 Salesforce 中,这通常通过查找 Product 对象来管理。 按产品细分流程 data 对于产品质量分析至关重要。它有助于识别哪些产品产生的支持请求最多、存在什么样的问题,以及不同产品线的解决流程是否存在差异。这些信息对于产品开发团队来说是至关重要的反馈。
为何重要
它支持基于产品的流程分析,从而发现特定产品的质量问题或支持缺口。
获取方式
Salesforce Case 对象,字段:ProductId。这是一个标准但可选的查找字段。
示例
Alpha CRM SuiteBeta Analytics ToolGamma Data Connector
|
|||
客户服务活动
| 活动 | 描述 | ||
|---|---|---|---|
|
Case 已分配至代理
|
标记服务请求被分配给特定客服人员或队列进行处理的时间点。这是流程中的基本步骤,通过 case 所有者字段的变更来获取。 | ||
|
为何重要
此 activity 对于追踪客服人员工作负载、分配延迟和交接频率至关重要。它是分析客服人员绩效和识别分配流程瓶颈的基础。
获取方式
从 Case 对象上 OwnerId 字段的更改推断。该更改的 timestamp 记录在 CaseHistory 对象中。
捕获
识别 OwnerId 字段第一次更新的 timestamp。
事件类型
inferred
|
|||
|
内部升级已触发
|
当 case 需要更高级别的支持或专业知识并被正式升级时,发生此 activity。这可以通过 Salesforce 的升级规则显式捕获,或从字段变更中推断得出。 | ||
|
为何重要
分析升级情况有助于识别复杂的 case 类型、一线座席的培训需求以及系统性问题。它是衡量流程摩擦及其对解决时间影响的关键指标。
获取方式
这可以是来自 CaseEscalation 记录的显式 event。更常见的是,当像“IsEscalated”这样的复选框字段被设为 true 时,从 CaseHistory 中推断得出。
捕获
“IsEscalated”字段变为 true 的 timestamp。
事件类型
inferred
|
|||
|
案件创建
|
此 activity 标记客户服务流程的正式开始,即在 Salesforce 中记录新的服务请求或 case。当在 Case 对象中创建新记录时,会显式捕获此 event 及其精确 timestamp。 | ||
|
为何重要
作为首要的开始 event,此活动对于计算整体 case 生命周期和解决时间至关重要。它为衡量 SLA 绩效和了解 case 容量提供了基准。
获取方式
此 event 对应 Case 对象的记录创建 event。timestamp 记录在标准 CreatedDate 字段中。
捕获
直接取自 Case 记录的创建 timestamp。
事件类型
explicit
|
|||
|
案件已结案
|
此 activity 代表服务请求生命周期的最终结束。一旦 case 关闭,除非重新开启,否则不再进行后续工作。 | ||
|
为何重要
作为终结 event,此活动为计算完整的 case 时长提供了终点。‘已解决’和‘已关闭’之间的时间也可以揭示关闭流程中的低效环节。
获取方式
从 Case 对象上的 IsClosed 字段设为 true 时的 timestamp 推断。此时 ClosedDate 字段也会被填充。
捕获
IsClosed 字段变为 true 的 timestamp,记录在 CaseHistory 中。
事件类型
inferred
|
|||
|
案例已解决
|
这一关键里程碑意味着客服人员已完成解决客户问题所需的工作。该 case 现在等待最终关闭,一段时间后可能会自动执行。 | ||
|
为何重要
这是衡量解决时间的主要终点,对于计算 SLA 达成情况至关重要。它标志着对 case 主动处理的结束。
获取方式
当 Status 字段变更为“已解决”时,从 CaseHistory 对象中推断。此时 IsClosed 字段可能仍为 false。
捕获
Case 状态变更为“已解决”的 timestamp。
事件类型
inferred
|
|||
|
违反 SLA 里程碑
|
当未达成服务承诺(如首次响应或解决时间)时触发此 event。Salesforce 使用权利流程和里程碑记录追踪此项。 | ||
|
为何重要
此 activity 对于 SLA 遵守情况分析和合规性监控至关重要。它直接突出了未能满足客户预期的 case,从而实现针对性的流程改进。
获取方式
从 CaseMilestone 对象中捕获。当里程碑记录上的 IsViolated 字段设为 true 时,将生成一个 event。
捕获
Event 是指 CaseMilestone 记录上的 IsViolated 标记变为 true 时的 timestamp。
事件类型
explicit
|
|||
|
Case 已分类并排序优先级
|
当 case 被分类并指定类型、类别和优先级时发生此 activity。这通常由分流团队或自动化规则完成,并根据相关 case 字段的变更推断得出。 | ||
|
为何重要
分类是理解 case 分布和路由有效性的关键。分析这一步骤有助于优化工作量分配,并确保高优先级 case 得到及时处理。
获取方式
通过跟踪 Priority、Type 或其他分类字段首次填充或偏离默认值的 CaseHistory 对象记录来推断。
捕获
在 CaseHistory 中追踪 Priority 或 Type 等字段的更新。
事件类型
inferred
|
|||
|
Case 已重新分配
|
代表在初始分配后,case 从一名客服人员或队列转移到另一名。这是根据 case 所有者字段随后的变更推断出来的。 | ||
|
为何重要
频繁的重新分配可能表明初始路由错误、流程低效或知识缺口,从而导致延迟和糟糕的客户体验。此活动有助于量化座席交接。
获取方式
从初始分配后 CaseHistory 对象中 OwnerId 字段的任何更改推断。
捕获
识别第一次更新之后对 OwnerId 字段的所有更新。
事件类型
inferred
|
|||
|
代理调查问题
|
代表客服人员主动诊断和理解客户问题的阶段。这不是一个显式 event,而是当 case 状态从新建或打开状态变为进行中状态时推断出来的。 | ||
|
为何重要
了解调查阶段的持续时间有助于识别服务请求的复杂性,以及客服人员可能需要更多培训或资源的领域。它将主动处理时间与等待时间分离开来。
获取方式
当 Status 字段更新为表示正在处理的值(如“处理中”或“工作中”)时,从 CaseHistory 对象中推断。
捕获
Case 状态变更为“进行中”值的 timestamp。
事件类型
inferred
|
|||
|
初始确认已发送
|
代表发送给客户的第一封沟通信息,确认收到其服务请求。这通常是由 case 创建规则触发的自动邮件,通过识别首次外发沟通来推断。 | ||
|
为何重要
追踪此 activity 对于衡量初始响应时间并确保及时通知客户至关重要。它有助于分析“初始确认延迟”KPI,从而改善客户沟通。
获取方式
从与 Case 关联的第一条外发 EmailMessage 记录的 timestamp 中推断。也可以从自动化规则触发的自定义字段更新中推断。
捕获
识别与该 Case 关联的第一个外发 EmailMessage 的 timestamp。
事件类型
inferred
|
|||
|
已向客户建议解决方案
|
指示座席向客户提供潜在解决方案的时间点。这是一个概念性步骤,通常从外发沟通或特定的状态更改中推断。 | ||
|
为何重要
追踪此里程碑有助于衡量从调查到提出解决方案的时间。如果方案未被接受,它也可能是一个确认循环的起点。
获取方式
从包含特定关键词的外发 EmailMessage 中,或从 CaseHistory 对象中变更为“已提供方案”的状态更改中推断。
捕获
状态变更或外发沟通 event 的 timestamp。
事件类型
inferred
|
|||
|
已向客户请求信息
|
当客服人员需要客户提供更多信息以继续处理 case 时发生此 activity。通常根据 case 状态变更为“等待客户”来推断。 | ||
|
为何重要
此 activity 标记了等待时间的开始,这不在客服人员的控制范围内。隔离这段时间对于准确衡量内部流程效率和客服人员绩效至关重要。
获取方式
当 Status 字段更新为“等待客户响应”或“挂起”等值时,从 CaseHistory 对象中推断。
捕获
Case 状态变更为“等待”值的 timestamp。
事件类型
inferred
|
|||
|
已收到客户提供的信息
|
此 activity 标记客户等待时间的结束,即客户提供所需信息的时间。通常在收到入站沟通后,case 状态切回活跃状态时推断得出。 | ||
|
为何重要
追踪此 event 对于理解客户响应时间及其对整体 case 生命周期和影响至关重要。它标志着客服人员恢复主动处理。
获取方式
通过与 case 关联的入站 EmailMessage 的 timestamp,或通过 CaseHistory 对象中从“等待客户”回到“处理中”的状态更改来推断。
捕获
收到入站邮件或状态从“等待”变更的 timestamp。
事件类型
inferred
|
|||
|
案件重新开启
|
当已解决或关闭的 case 因问题重复出现或解决方案无效而重新激活时发生。这是返工的关键指标。 | ||
|
为何重要
重新开启的 case 是解决方案质量低或首次联系解决失败的强烈信号。分析其频率和根源对于提高服务质量至关重要。
获取方式
当 IsClosed 字段从 true 变为 false,或 Status 从关闭/解决状态变回开启状态时,从 CaseHistory 对象中推断。
捕获
Status 或 IsClosed 字段从终止状态变更为活跃状态的 timestamp。
事件类型
inferred
|
|||
|
满意度调查已发送
|
代表发送客户满意度 (CSAT) 或净推荐值 (NPS) 调查。这通常是 case 解决或关闭后的自动操作。 | ||
|
为何重要
虽然不属于核心解决流程,但此 activity 对于理解反馈闭环非常重要。分析其时间点和频率可确保一致地获取客户的声音。
获取方式
从与 case 关联且匹配调查模板的外发 EmailMessage 记录中推断。或者,也可以从 SurveyInvitation 记录的创建中捕获。
捕获
识别外发调查邮件或 SurveyInvitation 记录的创建。
事件类型
inferred
|
|||