Insurance example - processing a claim

Published on

By Peter Hilton

A business process example

Sometimes, a large team has to collaborate on high-volume task processing, such as assessing insurance claims. This article explains how workflow roles can help.

You can also do this yourself using role-based assignment in Effektif, as demonstrated in the Insurance example screencast.

The insurance claim process

To understand this process example, it’s helpful to start with the process goal, typically an end result phrased in terms of something a customer values. Modelling and executing the process is merely a means to that goal. In this case, we can summarise the process and its goal as: Process an insurance claim in order to make a payment to a customer This is a high-level goal that doesn’t include alternative possibilities, such as rejecting the claim, or things that could go wrong. A high-level view of the process is shown in this model:

In summary, the process is to assess a claim and make a payment, or reject the claim for some reason. For this example, we’ll simplify the final step into merely calculating the payment amount and suppose that a follow-on process will actually make the payment to the customer, or send a rejection letter in case the calculated amount is zero. Instead, we’ll focus how we assess the claim in order to calculate the payment amount. In particular, we want to be able to model the case that a large team is handling a high volume of claims.

Handling large volumes

To handle a large volume of claims, we need a way to work with a large team, in order to do lots of work in parallel. However, a small volume of claims require special processing. Perhaps the claim is very large, which means that an assessor must visit the customer and investigate the claim, or perhaps it is a complex claim that is difficult to assess. If this special processing needs a senior assessor to assess the claim, then this will make it difficult to assign the Assess claim tasks to team members without first knowing more about the claim. To address this situation, we can split the task to assess the claim into a process that allows us to use a different flow for claims that require special processing. We can add checks that a junior assessor can perform to see if special processing is required, and process the claim themselves if not. When special processing is required, specific assessment tasks can be assigned to a senior assessor.

In this version of the process we have separated four easier tasks (along the top row) from the two harder tasks (on the bottom row). The path along the top row includes two exclusive gateways – decisions to check whether special processing is required. Now it’s easier to scale our team. Most claims can be handled completely by junior assessors. Junior assessors also perform the checks to discover whether a claim requires special processing by a senior assessor. Senior assessors can be left with a smaller workload: they only have to investigate high-value claims and process complex claims.

Modelling process roles

We have identified two different roles, to optimise handling a large number of cases: Junior  Assessor and Senior Assessor. Part of our process definition is that each task will always be assigned to one of the two roles.

  • Junior Assessor – for the four top-row tasks (a low-value simple claim).
  • Senior Assessor – for the two bottom-row tasks (special processing).

These two roles are only defined within this process, so they are not organisational roles. Within a small insurance company, employees with the job title (organisational role) Junior Clerk might be candidates for the Junior Assessor process role, while any Manager or Senior Partner might be a candidate for the Senior Assessor process role. A larger company might have more specialist positions in the company that correspond more closely to the process roles. As far is process modelling goes, this is separate to the process definition.