Claims
Claims workflow
Root has a multi-step claims workflow allowing you to easily manage claims in an efficient and compliant way. The Root claims process can either be integrated into your own claims frontend using the claims API endpoints, or you can use the Root management dashboard to manage claims against your product.
Claims pass through the following steps as they are processed on Root:
- Opening a claim - At this step the claim object is created and (optional) claimant information is saved to the claim.
- Capturing information and documents - This information is product specific and could include the particulars of the incident, the benefit being claimed for, medical reports, photos, etc.
- Assessment - After all required information is captured, the claim is sent to a claim assessor, who recommends an outcome for the claim and sends it to the claims supervisor for confirmation.
- Assessment confirmation - A claims supervisor will review the assessor's recommendation and bind the decision of approval or repudiation.
- Claim finalisation and payout - If the claim is approved, the payout or fulfilment request is created. In the case of a repudiation, a formal repudiation response can be sent to the claimant after which the claim can be closed.
Apart from Step 2: Capturing information and documents, the Root claims workflow is standard across all product modules. You configure Step 2 by specifying what information needs to be captured in the claim description form to process a claim. This is defined in a claims blocks schema specific to your product module. The claims blocks schema needs to be configured irrespective of whether you use your own claims frontend or use the Root management dashboard.
The claim description form on the Root management dashboard.
We recommend using the Root management dashboard to manage claims
We generally advise clients to use Root's out-of-the-box dashboard to manage claims, instead of building a custom claim management interface. This is due to the large scope and complexity of the claim management workflow.
You can also follow a hybrid approach, for example by building a custom frontend portal that allows customers to open claims via the API, and then manage claims on the Root management dashboard after they have been opened.
Claim and approval status
As a claim progresses through the steps outlined above, its status will change. A claim has both a claim_status and an approval_status. The claim_status relates to the overall status of the claim and indicates at what stage of the process the claim is between being opened and finalized. The approval_status relates to the claim outcome, for example whether the claim outcome is still pending, has been approved or has been repudiated.
A claim's claim_status and approval_status are accessible to the claims blocks schema. This means that specific form inputs can be disabled or hidden on the dashboard depending on the claim status. For example, you could disable a block storing the description of the incident while the claim has a claim_status of "acknowledged". Read more about configuring claims blocks in the claims blocks guide.
Claim status
The possible values of a claim's status are set out in the table below. The claim_status is stored as a field on the claim object.
| Claim status | Description |
|---|---|
"open" | Claims are created with the open status. This is the state during which all the claim information is being collected and captured. |
"in_review" | This state indicates that a claim is within first assessment. When a claim is in review, the claims assessor reviews the claim, decides on a claim outcome and submits the recommendation for confirmation to the Claim Supervisor |
"acknowledged" | A claim with status acknowledged can either be sent back for another round of review or the outcome recommendation can be accepted. |
"pending_payout" | This states indicates that there are payments pending. This status will be reached if the accepted outcome is approved or goodwill. |
"paid_out" | Once the claim has been successfully paid out or fulfilled the status can be changed to “paid out”. This status indicates that the claim is considered completed and can now be closed. |
"closed" | This state indicates that a claim is closed. A claim can move to closed from any other state. This is a terminal state and closed claims cannot be reopened. |
Approval status
The possible values of a claim's approval status are set out below. The approval_status is stored as a field on the claim object.
| Approval status | Description |
|---|---|
"pending" | Claims are created with an outcome status of pending. This indicates that no outcome has been recommended or confirmed yet. |
"approved" | The claim is valid, and a payout of some sort is granted. |
"repudiated" | The claim is rejected (not approved) on the grounds of the claim event not meeting the requirements for valid claims as set out in the policy wording. |
"no-claim" | The claim can’t be lodged as it is invalid, for example because the policy lapsed or was cancelled prior to the date of the incident. |
"goodwill" | The claim is not meant to be approved, but is paid out on goodwill. This status is generally treated the same as approved. |
Payout and fulfillment requests
If a claim is approved, this typically results in some form of compensation in favour of the beneficiary. Such benefit transfers are implemented on Root by means of payout requests (for monetary compensation) and fulfillment requests (for non-monetary compensation).
Payout requests contain information on the recipient (including their bank account details) and the amount to be paid out. Fulfillment requests contain additional customised information on the nature and quantity of the compensation.
These requests are objects saved to the platform and displayed in the payout workflow tooling on the Root management dashboard. Creating a request does not automatically result in a transfer to the beneficiary. You need to execute the transfer and then update the payout request, either via the API (update a payout request) or manually on the Root management dashboard.
Payout requests are available for export in our data exports tooling, which enables you to receive and process them in bulk.
Root allows you to configure special disbursement blocks directly in the claims workflow, to allow agents to generate payout and fulfillment requests as soon as a claim has been approved. You can read more about how to configure these blocks for your product module in the disbursement blocks guide.
Updated 7 months ago