Settlement Claim Status Portal UI

Quick answer

Claim status portal UI gives class members one place to see where their settlement claim stands—without forcing them to call the administrator or guess which email thread matters. Design a claimant dashboard with CLM-* status timeline, pending action cards (upload docs, fix bank details, sign tax forms), and payment tracking linked to PAY-* records. Support multi-claim households when one login covers spouse, minor, or deceased-estate claims. Connect to settlement claims, payment disbursement, disputes, and call center lookup. Start from the Figma guides hub and pair with account dashboard, progress steppers, and Dev Mode handoff.

Who this is for

Product designers building claimant-facing settlement portals—not generic order tracking from ecommerce.
Settlement administrators reducing call volume by surfacing status and next steps in self-service.
Class counsel defining which status labels and timelines claimants may see versus admin-only fields.

Claim status lifecycle overview

ClaimStatusPortal — Account: user@example.com · 2 active CLM-* · 1 pending action
├── Entry points:
│   ├── Post-login dashboard after [claim filing](/designing-breach-settlement-notice-and-victim-compensation-claims-ui-in-figma/)
│   ├── Magic link from status email · SMS deep link
│   ├── [Notice FAQ](/designing-breach-faq-and-notice-landing-page-ui-in-figma/) "Check claim status" CTA
│   └── [Call center](/designing-breach-call-center-and-agent-script-ui-in-figma/) sends portal link after lookup
├── ID namespace:
│   ├── CLM-* (primary claim) · PAY-* (payment) · DIS-* (dispute)
│   ├── MIN-*/GUA-* · DEC-*/HEI-* · FOR-*/XBR-* (special claim types)
│   └── ACT-* (pending action item for claimant)
├── Dashboard sections:
│   ├── Active claims summary cards
│   ├── Pending actions (blocking payout)
│   ├── Recent timeline events
│   └── Documents and notices archive
└── Status visibility rule: Show counsel-approved labels only—never internal fraud scores or admin notes

Claim state (claimant view)	Timeline shows	Action card
Submitted	Filed date · Confirmation number	None
Under review	Review started · Expected SLA badge	Upload additional docs if requested
Approved	Approval date · Payment amount	Complete tax form (W-9/W-8)
Payment pending	PAY-* created · Method selected	Fix invalid bank details
Paid	PAY-* delivered · Receipt available	Download tax doc
Disputed	DIS-* opened · Hearing date if set	Submit appeal evidence

Verdict: Every blocking state needs a visible action card—“Under review” alone without SLA or next step drives call center volume.

Claimant dashboard layout

ClaimantDashboard — Settlement: Acme Data Breach · Claims: 2 · Actions: 1 urgent
├── Header:
│   ├── Settlement name · Case ID · Last updated timestamp
│   ├── Claimant name (masked email/phone on shared devices)
│   └── [Notification prefs](/designing-notification-preferences-and-communication-settings-ui-in-figma/) link
├── Active claims row (cards):
│   ├── CLM-992-44102 · Status: Payment pending · $125.00
│   ├── CLM-992-55201 · Status: Guardian review · Minor · Linked GUA-*
│   └── Card click → Claim detail page
├── Pending actions panel (priority sorted):
│   ├── ACT-992-0088 · "Upload W-9 to release payment" · Due: none · Blocks PAY-*
│   ├── ACT-992-0091 · "Verify bank account" · Failed ACH return
│   └── Empty state: "No actions needed—check back for updates"
├── Recent activity feed (last 5 events):
│   ├── "Payment initiated" · PAY-992-44102 · Aug 20
│   ├── "Claim approved" · CLM-992-44102 · Aug 15
│   └── "Claim submitted" · CLM-992-44102 · Aug 1
└── Footer links: FAQ · Contact · [Opt-out status](/designing-breach-settlement-opt-out-and-class-member-exclusion-ui-in-figma/) · Privacy

Use account dashboard card patterns—settlement dashboards need case-scoped context in every header, not generic “My Account.”

Claim detail and status timeline

ClaimDetail — CLM-992-44102 · Status: Payment pending · Amount: $125.00 gross
├── Summary strip:
│   ├── Claim ID · Filed date · Payment tier (if tiered settlement)
│   ├── Current status badge · SLA estimate when in review
│   └── Estimated payment date (range, not promise)
├── Vertical timeline (newest bottom or top—pick one, stay consistent):
│   ├── ✓ Claim submitted · Aug 1 · Confirmation CLM-992-44102
│   ├── ✓ Eligibility verified · Aug 5
│   ├── ✓ Claim approved · Aug 15 · Amount $125.00
│   ├── ● Tax form required · Aug 16 · [Complete W-9] CTA
│   ├── ○ Payment processing · Pending TAX-*
│   └── ○ Payment delivered · Not started
├── Related records (tabs or accordion):
│   ├── Payments (PAY-* list)
│   ├── Documents uploaded
│   ├── Notices received (PDF archive)
│   └── Disputes (DIS-* if any)
├── Special claim overlays:
│   ├── [Minor](/designing-breach-settlement-minor-claimant-and-guardian-designation-ui-in-figma/): Show GUA-* status, hide direct PAY-* to minor
│   ├── [Deceased](/designing-breach-settlement-deceased-claimant-and-heir-designation-ui-in-figma/): Show HEI-* heir chain
│   └── [Foreign](/designing-breach-settlement-foreign-claimant-and-international-payment-ui-in-figma/): Show XBR-* and extended SLA
└── Actions: Download claim summary PDF · Contact support · Open dispute

Timeline events must use plain-language labels counsel approves—avoid internal codes like “XBR-* pending” without explanation.

Pending action cards

Action items block payout until resolved—design them as first-class UI, not buried emails:

ActionCard — ACT-992-0088 · Type: tax_form · Blocks: PAY-992-44102 · Priority: high
├── Card anatomy:
│   ├── Icon by type (document, bank, signature, identity)
│   ├── Title: "Complete your tax form"
│   ├── Body: Why required · What happens when done
│   ├── Primary CTA: "Complete W-9" → [tax wizard](/designing-breach-settlement-tax-reporting-and-1099-ui-in-figma/)
│   └── Secondary: "Learn why this is required" → FAQ anchor
├── Action types (settlement-configured):
│   ├── tax_form · identity_doc · bank_update · guardian_doc · heir_probate
│   ├── dispute_response · opt_out_confirmation · address_correction
│   └── signature_required · consent_acknowledgment
├── States:
│   ├── Open · In progress (draft saved) · Completed · Expired
│   └── Overdue badge if counsel sets deadline (rare for claimants)
├── Multi-claim: Same ACT-* may block multiple CLM-*—show affected claims list
└── Completion: Timeline event auto-added · Email confirmation · Clear ACT-* from dashboard

Pair urgent actions with inline alerts on login—do not rely on email alone.

Payment status tracking

PaymentTracking — PAY-992-44102 · CLM-992-44102 · Method: ACH · Status: In transit
├── Payment summary card on claim detail:
│   ├── Gross amount · Withholding (if any) · Net amount
│   ├── Method: ACH · Check · Wire (PAY-INT-*)
│   ├── Status progression: Initiated → Sent → Delivered · Failed
│   └── Tracking reference when available (check number, wire ref)
├── Failed payment UX:
│   ├── Reason code in plain language ("Account closed", "Invalid routing")
│   ├── [Update payment method] CTA → [payment wizard](/designing-breach-settlement-payment-disbursement-and-payout-tracking-ui-in-figma/)
│   └── Retry countdown or manual admin retry note
├── Check delivery:
│   ├── Mailed date · Expected delivery window
│   └── [Report check not received] → creates support ticket, not auto-reissue
├── [Unclaimed funds](/designing-breach-settlement-unclaimed-funds-and-escheatment-ui-in-figma/) warning:
│   └── If PAY-* stale > dormancy threshold · "Claim your payment before [date]"
└── Tax documents: Link to 1099/1042-S when available post-year-end

Never show full bank account numbers—mask to last four digits only.

Multi-claim and household view

HouseholdView — Account holder: Jane Doe · Linked claims: 3
├── Use cases:
│   ├── Spouse filed separate CLM-* under same email
│   ├── Parent manages [minor](/designing-breach-settlement-minor-claimant-and-guardian-designation-ui-in-figma/) CLM-* as GUA-*
│   ├── Estate executor views [deceased](/designing-breach-settlement-deceased-claimant-and-heir-designation-ui-in-figma/) CLM-*
│   └── Same person, multiple settlement tiers (rare—show separate cards)
├── Dashboard aggregation:
│   ├── "3 claims · 1 needs action" summary
│   ├── Filter: All · Needs action · Paid · Closed
│   └── Sort: Urgent actions first · Then by status
├── Access control:
│   ├── Claimant sees only CLM-* linked to verified identity
│   ├── Guardian sees minor CLM-* after GUA-* approval
│   └── Executor sees DEC-* after HEI-* verification—no cross-household leakage
├── Claim lookup (unauthenticated):
│   ├── CLM-* + last name + last 4 SSN or DOB
│   ├── [Email OTP](/designing-email-verification-and-otp-ui-in-figma/) before showing detail
│   └── Rate limit · No enumeration of valid CLM-* IDs
└── Empty states: No claims found · Opted out · Claim denied with appeal link

Household view reduces duplicate logins but requires strict identity linking—never show another claimant’s CLM-* from name guess alone.

Administrator status configuration console

StatusConfigConsole — Settlement: Acme · 12 claimant-visible statuses · 4 internal-only
├── Status label mapping:
│   ├── Internal: FRAUD_REVIEW → Claimant: "Under review"
│   ├── Internal: PAY_HOLD_TAX → Claimant: "Tax form required" + ACT-*
│   └── Blocklist: Never expose SANCTION_HIT, DUPLICATE_SUSPECT to claimant
├── SLA templates:
│   ├── Standard review: 30 days · Foreign XBR-*: 15–30 business days
│   └── Display range on timeline, not fixed date unless court-ordered
├── Notification triggers:
│   ├── Status change → Email + optional SMS
│   ├── ACT-* created → Immediate alert
│   └── PAY-* delivered → Receipt email with portal link
├── Preview mode: See dashboard as sample CLM-* states
└── Audit: status_label_version · published_at · counsel_approval_ref

Designers wireframe both claimant and admin config—claimant labels come from admin mapping, not hard-coded in frontend.

Comparison: status portal vs adjacent settlement surfaces

Surface	Focus	This UI adds
Settlement claims	Filing CLM-*	Post-filing visibility
Payment disbursement	PAY-* execution	Claimant-facing PAY status
Disputes	DIS-* workflow	Dispute status on timeline
Call center	Agent lookup	Self-service deflection
Notice FAQ	Static info	Personalized status

Handoff checklist (Dev Mode)

ClaimantDashboard — account_id, settlement_case_id, active_clm_ids[], pending_act_ids[], last_updated_at, notification_prefs_ref.
ClaimDetail — clm_id (CLM-*), status_label_enum, timeline_events[], related_pay_ids[], related_dis_id, sla_display_range, special_claim_type_enum.
ActionCard — act_id (ACT-*), action_type_enum, blocks_pay_ids[], clm_ids[], priority, cta_route, completion_status.
PaymentTracking — pay_id (PAY-*), clm_id, method_enum, status_enum, gross_amount, net_amount, failure_reason_code, tracking_ref.
HouseholdView — account_id, linked_clm_ids[], filter_state, access_scope_enum (claimant/guardian/executor).
StatusConfigConsole — settlement_id, status_mappings[], sla_templates[], notification_triggers[], counsel_approval_ref.

Common mistakes

Mistake	Why it hurts	Fix
Generic “Processing” with no timeline	Anxiety · Call volume	Stage-specific labels + SLA
Hide why payment blocked	Claimants call to ask	ACT-* cards with clear CTAs
Show internal fraud flags	Legal and trust damage	Admin-only status mapping
No unauthenticated lookup	Excludes low-digital users	CLM-* + OTP lookup flow
Full SSN/bank on dashboard	Privacy violation	Mask sensitive fields
Email-only status updates	Missed actions	Portal action cards + alerts
Different timelines per page	Confusion	Single timeline component
No multi-claim support	Duplicate accounts	Household aggregation
Promise exact pay date	Liability when delayed	Show ranges
Stale “last updated”	Distrust	Real-time or daily refresh badge

Recommended workflow

Counsel approves claimant-visible status labels and blocked internal fields before wireframes.
Design dashboard with action cards as primary CTA surface—not timeline alone.
Build claim detail timeline integrating CLM-, PAY-, DIS-*, and special claim overlays.
Add payment tracking states with failure recovery paths to payment wizard.
Design household/multi-claim view with strict access scoping.
Wire admin status config console for label mapping and SLA templates.

FAQ

Can claimants see why a claim was denied?

Only if counsel approves denial reason text · Generic “Not eligible” vs specific reason per order · Always show appeal/dispute path when allowed.

Should the portal show payment amount before approval?

Per settlement order · Some show estimated tier · Some hide until approval · Never show amounts that imply guaranteed payment before approval.

How handle opted-out class members?

Separate lookup result · “You opted out on [date]” · No CLM-* timeline · Link to opt-out confirmation if applicable.

Mobile-first for status portal?

Yes · Most claimants check on phone · Action cards stack vertically · Timeline readable without horizontal scroll.

Integration with final accounting?

When case closes · Dashboard shows closure notice · Download final accounting summary · Disable new claims · Archive read-only.

Next steps

Design breach settlement notice and victim compensation claims UI in Figma — CLM-* filing before status tracking
Design breach settlement payment disbursement and payout tracking UI in Figma — PAY-* execution details
Design breach settlement claims dispute and appeals UI in Figma — DIS-* on claimant timeline
Design breach call center and agent script UI in Figma — Agent view of same status data
Design account dashboard and my account UI in Figma — Generic dashboard patterns

Designing breach settlement claim status portal and claimant dashboard UI in Figma: timeline, action items, and multi-claim tracking