A verification system saving $27-51M per year

The Challenge

What was happening

Picture someone who just got married, adding their spouse to their health plan. Adding a dependent happens in one system. Enrolling in benefits happens in another. The two don't talk to each other, so a single task, "add my family member and keep them covered," was already split across disconnected places.

Then it got worse. If the dependent was flagged for verification, the only path forward was "Contact HR." The employee left the flow, opened a support case, and got into back-and-forth conversations with an agent to work out what to submit and whether it passed. There was no self-service way to upload a document, and no visible status anywhere. Coverage sat in limbo while the emails went back and forth.

The before journey: a task split across separate systems, an HR-case detour with no self-service, and no visible status the whole way through.

An audit flagged a meaningful share of enrolled dependents as potentially ineligible, a real cost risk to the health plan. But the process built to catch that was doing collateral damage: 72% of the people it flagged were actually eligible. They just couldn't get through it.

Research

The number that reframed everything wasn't about who failed to respond. It was how long the task itself took. Adding a dependent and getting them verified meant hopping across separate systems and page after page, and while an employee did all that, the dependent had no coverage. The delay was the problem, not the people.

One task, scattered across systems

Adding a dependent and getting them verified meant weaving through page after page across separate systems.

The whole time, the dependent had no coverage. The delay was the pain, not the people.

8+ pages to verify
one dependent

3 separate systems
to move between

2 days to clear
each review

One task, seven stops, three systems, and it still ends with coverage pending.

When we traced a real case end to end, the task never sat still in one place. An employee started in the benefits portal, got bounced into an HR case, jumped out to a policy article to check the rules, then back again to see whether the dependent had coverage yet. Each hop was a fresh page, a new system, and no shared status carried between them.

Four barriers came up again and again:

• Fragmented journey: adding a dependent, verifying, and enrolling lived in separate systems
• No self-service: the only path was an HR case and manual conversations
• No visible status: no way to see if documents were received, in review, or approved
• Coverage limbo: no clear answer to "is my family covered right now?"

Design Strategy

The first instinct was to block higher-risk cases at enrollment until they verified. Efficient on paper, but it delayed coverage for legitimate families and singled out some groups more than others. So we flipped it: everyone gets covered immediately, and verification runs in a 30-day window in the background.

Before committing, I put four approaches on the table with the tradeoffs spelled out, so the decision was made with eyes open, not by gut.

The options I brought to Benefits Science, Legal, Operations, and leadership. We aligned on the 30-day window together.

That flip became the whole design: dependents get immediate coverage while a 30-day window runs in the background. Every touchpoint answers the three questions employees actually ask.

1. "Is my dependent covered right now?"
2. "What exactly do I need to submit?"
3. "What happens if I miss the deadline?"

The redesigned flow: immediate coverage with verification running in the background over 30 days.

The real constraint

I couldn't merge the systems. Adding a dependent, uploading documents, and enrolling would stay in separate tools, and the upload itself still lived in a different internal portal. Rebuilding that architecture wasn't on the table.

So instead of forcing everything into one system, I designed a consistent status layer across every benefits touchpoint. Wherever an employee looked, the enrollment page, the dependent's profile, the benefits home, they'd see the same thing: this dependent's verification status, a plain-language message about what it meant for coverage, and the days left to submit. The document upload could stay where it was, as long as the status and the countdown followed the employee everywhere else.

Working toward it

Getting to that answer took a few wrong turns first. Early on I tried explaining the cover-first model with a bottom sheet that popped up over the enrollment page, and building the process into the dependent's profile as a step-by-step tracker. These are rough screens, closer to thinking out loud than final work. Each one made the process legible in a single spot, then showed me its own limit: a sheet you dismiss and a tracker on one page both left the rest of the journey blank. That is what pushed me toward carrying the status everywhere instead of parking it in one place.

Early exploration: a bottom sheet to explain the 30-day model, and a step tracker on the dependent's profile. Both worked in one spot but left the rest of the journey blank, which is what pointed me at a status that follows the employee everywhere.

Solution

The systems stayed separate, but the story stopped being fragmented. Coverage starts the moment you add a dependent, and every benefits touchpoint shows the same status, the same plain message, and the same countdown, with a deep link out to upload when you're ready.

Every state, in plain language

Coverage is live from the moment you add a dependent, so no status ever means "you're not covered yet." Each one tells you where you stand, what it means for your family, and the single next step.

Every status the enrollment page can show, at a glance. Coverage stays active throughout, so the states reassure rather than alarm.

The same status, everywhere you look

The systems behind this never merged. What made it feel like one journey was a status layer that reads identically wherever the employee lands. Step through each status below and watch it hold its shape across every touchpoint, from the enrolment page to the post-enrollment confirmation, saved choices, and the family page.

One status, shown across every touchpoint. The words, the colour, and the countdown match wherever the employee looks, so nothing has to be relearned between screens.

▶ Walk through the interactive prototype The cover-first flow and status layer, clickable in Figma →

Reminders that respect attention

A single email blast would get ignored or mistaken for spam. Instead, reminders layer across the surfaces people already use, escalating only as the deadline nears. Act early and you see just one message. Leave it late and the nudges get more direct.

Agent tools

Supporting employees at scale meant equipping agents with the right tools too. The admin console was updated so support agents could see verification status in real time, extend a window when someone needed a few more days, and step in without escalating.

Rollout

The system shipped in phases across the US employee base, starting with a single-state pilot and expanding outward. Each phase validated the experience before widening the population, so problems surfaced small rather than all at once.

Impact

What I learned