Turning complex logic into a simple claims experience
Super.com, all in one savings app
Shipment Protection pays members back when a package is lost, stolen or damaged. This is the part of it that runs when something has actually gone wrong — the form a member fills in, and the eligibility rules behind it.
Overview
What happens when the package does not arrive
Signing up for protection is a promise. A claim is the moment the promise is tested — and it arrives when the member is already annoyed, because something they paid for has gone missing.
I designed the in-app claims experience that replaced the third-party form Shipment Protection launched on, translating the policy's rules into a flow that adapts to the member's situation rather than asking them to work out which parts apply.
The problem
A third-party form, hard at both ends
The original claims process ran on a form owned by someone else. It was difficult for members to complete and difficult for our operations team to work through — a claim that arrived incomplete came back as a support conversation rather than as a decision.
The solution
A flow that knows which rules apply
The policy has conditions — what counts as lost, how long after delivery a claim can be filed, what evidence a given case needs. In a static form all of them are the member's problem to read. In a flow they are the flow's problem: it asks only what this claim needs, and it asks in an order that makes sense from where the member is standing.
Fewer incomplete claims arriving meant roughly half as many reaching the support team for review.
The claim, before and after
Third-party form
In-app claim flow