Claim rejection rate cut to ≈1/3, after a rollout that had to be pulled

System: Desktop & mobile
Constraint: Unreliable third-party service
Proof: Observed result
Role: Product designer

1 · The constraint

I was the product designer on this initiative for its whole duration: both design epics (phase I and II), desktop and mobile, the entitlement-check display, error handling for the third-party service, the practitioner override mechanism, and the remote usability study that ran alongside it.

Practitioners were billing blind. Even with a correctly registered supplementary insurer, at the moment they validated an invoice they had no way to know whether it would be paid, how much, or why it might be refused — the rejection surfaced days or weeks later, disconnected from the action that caused it. Rejection analysis showed that ≈70% of rejections were tied to the validity of supplementary coverage, and that a real-time entitlement check before billing could, in theory, cut the rejection rate by close to a factor of 10. That estimate is what justified the investment.

Where the signal gets lost

Friction point for the practitioner
Neutral step in the journey

The challenge

How do you display uncertain financial information from a third-party service that might be down, without ever blocking the practitioner or making them responsible for a system error?

2 · The blueprint

Mapping the edge cases

The actual design work wasn't displaying the success state, but structuring the failures. Four states were explicitly mapped to handle third-party unreliability:

Billing screen where coverage is confirmed: the full amount is covered by third-party payment and nothing is left to collect from the patient — Coverage valid — third-party payment confirmed, nothing left to collect.

Billing screen where the patient's supplementary coverage has expired; the screen explains it in plain language and offers to add a new one — Coverage expired — a plain-language explanation, and a direct action to ask the patient for the new card.

Billing screen where the third-party service is temporarily unavailable; the compulsory share is still advanced and only the supplementary falls back to patient payment — Service unavailable — the compulsory share still applies; only the supplementary falls back to the patient.

Billing screen where the supplementary insurer's details are incomplete; an agreement picker lets the practitioner resolve it without leaving the invoice — Supplementary data incomplete — the invoice is still priced, and an agreement picker appears inline.

State 1 of 4

Each failure state says what happened and what to do next, in plain language: practitioners aren't insurance specialists, and an error they can't read turns into a support call.

Architectural decision: the system never blocks the human

The software acts purely as a technical relay for the insurance data. The practitioner always retains the final decision to bypass the warning and secure the payment. Blocking uncertain cases would have transferred a legal responsibility to the software.

3 · The reality check

When the system failed

The first gradual rollout generated a severe spike in support tickets, and the cohort had to be deactivated the same day. The interface had successfully caught the errors, but failed to explain them to the practitioners. Two external events landed in the same window and compounded it: a major supplementary insurer changed its processing rules, and a technical operator went down for 24 hours.

The impact:

Support call volume up ≈30%.
Answer rate down almost 20 points.
Support cases tied to this topic roughly doubled.

Team retrospective

“We expected the errors to be rare and obvious. We're seeing the opposite.”

Team member, internal retrospective

“One practice had 100% of its supplementary third-party payments failing. Support was already stretched thin.”

Team member, internal retrospective

The fix

The friction had been transferred to the support team. We paused the rollout, rewrote the error states with contextual help links, added an override mechanism so practitioners could act on a rejection themselves, and resumed in finer cohorts to spread the support load.

4 · Outcome

Rejection rate · normalized index

Baseline indexed to 100. Absolute rates withheld. Two documented snapshots, intermediate trajectory not available.

Baseline

100

Rejection index before the initiative

One year later

Observed result

≈ 1/3

On the most exposed segment, comfortably below 2% vs. a market reference several times higher

Attribution note:

Result covers the broader payment-guarantee initiative, not a single interface change. The under-1% target is not documented as reached, and the no-degraded-support constraint wasn't held at the first attempt.

Observed result

Rejection rate on the most exposed segment cut to ≈1/3 over the following year, landing comfortably under 2% — against a market reference several times higher. Baseline indexed to 100; absolute rates withheld. Two documented snapshots, intermediate trajectory not available.

Ground truth

Support isn't a post-release metric; it's a sensor for design quality. The honest part of this case is that the first rollout failed, and that failure is what produced the version that worked. An interface that requires a phone call to be understood is a system that failed to absorb the cognitive load.

Short read · what came next

After launch: a coverage ceiling

After the payment guarantee launched, only ≈60% of invoices actually received a guarantee number. The next step produced no screen: three targeted fixes, each sized in coverage points — a major supplementary-insurance operator that changed its management regime, a family of directory error codes, and truncated or malformed identifiers. A threshold calculation set the bar: above ≈84% guaranteed invoices to get under 1% rejection.

One diagnostic signal mattered more than the targets. On a separate analysis scope, part of the refusals were forced by practitioners themselves, overriding the warning knowingly. It supports the decision never to block billing — and questions how readable the warning is.

Proof: fixes shipped, final measure not documented. The ≈60% → ≈80% coverage goal and the per-fix gains remain targets and estimates. Role: design owner of the fixes, desktop and mobile.