您的客户服务数据模板
您的客户服务数据模板
- 建议收集的属性
- 需要追踪的关键活动
- 提取指南
客户服务属性
| 名称 | 描述 | ||
|---|---|---|---|
|
Event 时间
EventTime
|
指示特定活动或事件发生时间的时间戳。 | ||
|
描述
Event Time(即时间戳)记录了 Activity 发生的准确日期和时间。它是按时间顺序对事件进行排序,以及计算流程中不同步骤之间时长的关键组件。每个记录的 Activity 必须有对应的时间戳。 在分析中,此属性用于构建每个服务请求的时间轴。它是计算所有时间相关 KPI(如解决时间、首次响应时间以及瓶颈时长)的基础。准确的时间戳对于理解流程性能和识别延迟至关重要。
为何重要
此时间戳对于按时间顺序排列事件以及计算所有基于时长的指标(如周期时间和 SLA 合规性)至关重要。
获取方式
这对应于 Freshdesk API 中与工单事件、回复或状态变更相关的 'created_at' 或 'updated_at' 字段。
示例
2023-10-25T10:00:00Z2023-10-25T10:05:14Z2023-10-26T14:30:00Z
|
|||
|
服务请求
ServiceRequest
|
单次客户咨询或问题的唯一标识符,通常称为工单或案例。 | ||
|
描述
Service Request(服务请求)是关联单次客户互动中所有活动的首要案例标识符。每项新的客户咨询、问题或请求都会生成唯一的服务请求 ID。该 ID 在工单从创建、分配到解决和关闭的整个生命周期中保持不变。 在流程挖掘中,该属性是重构每个客户案例端到端旅程的基础。通过将所有相关事件归组到同一个服务请求 ID 下,分析师可以实现流程流向的可视化,衡量周期时间,并识别影响单个案例的变体或瓶颈。
为何重要
这是将所有相关事件连接到单个流程实例中的关键 Case ID,支持对每个客户服务旅程的完整视图呈现。
获取方式
这是 Freshdesk 中的主要工单 ID,通常在 'Tickets' API 端点的 'id' 字段中找到。
示例
SR-2023-10-4831SR-2023-11-0192SR-2023-11-5210
|
|||
|
活动
Activity
|
客户服务流程中发生的具体业务事件或步骤的名称。 | ||
|
描述
Activity(活动)属性代表服务请求生命周期中的一个具体操作或状态变更。它记录了关键业务事件,如“工单已创建”、“工单已分配”、“首次回复已发送”和“工单已解决”。这些活动构成了流程图中的节点。 分析这些活动的顺序和频率是流程挖掘的核心。它能实现流程流向的可视化,识别常见和罕见的路径,并检测与标准作业程序(SOP)的偏差。深入了解这些活动对于定位效率低下、返工循环(如“工单已重新开启”)或合规性问题至关重要。
为何重要
此属性定义了流程图中的步骤,支持从头到尾对流程流向进行可视化分析。
获取方式
派生自 Freshdesk 内部的事件类型。这可以是来自“Tickets”API 端点的状态变更,以及来自“Conversations”端点的特定事件(如备注或回复)的组合。
示例
工单已创建首次响应已发送状态变更为待处理工单已解决工单已关闭
|
|||
|
优先级
Priority
|
分配给服务请求的优先级,例如“低”、“中”、“高”或“紧急”。 | ||
|
描述
Priority(优先级)属性反映了服务请求的紧急程度,通常决定了目标响应和解决时间。优先级可以通过规则自动设置,也可以由坐席在分拣过程中手动设置。 该属性对于分析 SLA 合规性和资源分配必不可少。通过按优先级筛选流程图,分析师可以判断高优先级工单是否真的比低优先级工单处理得更快。它还有助于了解优先级变更(一种返工形式)是否常见,以及这对整体流程产生了什么影响。
为何重要
对于 SLA 分析至关重要,有助于了解资源分配是否合理,即高优先级问题是否比低优先级问题得到了更快的处理。
获取方式
这对应于 Freshdesk 'Tickets' 对象中的 'priority' 字段。
示例
低中高紧急
|
|||
|
指派处理人
AssignedAgent
|
事件发生时负责该工单的客服坐席姓名或 ID。 | ||
|
描述
此属性标识负责处理服务请求的具体坐席。由于重新分配或升级,负责坐席在工单生命周期内可能会发生变化。 按 Assigned Agent(负责坐席)分析数据对于绩效管理仪表板至关重要。它可以衡量坐席特定的 KPI,如平均解决时间、工单量和重新开启率。这有助于识别表现优异的坐席、发现培训需求,并分析坐席流转对整体解决时间的影响。
为何重要
支持按客服个人进行绩效分析,有助于识别优秀员工、培训机会以及转办对流程的影响。
获取方式
这对应于 Freshdesk 'Tickets' 对象中的 'responder_id' 字段,之后可以与坐席详情进行关联。
示例
爱丽丝·约翰逊Robert SmithMaria Garcia
|
|||
|
服务请求类型
ServiceRequestType
|
服务请求的分类,例如“咨询”、“故障”、“问题”或“功能请求”。 | ||
|
描述
服务请求类型是一个至关重要的分类字段,它定义了客户咨询的性质。这种分类通常在工单创建时或初步分拣阶段设定,有助于将请求路由到正确的团队或坐席。 在分析中,该属性允许对流程进行细分,以了解不同类型的请求是如何被处理的。它能解答如“故障工单是否比咨询工单需要更长的解决时间?”以及“哪些类型的请求最常被重新开启?”等问题。这种细分是识别特定类型瓶颈并相应优化工作流的关键。
为何重要
支持流程细分,以便比较不同类型客户问题(如故障与一般咨询)的绩效和工作流。
获取方式
这可能是 Freshdesk 'Tickets' 对象中可用的 'type' 字段。
示例
咨询事件问题功能建议
|
|||
|
状态
Status
|
服务请求的当前或历史状态,例如“开启”、“待定”、“已解决”或“已关闭”。 | ||
|
描述
Status(状态)属性显示了服务请求在特定时间点所处的阶段。状态变更通常代表流程中的关键里程碑,例如由于等待客户输入而从“开启”变为“待定”,或者当客户回复时从“待定”变回“开启”。 跟踪状态变更是了解工单生命周期的基础。它有助于识别工单在特定状态下停留的时间,这对于精准定位瓶颈非常有用。例如,在“待定”状态停留时间过长,可能意味着在获取客户信息方面存在延迟。
为何重要
跟踪状态变更是了解工单生命周期的关键,有助于识别案例在“待定”或“挂起”等特定状态下停留了多久。
获取方式
这对应于 Freshdesk 'Tickets' 对象中的 'status' 字段。历史状态需要从活动日志中推导。
示例
未结挂起已解决已结案
|
|||
|
解决时长
ResolutionTime
|
从服务请求创建到解决所经历的总时长。 | ||
|
描述
解决时间是一个关键的案例级 KPI,用于衡量服务流程的端到端时长。它的计算方法是“工单已解决”活动与“工单已创建”活动之间的时间差。 该属性是衡量流程效率的首要指标。几乎所有的服务仪表板都会用到它,以便跟踪各阶段的表现、对比不同类别的绩效,并识别处理时间异常长的案例。减少平均解决时间通常是流程优化项目的核心目标。
为何重要
这是衡量流程效率的主要 KPI,展示了从头到尾解决客户问题所花费的总时间。
获取方式
计算字段。指每个服务请求中第一个事件的时间戳(创建)与“工单已解决”事件时间戳之间的时间间隔。
示例
25920000086400000604800000
|
|||
|
SLA 目标解决时间
SlaTargetResolutionTime
|
合同约定或设定的服务请求解决目标时间。 | ||
|
描述
此属性定义了根据服务水平协议 (SLA) 处理服务请求的目标时长。该目标通常取决于工单的优先级或类型。 这是计算 SLA 合规性的关键输入。通过对比实际解决时间与此目标,可以判定为“达标”或“违规”。在不同请求类型、团队或坐席之间分析 SLA 表现是服务管理的核心工作。
为何重要
为衡量 SLA 合规性提供基准,这是任何客户服务组织的核心绩效指标。
获取方式
这可能作为 Freshdesk 'Tickets' 对象中的 'fr_due_by'(首次响应)或 'due_by'(解决)字段提供,或者可能需要根据 SLA 策略规则派生。
示例
2023-10-25T14:00:00Z2023-10-27T09:00:00Z2023-11-01T17:00:00Z
|
|||
|
产品
Product
|
客户请求所涉及的产品或服务。 | ||
|
描述
此属性指定服务请求所涉及的产品或服务线。这通常是在 Freshdesk 中配置的自定义字段,用于帮助对工单进行分类,以便路由和报告。 通过按产品筛选流程,企业可以发现特定产品的问题。例如,它可以突出显示某种产品是否产生了不成比例的维护工单,或者新产品的发布是否导致咨询量激增。这种分析能为产品开发和管理团队提供有价值的反馈。
为何重要
支持按产品领域筛选流程,从而洞察哪些产品产生的支持请求最多,或哪些产品的解决时间最长。
获取方式
这通常是一个自定义字段。具体位置取决于 Freshdesk 配置,可能位于 'Tickets' API 响应的 'custom_fields' 部分。
示例
Alpha 平台Beta 版移动应用Gamma 订阅
|
|||
|
最后数据更新
LastDataUpdate
|
用于指示数据上次从源系统刷新的时间戳。 | ||
|
描述
此属性记录了数据集最后一次从 Freshdesk 提取或更新的日期和时间。它提供了所分析数据新鲜度的透明信息,这对于做出及时且相关的业务决策至关重要。 分析师利用这些信息来了解数据涵盖的时间窗口,并确认他们正在处理的是最新的可用信息。它是任何流程挖掘仪表板或报告的关键元数据,确保相关利益方了解数据的时效性。
为何重要
指示数据的时效性,确保分析和决策基于最新信息。
获取方式
这是在数据提取过程中生成的元数据字段,记录了抓取数据的时间戳。
示例
2023-12-01T08:00:00Z
|
|||
|
客户名称
CustomerName
|
发起服务请求的客户姓名或 ID。 | ||
|
描述
此属性识别与服务请求关联的客户。它提供了一种以客户为中心的分析视角,跟踪特定客户在一段时间内的所有互动。 按客户分析可以揭示诸如哪些客户提交工单最频繁,或哪些客户经历的重复开启问题最多等模式。这能为客户成功计划提供参考,并有助于识别由于服务体验不佳而面临流失风险的客户。这对于理解跨多个服务请求的端到端客户旅程也至关重要。
为何重要
支持以客户为中心的流程视角,有助于识别频繁发起请求的客户或反复遇到问题的客户。
获取方式
此信息通过 'Tickets' 对象中的 'requester_id' 链接,该字段连接到 Freshdesk 中的 'Contacts' 或 'Users' 对象。
示例
John DoeJane SmithGlobal Tech Inc.
|
|||
|
客服转办次数
AgentTransferCount
|
服务请求在不同坐席之间重新分配的总次数。 | ||
|
描述
此属性是案例级指标,用于计算工单负责坐席变更的次数。它的计算方法是统计每个服务请求中“工单已重新分配”活动发生的次数。 频繁的流转(也被称为“乒乓效应”)会导致明显的延迟,并由于背景信息在交接中丢失而造成挫败的客户体验。分析流转次数有助于识别初始路由、坐席技能缺口或流程复杂度方面的问题。目标通常是尽量减少不必要的流转,以提升效率和客户满意度。
为何重要
衡量内部交接的频率。频繁的环节流转往往是导致处理延迟和客户不满的主因,优化此项有助于提升一线解决率。
获取方式
计算字段。指每个独立服务请求中“工单重新分配”Activity 的总次数。
示例
0132
|
|||
|
指派小组
AssignedGroup
|
分配该服务请求的团队或部门。 | ||
|
描述
Assigned Group(分配小组)代表负责处理特定服务请求的坐席团队。工单通常根据其类型或复杂度路由到专门的小组,例如“技术支持”或“财务部”。 该属性对于分析部门间的交接以及团队层面的绩效非常有价值。它有助于识别哪些小组处理的工单最多、哪些小组的解决时间最长,以及工单在小组间流转的频率。这些信息对于优化团队结构和工作流至关重要。
为何重要
支持团队或部门维度的绩效分析,突出交接环节并识别特定组别的瓶颈。
获取方式
这对应于 Freshdesk 'Tickets' 对象中的 'group_id' 字段。
示例
一线支持二线技术支持账务客户成功
|
|||
|
是否发生SLA违约
IsSlaBreached
|
一个布尔标记(boolean flag),用于指示该服务请求的解决时间是否超过了 SLA 目标。 | ||
|
描述
此计算属性为每个服务请求提供了清晰、二元的 SLA 合规性指标。它是通过对比实际的“解决时间”与“SLA 目标解决时间”得出的。如果实际时间超过目标,则标记为 true(违规)。 该属性简化了 SLA 合规性的分析和仪表板呈现。它支持轻松统计和筛选违规工单,让分析师能快速识别 SLA 不合规的规模,并深入钻研违规工单的流程模式以寻找根本原因。它直接支持 SLA 合规概览仪表板和 KPI。
为何重要
通过为每个未达标案例提供清晰的标记,简化了 SLA 合规性分析,从而支持对违规原因进行深度追溯。
获取方式
这是一个计算字段,通过比较实际解决时间戳与 Freshdesk 的 'SlaTargetResolutionTime' 或 'due_by' 字段得出。
示例
truefalse
|
|||
|
是否重新打开
IsReopened
|
一个布尔标记(boolean flag),用于指示已解决的服务请求是否曾被重新打开。 | ||
|
描述
此案例级属性是一个标记,如果在服务请求生命周期中的任何时间点发生了“工单已重新开启”活动,该标记将设为 true。它提供了一种简单的方法来识别和分析需要返工的案例。 工单重新开启率高表明初始解决方案无效或不完整,导致低效和客户不满。通过筛选重新开启的工单,分析师可以调查根本原因,例如重新开启的常见原因、哪些坐席或团队的此类比率较高,以及哪些工单类型最容易被重新开启。
为何重要
识别需要返工的案例,这是衡量解决质量和流程低效的关键指标。分析这些案例有助于提升首次解决率。
获取方式
计算字段。如果某个 case 存在 Activity 为“工单重新打开”的事件,则该服务请求的此字段设为 true。
示例
truefalse
|
|||
|
沟通渠道
CommunicationChannel
|
发起服务请求的渠道,例如“电子邮件”、“电话”、“聊天”或“ Web 门户”。 | ||
|
描述
此属性标识客户沟通的来源或渠道。不同的渠道可能有不同的流程流向和解决时间。例如,通过聊天发起的请求其预期解决时间可能比电子邮件提交的更短。 按沟通渠道分析流程有助于优化资源分配并了解渠道效率。它可以揭示哪些渠道与更快的解决速度或更高的客户满意度相关,从而为推广或投资哪些渠道的战略决策提供依据。
为何重要
有助于分析邮件、电话或聊天等不同客户联系渠道的流程性能和效率。
获取方式
这对应于 Freshdesk 'Tickets' 对象中的 'source' 字段。
示例
电子邮件电话网络门户聊天
|
|||
|
源系统
SourceSystem
|
数据提取的源系统,在本案例中为“Freshdesk”。 | ||
|
描述
此属性标识流程数据的来源应用程序。在此分析中,该值将是静态的,例如“Freshdesk”,表示所有事件均来自 Freshdesk 客户服务平台。 虽然看似简单,但此属性对于数据治理以及合并来自多个系统的数据的场景非常重要。它提供了清晰的血缘和背景,确保分析师了解所检查数据的来源。这对于维护数据完整性和建立对分析结果的信任至关重要。
为何重要
提供有关数据来源的关键背景信息,这对于数据治理以及整合多个源系统的数据至关重要。
获取方式
这是一个静态值“Freshdesk”,在数据转换过程中添加以识别数据源。
示例
Freshdesk
|
|||
|
满意度评分
SatisfactionRating
|
工单解决后由客户提供的满意度得分。 | ||
|
描述
Satisfaction Rating(满意度评分)是一个关键的结果指标,通常通过在工单解决后发送的调查收集。它通常由数字评分或“满意”、“一般”、“不满意”等分类组成。 该属性允许将流程模式与客户结果关联起来。通过分析导致低满意度评分的流程变体,企业可以识别出负面影响客户体验的具体行为或延迟。这在流程效率与客户幸福感之间建立了直接联系。
为何重要
将流程执行与客户结果关联起来,有助于识别哪些流程行为会导致客户满意度的高低波动。
获取方式
此数据是 Freshdesk 满意度评分功能的一部分,可以通过 'Surveys' 或 'Satisfaction Ratings' API 端点获取。
示例
5314
|
|||
|
首次响应时间
FirstResponseTime
|
从创建工单到坐席首次回复客户所经过的时间。 | ||
|
描述
“首次响应时间”衡量客户收到客服人员(非自动化回复)首次回应的速度。其计算方法是“发送首次响应”Activity 的时间戳与“工单已创建”Activity 的时间戳之差。 该 KPI 是服务响应能力的关键指标,对客户满意度有重大影响。较短的首次响应时间能让客户确信其问题已被受理并正在处理。分析这一指标有助于企业确保达成初始响应 SLA,并提供及时的客户体验。
为何重要
衡量服务响应速度,这是提升客户满意度的核心驱动力,直接助力实现主动化服务的战略目标。
获取方式
计算字段。指“工单已创建”事件与“发送首次响应”事件之间的时间间隔。
示例
3000009000001800000
|
|||
客户服务 Activity
| 活动 | 描述 | ||
|---|---|---|---|
|
工单已关闭
|
这是最终活动,代表工单的永久关闭。这通常在工单处于“已解决”状态一段时间且没有新的客户回复后,由系统自动执行。 | ||
|
为何重要
此活动标志着服务请求生命周期的最终结束。它为准确计算端到端周期时间提供了终点。
获取方式
从“工单活动”日志中获取,该日志记录了状态变更为“已关闭”的最终状态。这通常由系统自动化规则触发。
捕获
当工单的“状态”字段更新为“已关闭”时记录的事件。
事件类型
explicit
|
|||
|
工单已分派
|
代表将工单分配给特定坐席或小组处理。每当分配坐席或小组字段被填写或变更时,该事件都会记录在工单历史中。 | ||
|
为何重要
跟踪分配情况对于分析坐席工作量、识别路由低效环节以及衡量“分派用时”KPI 至关重要。它有助于了解工作是如何分布的,以及在工作开始前哪里出现了延迟。
获取方式
从“工单活动”日志中获取,该日志记录了“客服”或“部门”字段的变更及相应时间戳。
捕获
当“分配给”字段(针对客服或部门)更新时记录的事件。
事件类型
explicit
|
|||
|
工单已创建
|
这是客户服务生命周期中的第一个事件,代表客户请求在 Freshdesk 中正式记录的时刻。当通过电子邮件、门户、电话或 API 集成生成新工单时,此活动会被明确捕获。 | ||
|
为何重要
此活动是每个案例的起点,对于计算整体解决时间以及按渠道或类型分析工单量趋势至关重要。
获取方式
这是 Freshdesk“工单活动”日志中的明确事件。它是在创建新工单记录时自动生成的。
捕获
工单创建时直接记录在活动流中。
事件类型
explicit
|
|||
|
工单已解决
|
代表坐席已提供解决方案并将工单状态更改为“已解决”的关键里程碑。这是工单历史中记录的明确状态变更。 | ||
|
为何重要
此活动标志着工单主动处理工作的结束,是衡量解决时间的基础。它是分析坐席绩效和整体流程效率的关键事件。
获取方式
从“工单活动”日志中获取,该日志记录了变更为“已解决”的具体状态及其时间戳。
捕获
当工单的“状态”字段更新为“已解决”时记录的事件。
事件类型
explicit
|
|||
|
首次响应已发送
|
标志着工单创建后客服向客户发送的首次公开回复。Freshdesk 明确捕获此事件,以便为 SLA 追踪衡量“首次响应时间”。 | ||
|
为何重要
这是衡量客户响应速度和 SLA 合规性的关键里程碑。分析此活动的时间有助于识别与客户初步接触中的延迟。
获取方式
这是 Freshdesk 为 SLA 目的而跟踪的特定事件。它对应于坐席添加第一条公开评论的时间戳。
捕获
根据工单对话历史记录中客服的首次公开回复来识别。
事件类型
explicit
|
|||
|
SLA 违约
|
一种计算得出的事件,当响应或解决工单所需的时间超过定义的 SLA 政策目标时触发。Freshdesk 会追踪 SLA 状态并将工单标记为“违规”(violated),由此可推导出此 Activity。 | ||
|
为何重要
此活动通过精准定位服务水平承诺未达成的时间和环节,直接支持 SLA 合规性分析。它是识别系统性延迟原因的关键。
获取方式
此事件是通过观察工单的“SLA”状态推断或计算出来的。当工单的 SLA 状态变为“违规”时,或者通过对比响应/解决时间戳与 SLA 目标时,可以生成一个活动。
捕获
当“解决时长”超过“SLA 目标解决时间”时,从工单数据中推导得出。
事件类型
calculated
|
|||
|
内部备注已添加
|
客服人员在工单中添加私密备注,用于与其他客服内部协作。这是工单活动流中捕获的明确事件,仅客服人员可见。 | ||
|
为何重要
跟踪内部备注有助于分析协作模式,并识别需要大量内部讨论的问题。解决前内部备注频率高,可能意味着问题复杂或存在知识缺口。
获取方式
记录在工单对话历史中的“私密备注”,与回复给客户的公开内容区分开。
捕获
当客服人员添加标记为“私密”的备注时记录的事件。
事件类型
explicit
|
|||
|
客户已回复
|
代表收到来自客户的新回复。这是工单对话记录中的一个明确事件,通常会触发工单状态从“待定”变回“开启”。 | ||
|
为何重要
此活动对于了解客户互动的往复过程以及衡量客户响应时间至关重要。它还会重启任何暂停的 SLA 计时器,从而影响合规性指标。
获取方式
作为工单对话线程中的新条目记录。该事件与客户的联系人记录相关联。
捕获
客户联系人在工单中添加了新的公开备注。
事件类型
explicit
|
|||
|
工单优先级已变更
|
当坐席或自动化规则更改工单的优先级(例如从“低”改为“高”)时,会发生此事件。这记录在工单活动日志中的显式更新里。 | ||
|
为何重要
优先级的变更可能预示着问题的升级或紧迫性的重新评估。分析这些变更不仅有助于理解升级的动因,还能了解其对解决时间的影响。
获取方式
从“工单活动”日志中获取,该日志记录了包括“优先级”字段在内的所有工单属性变更。
捕获
当“优先级”字段值更新时记录的事件。
事件类型
explicit
|
|||
|
工单已重开
|
当客户回复处于“已解决”状态的工单时发生此活动,系统会自动将其状态更改回“开启”。这是系统记录的明确事件。 | ||
|
为何重要
高重新打开率表明初始解决方案无效,导致返工和客户不满。分析此 Activity 对于“工单重开分析”和提升“首次解决率”至关重要。
获取方式
当客户回复触发状态自动从“已解决”变回“开启”时,此事件会被捕获。该状态变更记录在“工单活动”日志中。
捕获
由客户互动触发的状态变更,工单从“已解决”变为“开启”。
事件类型
explicit
|
|||
|
工单已重新分配
|
指工单在首次分配后,在不同坐席或小组之间流转。这是工单活动日志中记录的一个明确事件,表现为负责人变更。 | ||
|
为何重要
频繁的重新分配或过高的客服间转办率,通常意味着初始路由错误或知识孤岛。此分析有助于找准提升“首次解决率”的切入点。
获取方式
通过首次分配后“工单活动”日志中“坐席”或“小组”字段的变更进行跟踪。
捕获
在初始分配之后,对“分配给”字段进行的后续更新。
事件类型
explicit
|
|||
|
满意度调查已发送
|
代表发送客户满意度调查。通常由工单解决后的自动化规则触发。如果自动化操作被记录在工单历史中,该事件即可被捕获。 | ||
|
为何重要
标志着反馈收集过程的开始。将调查响应与流程变体关联起来,可以深入了解流程绩效如何影响客户满意度。
获取方式
这通常由“自动化规则”触发。它在工单活动日志中作为独立事件的可见性取决于 Freshdesk 对自动化的日志配置。
捕获
工单解决后,由自动化规则执行记录的事件。
事件类型
explicit
|
|||
|
状态变更为待处理
|
当坐席等待客户提供信息并由于此将工单状态更改为“待定”时,会发生此活动。此事件在工单活动历史中记录为状态变更。 | ||
|
为何重要
识别流程因等待外部输入而暂停的阶段。分析处于此状态的时长有助于量化客户侧的延迟,并支持 SLA 合规性分析(因为 SLA 计时器在此状态下通常会暂停)。
获取方式
从“工单活动”日志中获取,该日志记录了所有状态变更,包括转换为“待处理”状态。
捕获
当工单的“状态”字段更新为“待处理”时记录的事件。
事件类型
explicit
|
|||