One list for every claim a customer has filed

When you file something with an insurance company — a claim after a crash, a request to cancel a policy, an application for a payout — you want one thing: to know where it is right now.

Our customers couldn't get that. Their requests lived in three separate systems, and the website showed them in three separate places, in three different shapes.

Three lists, three different worlds

Each type of request had grown up on its own:

• Policy cancellations were stored in our own database.
• Accident claims filed through the website sat in a different table, with their own set of statuses.
• Payout applications lived in a completely separate system, run by another team.

None of them agreed on anything — not the date format, not the status names, not even what "finished" meant. Showing them side by side wasn't a design problem, it was a translation problem.

One shape for every request

I built a single point on the server that fetches from all three sources and rewrites them into one identical shape. Whatever the request is, it comes out with the same fields: what product it's for, which policy, when it was filed, and — the important part — a list of steps.

The steps work like a parcel tracker. Each one is marked done, in progress, still to come, or failed. The website doesn't try to interpret any status text; it just draws the steps it's given. All the business rules live in one place on the server, so adding a fourth source later won't require touching the page at all.

Two details mattered more than I expected:

1. A countdown on the waiting step. Payout applications have a 15-day review window, so instead of an open-ended "under review", people see how long is left.
2. "Paid" only when it's actually paid. The other system marks an application "done" both when money is sent and when a decision letter goes out. Telling someone they've been paid when they haven't is worse than telling them nothing, so that became its own, honest state.

What happens when one of them is down

The risk in joining systems together is that you inherit all of their outages. If the external payout system is unavailable, the obvious outcome is an error page — and the customer also loses sight of the two requests that were perfectly fine.

So the list never fails as a whole. If one source doesn't answer, the other two still come back, and the response says plainly which one was missing. The page stays up, slightly incomplete, instead of going dark.

Why I'm proud of it

The code ended up smaller than what it replaced. The page that renders the list lost about a third of its lines while gaining a step tracker, document downloads and a countdown. That's usually a sign the complexity went to the right place.

But the real result isn't in the code. A customer can now open one page and see, in a single glance, every request they've made and exactly where each one stands. That's a phone call they don't have to make.