Why insurance workflow automation breaks on exceptions

A broker’s client adds ten cars to a fleet policy. Nine go through. The tenth is flagged as stolen and can’t be insured. The automation that was supposed to handle the request now has two bad options: fail the whole batch, or push nine through and leave the tenth in someone’s inbox with no note about what went wrong.

Most insurance teams have a version of this story. The clean case flows through, and anything slightly off goes back to a person who now has less context than before the automation existed. McKinsey estimates that more than half of today’s claims activities could be automated by 2030, and says complex claims will keep needing human judgment. The work that stays with people is the work that went off plan, which makes it the part most worth designing for.

The happy path is a choice someone made

Workflows are usually drawn from the process map or from the form. A request comes in, the documents arrive, the data is checked, the system is updated and the client hears back. Each step assumes the previous one went well. That is a sensible place to start, and it describes the process the team would like to have.

Process mining researchers built a whole field around that gap. Their manifesto sets out to study real processes as opposed to assumed ones, because what the event logs show rarely matches the drawing. In an insurance office the gap looks like a missing account number or a reply that answers a different question.

It also explains why so many first automation projects disappoint. EY reported that as many as 30 to 50 percent of initial robotic process automation projects fail, and one of the recurring mistakes on its list is picking processes that are too complex for the tool. In insurance, complexity usually means exceptions.

Lisanne Bainbridge saw the deeper problem in 1983. In Ironies of automation she showed that when a machine takes over the routine work, people are left with the tasks that could not be automated, and get less practice at them. Automate the easy part of a claims flow and a handler’s day turns into a steady stream of the hard part, without the routine cases that used to give them context.

Where cases leave the path

The exits are predictable once you write them down. Most start with the client or the document, and very few with the system itself.

The first row is the most common, and it is rarely the client’s fault. A Belgian broker described it to us like this:

The two-request email is harder to spot and just as frequent. One insurer we spoke with estimated that around 60 percent of the customer emails they wanted to automate carried more than one request. A workflow that expects one intent per message treats each of those as an exception.

Where the exception goes next

An exception is rarely hard to solve. The cost sits in the handoff. The case leaves the workflow as an email or a notification, lands in a shared inbox, gets forwarded, and is opened by two or three people before anyone owns it. The client waits, and so does the insurer or broker on the other side.

The McKinsey Global Institute estimated that knowledge workers spend about 28 percent of their week managing email. In an insurance office a good share of that mail is exceptions coming back in, because every case that leaves the workflow returns as a message somebody has to read and route. The animation below shows the difference in miniature. Switch between the two settings to see where the same exceptions end up.

Put a number on it

Few teams know what their exceptions cost, because the time is spread across many people and many small interruptions. A rough estimate is enough to decide whether it is worth fixing. The defaults below are an illustration of a mid-sized office, so replace them with your own numbers.

With 400 cases a month, a quarter of them leaving the path and 35 minutes of handling each, the team spends around 58 hours a month on exceptions. That is close to half a person. Most of the time goes into finding the case and asking the client again. The fix itself is usually quick.

Designing for the case that goes wrong

A workflow that survives exceptions is built around the case. The case holds the messages, the documents, the data and the status, so an exception becomes a state of the case with an owner and a history. Four habits make the difference in practice.

1. Finish what you can, hand over the rest with context. Nine cars get added and confirmed to the client. The tenth becomes a task that says why it stopped.

2. Take the case in whatever shape it arrives. A reply to an old thread or a scanned letter gets read and attached to the right case, wherever it came in.

3. Let the system say when it is unsure. If a contract number can’t be matched, the case flags it for a person to check, so a misread number is caught before it travels further.

4. Show who the case is waiting for. When the team can see at a glance whether the next move is theirs or the client’s, exceptions stop hiding in the gaps between people.

People stay in the work. They move to the part where judgment matters, with the context to use it.

The honest trade

Designing for exceptions takes more work up front. You have to decide who owns each kind of exception and what the fallback is when the data doesn’t match. A happy-path automation is quicker to build and looks better in a demo. The difference shows a few months later, when volume grows and the exceptions grow with it.

A useful test is to take last month’s exceptions and ask where each one waited, and for how long. If the honest answer is “someone’s inbox”, that is where the next improvement sits.

Penbox is built around the case for this reason. Case automations move a case forward when its data changes and log each step in the timeline, a failed automation can be retried, and every case shows whether it is waiting on your team or on the client. Email Intelligence and Document Intelligence read what comes in and attach it to the right case, so exceptions stay where someone can pick them up.

To go further, read why claims intake is a reading problem, what email ping-pong costs a team, or how the FNOL process works for brokers. If you are new to the idea, start with what case management is.