您的理赔处理数据模板

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

您的理赔处理数据模板

欢迎使用这份理赔处理优化指南。此模板列出了需要收集的关键数据属性和需要跟踪的重要活动,并提供了清晰的数据提取说明。您可以据此确保收集全面流程分析所需的信息。
  • 建议收集的属性
  • 需要跟踪的关键活动
  • Guidewire ClaimCenter数据提取指南
刚接触事件日志?了解 如何创建流程挖掘事件日志.

理赔处理属性

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

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

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

重要性

此时间戳对于事件排序、周期时间和时长计算,以及流程延迟识别都不可或缺。

获取途径

可在Guidewire ClaimCenter的历史记录或审计表中找到,通常对应“CreateTime”或“UpdateTime”字段。

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

此属性描述理赔流程中的具体步骤或里程碑,例如“创建理赔”“开始调查”或“发放赔款”。同一案例ID对应的活动序列构成流程路径。

分析活动的顺序、频次及活动间隔时长,是流程挖掘的核心。借此可以发现流程模型、识别瓶颈、发现返工循环并分析流程偏差。

重要性

此属性定义流程步骤,便于呈现流程图,并分析流程路径和瓶颈。

获取途径

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

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

理赔ID是理赔流程分析的核心,可从提交到结案唯一标识每个案例。它将相关活动、文档、付款和沟通记录关联起来,确保完整、一致地呈现理赔生命周期。

在流程挖掘中,数据集中的每个事件都与理赔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
造成损失事件的具体原因,例如碰撞、火灾或水损。
说明

此属性详细说明提交理赔的原因。损失原因通常决定所需的调查步骤、需要的专家类型以及理赔案件的整体复杂程度。

按损失原因分析流程可以发现潜在规律。例如,与盗窃理赔相比,水损理赔可能更常出现返工,或需要更多专家参与。这些洞察有助于制定更有针对性、更高效的处理流程。

重要性

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

获取途径

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

示例
碰撞火灾水损盗窃
理赔状态
ClaimStatus
事件发生时理赔案件的整体状态,例如未结、已结或已拒赔。
说明

此属性反映理赔案件的整体状态,主要状态包括“未结”“已结”“已拒赔”和“重新开启”。理赔最终状态是一项重要的结果指标。

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

重要性

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

获取途径

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

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

理赔类型是根据业务险种或损失性质对理赔案件进行的基本分类。不同类型的理赔通常遵循不同流程,复杂程度各异,也受不同法规约束。

按理赔类型细分流程分析,才能获得有意义的洞察。这样可以比较不同险种的流程绩效、识别特定类型的瓶颈,并根据各类理赔的特点制定改进措施。

重要性

支持按理赔类型细分分析。不同类型(例如汽车与财产理赔)通常遵循不同流程,绩效目标也各不相同。

获取途径

从ClaimCenter的Policy或Claim实体中提取,通常依据业务险种(LOB)代码。

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

此计算属性以类别形式显示每项已结案理赔的SLA达标情况。它通过比较“理赔结案”活动的时间戳与“目标结案日期”得出。

此属性直接支持“理赔目标结案达标情况”仪表板,将分析结果归纳为“按时”或“逾期”等清晰类别。您可以轻松筛选和汇总数据,计算整体SLA达标率,并逐级下钻分析延迟原因。

重要性

以清晰的类别显示SLA达标结果,便于筛选、汇总和分析按时完成情况。

获取途径

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

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

与理赔类型相比,保单类型的分类更细,具体到保险产品,例如“房主险”“商业汽车险”或“网络责任险”。这一层级的细分有助于发现特定产品相关的流程差异。

按保单类型分析流程,有助于发现产品特有的低效环节。例如,新推出的保单可能对应尚不成熟的流程,导致处理延迟。分析结果可为产品设计和流程标准化提供参考。

重要性

支持针对特定保险产品开展流程分析,帮助识别不同保单特点对处理方式的影响。

获取途径

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

示例
房主综合险商业汽车责任险内陆海上保险
司法管辖州
JurisdictionState
负责管辖理赔案件的州或司法管辖区,决定适用的监管要求。
说明

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

此属性对于合规监控至关重要。按司法管辖区分析流程,可以确认是否满足各州的监管要求。它也有助于解释由法律约束而非运营低效造成的周期时间或流程路径差异。

重要性

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

获取途径

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

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

损失发生日期是实际事故发生的日期,例如车祸或财产损坏,与理赔报案或创建日期不同。

从损失发生日期到“创建理赔”活动之间的时间差称为报案延迟,是一项重要的KPI。分析这一指标有助于了解客户行为,以及首次报案渠道的有效性。

重要性

提供理赔起因的重要背景信息,并有助于分析报案延迟,即事故发生到提交理赔之间的时间。

获取途径

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

示例
2023-05-102023-04-202023-05-28
数据最近更新时间
LastDataUpdate
指示数据最近一次从源系统刷新或提取的时间戳。
说明

此属性记录最近一次从源系统提取数据的时间戳,是用于判断分析数据时效性的重要元数据。

仪表板和分析结果应醒目显示此信息,让用户了解数据的更新时间。借此可以判断分析反映的是当前运营状况,还是基于较早的数据。

重要性

显示数据的时效性,帮助用户了解流程分析反映的最新情况。

获取途径

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

示例
2024-07-28T04:00:00Z2024-07-29T04:00:00Z
是否自动执行
IsAutomated
标记活动由系统自动执行还是由人工用户完成。
说明

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

分析此属性是了解理赔流程自动化程度的关键。它有助于识别人工介入频繁的环节、衡量直通式处理计划的成效,并找出新的自动化机会,例如定位目前由人工执行的重复性、基于规则的任务。

重要性

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

获取途径

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

示例
truefalse
是否返工
IsRework
标记活动是否属于返工循环,即流程返回到之前的阶段。
说明

此计算属性用于标记属于返工循环的活动。例如,流程从“调查完成”返回到“开始调查”时,第二次出现的“开始调查”活动会被标记为返工。

识别返工是发现流程低效和质量问题的基础。“返工与拒绝频率”仪表板依靠此指标,量化理赔案件偏离理想路径的频率。分析返工原因有助于显著提升流程质量和处理速度。

重要性

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

获取途径

流程挖掘工具会分析每个案例的活动顺序并计算此值。

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

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

指定源系统对于数据治理、排查数据不一致问题以及了解流程所处的技术环境至关重要。它有助于区分核心流程步骤与外围系统提供的支持活动。

重要性

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

获取途径

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

示例
Guidewire ClaimCenter v10客户门户APIDocumentum
目标结案日期
ResolutionTargetDate
根据内部或监管SLA,理赔案件预计解决的截止日期。
说明

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

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

重要性

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

获取途径

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

示例
2023-06-142023-07-202023-08-28
索赔金额
ClaimedAmount
投保人最初申报的索赔总金额。
说明

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

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

重要性

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

获取途径

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

示例
5000.00150000.00750.50
结束时间
EndTime
指示活动完成时间的时间戳。
说明

结束时间标记活动完成的时刻,尤其适用于“调查”或“文档审核”等具有可测量时长的任务。许多流程挖掘活动是瞬时的,只需StartTime即可;对于有明确开始和结束时间的活动,则应同时记录这两个时间戳。

此属性可准确计算活动处理时间,并将其与等待时间区分开来。这样可以识别具体哪些任务耗时较长,而不只是观察不同步骤之间的长时间延迟。

重要性

此属性可准确测量活动的完成时长,并将处理时间与等待时间区分开来。

获取途径

可能需要通过查找后续事件来推导该值,例如状态从“进行中”变为“已完成”,以此判断活动何时结束。

示例
2023-05-15T17:00:00Z2023-05-16T15:00:00Z2023-06-02T10:00:00Z
赔付金额
PaymentAmount
某项赔付活动实际支付的金额。
说明

此属性记录针对某项理赔支付的每笔款项金额。同一理赔案件在整个生命周期内可能有多笔赔付。

在流程挖掘分析中,此属性对于财务分析至关重要。它可用于跟踪每项理赔的总赔付金额、分析不同金额对应的赔付审批时长,并将流程低效与财务结果关联起来。例如,周期时间较长的理赔案件可能对应更高的总赔付金额。

重要性

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

获取途径

可在与理赔案件关联的赔付实体中找到,通常位于交易表或支票表中。

示例
4500.00125000.00500.00
部门
Department
负责处理理赔活动的业务单元或部门。
说明

此属性表示指定理赔专员所属的部门或团队,例如“汽车理赔”“财产理赔”或“特别调查组”,为流程提供组织层面的背景信息。

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

重要性

提供组织层面的背景信息,支持跨团队绩效分析,并揭示部门间交接问题。

获取途径

此信息通常关联到ClaimCenter中指定用户或群组的个人资料。

示例
汽车理赔部财产理赔组特别调查组(SIU)
重复请求信息
RepeatedInfoRequestFlag
标记同一理赔案件是否多次发生“请求补充信息”。
说明

如果某项理赔案件发生多次“请求补充信息”活动,此布尔标记将设为true。这通常表明初次信息收集环节效率不高。

此属性直接支持“重复请求信息率”KPI,有助于量化初次事实调查不完整的问题,而这可能导致明显延迟并令客户不满。分析带有此标记的理赔案件,有助于改进理赔专员使用的清单和流程,确保一次性收集所有必要信息。

重要性

识别首次信息收集不完整造成的低效问题,以及由此导致的流程延迟和返工。

获取途径

流程挖掘工具会统计每个案例中“请求补充信息”活动的发生次数并计算此值。

示例
truefalse
必填 建议填写 选填

理赔处理活动

在事件日志中记录这些关键流程步骤和重要里程碑,以便准确发现并分析理赔流程。
7 建议填写 7 选填
活动 说明
付款已发出
此活动标志着付款流程的最后一步,即正式发出付款并将其发送至财务系统。这是一笔明确记录的财务交易。
重要性

此活动对于衡量付款发放效率至关重要,有助于区分审批延误与实际拨款发放延误。

获取途径

从cc_check或cc_transaction实体的IssueDate字段,或状态变更为“已发出”或“已提交”的记录中获取。通常会明确记录带时间戳的事件。

采集

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

事件类型 explicit
付款已批准
表示结算付款已正式获批。这是重要的审计事件,具有审批权限的用户批准交易时会明确记录此事件。
重要性

这一重要里程碑使最终付款步骤得以继续。分析此活动前后的耗时,有助于区分审批工作流或经理无法及时处理所造成的延误。

获取途径

通常会在cc_history表中明确记录与cc_check或cc_transaction实体相关的事件,显示状态从“待审批”变为“已批准”。

采集

跟踪特定付款交易的状态变更事件,确认其变为“已批准”。

事件类型 explicit
已设置初始准备金
表示已为某个损失项目创建首笔财务准备金交易,用于估算理赔的潜在成本。这是重要的财务事件,会被明确记录。
重要性

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

获取途径

此事件根据理赔中某个损失项目关联的首条cc_reserveline记录创建情况获取。该交易的CreateTime即为事件时间戳。

采集

查找指定理赔各损失项目准备金记录中的最早创建时间戳。

事件类型 explicit
损失项目已创建
此活动表示已创建一个损失项目,即理赔项下某项潜在责任或损失类型(例如车辆损坏、人身伤害)。这是Guidewire中明确记录的事件。
重要性

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

获取途径

从cc_exposure表中新记录的CreateTime字段获取。每条记录都关联到一个理赔ID。

采集

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

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

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

获取途径

这是从cc_claim表的CreateTime字段中明确记录的事件。新记录创建后会生成唯一理赔ID,并触发此事件。

采集

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

事件类型 explicit
理赔已拒赔
表示最终决定拒绝理赔,是流程的终止节点。通常根据理赔状态变为已关闭且原因是“已拒赔”来推断此事件。
重要性

这是重要的结果事件。分析拒赔的频率、原因和相关流程路径,有助于发现理赔受理、调查或保单解读方面的问题。

获取途径

根据cc_claim表的State字段变为“已关闭”,且CloseReason字段为“已拒赔”或类似值来推断此事件。事件时间戳为CloseDate。

采集

筛选状态变更为“已关闭”且原因代码表示拒赔的理赔记录。

事件类型 inferred
理赔已结案
表示所有活动和付款完成后,理赔已成功结案。这是主要的成功结束事件,通常根据理赔主状态变更来推断。
重要性

作为主要结束事件,此活动对于计算端到端周期时间和衡量SLA达成情况至关重要,标志着理赔生命周期结束。

获取途径

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

采集

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

事件类型 inferred
已收到补充信息
表示补充信息请求已完成。当对应的信息请求“活动”(任务)标记为“已完成”时,系统会记录此事件。
重要性

这是衡量“补充信息收集周期时间”KPI的终点。从请求到收到信息的间隔过长,是理赔流程中常见的延误原因。

获取途径

从cc_activity记录的CloseTime字段获取,其中ActivityPattern与信息请求有关。该活动的状态必须为“已完成”。

采集

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

事件类型 explicit
已请求补充信息
表示已向索赔人或第三方发出补充信息或文档请求。通常会在ClaimCenter中明确记录为新建的“活动”(任务)。
重要性

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

获取途径

从cc_activity记录的CreateTime字段获取,其中ActivityPattern与向外部相关方请求文档或信息有关。

采集

识别用于请求外部信息的任务创建记录。

事件类型 explicit
理赔已分配
表示将理赔分配给特定用户(理赔员)或团队处理。通常通过监控Claim实体中的分配字段变更来推断此事件。
重要性

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

获取途径

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

采集

监控审计日志或历史记录表中理赔分配字段的更新。

事件类型 inferred
理赔已重新开启
表示理赔从“已关闭”状态重新变为“已开启”状态,以便继续处理。通常根据特定的状态变更顺序推断此事件。
重要性

此活动表示发生了返工。大量理赔重新开启,可能说明初次结算存在问题、遗漏损失或其他流程失误,导致成本增加、效率降低。

获取途径

通过cc_history表识别cc_claim实体的State字段从“已关闭”变回“已开启”或其他活跃状态来推断此事件。

采集

监控理赔主状态字段,识别其从已关闭状态变为已开启状态的情况。

事件类型 inferred
结算金额已计算
此活动表示结算金额已确定,但尚未获准付款。可根据状态为“待审批”的付款记录创建情况推断此事件。
重要性

此活动标志着流程从评估转入付款阶段,也是衡量“付款授权前置时间”KPI的起点,可用于发现审批链中的延误。

获取途径

根据cc_check或cc_transaction记录的CreateTime推断,其初始状态为“待审批”或类似状态,尚未变为“已批准”。

采集

识别处于预审批状态的付款或交易记录创建情况。

事件类型 inferred
调查已开始
表示理赔或损失项目的调查阶段正式开始。通常根据Guidewire中首个与调查相关的“活动”(任务)创建情况推断。
重要性

此活动标志着一个重要且通常耗时较长的阶段开始。分析调查启动前的等待时间和调查本身的持续时间,有助于发现主要瓶颈。

获取途径

根据cc_activity记录的CreateTime推断,其中ActivityPattern与调查相关(例如“初步调查”“联系证人”)。

采集

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

事件类型 inferred
责任认定已完成
表示已确定某个损失项目的责任或过错。通常根据Exposure实体的状态变更推断此事件。
重要性

这是影响结算和付款阶段的重要决策里程碑。分析作出决定所需的时间,有助于发现调查和评估阶段的瓶颈。

获取途径

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

采集

监控审计日志或历史记录表中损失项目状态或责任状态的更新。

事件类型 inferred
建议填写 选填

数据提取指南

如何从Guidewire ClaimCenter获取数据

准备好开始了吗?

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

加快理赔处理,更快结案

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

开始免费试用

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