Data Template: Claims Processing

The Claim ID is the fundamental case identifier that links all activities, events, and data points for a single insurance claim from submission to closure.

In process mining, this attribute is crucial for reconstructing the end-to-end journey of each claim. It allows for the aggregation of all related events into a cohesive case, enabling analysis of cycle times, process variants, and bottlenecks for individual claims.

This is the essential key for tracking a claim's lifecycle. Without a unique Claim ID, it is impossible to connect the various process steps into a coherent journey for analysis.

This is typically the 'CaseNumber' on the Case object or a custom unique ID field on the 'Claim' (FinancialServicesCloud.Claim) object.

This attribute describes a single step or milestone in the claims process, such as 'Claim Submitted', 'Initial Review Performed', or 'Payment Issued'. It forms the backbone of the process map.

Analyzing the sequence and frequency of activities helps identify the most common process paths (variants), discover deviations from the standard process, and pinpoint activities that are frequently repeated, indicating rework.

It defines the 'what' in the process, allowing for the visualization of the process flow and the identification of bottlenecks, rework loops, and process variations.

Derived from changes to the 'Status' field on the Claim/Case object, or from the 'Subject' of related Task or Event records.

Event Time provides the precise date and time for each activity in the claim's lifecycle. This temporal data is essential for ordering events chronologically and calculating durations.

In analysis, timestamps are used to calculate all time-related metrics, including cycle times between activities, waiting times, and total case duration. They are fundamental for creating a dynamic process animation and for identifying when and where delays occur.

This attribute provides the 'when' for each event, making it possible to calculate durations, analyze process performance over time, and identify time-based bottlenecks.

For status changes, this is the 'CreatedDate' from the object's field history (e.g., CaseHistory). For tasks, it's the 'CompletedDateTime' or 'CreatedDate'.

This attribute indicates the date and time when the data was last pulled from Salesforce Financial Services Cloud. It provides context for the freshness of the data being analyzed.

This is important for dashboard users to understand how current the analysis is. It helps manage expectations about the data's timeliness and is crucial for validating that data pipelines are running as scheduled.

Provides crucial context on data freshness, ensuring that analysts and business users are aware of how up-to-date the process view is.

This value is generated and stamped onto the dataset by the data extraction tool or ETL process at the time of execution.

This attribute specifies the source application or platform from which the data was extracted. For this process, it will consistently be 'Salesforce Financial Services Cloud'.

While it may seem constant, explicitly tracking the source system is a best practice, especially in environments where data might be merged from multiple systems. It ensures clarity on data provenance and is useful for data governance and validation.

Confirms data provenance, which is crucial for data governance, troubleshooting, and when integrating data from multiple enterprise systems.

This is typically a static value added during the data extraction and transformation process to label the dataset's origin.

This attribute identifies the individual claims adjuster responsible for an activity or the case as a whole. It is typically derived from the owner of the claim case or the person who completed a specific task.

Analyzing performance by adjuster is critical for operational management. Dashboards like 'Adjuster Workload & Performance' use this attribute to track claim volume, active cases, and cycle times per person, supporting balanced workload distribution and identifying coaching opportunities.

This attribute is essential for analyzing team and individual performance, managing workloads, and identifying best practices or training needs.

This is the 'OwnerId' field on the Case or Claim object, which links to the User object to get the adjuster's name.

Claim Status provides a snapshot of where the claim is in its lifecycle, such as 'New', 'Investigation', 'Pending Customer', or 'Closed'. It's a key attribute for understanding the current state of the process.

This attribute is used heavily in operational dashboards like the 'Open Claims Ageing Report' to visualize the current workload and identify claims that are stuck in a particular status for too long. Analyzing transitions between statuses is also a primary method for defining the activities in the process map.

Provides real-time visibility into the current state of active claims, helping to manage backlogs and identify stalled cases.

This is the standard 'Status' field on the Case or Claim object.

Claim Type is a critical dimension for segmenting and analyzing the claims process. Different types of claims often follow distinct processes, have different complexities, and are subject to different SLAs.

By filtering or comparing performance based on Claim Type, analysts can uncover type-specific bottlenecks, assess compliance with targeted SLAs, and understand how process variations differ across categories. It is used in dashboards like 'Claim SLA Compliance Overview' and 'Claim Rejection Reason Analysis' to provide more targeted insights.

Allows for the segmentation of claims to compare processes, identify type-specific issues, and tailor improvement initiatives.

This is often a standard 'Type' or custom picklist field on the Case or Claim object.

This attribute specifies the business unit or department assigned to the claim, such as 'Personal Lines', 'Commercial Auto', or 'Special Investigations Unit'.

Analyzing the process by department helps identify performance differences between teams, understand how workloads are distributed, and pinpoint department-specific process deviations or bottlenecks. This dimension is valuable in dashboards like 'Claim SLA Compliance Overview' to see how different parts of the organization are performing.

Enables performance comparison across different business units, helping to identify best practices and allocate resources more effectively.

This could be a custom field on the Claim/Case object or inferred from the assigned user's profile or role in the User object.

The End Time attribute records the exact moment an activity concludes. While Start Time (EventTime) marks the beginning, End Time provides the other boundary needed to measure how long an activity took to complete.

In analysis, having both a Start Time and End Time allows for the precise calculation of activity processing times, distinguishing them from waiting times between activities. This is fundamental for building dashboards like 'Process Step Duration Breakdown' and for pinpointing inefficiencies within specific tasks, not just between them.

Enables the precise calculation of active processing time for each activity, which is crucial for separating value-adding time from waiting time.

Derived from timestamp data. For instance, if 'Initial Review Performed' is triggered by a status change, the EndTime could be the timestamp of the next status change.

This attribute indicates how a claim was first reported, for example, via a web portal, mobile app, phone call, or email. The submission channel can significantly impact the quality of initial information and subsequent processing steps.

Analyzing claims by submission channel helps in understanding demand patterns and the efficiency of different intake methods. The 'Claims Throughput & Volume' dashboard uses this attribute to track how many claims are coming from each channel over time, which can inform resource allocation and technology investment decisions.

Helps in evaluating the efficiency of different intake channels and understanding if certain channels lead to more rework or longer cycle times.

This is typically a custom picklist field on the Claim/Case object, often labeled 'Origin' or 'Channel'.

This attribute represents the total amount of loss or damages being claimed by the customer at the outset of the process. This value often influences the claim's complexity, the level of scrutiny required, and the processing path it follows.

Analyzing process metrics based on claim value can reveal important patterns. For instance, higher-value claims may have longer cycle times, involve more steps, or be routed to specialized teams. This helps in setting realistic SLAs and in forecasting financial reserves.

Provides financial context to each case, allowing for analysis of how claim value impacts process complexity, duration, and outcomes.

This would be a custom currency field on the Claim object in Financial Services Cloud, for example 'ClaimedAmount__c'.

This metric calculates the duration of a single process step, representing the 'active' time spent working on it. It is typically calculated as the difference between the End Time and Start Time of an activity.

This is a fundamental metric for bottleneck analysis. The 'Process Step Duration Breakdown' dashboard relies on this calculation to show which specific activities consume the most time, helping to focus improvement efforts where they will have the greatest impact.

Quantifies the actual work time for each step, helping to distinguish active processing bottlenecks from idle waiting time.

Calculated field: 'EndTime' minus 'EventTime' (StartTime). This calculation is performed within the process mining tool or during data transformation.

This metric measures the total end-to-end duration of a claim case, from its initial submission to its final closure. It is calculated as the difference between the timestamp of the very last event and the very first event for a given Claim ID.

This is one of the most important KPIs for process performance, directly addressed by the 'Average Claim Cycle Time' KPI and the 'Claim End-to-End Cycle Time' dashboard. Reducing this value is often a primary goal of process improvement projects.

Measures the overall end-to-end efficiency of the process and is a key indicator of customer experience.

Calculated field: Timestamp of the last event minus the timestamp of the first event for each 'ClaimId'. This is computed by the process mining tool.

The Customer ID links the claim to the person or organization that filed it. In Salesforce, this is typically a lookup to the Account or Contact object.

This attribute allows for a customer-centric view of the claims process. It can be used to analyze claim history per customer, identify frequent claimants, and personalize service. It's also crucial for linking claim data with other customer data from a CRM for a holistic business view.

Enables a customer-centric analysis, helping to understand claim patterns for individual clients and measure the impact of the claims process on customer relationships.

This is a lookup field on the Claim/Case object that points to the Account or Contact object (e.g., 'AccountId' or 'ContactId').

This flag differentiates between tasks completed by human adjusters and those executed by automated workflows, rules, or system integrations. For example, an initial claim registration might be fully automated.

Analyzing automation is key to understanding process efficiency. It helps measure the success of automation initiatives, identifies which steps are good candidates for future automation, and compares the speed and consistency of automated tasks versus manual ones.

Distinguishes between human and system-driven activities, which is critical for evaluating the impact and effectiveness of automation.

This is typically derived. If the user associated with an event is a generic 'System' or 'Integration' user, this flag is set to true.

This flag is set to true when a claim loops back to a previous stage in the process. A classic example is moving from 'Investigation Completed' back to 'Additional Information Requested'. The logic for identifying rework is defined based on process knowledge.

This attribute is fundamental for the 'Claims Rework Loop Analysis' dashboard and the 'Rework Rate' KPI. It allows for direct quantification of the frequency and impact of rework, which is a primary driver of inefficiency, increased costs, and longer cycle times.

Directly flags inefficient process loops, allowing for easy quantification of rework and targeted analysis of its root causes.

Calculated field. This is derived by analyzing the sequence of activities for each case. For example, if 'Activity A' is followed by 'Activity B' and then 'Activity A' again, the second instance of 'A' is rework.

This attribute provides geographical context for the claim, such as the state where the loss occurred or the country of the policyholder. This data can be derived from the policyholder's address or from details of the loss.

Geographical analysis can reveal regional trends in claim types, frequencies, and processing times. It can also be used to assess performance across different regional offices and ensure compliance with location-specific regulations.

Allows for geographical analysis of claims, which can highlight regional performance differences, fraud patterns, or impacts of local events.

Typically derived from the address fields (e.g., 'BillingState', 'BillingCountry') on the associated Account or Contact object.

The Loss Date records when the event covered by the insurance policy happened. This is distinct from the date the claim was submitted.

This attribute is important for compliance and for analyzing the lag time between the incident and its reporting. Large gaps can sometimes indicate potential issues or require different handling procedures. It provides valuable context for understanding the full timeline of events.

Helps analyze the lag between an incident and its reporting, which can impact investigation and settlement.

This would be a custom date field on the Claim object, e.g., 'DateOfLoss__c'.

The Policy Number links the claim back to the customer's active insurance policy. This provides essential context about coverage, limits, and policyholder history.

While not always a primary driver of process flow, it's a key piece of contextual data. It can be used to join claim data with policy data for deeper analysis, such as understanding if certain policy types are associated with more frequent or complex claims.

Links the claim to the underlying insurance policy, enabling broader analysis of claims patterns related to specific policies or coverage types.

This would be a lookup field on the Claim object that references the 'InsurancePolicy' object in Financial Services Cloud.

When a claim's final decision is 'Rejected', this attribute provides the underlying reason, such as 'Not Covered by Policy', 'Fraud Suspected', or 'Incomplete Information'.

This is the key attribute for the 'Claim Rejection Reason Analysis' dashboard. By analyzing the frequency of different rejection reasons, often segmented by claim type or department, the organization can identify opportunities to improve underwriting, clarify policy language, or enhance the information gathering process to reduce invalid submissions.

Provides direct insight into why claims are denied, which is essential for improving underwriting policies and reducing wasteful processing of invalid claims.

This is typically a custom picklist field on the Claim/Case object that becomes mandatory when the status is moved to 'Rejected' or 'Closed - Denied'.

This attribute records the actual amount paid to the claimant when the claim is closed and settled. This can differ from the initially claimed amount due to assessment, deductibles, and policy limits.

Analyzing the settlement amount, especially in relation to the initially claimed amount, provides insights into loss assessment accuracy and settlement negotiation outcomes. It is a critical financial metric for understanding the total cost of claims.

Represents the ultimate financial impact of a claim, crucial for financial analysis, reserving, and assessing the accuracy of initial loss assessments.

This would be a custom currency field on the Claim object or on a related Payment object in Financial Services Cloud.

This attribute is a categorical outcome, typically with values like 'Met' or 'Breached'. It is derived by comparing the claim's actual completion date (the timestamp of the final activity) with its 'SlaTargetDate'.

This is the core metric for the 'SLA Adherence Rate' KPI and the 'Claim SLA Compliance Overview' dashboard. It provides a clear, black-and-white measure of performance against targets and is essential for compliance reporting and operational management.

Provides a clear indicator of performance against timeliness targets, which is crucial for customer satisfaction and regulatory compliance.

Calculated field: If 'EndTime' of the final event is less than or equal to 'SlaTargetDate', then 'Met', else 'Breached'. This logic is applied during data transformation or within the process mining tool.

The SLA Target Date is a calculated or manually set date that represents the deadline for claim resolution. It is the benchmark against which timeliness is measured.

This attribute is essential for monitoring performance against promises made to customers or regulators. It is the basis for the 'SLA Adherence Rate' KPI and the 'Claim SLA Compliance Overview' dashboard, allowing the organization to track what percentage of claims are resolved on time and to identify which claim types or departments are struggling to meet their targets.

Defines the performance target for claim resolution time, enabling direct measurement of SLA compliance.

This is typically a custom formula field or a date field on the Claim/Case object, calculated based on the submission date and claim type.