您的理赔处理数据模板

Guidewire ClaimCenter
您的理赔处理数据模板

您的理赔处理数据模板

欢迎使用专为优化理赔处理而准备的资源。本模板列出了需要收集的核心数据属性和需要跟踪的关键活动,并提供清晰的数据提取指导。使用本模板可确保您采集完整信息,从而开展全面的流程分析。
  • 建议收集的属性
  • 需要跟踪的关键活动
  • Guidewire ClaimCenter数据提取指南
刚接触事件日志?了解 如何创建流程挖掘事件日志.

理赔处理属性

以下建议的数据字段对于构建完整事件日志至关重要,可有效分析您的理赔处理工作流。
3 必需 4 建议 14 可选
名称 说明
事件时间
EventTime
活动发生的准确日期和时间。
说明

该时间戳记录活动在系统中发生的准确时刻,是所有基于时间的流程分析的基础。

对单个Claim ID的EventTime按时间顺序排列后,即可还原流程。相邻事件之间的时间差用于计算周期时间、等待时间和处理时间,这些指标对于绩效分析、瓶颈识别和SLA监控至关重要。

为什么重要

该时间戳对于事件排序、计算周期时间和时长,以及识别流程延误至关重要。

获取位置

通常与Guidewire ClaimCenter历史表或审计表中的事件或活动数据一起出现,字段名称通常为“CreateTime”或“UpdateTime”。

示例
2023-05-15T09:00:00Z2023-05-16T14:30:15Z2023-06-01T11:20:00Z
活动名称
ActivityName
理赔生命周期中特定时点发生的业务活动或事件名称。
说明

该属性描述理赔流程中的具体步骤或里程碑,例如“理赔已创建”“调查已开始”或“已付款”。对于给定Claim ID,这些活动的顺序构成流程。

分析活动之间的顺序、频率和持续时间是流程挖掘的核心。它支持发现流程模型、识别瓶颈、检测返工循环,以及分析流程偏差。

为什么重要

它定义流程步骤,支持流程图可视化,以及流程和瓶颈分析。

获取位置

通常从ClaimCenter的事件表或审计日志中获取,方法是将特定系统事件或状态变更映射为标准化活动名称。

示例
理赔案件创建作出责任认定付款发放理赔结案
理赔ID
ClaimID
每个保险理赔案件的唯一标识符,也是主要案件标识。
说明

Claim ID是理赔流程分析的核心,用于从提交到结案唯一标识每个案例。它关联所有相关活动、文档、付款和通信,确保完整、连贯地呈现理赔生命周期。

在流程挖掘中,数据集中的每个事件都与Claim ID关联,因此可以还原端到端流程。这对于分析周期时间、识别流程变体,以及跟踪理赔在不同部门和理赔员之间的处理旅程至关重要。

为什么重要

它是连接所有相关事件的基础键,使单个理赔案件的完整旅程能够被追踪和分析。

获取位置

这是Guidewire ClaimCenter中的主键,通常位于核心Claim实体的Claim.ClaimNumber或类似字段中。

示例
000-123-45678000-987-65432001-456-11223
指定的理赔员
AssignedAdjuster
负责处理理赔或具体活动的用户姓名或ID。
说明

此属性用于识别在特定时间点负责某项理赔的理赔员。理赔员可能负责整项理赔,也可能只负责其中的特定任务。

按指定理赔员分析对于平衡工作量、管理绩效和发现培训机会至关重要。它可以帮助回答以下问题:“哪些理赔员的案件量最高?”“不同理赔员之间是否存在绩效差异?”“工作分配是否均衡?”

为什么重要

跟踪用户参与情况,支持工作量分析、绩效比较,并帮助识别资源相关的瓶颈。

获取位置

在ClaimCenter的Claim或Exposure实体中提供,通常与User对象关联,例如Claim.Assignee。

示例
j.doem.smiths.jones
损失原因
LossCause
损失事件的具体原因,例如碰撞、火灾或水灾。
说明

此属性提供理赔申请原因的详细背景信息。损失原因通常决定所需的调查步骤、所需专家类型以及理赔的整体复杂程度。

按损失原因分析流程可以发现隐藏模式。例如,与“Water Damage”相关的理赔可能比“Theft”理赔更常需要返工或专家参与。这些洞察有助于制定更专业、更高效的处理流程。

为什么重要

提供理赔性质的背景信息,支持分析不同损失原因对流程路径和持续时间的影响。

获取位置

这是Claim实体中的标准字段,通常命名为“LossCause”。

示例
碰撞火灾水损盗窃
理赔状态
ClaimStatus
事件发生时理赔的总体状态,例如Open、Closed或Denied。
说明

此属性反映理赔的高层级状态,主要包括“Open”“Closed”“Denied”和“Reopened”。理赔的最终状态是重要的结果指标。

跟踪理赔状态变化有助于定义关键流程里程碑和结果。它可用于识别理赔的最终处理结果、计算拒赔率,并分析理赔结案后重新开启的频率。重新开启通常意味着流程存在问题或客户满意度不足。

为什么重要

表示理赔结果,对于分析拒赔率、结案模式和理赔重新开启频率至关重要。

获取位置

这是Claim实体中的核心字段,通常命名为“State”或“Status”。

示例
开放已关闭已拒赔已重新打开
理赔类型
ClaimType
保险理赔的类别,例如汽车、财产或责任。
说明

理赔类型是根据业务线或损失性质对理赔进行的基础分类。不同理赔类型通常遵循不同流程,复杂程度也不同,并受不同法规约束。

按理赔类型细分流程分析对于获得有意义的洞察至关重要。它支持比较不同业务线的流程绩效、识别特定类型的瓶颈,并根据各类理赔的独特特征制定流程改进方案。

为什么重要

支持对理赔进行细分,因为不同类型的理赔,例如汽车理赔和财产理赔,通常遵循不同流程,并有不同的绩效目标。

获取位置

从ClaimCenter的Policy或Claim实体中推导,通常基于业务线(LOB)代码。

示例
个人汽车商业财产一般责任工伤赔偿
SLA状态
SLAState
表示理赔是否在目标解决日期内结案。
说明

此计算属性为每项已结案理赔提供SLA遵循情况的分类状态。它通过比较“Claim Closed”活动的时间戳与“Resolution Target Date”得出。

此属性直接支持“Claim Resolution Target Adherence”仪表板,将分析简化为“On Time”或“Late”等清晰类别。您可以据此轻松筛选和汇总数据,计算总体SLA遵循率,并深入分析延迟原因。

为什么重要

为SLA遵循情况提供清晰的分类结果,便于筛选、汇总和分析按时完成绩效。

获取位置

计算字段:IF(ActualCloseDate <= ResolutionTargetDate,“On Time”,“Late”)。

示例
按时逾期
保单类型
PolicyType
提交理赔所依据的具体保险保单类型。
说明

保单类型比理赔类型提供更细粒度的分类,用于说明具体保险产品,例如“Homeowners”“Commercial Auto”或“Cyber Liability”。这一层级的详细信息可以揭示与特定产品相关的流程差异。

按保单类型分析流程有助于发现产品特有的低效问题。例如,新推出保单的理赔可能遵循尚不成熟的流程,从而导致延迟。此类分析可以为产品设计和流程标准化提供依据。

为什么重要

支持针对具体保险产品开展流程分析,帮助识别因保单特征不同而产生的处理差异。

获取位置

此信息位于与Claim关联的Policy实体中。

示例
房主综合险商业汽车责任险内陆运输险
最后数据更新时间
LastDataUpdate
表示数据最近一次从源系统刷新或提取的时间戳。
说明

此属性提供最近一次从源系统提取数据的时间戳,是了解分析数据新鲜度所必需的元数据字段。

仪表板和分析应突出显示此信息,帮助用户了解数据的时效性。借助该信息,用户可以判断分析结果是否反映当前运营状态,还是基于较早的数据。

为什么重要

表示数据的新鲜度,帮助用户了解流程分析反映的是当前状态还是历史状态。

获取位置

此值在ETL过程中生成并存储,表示数据加载的时间戳。

示例
2024-07-28T04:00:00Z2024-07-29T04:00:00Z
司法管辖州
JurisdictionState
管辖理赔的州或司法管辖区,该信息决定监管要求。
说明

此属性指定处理理赔所依据的法律管辖区,例如美国的州。不同司法管辖区的保险法规可能存在显著差异,从而影响必需的流程步骤、沟通时限和文档要求。

这是开展合规监控的重要属性。按司法管辖区分析流程,可以确保满足各州特定的监管要求,也可以解释由法律约束而非运营低效导致的周期时间或流程路径差异。

为什么重要

对于合规分析至关重要,因为不同司法管辖区的法规不同,会影响理赔流程。

获取位置

Claim实体中的标准字段,通常命名为“JurisdictionState”。

示例
CANYTXFL
损失日期
LossDate
引发理赔的事故或损失发生日期。
说明

损失日期是实际事件发生的日期,例如车祸或财产损坏,也是提出理赔的依据。它不同于理赔报告日期或创建日期。

损失日期与“Claim Created”活动之间的时间差称为报告延迟,是一项重要KPI。分析该时间差可以帮助了解客户行为以及首次报案渠道的有效性。

为什么重要

提供理赔起因的重要背景信息,并支持分析报告延迟,即从事故发生到提交理赔之间的时间。

获取位置

这是Claim实体中的基础日期字段,通常命名为“LossDate”。

示例
2023-05-102023-04-202023-05-28
支付金额
PaymentAmount
某项支付活动实际支付的金额。
说明

此属性记录针对某项理赔进行的每笔支付金额。一项理赔在整个生命周期内可能包含多笔支付。

在流程挖掘场景中,这对于财务分析至关重要。您可以使用它跟踪每项理赔的总赔付额,根据金额分析支付审批时间,并将流程低效与财务结果关联起来。例如,周期时间较长的理赔可能对应更高的总赔付额。

为什么重要

跟踪理赔中的财务交易,支持分析支付金额及其与流程活动之间的关系。

获取位置

位于与理赔关联的支付相关实体中,通常存储在交易表或支票表内。

示例
4500.00125000.00500.00
是否自动化
IsAutomated
用于标识某项活动由系统自动执行还是由人工用户执行的标志。
说明

此布尔属性用于区分系统执行的活动,例如自动创建准备金、系统生成函件,与理赔员手动执行的活动。

分析此属性是了解理赔流程自动化程度的关键。它有助于识别人工干预集中点、衡量直通式处理计划的成效,并通过定位当前由人工执行的重复性、基于规则的任务,发现新的自动化机会。

为什么重要

区分系统驱动和人工驱动的活动,对于自动化分析和识别人工瓶颈至关重要。

获取位置

通常需要推导得出。例如,可以将由通用“system”用户记录的事件标记为自动化事件。

示例
truefalse
是否返工
IsRework
用于标识某项活动是否代表返工循环,即返回之前的流程阶段。
说明

此计算属性用于标记属于返工循环的活动。例如,如果流程从“Investigation Completed”返回到“Investigation Started”,第二次出现的“Investigation Started”活动就会被标记为返工。

识别返工对于发现流程低效和质量问题至关重要。“Rework and Rejection Frequency”仪表板依靠此指标量化理赔偏离理想“happy path”的频率。分析返工原因可以显著提升流程质量和速度。

为什么重要

明确标记属于返工循环的活动,突出流程低效和质量问题。

获取位置

由流程挖掘工具通过分析每个案例的活动序列计算得出。

示例
truefalse
是否重复请求信息
RepeatedInfoRequestFlag
用于标识同一项理赔是否多次发生“Additional Info Requested”。
说明

如果某项理赔包含多次“Additional Info Requested”活动,此布尔标志将设为true。这通常意味着初始信息收集阶段存在低效问题。

此属性直接支持“Repeated Info Request Rate”KPI,有助于量化初始事实调查不完整的问题。该问题可能导致明显延迟并引发客户不满。分析带有此标志的理赔,可以帮助改进理赔员的检查清单和操作流程,确保一次性请求所有必要信息。

为什么重要

识别信息未能一次性完整收集的低效环节,这些问题可能导致流程延迟和返工。

获取位置

由流程挖掘工具按案例统计“Additional Info Requested”活动的发生次数计算得出。

示例
truefalse
源系统
SourceSystem
提取数据的来源系统。
说明

该属性用于标识事件数据的来源。在现代企业环境中,理赔相关事件可能来自多个系统,例如Guidewire等核心系统、文档管理系统或客户门户。

指定来源系统对于数据治理、排查数据不一致,以及了解流程的技术环境至关重要。它有助于区分核心流程步骤与外围系统中的辅助活动。

为什么重要

标识数据来源,对于数据治理以及涉及多个集成系统的分析至关重要。

获取位置

通常是在数据提取、转换和加载(ETL)过程中添加的静态值。

示例
Guidewire ClaimCenter v10客户门户APIDocumentum
申报金额
ClaimedAmount
投保人最初申报的理赔总金额。
说明

此属性表示申报人报告的损失金额,通常是初始估算值,可能会随着理赔调查和准备准备金而变化。

分析申报金额有助于按财务影响细分理赔。高金额理赔通常比低金额理赔遵循更严格、更复杂的流程。比较不同金额区间的流程,可以发现简化小额理赔处理或加强大额理赔控制的机会。

为什么重要

支持按财务价值细分理赔,因为高金额理赔可能遵循不同且更复杂的流程。

获取位置

此信息可能不是单一字段,而是根据Exposure中记录的初始损失估算值推导得出。

示例
5000.00150000.00750.50
目标解决日期
ResolutionTargetDate
根据内部或监管SLA,理赔预计完成解决的日期。
说明

目标解决日期是为理赔结案设定的截止日期,通常由司法管辖区、理赔类型和保单条款等因素决定。它是衡量绩效和合规情况的基准。

此属性对于构建SLA遵循情况仪表板和KPI至关重要。通过将实际“Claim Closed”日期与目标日期比较,分析可以自动标记逾期理赔、衡量按时完成率,并识别哪些理赔类型或部门难以达到目标。

为什么重要

这是衡量服务级别协议(SLA)遵循情况并识别可能逾期理赔的基准。

获取位置

这可能是自定义字段,也可能根据ClaimCenter中配置的业务规则推导得出,并与特定理赔指标相关。

示例
2023-06-142023-07-202023-08-28
结束时间
EndTime
表示某项活动完成时的时间戳。
说明

结束时间表示某项活动完成的时间,尤其适用于“Investigation”或“Document Review”等具有可测量持续时间的任务。许多流程挖掘活动是瞬时完成的,此时StartTime已足够;但对于具有明确开始和结束时间的活动,同时记录两个时间戳更为准确。

此属性支持精确计算活动处理时间,并将其与等待时间区分开来。借助该信息,您可以识别具体耗时的任务,而不只是观察不同步骤之间的长时间延迟。

为什么重要

支持精确衡量活动完成所需的时间,并将处理时间与等待时间区分开来。

获取位置

可能需要通过查找逻辑上结束该活动的后续事件来推导,例如状态从“In Progress”变为“Completed”。

示例
2023-05-15T17:00:00Z2023-05-16T15:00:00Z2023-06-02T10:00:00Z
部门
Department
负责处理理赔活动的业务单元或部门。
说明

此属性表示指定理赔员所属的部门或团队,例如“Auto Claims”“Property Claims”或“Special Investigations Unit”,为流程提供组织层面的背景信息。

按部门分析对于了解组织层面的流程绩效至关重要。它有助于识别部门间交接延迟、比较团队效率,并在整个理赔组织内更有效地分配资源。

为什么重要

提供组织背景信息,支持跨团队绩效分析,并突出部门间交接问题。

获取位置

此信息通常与ClaimCenter中指定用户或用户组的配置文件关联。

示例
汽车理赔部门财产理赔部门特别调查部门(SIU)
必需 建议 可选

理赔处理活动

以下是建议记录在事件日志中的关键流程步骤和重要里程碑,用于精准发现和分析理赔流程。
7 建议 7 可选
活动 说明
付款发放
该活动标志着付款流程的最后一步,即付款正式发放并发送至财务系统。这是一笔明确记录的财务交易。
为什么重要

该活动对于衡量付款发送流程的效率至关重要,有助于区分审批延误与实际资金发放延误。

获取位置

从cc_check或cc_transaction实体的IssueDate,或状态变为“Issued”或“Submitted”的时间戳中提取。通常这是带有明确时间戳的事件。

采集

识别付款记录中的IssueDate,或状态变为“Issued”的时间戳。

事件类型 explicit
付款获批
表示正式批准结算付款。这是关键审计事件,当具备权限的用户批准交易时会被明确记录。
为什么重要

该关键里程碑解除最终付款步骤的阻塞。分析该活动前后的时间,有助于区分审批工作流或管理人员可用性造成的延误。

获取位置

通常这是cc_history表中与cc_check或cc_transaction实体相关的明确事件,记录状态从“Pending Approval”变为“Approved”。

采集

跟踪特定付款交易状态变为“Approved”的事件。

事件类型 explicit
损失责任项创建
该活动表示创建一项损失责任项,用于表示理赔案件下某项具体潜在负债或损失类型,例如车辆损坏或人身伤害。这是Guidewire中的明确事件。
为什么重要

损失责任项是理赔分段和分析的基础。跟踪其创建情况,有助于了解不同理赔复杂度和损失类型导致的流程差异。

获取位置

从cc_exposure表中新记录的CreateTime中提取。每条记录都关联一个Claim ID。

采集

识别Exposure实体表中新记录的创建时间戳。

事件类型 explicit
理赔拒付
表示最终决定拒付理赔案件,是流程的终止节点。通常通过理赔状态变为关闭状态且原因是“Denied”来推断。
为什么重要

这是关键结果事件。分析拒付频率、原因及导致拒付的流程路径,有助于发现理赔受理、调查或保单解释方面的问题。

获取位置

根据cc_claim表的State字段变为“Closed”,并结合CloseReason字段为“Denied”或类似值来推断。事件时间戳为CloseDate。

采集

筛选状态变为“Closed”且原因代码表示拒付的理赔案件。

事件类型 inferred
理赔案件创建
该活动标志着首次损失通知(FNOL)以及Guidewire ClaimCenter中新理赔记录的正式创建。当新的Claim实体首次保存至数据库时,系统会明确记录此活动。
为什么重要

作为主要开始事件,该活动对于衡量端到端理赔周期时间至关重要,并为后续所有绩效和时长KPI提供基准。

获取位置

这是从cc_claim表的CreateTime中提取的明确事件。创建带有唯一Claim ID的新记录即会触发该事件。

采集

识别基础Claim实体表中新记录的创建时间戳。

事件类型 explicit
理赔结案
标志着所有活动和付款完成后的理赔成功结案。这是主要的成功结束事件,通过理赔主状态的变更来推断。
为什么重要

作为主要结束事件,该活动对于计算端到端周期时间和衡量SLA达成率至关重要,表示理赔生命周期已完成。

获取位置

根据cc_claim表的State字段变为“Closed”来推断。事件时间戳为理赔记录中的CloseDate。

采集

识别理赔主状态字段更新为“Closed”的时间。

事件类型 inferred
设置初始准备金
标志着为某项损失责任项创建第一笔财务准备金交易,用于估算理赔潜在成本。这是关键财务事件,会被明确记录。
为什么重要

该里程碑对于财务分析和了解潜在负债评估速度至关重要。延误可能影响财务规划和报告。

获取位置

该事件从与理赔案件中某项损失责任项关联的第一条cc_reserveline记录创建中提取。该交易的CreateTime即为事件时间戳。

采集

查找指定理赔案件各项损失责任准备金行的最早创建时间戳。

事件类型 explicit
作出责任认定
表示已确定某项损失责任项的责任或过错归属。通常通过Exposure实体的状态变更来推断。
为什么重要

这是决定结算和付款阶段能否推进的关键里程碑。分析作出该决定所需的时间,有助于识别调查和评估阶段的瓶颈。

获取位置

通过cc_history表跟踪cc_exposure实体的State字段或自定义责任状态字段变更来推断。历史记录的时间戳表示事件时间。

采集

监控审计日志或历史表,查看损失责任项状态或责任状态的更新。

事件类型 inferred
完成结算金额计算
该活动表示已确定结算金额,但尚未获准付款。通常可通过创建状态为“Pending Approval”的付款记录来推断。
为什么重要

标志着从评估阶段过渡到付款阶段,是衡量“付款授权提前期”KPI的起点,可揭示审批链中的延误。

获取位置

根据cc_check或cc_transaction记录的CreateTime推断,其初始状态为“Pending Approval”或类似状态,之后才变为“Approved”。

采集

识别处于待审批状态的付款或交易记录创建事件。

事件类型 inferred
开始调查
表示理赔案件或损失责任项正式进入调查阶段。通常通过Guidewire中创建第一项调查相关Activity(任务)来推断。
为什么重要

该活动标志着一个关键且通常耗时较长的阶段开始。分析从案件创建到调查开始的时间,以及调查本身的持续时间,可以发现主要瓶颈。

获取位置

根据cc_activity记录的CreateTime推断,其中ActivityPattern与调查相关,例如“Initial Investigation”或“Contact Witness”。

采集

识别首个具有调查相关模式或主题的任务创建事件。

事件类型 inferred
收到补充信息
标志着补充信息请求完成。当对应的信息请求Activity(任务)被标记为“Completed”时记录该事件。
为什么重要

这是“补充信息收集周期时间”KPI的终点。从请求到收到信息之间的时间过长,是理赔流程延误的常见来源。

获取位置

从cc_activity记录的CloseTime中提取,其中ActivityPattern与信息请求相关,且活动状态必须为“Completed”。

采集

识别请求外部信息任务的完成时间戳。

事件类型 explicit
理赔案件分配
表示将理赔案件分配给特定用户(理赔员)或处理小组。通常通过监控Claim实体中的分配字段变更来推断。
为什么重要

跟踪分配情况对于分析理赔员工作量、识别路由瓶颈,以及衡量受理人员首次行动所需时间至关重要。

获取位置

通过cc_history表跟踪与特定Claim ID关联的AssignedUser或AssignedGroup字段变更来推断。变更时间戳表示事件发生时间。

采集

监控审计日志或历史表,查看理赔分配字段的更新。

事件类型 inferred
理赔重新打开
表示理赔案件从“Closed”状态重新变为“Open”状态,以开展额外工作。通过特定的状态变更序列来推断。
为什么重要

该活动表示发生返工。大量理赔案件重新打开,说明初始结算存在问题、遗漏损失或其他流程故障,导致成本和低效增加。

获取位置

通过cc_history表识别cc_claim实体的State字段从“Closed”变回“Open”或其他活动状态来推断。

采集

监控理赔主状态字段,识别其从关闭状态转为打开状态。

事件类型 inferred
请求补充信息
表示向报案人或第三方发出获取更多信息或文件的请求。通常通过在ClaimCenter中创建明确的Activity(任务)来记录。
为什么重要

该活动是衡量“补充信息收集周期时间”KPI的起点。频繁出现可能表明FNOL流程不完整或信息收集效率低下。

获取位置

从cc_activity记录的CreateTime中提取,其中ActivityPattern与向外部方请求文件或信息相关。

采集

识别请求外部信息的任务创建事件。

事件类型 explicit
建议 可选

提取指南

如何从Guidewire ClaimCenter获取数据

准备开始了吗?

使用本模板准备分析数据,深入了解您的理赔处理流程。立即开始优化工作流。

加快理赔处理,更快解决案件

消除积压、预防欺诈,并以70%的直通式处理为目标。

开始免费试用

无需信用卡,几分钟即可完成设置。