SUNBOUND · ONBOARDING · 2024–2025

Smarter onboarding for caregivers who pay for more than one parent.

Sunbound’s billing assumed one resident per account. But many payers, often adult children, were paying for both parents, and a backend patch that merged their balances caused more confusion than it solved. I redesigned onboarding so one payer can manage several residents clearly, without calling support.

Role: Lead product designer
Partners: Director of Customer Success, customer ops
Users: Family caregivers and other third-party payers
Timeline: Sunbound, 2024–2025
Outcome: Multi-resident accounts, self-serve

One account, two parents

Our primary persona, “Daughter Deb,” manages care for both her parents. She needs separate invoices for reimbursement or taxes, different payment methods per parent, and a way to set it all up without calling support. The platform couldn’t give her any of that.

Digging into the pain

I led a cross-functional onboarding audit with our Director of Customer Success: a customer ops journey workshop plus an analysis of the top monthly support tickets. Three findings:

First-time sign-in confusion was the #2 support issue
Multi-resident payers had no self-serve option at all
Merging balances under a generic “joint resident” hid who owed what

Designing a smarter onboarding flow

One account, separate records: each resident keeps their own balance, history and preferences
Per-resident payment methods
No added friction for the common case: one resident is the same steps as before

The new first-time flow asks whether you manage one resident or several, offers a guided path to add another during setup or later, and adds a resident selector to the dashboard. Invoices, communications and payment records stay separate per resident.

Flexibility without complexity

The part I’m proudest of: the flow is built for adult children, but the same model accommodates case managers, powers of attorney and other third-party payers with no extra paths.

Results

Fewer
onboarding support calls as payers set up on their own
0
backend workarounds left for Customer Success
New
payer types able to adopt the platform

The project changed how the platform models accounts, identity and responsibility, moving it from a brittle one-size-fits-all setup to one that fits how families actually pay.

What I took from it

Support tickets are research. The #2 ticket category pointed straight at a data-model problem, not a UI one. Fixing the model made the interface simple.