Insurance Claim Tracker

Solution

Every claim now says where it stands, what comes next, and by when.

Claim progress you can follow

Every step carries its own status and an expected completion date, so the assessment phase stops being a silent black box.

Telling FWD what happened

The prompt asks for exactly what an assessor needs, in both languages: date, time, place, what happened and which part of the body. A review step and a plain confirmation close the loop, so nobody wonders whether it went through.

Finding one claim among many

Filters are ordered by what people actually use, and because employee benefits and life policies filter on different attributes, choosing the policy comes first instead of showing everyone every option.

Overview

Making a stressful journey easier to follow.

Customers struggled with the app after submitting a claim, and every struggle became a call to customer service. The brief was to find where the journey breaks down and streamline what happens next.

FWD Insurance↗ Life insurance

Problem

Submitting a claim dropped it into a black box.

The pain concentrated on one stage

Mapping the journey with the CX, Life Ops and Employee Benefits teams put the damage in one place. Assessment carried nearly all of it, for the customer and the business at once, which is why the work was scoped as a claim tracker rather than a submission fix.

Where that came from

I sat with the CX team and read the feedback they had been collecting, then walked the claim journey end to end with Life Ops and Employee Benefits.

Enlarge Expectation vs reality

Enlarge Proactiveness gap

Enlarge Tracker date spec

Six complaints, three problems

Then design audited the screens that carried it

A heuristic evaluation of the two live claim screens turned the complaints into four concrete usability violations.

Screen 1: Home

• Unclear claim stage Three bare dots with no labels: the card never says which stage the claim is in, or what happens next. Visibility of system status

Screen 2: My Claims

• Single-selection filter Every field takes exactly one value, so common asks like two claim types at once are impossible. Flexibility & efficiency of use
• Filter first, claims below the fold The filter fills the first screen even when it is empty, pushing the claims people came for out of view. Aesthetic & minimalist design
• Unclear information architecture A flat wall of label and value pairs with no hierarchy: people had to read everything to find anything. Recognition rather than recall

Goals

Know where a claim stands, and what to do next, without calling anyone. User goal

Cut claim-status calls and repeat submissions, and earn back trust after a claim. Business goal

Design process

Finding the gaps in the current experience, then designing for transparency

Every iteration was checked against one test: at any moment, can a customer tell what is true about their claim?

Every state a claim can be in, before any screen.

Five tracker states cover the whole system. Three scenarios draw on them for thirteen cards, including the ones nobody enjoys designing.

The claim leads now, not the filter.

Before

Five empty filters filled the first screen, and the claim arrived as a wall of labels.

After

The claim comes first, then its progress, with a date at every stage.

A card that says where the claim is.

Before

Three unlabelled dots: no stage, no next step, no date.

After

The stage, and the date it is expected by, on the card itself.

Sending a document became part of the app.

FWD asks for five kinds of thing after a claim is in. Each one gets the same four beats: say exactly what is needed, take it in, let the customer review it, confirm it arrived.

1 / 3 Fixes No timely update when something is pending on them

What is outstanding, in one list

Every request waiting on the customer, its due date, and a Submit now on each.

2 / 3 Fixes Unclear which documents are required

The rules before the file, not after

Accepted formats, size limit and file count sit above the upload, so the first try is the right one.

3 / 3

One look before it goes

The file and the declaration to agree to, on one screen.

Then: pre-approved claims.

Before a planned hospital stay or surgery, the customer sends FWD the doctor's treatment plan and cost estimate. FWD answers in writing: what it covers, and what the customer pays. That is pre-approval. The customer is not asking whether they are covered, only what is still needed and when the bill is settled.

Before

Anything FWD needed from the customer was inside a step, found only by reading down the tracker.

After

A Pre-approved tag, a banner counting what is waiting on the customer, and a step for what FWD collects on their behalf.

Challenges

The backend was slow and the legal wording was fixed, so the design had to work around both.

Outcome

Claim transparency improved within a month of launch.

↓20%

Claim-status inquiries to CX

↓8%

Incomplete (NIGO) submissions

4.5/5

Post-claim CSAT