您的理赔处理数据模板
您的理赔处理数据模板
- 建议收集的属性
- 应跟踪的关键活动
- Salesforce Financial Services Cloud数据提取指南
理赔处理属性
| 名称 | 说明 | ||
|---|---|---|---|
|
理赔ID
ClaimId
|
每笔保险理赔的唯一标识符,也是流程分析中的主要Case ID。 | ||
|
说明
理赔ID是连接单笔保险理赔从提交到结案期间所有活动、事件和数据点的基础Case标识符。 在流程挖掘中,此属性对于重建每笔理赔的端到端历程至关重要。它可以将所有相关事件汇总为一个完整Case,从而分析单笔理赔的周期时间、流程变体和瓶颈。
为什么重要
这是跟踪理赔生命周期的关键标识。没有唯一的理赔ID,就无法将各个流程步骤关联起来,形成连贯的分析路径。
获取位置
通常是Case对象上的'CaseNumber',或'Claim'(FinancialServicesCloud.Claim)对象上的自定义唯一ID字段。
示例
CL-00012345CL-00012346CL-00012347
|
|||
|
事件时间
EventTime
|
表示特定活动或事件发生时间的时间戳。 | ||
|
说明
Event Time提供理赔生命周期中每项活动的准确日期和时间。这些时间数据对于按时间顺序排列事件和计算时长至关重要。 在分析中,时间戳用于计算所有时间相关指标,包括活动之间的周期时间、等待时间和Case总时长。它们是创建动态流程动画以及识别延迟发生时间和位置的基础。
为什么重要
此属性定义每个事件的“何时”,支持计算时长、分析流程绩效随时间的变化,并识别基于时间的瓶颈。
获取位置
对于状态变更,这是对象字段历史中的'CreatedDate'(例如CaseHistory)。对于任务,则使用'CompletedDateTime'或'CreatedDate'。
示例
2023-04-15T10:22:05Z2023-04-16T14:05:10Z2023-04-18T09:00:00Z
|
|||
|
最近数据更新时间
LastDataUpdate
|
源系统最近一次刷新或提取数据的时间戳。 | ||
|
说明
此属性表示最近一次从Salesforce Financial Services Cloud提取数据的日期和时间,反映待分析数据的新鲜度。 仪表板用户需要了解分析数据的时效性。该信息有助于管理对数据及时性的预期,并验证数据管道是否按计划运行。
为什么重要
提供数据新鲜度的重要背景,确保分析人员和业务用户了解流程视图的更新程度。
获取位置
该值由数据提取工具或ETL流程在执行时生成并写入数据集。
示例
2023-10-27T02:00:00Z
|
|||
|
活动名称
ActivityName
|
理赔生命周期中某个时间点发生的具体业务活动或事件名称。 | ||
|
说明
此属性描述理赔流程中的单个步骤或里程碑,例如'Claim Submitted'、'Initial Review Performed'或'Payment Issued'。它构成流程图的基础。 分析活动的顺序和频率,有助于识别最常见的流程路径(变体)、发现偏离标准流程的情况,并定位频繁重复的活动,从而识别返工。
为什么重要
它定义流程中的“内容”,支持可视化流程,并识别瓶颈、返工循环和流程变体。
获取位置
根据Claim/Case对象'Status'字段的变更,或相关Task、Event记录的'Subject'获取。
示例
理赔已提交已完成初始审核已请求补充信息理赔已结案
|
|||
|
源系统
SourceSystem
|
标识记录事件数据的源系统。 | ||
|
说明
此属性指定提取数据的源应用或平台。对于此流程,值始终为'Salesforce Financial Services Cloud'。 虽然该值看似固定,但明确记录源系统是最佳实践,尤其适用于数据可能来自多个系统的环境。它有助于明确数据来源,并支持数据治理和验证。
为什么重要
确认数据来源,对于数据治理、问题排查以及整合多个企业系统的数据至关重要。
获取位置
通常是在数据提取和转换过程中添加的静态值,用于标记数据集来源。
示例
Salesforce Financial Services Cloud
|
|||
|
已分配理赔员
AssignedAdjuster
|
负责处理理赔的用户或理赔员姓名。 | ||
|
说明
此属性标识负责某项活动或整个Case的理赔员,通常根据理赔Case的所有者或完成特定任务的人员获取。 按理赔员分析绩效对于运营管理至关重要。“理赔员工作量与绩效”等仪表板使用此属性跟踪每人的理赔量、活动Case数和周期时间,支持均衡分配工作量并发现辅导机会。
为什么重要
此属性对于分析团队和个人绩效、管理工作量以及识别最佳实践或培训需求至关重要。
获取位置
这是Case或Claim对象上的'OwnerId'字段,关联User对象以获取理赔员姓名。
示例
Alice JohnsonRobert SmithMaria Garcia
|
|||
|
提交渠道
SubmissionChannel
|
最初提交理赔的方式或渠道。 | ||
|
说明
此属性表示理赔首次报案的方式,例如通过Web门户、移动应用、电话或电子邮件。提交渠道可能显著影响初始信息质量和后续处理步骤。 按提交渠道分析理赔,有助于了解需求模式和不同受理方式的效率。“理赔吞吐量与数量”仪表板使用此属性跟踪各渠道随时间产生的理赔数量,为资源分配和技术投资决策提供依据。
为什么重要
有助于评估不同受理渠道的效率,并了解某些渠道是否会导致更多返工或更长周期时间。
获取位置
通常是Claim/Case对象上的自定义选项列表字段,常标记为'Origin'或'Channel'。
示例
Web门户移动应用电话电子邮件
|
|||
|
理赔总金额
TotalClaimAmount
|
投保人最初申报的损失总金额。 | ||
|
说明
此属性表示客户在流程开始时申报的损失或损害总金额。该值通常会影响理赔复杂程度、所需审核力度及后续处理路径。 按理赔金额分析流程指标,可以发现重要规律。例如,高金额理赔可能周期更长、涉及更多步骤,或被分配给专业团队。这有助于制定合理的SLA并预测财务准备金。
为什么重要
为每个Case提供财务背景,支持分析理赔金额如何影响流程复杂度、时长和结果。
获取位置
这是Financial Services Cloud中Claim对象上的自定义货币字段,例如'ClaimedAmount__c'。
示例
1500.0025000.50125.75
|
|||
|
理赔状态
ClaimStatus
|
事件发生时理赔的当前状态(例如Open、Under Review、Closed)。 | ||
|
说明
Claim Status反映理赔在生命周期中的位置,例如'New'、'Investigation'、'Pending Customer'或'Closed',是了解流程当前状态的关键属性。 此属性广泛用于“未结理赔账龄报告”等运营仪表板,以展示当前工作量,并识别长时间停留在某一状态的理赔。分析状态之间的转换,也是定义流程图活动的主要方法。
为什么重要
实时呈现活动理赔的当前状态,帮助管理积压并识别停滞Case。
获取位置
这是Case或Claim对象上的标准'Status'字段。
示例
已登记调查中已提供和解方案已关闭-已付款已关闭-已拒赔
|
|||
|
理赔类型
ClaimType
|
保险理赔的类别,例如汽车、财产或责任。 | ||
|
说明
Claim Type是细分和分析理赔流程的重要维度。不同类型的理赔通常遵循不同流程,复杂程度不同,也适用不同的SLA。 按Claim Type筛选或比较绩效,分析人员可以发现特定类型的瓶颈,评估针对性SLA的合规情况,并了解不同类别的流程变体。“理赔SLA合规概览”和“理赔拒绝原因分析”等仪表板会使用此属性提供更有针对性的洞察。
为什么重要
支持按类别细分理赔,用于比较流程、识别特定类型的问题并制定针对性的改进措施。
获取位置
通常是Case或Claim对象上的标准'Type'字段或自定义选项列表字段。
示例
汽车房主保险商业财产一般责任
|
|||
|
结束时间
EndTime
|
标记活动完成的时间戳,用于精确计算时长。 | ||
|
说明
End Time属性记录活动结束的准确时刻。Start Time(EventTime)标记开始时间,而End Time提供计算活动完成耗时所需的另一端点。 同时具备Start Time和End Time后,可以精确计算活动处理时间,并将其与活动之间的等待时间区分开来。这对于构建“流程步骤时长明细”等仪表板,以及定位具体任务内部而非仅任务之间的低效环节至关重要。
为什么重要
支持精确计算每项活动的实际处理时间,对于区分增值时间和等待时间至关重要。
获取位置
根据时间戳数据获取。例如,如果'Initial Review Performed'由状态变更触发,EndTime可以使用下一次状态变更的时间戳。
示例
2023-04-15T11:05:30Z2023-04-16T17:20:00Z2023-04-18T09:45:12Z
|
|||
|
部门
Department
|
负责处理理赔的内部部门或团队。 | ||
|
说明
此属性指定负责理赔的业务单元或部门,例如'Personal Lines'、'Commercial Auto'或'Special Investigations Unit'。 按部门分析流程,有助于识别团队间的绩效差异、了解工作量分配情况,并定位部门特有的流程偏差或瓶颈。在“理赔SLA合规概览”等仪表板中,该维度可用于比较组织不同部分的绩效。
为什么重要
支持比较不同业务单元的绩效,帮助识别最佳实践并更有效地分配资源。
获取位置
可以是Claim/Case对象上的自定义字段,也可以根据User对象中已分配用户的档案或角色推断。
示例
个人汽车理赔商业财产欺诈调查部门
|
|||
|
Case时长
CaseDuration
|
单笔理赔从第一个事件到最后一个事件经过的总时间,也称为周期时间。 | ||
|
说明
此指标衡量理赔Case从最初提交到最终结案的端到端总时长。计算方式为指定Claim ID最后一个事件的时间戳减去第一个事件的时间戳。 这是流程绩效最重要的KPI之一。“平均理赔周期时间”KPI和“理赔端到端周期时间”仪表板都会直接关注该指标。降低这一数值通常是流程改进项目的主要目标。
为什么重要
衡量流程整体端到端效率,是客户体验的重要指标。
获取位置
计算字段:每个'ClaimId'最后一个事件的时间戳减去第一个事件的时间戳。由流程挖掘工具计算。
示例
30天5小时15天10小时90天2小时
|
|||
|
SLA状态
SlaStatus
|
表示理赔是否在规定的服务级别协议(SLA)期限内解决。 | ||
|
说明
此属性表示分类结果,通常取值为'Met'或'Breached'。通过比较理赔实际完成日期(最后一项活动的时间戳)与其'SlaTargetDate'推导得出。 这是“SLA达标率”KPI和“理赔SLA合规概览”仪表板的核心指标,以清晰明确的方式衡量绩效是否达到目标,对于合规报告和运营管理至关重要。
为什么重要
清晰反映绩效是否达到时效目标,这对客户满意度和监管合规至关重要。
获取位置
计算字段:如果最终事件的'EndTime'小于或等于'SlaTargetDate',则为'Met',否则为'Breached'。此逻辑可在数据转换过程中或流程挖掘工具内应用。
示例
已达标已超时
|
|||
|
SLA目标日期
SlaTargetDate
|
根据服务级别协议,预计完成理赔处理的目标日期。 | ||
|
说明
SLA Target Date是计算得出或手动设置的日期,表示理赔解决期限,是衡量及时性的基准。 此属性对于监控对客户或监管机构作出的时效承诺至关重要。它是“SLA达标率”KPI和“理赔SLA合规概览”仪表板的基础,可帮助组织跟踪按时解决的理赔比例,并识别未达目标的理赔类型或部门。
为什么重要
定义理赔解决时长的绩效目标,支持直接衡量SLA合规情况。
获取位置
通常是Claim/Case对象上的自定义公式字段或日期字段,根据提交日期和理赔类型计算。
示例
2023-05-15T23:59:59Z2023-06-20T23:59:59Z2023-07-01T23:59:59Z
|
|||
|
位置
Location
|
与理赔或保单相关的地理位置(国家、州或地区)。 | ||
|
说明
此属性提供理赔的地理背景,例如损失发生的州或投保人所在国家。数据可以来自投保人地址或损失详情。 地理分析可以揭示不同地区在理赔类型、频率和处理时长方面的趋势,也可用于评估不同区域办公室的绩效,并确保符合特定地区的法规。
为什么重要
支持理赔地理分析,有助于发现地区绩效差异、欺诈模式或本地事件的影响。
获取位置
通常根据关联Account或Contact对象上的地址字段(例如'BillingState'、'BillingCountry')获取。
示例
USA加利福尼亚州英国
|
|||
|
保单号
PolicyNumber
|
与理赔关联的保险保单唯一标识符。 | ||
|
说明
Policy Number将理赔关联回客户当前有效的保险保单,提供承保范围、限额和投保人历史等重要上下文信息。 虽然它不一定是流程的主要驱动因素,但它是关键的上下文数据。您可以使用它将理赔数据与保单数据关联起来,开展更深入的分析,例如了解某些保单类型是否更容易产生频繁或复杂的理赔。
为什么重要
将理赔关联至基础保险保单,支持分析特定保单或保障类型相关的理赔模式。
获取位置
这是Claim对象上的查找字段,引用Financial Services Cloud中的'InsurancePolicy'对象。
示例
POL-987654321POL-123456789POL-555444333
|
|||
|
和解金额
SettlementAmount
|
理赔和解后最终支付给索赔人的金额。 | ||
|
说明
此属性记录理赔结案并完成和解时实际支付给索赔人的金额。由于评估结果、免赔额和保单限额等因素,该金额可能不同于最初申报金额。 分析和解金额,尤其是将其与最初申报金额对比,有助于了解损失评估准确性和和解协商结果。这是了解理赔总成本的重要财务指标。
为什么重要
代表理赔最终造成的财务影响,对于财务分析、准备金管理和评估初始损失评估准确性至关重要。
获取位置
这是Claim对象或Financial Services Cloud中相关Payment对象上的自定义货币字段。
示例
1450.0022500.000.00
|
|||
|
客户ID
CustomerId
|
提交理赔的客户或投保人唯一标识符。 | ||
|
说明
Customer ID将理赔关联至提交理赔的个人或组织。在Salesforce中,通常通过查找字段关联Account或Contact对象。 此属性支持以客户为中心分析理赔流程,可用于分析每位客户的理赔历史、识别高频理赔客户并提供个性化服务。它对于将理赔数据与CRM中的其他客户数据关联,形成完整业务视图也至关重要。
为什么重要
支持以客户为中心的分析,帮助了解单个客户的理赔模式,并衡量理赔流程对客户关系的影响。
获取位置
这是Claim/Case对象上的查找字段,指向Account或Contact对象(例如'AccountId'或'ContactId')。
示例
0018d00000abcdeFAA0018d00000fghijKLM0018d00000mnopqrSTU
|
|||
|
拒绝原因
ReasonForRejection
|
理赔被拒或拒绝时提供的具体原因。 | ||
|
说明
当理赔最终决定为'Rejected'时,此属性提供具体原因,例如'Not Covered by Policy'、'Fraud Suspected'或'Incomplete Information'。 这是“理赔拒绝原因分析”仪表板的关键属性。通过分析不同拒绝原因的频率,并按理赔类型或部门细分,组织可以发现改进承保、明确保单条款或完善信息收集流程的机会,从而减少无效提交。
为什么重要
直接说明理赔被拒的原因,对于改进承保政策并减少无效理赔造成的无效处理至关重要。
获取位置
通常是Claim/Case对象上的自定义选项列表字段,当状态变更为'Rejected'或'Closed - Denied'时必须填写。
示例
保险范围已过期损失不在承保范围内疑似欺诈重复理赔
|
|||
|
损失日期
LossDate
|
引发理赔的事故或损失发生日期。 | ||
|
说明
Loss Date记录保险保单承保事件发生的时间,与理赔提交日期不同。 此属性对于合规以及分析事故与报案之间的延迟非常重要。较大的时间间隔有时可能表明潜在问题,或需要采用不同的处理程序。它为了解事件完整时间线提供了重要背景。
为什么重要
有助于分析事故与报案之间的延迟,该延迟可能影响调查和和解。
获取位置
这是Claim对象上的自定义日期字段,例如'DateOfLoss__c'。
示例
2023-04-122023-05-202023-06-01
|
|||
|
是否自动执行
IsAutomated
|
用于表示活动是否由自动化系统而非人工用户执行的布尔标记。 | ||
|
说明
此标记用于区分由人工理赔员完成的任务与由自动化工作流、规则或系统集成执行的任务。例如,初始理赔登记可能完全自动完成。 分析自动化情况是了解流程效率的关键。它有助于衡量自动化举措的成效,识别适合进一步自动化的步骤,并比较自动任务与人工任务的速度和一致性。
为什么重要
区分人工活动和系统驱动活动,对于评估自动化的影响和成效至关重要。
获取位置
通常通过推断获得。如果事件关联用户为通用'System'或'Integration'用户,则此标记设为true。
示例
truefalse
|
|||
|
是否返工
IsRework
|
用于标识某项活动或一系列活动是否代表返工的布尔标记。 | ||
|
说明
当理赔回到流程中的上一阶段时,此标记设为true。典型示例是从'Investigation Completed'退回'Additional Information Requested'。返工识别逻辑根据流程知识定义。 此属性是'Claims Rework Loop Analysis'仪表板和'Rework Rate'KPI的基础。它可以直接量化返工的频率和影响,而返工是效率低下、成本增加和周期时间延长的主要原因。
为什么重要
直接标记低效的流程循环,便于量化返工并针对其根本原因开展分析。
获取位置
计算字段。通过分析每个案例的活动序列得出。例如,如果'Activity A'之后是'Activity B',随后再次出现'Activity A',则第二个'A'实例属于返工。
示例
truefalse
|
|||
理赔处理活动
| 活动 | 说明 | ||
|---|---|---|---|
|
已付款
|
标志着资金实际支付给索赔人。这是关键财务事件,通常在与理赔关联的付款记录标记为'Paid'或'Issued'时捕获。 | ||
|
为什么重要
此活动是衡量理赔履行流程最后阶段的重要里程碑。分析批准到付款之间的耗时,有助于优化财务运营。
获取位置
根据相关'Claim Payment'自定义对象的状态变更推断。状态变更为'Paid'或'Sent'的时间戳表示此事件发生。
采集
相关'Claim Payment'对象状态变更的时间戳。
事件类型
inferred
|
|||
|
已完成初始审核
|
表示分配的理赔员已完成对理赔详情的首次全面审核。通常可根据“Claim”对象的状态变化推断,例如从“New”变为“Under Review”或“Initial Assessment Complete”。 | ||
|
为什么重要
这一里程碑标志着初始等待期结束和主动处理开始。到达此步骤所需的时间,是衡量理赔员工作负载和受理效率的重要指标。
获取位置
根据通过Field History Tracking捕获的“Claim”对象“Status”字段变更时间戳推断。
采集
“Status”字段变更为“Under Review”或类似状态的时间戳。
事件类型
inferred
|
|||
|
已请求补充信息
|
表示理赔员判断需要从保单持有人或第三方获取更多信息的节点。可以根据状态变更为“Pending Customer Information”,或创建相关“Task”或“EmailMessage”记录来推断。 | ||
|
为什么重要
这是识别返工循环的关键活动。此事件频繁发生,通常说明初始数据收集存在问题,导致流程延误和周期时间增加。
获取位置
根据“Claim”对象“Status”字段变更为“Pending Information”状态推断。也可以根据具有特定类型的关联Task或EmailMessage记录的创建日期推断。
采集
“Status”变更为“Pending Info”的时间戳,或相关通信记录的创建时间戳。
事件类型
inferred
|
|||
|
理赔决策完成
|
表示正式批准或拒绝理赔的决定。这是一个关键里程碑,根据状态变更为'Approved'或'Rejected'等终止决策状态推断。 | ||
|
为什么重要
这是决定后续流程路径的关键决策点。分析决策耗时是衡量理赔员效率和SLA合规情况的重要KPI。
获取位置
根据'Claim'对象'Status'字段变更为决策状态(例如'Approved'、'Rejected')的时间戳推断,数据通过Field History Tracking记录。
采集
'Status'变更为'Approved'或'Rejected'的时间戳。
事件类型
inferred
|
|||
|
理赔已提交
|
表示理赔流程的启动,即新理赔首次录入Salesforce。通常通过新建“Claim”对象记录捕获此事件。 | ||
|
为什么重要
这是流程的主要开始事件。分析从提交到下一步所需的时间,有助于识别初始受理延误,并建立衡量整体周期时间的基线。
获取位置
取自“Claim”标准对象的“CreatedDate”时间戳,为每个理赔案件提供准确、可靠的起始点。
采集
“Claim”对象的记录创建时间戳。
事件类型
explicit
|
|||
|
理赔已结案
|
在包括付款在内的所有活动完成后,标志着系统中的理赔最终成功结案。通过'Claim'对象状态最终变更为'Closed'捕获。 | ||
|
为什么重要
这是流程主要的成功结束事件,对于计算端到端周期时间和衡量整体流程吞吐量至关重要。
获取位置
根据'Claim'对象'Status'字段的Field History Tracking推断,记录状态变更为'Closed'的时间戳。
采集
'Status'字段变更为'Closed'的时间戳。
事件类型
inferred
|
|||
|
付款已授权
|
表示和解金额已获内部批准,可以付款。此事件可以来自相关'Payment Request'对象,也可以根据状态变更为'Approved for Payment'等状态推断。 | ||
|
为什么重要
这是关键的内部控制点。决策与付款授权之间的延迟,可能表明财务审批工作流存在瓶颈。
获取位置
根据'Claim'对象'Status'字段变更的时间戳推断。更稳妥的方式是使用相关'Claim Payment'或类似自定义对象的'CreatedDate'。
采集
'Claim Payment'对象的记录创建时间戳。
事件类型
explicit
|
|||
|
已提供和解方案
|
表示已正式向索赔人提供和解金额。此事件可通过状态变更为'Settlement Offered'或创建通信记录捕获。 | ||
|
为什么重要
此活动启动最终协商或接受阶段。分析索赔人响应所需时间,有助于改进沟通策略并缩短流程最后阶段。
获取位置
根据'Claim'对象'Status'字段变更推断,也可根据代表报价函的相关'EmailMessage'或'Document'记录创建日期捕获。
采集
'Status'变更为'Settlement Offered'的时间戳。
事件类型
inferred
|
|||
|
已收到补充信息
|
表示已收到所请求的信息,理赔处理可以恢复。通常在“Claim”对象状态从“Pending”状态变回“Under Review”等活动状态时推断。 | ||
|
为什么重要
“Information Requested”与“Information Received”之间的时间通常是重要瓶颈。分析这段时长有助于了解外部依赖和沟通效果。
获取位置
根据“Claim”对象“Status”字段的Field History Tracking推断,记录其从“Pending Information”变更为活动状态的时间戳。
采集
'Status'字段从待处理状态变更的时间戳。
事件类型
inferred
|
|||
|
损失评估完成
|
表示损失造成的财务影响已完成评估并记录。此事件可根据'Claim'对象上的'Loss Estimate'或'Settlement Amount'字段首次填充值的时间推断。 | ||
|
为什么重要
此活动是重要的财务里程碑。跟踪其发生时间,有助于了解财务评估延迟,这可能成为最终决策前的瓶颈。
获取位置
根据'Claim'对象上货币字段(例如'Loss_Estimate__c')的Field History Tracking推断,使用该字段从空值或零值首次更新的时间戳。
采集
财务评估字段首次填值的时间戳。
事件类型
inferred
|
|||
|
理赔已分配
|
表示理赔已分配给特定理赔员或团队处理。通过跟踪“Claim”对象的“OwnerId”字段何时被填充,或何时从队列变更为用户,可以捕获此事件。 | ||
|
为什么重要
跟踪分配情况对于分析资源工作负载、识别理赔员开始处理前的延误至关重要,还可以衡量理赔在队列中等待主动处理的时间。
获取位置
取自“Claim”对象“OwnerId”字段的Field History Tracking。从队列变更为特定用户的时间戳即标志着此事件。
采集
“OwnerId”字段从队列变更为用户的时间戳。
事件类型
inferred
|
|||
|
理赔已登记
|
表示完成初始数据录入后,系统正式确认并登记理赔。通常可根据“Claim”对象的状态变化推断,例如从“Draft”变为“New”或“Submitted”。 | ||
|
为什么重要
此活动确认理赔已正式进入处理队列。提交与登记之间的时长可以揭示初始数据验证团队或受理团队的积压情况。
获取位置
根据“Claim”对象“Status”字段的Field History Tracking推断,记录状态变为已登记状态的时间戳,例如“New”或“Open”。
采集
“Status”字段变更为“New”或“Registered”的时间戳。
事件类型
inferred
|
|||
|
理赔被拒绝
|
表示理赔被拒后的最终结果。这是一个结束事件,在'Claim'对象状态更新为'Rejected'或'Denied'时捕获。 | ||
|
为什么重要
这是流程的终止状态,与成功结案不同。分析被拒理赔及其原因,有助于改进承保或初步筛选流程。
获取位置
根据'Claim'对象'Status'字段变更为'Rejected'的时间戳推断。'Reason for Rejection'属性可从对应字段中获取。
采集
'Status'字段变更为'Rejected'的时间戳。
事件类型
inferred
|
|||
|
调查完成
|
表示理赔证据收集和分析阶段结束。通常根据状态从'Investigation in Progress'变更为'Pending Decision'或类似状态推断。 | ||
|
为什么重要
此里程碑标志着调查子流程结束,可精确测量调查周期时间,帮助优化这一关键阶段。
获取位置
根据'Claim'对象'Status'字段的Field History Tracking推断,记录状态从调查状态变更的时间戳。
采集
'Status'字段从'Investigation'变更的时间戳。
事件类型
inferred
|
|||
|
调查开始
|
表示理赔详细调查阶段正式开始。此事件根据'Claim'对象的状态变更推断,例如变更为'Investigation in Progress'。 | ||
|
为什么重要
此活动标志着一个关键且通常耗时较长的子流程开始。测量调查周期时间对于识别证据收集和分析环节的瓶颈至关重要。
获取位置
根据通过Field History Tracking捕获的“Claim”对象“Status”字段变更时间戳推断。
采集
'Status'字段变更为'Investigation'的时间戳。
事件类型
inferred
|
|||
提取指南
终结理赔积压:立即加快处理速度
实现70%的直通式处理,提升客户满意度。
无需信用卡,几分钟即可完成设置。