Retrace · B2B SaaS · Design walkthrough
Claim Task Helper
A side panel that turns a rejected insurance claim into three steps anyone at the front desk can follow.
Problem
When a payer rejects a claim, it sends back a short reason. The reason often isn't the real cause, and the fix usually happens in another system. Staff are left to work out what went wrong and what to do.
What I designed
A panel beside the claim that explains the rejection in plain language, then walks the person through the fix one confirmed step at a time, ending in resubmission.
Try it
The panel, rebuilt for this page
This is a working recreation of the design. Complete the steps in order.
Jun 01 – Jun 06, 2022
- Date of birth
- 01/01/2000
- Phone
- (408) 888-8888
- Insurance payer
- Delta Dental
- Subscriber relationship
- Self
- Subscriber name
- Omar Siphron
- Subscriber ID
- U8315064502
The problem in one example
“Subscriber ID not found” when the ID is fine
The example in the design is a real kind of rejection. The payer's message says the subscriber ID wasn't found. Read literally, that sends someone off to re-check the ID, which is correct.
The actual cause is elsewhere. An eligibility check finds an active record for that ID. The claim was rejected because the subscriber's name was misspelled, and the payer matches on name as well as ID.
The message misleads
The stated reason points at the wrong field.
The fix is elsewhere
The name lives in the practice management system, not in the claim screen.
The loop is easy to break
Fix it, wait for the sync, resubmit. Skip the middle step and the claim bounces again.
Someone who handles claims all day knows this pattern. A front-desk coordinator who sees it twice a month doesn't, and shouldn't need to.
Design decisions
Five choices, and why
1 · A panel beside the claim, not a separate page
The helper opens from a button on the claim and slides in over the right edge. The claim stays visible underneath. The person can read “the name is misspelled” and look straight at the subscriber name on the same screen. A separate task page or a modal would have hidden the evidence the explanation refers to.
2 · Keep the payer's words, then translate them
The panel shows the rejection exactly as the payer sent it, then a plain-language diagnosis under its own heading. I kept both on purpose. The original wording is what staff will see in payer portals and on the phone, so they need to recognise it. The translation is what tells them what to do.
3 · Say what the system already checked
The diagnosis opens with “we ran eligibility and found an active record”. That one line does two jobs. It rules out the obvious suspicion, and it shows the reasoning, so the person can trust the conclusion without taking it on faith.
4 · Steps the person confirms, because the system can't see them
The fix happens in the practice's own software. Retrace can't observe someone correcting a name in OpenDental. So each step ends with an explicit confirmation, “I've updated it”, “I've verified”, and the next step unlocks only after it. The checkmarks also make the task resumable: someone interrupted at the front desk can come back and see where they stopped.
5 · Verify before resubmitting
Step 2 looks redundant and is the most important one. Resubmitting before the corrected name has synced produces the same rejection, a second wasted cycle with the payer. Making verification its own step, with its own button, turns an easy-to-skip check into part of the path.
And: comments stay with the task
A comment thread sits under the steps. Rejected claims often pass between people, and “called the payer, waiting on a callback” belongs next to the task, not in someone's notebook.
What I'd validate
Open questions
How many rejections fit three steps?
This design covers one reason. I'd map the most frequent rejection reasons and check which reduce to a short fixed path and which need branching.
Can step 2 confirm itself?
If Retrace can detect that the synced name changed, the system should tick that step and the person shouldn't have to.
Do the words work?
The panel is mostly writing. I'd test the diagnosis and step text with front-desk staff and watch where they hesitate.
What does “confirmed” really mean?
A self-reported checkbox can be clicked through. I'd watch whether people confirm without doing, and whether that shows up as repeat rejections.
How I'd measure it
| Signal | What it tells us |
|---|---|
| Acceptance rate on resubmission | Whether the guided fix actually fixes the claim. |
| Time from rejection to resubmission | Whether rejected claims stop sitting untouched. |
| Tasks closed without contacting support | Whether the explanation is enough on its own. |
| Same claim rejected twice for the same reason | Whether people are confirming steps they didn't do. |